The EU AI Act Explained for Teams Deploying AI Agents

What are the four risk tiers in the EU AI Act?

The four tiers run from banned to barely regulated. Where your AI agent lands decides how much paperwork, testing, and oversight you owe. Most business agents that look up records, draft replies, or run reports sit in the limited or minimal tiers, but the line can move fast if the agent starts making or heavily influencing decisions about people.

• Unacceptable risk (banned): a short list of practices the EU considers a clear threat to people's rights. This covers social scoring by public authorities, manipulative systems that exploit vulnerabilities, untargeted scraping of facial images, and emotion recognition in workplaces and schools. These have been prohibited since February 2025, so they are not a future problem, they are a current one.
• High risk: AI used in sensitive areas such as hiring, credit scoring, education, critical infrastructure, biometrics, and access to essential services. These systems are allowed but carry the heaviest duties: risk management, data governance, logging, technical documentation, human oversight, and a conformity assessment before going to market.
• Limited risk: systems people interact with directly or that generate content, like chat interfaces and AI-written text or media. The main duty here is transparency. Users must be told they are dealing with AI, and synthetic content generally has to be labeled as such.
• Minimal risk: everything else, which is the large majority of AI in use today. Spam filters, recommendation features, and most internal tooling fall here with no specific obligations under the Act, though general good practice still applies.

EU AI Act risk tiers at a glance

Here is how the four tiers compare on what they cover and what they demand. Use it to get a rough read on where a given agent use case might land before you do a formal classification.

What are GPAI obligations under the EU AI Act?

General-purpose AI models get their own rule set because they are reused in so many products downstream. If you build on top of a foundation model rather than training one yourself, most of these duties fall on the model provider, not on you. But you should still know what they are, because they shape what documentation you can expect to receive and rely on.

Every GPAI provider has to keep technical documentation, publish instructions for downstream developers, comply with EU copyright rules, and publish a summary of the data used to train the model. There is a lighter path for free and open-source models that do not pose systemic risk. These baseline rules became applicable on 2 August 2025.

A smaller group of the most capable models carries extra duties for systemic risk. The Act sets a rough trigger at models trained using more than 10^25 floating point operations of compute. Providers above that line have to run model evaluations, do adversarial testing, track and report serious incidents, and meet cybersecurity requirements. For most teams deploying agents, this tier is something your upstream provider handles, but it is good context for why the documentation you get exists at all.

The EU AI Act timeline: key dates from 2024 to 2028

The Act does not switch on all at once. It enters into force, then individual chunks of obligation become applicable on staggered dates. This phasing is deliberate: it gives the most dangerous practices the shortest runway and gives complex high-risk obligations the longest. Below is the sequence as it stands, including the May 2026 Digital Omnibus amendment that pushed the high-risk deadlines later.

A few dates deserve a highlighter. February 2025 already passed, so the banned-practice list is enforceable now. August 2026 is the next big one for most companies: that is when transparency rules, GPAI enforcement, and the financial penalties all come online together. Stand-alone high-risk obligations were deferred to December 2027 by the omnibus amendment, and high-risk AI embedded in regulated products runs to August 2028, but treating these as comfortable deadlines is a mistake, because the controls they require take time to build.

Article 14 and the human-oversight requirement

Article 14 is the part of the Act that maps most directly onto how you should design an agent. It requires that high-risk AI systems be designed so that people can effectively oversee them while they are in use. Oversight is not a vague aspiration in the text, it is a design property the system has to support.

In practice, Article 14 expects a human to be able to understand what the system is doing, monitor it for signs that it is going wrong, decide not to use an output, and intervene or stop the system entirely. The point is to keep a person meaningfully in control of consequential decisions rather than rubber-stamping whatever the model produces. For an agent that takes actions, that means the human needs a real chance to review and halt an action before it lands, not just an after-the-fact log.

This is where the design of your agent and the law line up neatly. If your agent can pause before a sensitive action and ask a person to approve or reject it, you have built the mechanism Article 14 is asking for. Approval steps, clear reasons for each action, and a hard stop are not just nice features, they are the oversight controls a high-risk classification will require you to demonstrate.

A worked example: an agent that updates a customer record

Walk through a concrete case. A support rep is handling a ticket from a customer in Germany who wants their shipping address corrected and a refund processed. The rep asks the AI agent to update the address in the CRM and issue the refund. Two very different actions, two very different risk profiles.

Updating the shipping address is low stakes and reversible. The agent can look up the account, change the field, and log the change. That sits comfortably in the limited or minimal range, with transparency as the main duty: the customer should know an AI was involved if they interact with it directly. Issuing a refund moves money, so it carries more weight. Here the sensible design is to have the agent prepare the refund, then pause and surface an approval card to the rep with the amount and the reason, before anything is committed.

That pause does double duty. It satisfies the Article 14 expectation that a person can intervene before a consequential action, and it gives you a clean audit trail showing who approved what and when. If a regulator or an internal auditor ever asks how oversight works for this agent, the answer is concrete: sensitive actions require a named human to approve them, every approval is logged, and the agent only ever uses the least access it needs to do the job. That last part, least-privilege access, is also what keeps a single over-broad agent from quietly becoming a high-risk system across half your stack.

How heavy are the compliance duties by tier?

Not every tier costs the same to comply with. The chart below gives a directional sense of the relative compliance burden across tiers, so you can budget attention accordingly. The numbers are illustrative, meant to show the shape of the effort, not a precise audit estimate.

The jump from limited to high risk is steep, and that is the gap most teams underestimate. A chat-style agent that only informs people is cheap to comply with. The same agent rewired to screen job applicants or set credit limits crosses into high risk and inherits risk management, data governance, logging, documentation, and oversight duties. Knowing where that line is, for your specific use case, is the single most valuable thing you can do early.

Common mistakes teams make with the EU AI Act

Most compliance trouble comes from a handful of avoidable misreads. These are the patterns that show up again and again when teams first map their agents to the Act.

• Assuming it does not apply because you are not in the EU. The Act follows the user and the affected person, not your headquarters. A US company with EU customers is usually in scope.
• Treating the deferred high-risk dates as relief. The prohibitions are already live, transparency and penalties hit in August 2026, and the high-risk deadlines, though pushed to December 2027 and August 2028 by the omnibus, demand controls that take a long time to build. Planning to the deadline leaves you short.
• Classifying once and forgetting. An agent's risk tier can change the moment you give it a new job. Adding a hiring or credit-decision use case can push a minimal-risk tool straight into high risk.
• Logging actions but not enabling intervention. Article 14 wants a person who can stop an action before it happens, not just read about it afterward. After-the-fact logs alone do not satisfy human oversight.
• Giving the agent broad standing access to everything. Wide permissions make any single agent harder to scope and easier to misclassify upward. Least-privilege access keeps the blast radius, and the compliance surface, small.
• Confusing GPAI duties with your own. If you build on a foundation model, most GPAI obligations rest with the model provider. Do not over-engineer for rules that are not yours, but do collect the documentation the provider is required to give you.

A practical checklist for an agent that touches customer data

If your agent reads, writes, or acts on customer data inside the EU, run through this list before launch and revisit it whenever the agent gets a new capability. It turns the abstract tiers into concrete decisions.

Start by classifying the actual use cases, not the technology. Write down each thing the agent does, decide which tier each one falls into, and flag anything that decides or heavily influences outcomes for people. Then make sure none of your use cases touch the banned list, since that is a hard stop rather than a paperwork item.

Next, build the controls the tier demands. For anything that interacts with people, add a clear disclosure that they are dealing with an AI agent and label any synthetic content it produces. For sensitive or irreversible actions, add an approval step so a named person can review and reject before the action commits. Keep an audit log of every action and every approval, scope the agent to the least access it needs, and keep the technical documentation that explains what the agent does and how oversight works. Onpilot is one platform built around exactly these controls, with approval gates, least-privilege roles, and audit logs as defaults rather than add-ons. Whatever you use, the goal is the same: be able to show, on demand, who approved what, what the agent could access, and how a human stays in control.

A decision framework: when does your agent need the heavy controls?

You do not need full high-risk machinery for every agent. Use a simple test to decide how much governance a given agent actually warrants, and avoid both under-building and over-building.

• Use the full high-risk controls when the agent makes or strongly shapes decisions about people in sensitive areas: hiring, credit, access to services, education, or biometrics. Here you owe risk management, oversight, documentation, and a conformity assessment.
• Use approval gates and audit logs when the agent takes irreversible or money-moving actions, even outside high-risk areas. Refunds, contract changes, and bulk data edits all deserve a human in the loop before they commit.
• Use transparency controls when the agent mainly talks to people or generates content. Disclose that it is AI and label synthetic outputs, and you have met the core limited-risk duty.
• Keep it light when the agent only does internal, low-stakes work like summarizing tickets or drafting internal notes that a person edits. Minimal-risk uses carry no specific obligations, so do not bury them in process they do not need.
• Re-run this test on every new capability. The framework is not a one-time gate, it is something you apply each time the agent's job changes, because a new use case can move the whole system into a heavier tier.

What the penalties look like

The Act has real teeth, and the fines are tiered to match the seriousness of the breach. The headline number is up to 35 million euros or 7 percent of global annual turnover, whichever is higher, for using a prohibited AI practice. Breaching other obligations, such as the high-risk requirements, carries lower but still significant ceilings, and GPAI-specific infringements top out around 15 million euros or 3 percent of global turnover. These penalty provisions come into force alongside the August 2026 wave.

The practical lesson is not to memorize the exact figures, it is to notice what the EU chose to fine most heavily. The biggest penalties attach to banned practices and to systems that affect people without proper oversight. That tells you where to spend your governance effort first: stay well clear of the prohibited list, and make human oversight real for anything consequential. Do those two things and the rest of the Act becomes a documentation exercise rather than an existential risk.