EU AI Act compliance guide: what it means for the systems you run

What the Act is

The EU AI Act (Regulation (EU) 2024/1689) entered into force in August 2024 and applies in phases over the following years. It regulates AI systems by the risk they pose to health, safety and fundamental rights, not by the technology inside them. A spreadsheet macro and a frontier model are treated the same way if they do the same job in the same context.

That framing matters for how you approach it. Compliance is not a property of a model; it is a property of a use. The same language model can power a minimal-risk writing aid and a high-risk hiring tool, and only the second attracts the heavy obligations.

The four risk tiers

Unacceptable risk systems are prohibited outright: social scoring by public authorities, manipulative techniques that cause harm, certain biometric categorisation and most real-time remote biometric identification in public spaces, among others. These bans applied first.

High-risk systems are permitted but heavily regulated. They fall into two groups: AI used as a safety component in products already covered by EU product legislation (machinery, medical devices, vehicles), and AI used in listed sensitive areas, discussed next.

Limited risk systems carry transparency obligations. People must know they are interacting with AI, and synthetic content must be identifiable as such.

Minimal risk covers everything else, which is most of what businesses deploy. The Act encourages voluntary codes of conduct but imposes no specific duties.

What makes a system high-risk

The Act lists the sensitive areas in an annex. In plain terms, a system is likely to be high-risk if it is used to make or materially influence decisions about people in areas such as:

• Recruitment, promotion, task allocation and monitoring of workers.
• Access to education and vocational training, including assessment and admission.
• Access to essential services: creditworthiness, insurance pricing, public benefits, emergency dispatch.
• Biometric identification and categorisation, and emotion recognition.
• Management of critical infrastructure such as energy, water and transport.
• Law enforcement, migration and border control, and the administration of justice.

There is an important carve-out. A system in a listed area may escape the high-risk label if it performs a narrow procedural task, improves the result of a previously completed human activity, or detects patterns without replacing human assessment. The provider must document that reasoning. "We think it is only an assistant" is not documentation.

Note how often this touches ordinary products. A CV screening tool is high-risk. An HR platform's shift-allocation feature can be. So can a credit-decision model in a fintech app. If you build or buy in these areas, assume high-risk until you have written down why not.

Obligations by role

The Act assigns duties by role in the supply chain. Most businesses are deployers; anyone who builds, substantially modifies or white-labels a system becomes a provider, with much heavier duties.

The trap is role drift. A deployer who fine-tunes a vendor's model, changes its intended purpose or puts their brand on it can become a provider. Keep a record of every modification and check the role each time.

Transparency duties that apply to almost everyone

Even outside the high-risk tier, a few duties will touch most AI products. If people interact with an AI system, they must be told, unless it is obvious from context. Content generated or manipulated by AI must be marked in a machine-readable way where feasible. Deepfakes must be disclosed. Emotion recognition and biometric categorisation require informing the people exposed to them.

For a typical customer support assistant this means a clear label, a route to a human, and no pretending. For content tooling, it means provenance metadata and a policy on disclosure. These are cheap to do early and awkward to retrofit.

General-purpose models and what they mean for you

If you build on a commercial or open-weight foundation model, you are a downstream provider or deployer, not a model provider. The model's provider owes you documentation and information about capabilities and limits. Collect it. It becomes part of your own technical file if your system is high-risk, and it is evidence of due diligence even when it is not. Our model supply chain work covers how to record this.

Penalties

Fines are tiered by the seriousness of the breach, with the highest tier for prohibited practices reaching a substantial percentage of global annual turnover. Enforcement sits with national market-surveillance authorities and, for general-purpose models, with the European Commission's AI Office. As with GDPR, the practical risk for most firms is not the headline fine but a stop order on a product, or a customer's procurement team walking away for lack of documentation.

A practical readiness path

Compliance work scales with how many systems you have in the upper tiers. The path below gets most organisations from "we are not sure what we use" to a defensible position in a few months, and it is the one our EU AI Act readiness engagement follows.

1. Inventory

   List every AI system in use or development, including features inside SaaS products, with owner, purpose and affected people.

2. Classify

   Assign each system a tier and a role, and write down the reasoning, especially for borderline cases.

3. Gap analysis

   For high-risk and transparency systems, compare current practice with the obligations and rank the gaps.

4. Controls and documentation

   Implement oversight, logging, evaluation and disclosure; assemble the technical file and the impact assessment.

5. Operate and monitor

   Review periodically, handle incidents, and re-classify when a system's purpose or role changes.

Much of step four is good engineering you should want anyway: evaluation sets, logging, access control, human review of consequential outputs. Our LLM security checklist and evaluation guide cover the technical side.

Where ISO/IEC 42001 fits

The Act tells you what outcomes to achieve; it does not tell you how to run the organisation that achieves them. ISO/IEC 42001, the AI management-system standard, fills that gap with a structure of policies, roles, risk assessment, controls and continual improvement, the same shape as ISO 27001 for information security. Organisations that already run an ISO 27001 programme find it a natural extension. For everyone else, it is a sensible blueprint for the AI governance the Act assumes you have.

Pitfalls

Key takeaways

• The Act regulates uses, not models; the same model can be minimal-risk in one product and high-risk in another.
• Most business AI is minimal or limited risk; the work is proving it and handling the exceptions properly.
• Hiring, credit, education and essential-services decisions are high-risk by default.
• Deployers have real duties; customising a vendor system can make you a provider.
• Transparency obligations (labelling AI interactions and generated content) touch nearly everyone.
• Start with an inventory, classify with written reasoning, then close gaps with engineering controls.
• ISO/IEC 42001 gives the governance structure the Act assumes.

Related services