The AI Act, for people who have to comply with it

The AI Act does not regulate artificial intelligence as such. It regulates putting AI systems on the European market, in the same way the machinery directive regulates putting a machine on it. The obligations attach to a use case, not to a model, and they scale with the risk that use case carries.

The four tiers, in plain terms

Prohibited. A short list including social scoring by public authorities, untargeted scraping of facial images to build recognition databases, emotion inference in workplaces and schools, and certain predictive policing. These are not compliance questions; they are bans.

High risk. The tier that generates the work. It covers AI used in recruitment, credit scoring, education access, essential services, law enforcement, migration, critical infrastructure and as a safety component of a regulated product. Obligations include risk management, data governance, technical documentation, logging, human oversight, accuracy and robustness measures, and conformity assessment before market entry.

Limited risk. Transparency duties. People must be told they are interacting with an AI system, and synthetic media must be machine-readably marked as such.

Minimal risk. Most software. No specific obligations.

General-purpose models sit alongside this with their own duties: technical documentation, a copyright policy, a summary of training data, and for the most capable models additional evaluation and incident reporting.

The three mistakes organisations keep making

Assuming the model provider's compliance covers you. It does not. If you deploy a system in a high-risk context, you carry deployer obligations regardless of who built the model: human oversight, monitoring, keeping logs, informing affected people. A hiring tool built on somebody else's model is your high-risk system.

Confusing risk to the business with risk under the Act. The tiers are about risk to people's rights and safety, not about commercial exposure. An internal tool that quietly filters job applications is high risk. A customer-facing chatbot that answers product questions usually is not.

Starting with the model instead of the inventory. The first deliverable in any compliance project is a list: every AI system in use, what it decides, who it affects, and whether a human can meaningfully override it. Most organisations cannot produce that list, and producing it usually finds two or three systems nobody remembered.

What human oversight has to mean

The requirement is not a person in the loop as a formality. It means someone who can understand the output, has the authority to override it and is not so overloaded that overriding is theoretical. Regulators have signalled that rubber-stamping is not oversight, which makes the staffing question a compliance question.

Does it slow European AI down

The honest answer is that it depends on where you sit. For a company building a recruitment or credit product, the documentation burden is substantial and real. For the large majority of software using AI in minimal-risk ways, the obligations are transparency and little else. The strongest criticism is not the tiers but the uncertainty: standards and guidance arrived slowly, and compliance work had to start before the target was fully drawn.

The counter-argument is worth stating too: most of the high-risk obligations describe what a competent engineering organisation should do anyway. Knowing your training data, logging decisions, measuring accuracy and letting a human override the machine are not exotic requirements.

What to watch

Watch the harmonised standards, because they turn abstract duties into checkable requirements. Watch the first enforcement actions, which will define how strictly human oversight is read. And watch whether other jurisdictions copy the risk-tier structure, which would make it a de facto global framework the way the GDPR became one.