EU AI Act compliance for enterprise AI agents: what the Act requires, and what to build

TL;DR

• The EU AI Act became generally applicable on 2 August 2026, and its obligations for the high-risk uses that most enterprise agents fall under (Annex III) apply from 2 December 2027. The clock is running, but the deadline for high-risk agents is not yet here - which makes now the cheap time to build for it.
• An enterprise agent is likely high-risk when it influences consequential decisions about people: access to a service, credit or insurance, hiring, or worker management. A bot answering published-doc FAQs usually isn't. Article 6 and Annex III draw the line.
• The Act's core high-risk obligations - risk management (Art 9), technical documentation (Art 11), transparency (Art 13), human oversight (Art 14), and accuracy and robustness (Art 15) - aren't a paperwork exercise. Each maps to an engineering capability a well-built agent already needs.
• The penalties are tiered: up to €35M or 7% of global turnover for the banned practices in Article 5, and up to €15M or 3% for breaching the high-risk obligations above. Either way, retrofitting oversight and audit onto a live agent costs more than designing them in.

EU AI Act compliance, for an enterprise running AI agents, means meeting the obligations the Act places on high-risk systems: a documented risk assessment, human oversight, transparency, technical documentation, and demonstrable accuracy - and being able to prove each one. For most agents the practical work is architectural, not legal.

Which enterprise AI agents count as high-risk?

Under the EU AI Act, an AI system is high-risk in one of two ways (Article 6): it's a safety component of a product already regulated under EU law (Annex I), or it's used in one of the sensitive areas listed in Annex III. For enterprise AI agents, Annex III is the one that bites. The categories that most often catch enterprise deployments:

• Access to essential services - agents that decide or materially influence eligibility for credit, insurance, or public benefits.
• Employment and worker management - agents that screen candidates, evaluate performance, or allocate tasks.
• Critical infrastructure and safety - agents embedded in the operation of systems where a failure carries physical risk.

Not every agent qualifies. An agent that answers questions from published documentation, with no access to personal data and no consequential decision, is unlikely to be high-risk. But the moment an agent reasons over personal data and shapes a decision that affects someone's rights or livelihood, assume it's in scope until a documented assessment says otherwise - Article 6 even requires you to write that assessment down.

The five high-risk obligations, and when they land

For a high-risk system, the Act sets requirements on both the provider and the deployer. Five of them apply most directly to how you build and run an enterprise agent. The Annex III obligations become enforceable on 2 December 2027; the transparency duties in Article 50 (telling people they're dealing with AI) already apply as of 2 August 2026.

1. Risk management (Article 9). A risk management system that runs across the whole lifecycle - identify the risks, mitigate what you can by design, and keep reviewing. For an agent, that means monitoring its behavior continuously and being able to pull it back when it acts outside its parameters. It's ongoing, not a one-time sign-off.
2. Technical documentation (Article 11). Before the system goes live, you document how it's built and how it behaves, and you keep that current (the elements are spelled out in Annex IV). For an agent, the honest version of this is a record of the full chain: what it read, how it reasoned, which tools it invoked, what it did.
3. Transparency (Article 13). Deployers must be able to interpret the system's output and use it correctly - which means clear information on accuracy, limitations, and the logging the system produces. For an agent, transparency is a legible audit trail, not a model card no one reads.
4. Human oversight (Article 14). The system has to be designed so a person can understand it, monitor it, and step in - including stopping or overriding it. For an agent, that's an approval gate on consequential actions: before it issues a refund, changes a record, or grants access, a human can intervene.
5. Accuracy and robustness (Article 15). The system must be accurate enough for its purpose and resilient to errors and misuse. For an agent, accuracy starts with what it's allowed to read - reasoning over authorized, current data rather than a stale cache or an over-broad memory. Governed access is an accuracy requirement, not just a security one.

None of these is exotic. They describe an agent you'd want to run in production anyway.

Mapping the obligations to architecture

Read the Act as a spec and each obligation resolves to a capability you either have or you don't. Compliance stops being a legal overlay and becomes a set of build decisions.

Computer, by DevRev implements these through Safe Actions, the pillar that governs what an agent can do. Consequential actions pause for human-in-the-loop approval, so Article 14 oversight is a property of the runtime rather than a policy on a wiki.

Every action lands in an immutable audit trail that names the agent and the person it acted for - the record Articles 11 and 13 ask for. Actions can be reversed and behavior watched continuously, which is what Article 9 means by managing risk across the lifecycle.

And permissions are enforced at the data layer, so the agent reasons only over authorized, current data - the accuracy footing Article 15 requires.

For the monitoring side, see AI agent observability; for how access is enforced beneath the agent, AI access control; and for the broader program around it, AI governance.

This is also where the Act meets the standards teams already use. A risk management system under Article 9 sits comfortably inside an ISO/IEC 42001 AI management system or the NIST AI Risk Management Framework; the personal-data duties overlap with GDPR; and Annex III deployers may owe a fundamental-rights impact assessment (FRIA) on top of the technical file. The architecture that satisfies the Act tends to satisfy those too.

An EU AI Act compliance checklist for enterprise agents

Use this to find the gaps before an auditor does. If an item is "planned, not built," that's the gap.

• [ ] High-risk status assessed and documented for each agent use case (Article 6).
• [ ] Human oversight: approval gates on consequential actions, with a real override.
• [ ] Transparency: a legible, per-interaction audit trail deployers can interpret.
• [ ] Risk management: continuous monitoring plus the ability to roll an action back.
• [ ] Technical documentation: the reasoning-and-tool chain recorded, mapped to Annex IV.
• [ ] Accuracy: the agent reasons only over authorized, current data, enforced at the source.
• [ ] Penalty exposure understood (up to €15M or 3% for high-risk breaches; €35M or 7% for prohibited practices).
• [ ] Timeline mapped: transparency duties live now, Annex III high-risk obligations from 2 December 2027.

Frequently asked questions

What is the EU AI Act, and is it in force?

The EU AI Act is the European Union's risk-based regulation for AI systems. It entered into force on 1 August 2024 and became generally applicable on 2 August 2026, with a phased timeline: prohibited practices from February 2025, general-purpose AI obligations from August 2025, and the obligations for Annex III high-risk systems from 2 December 2027. So it's in force, but the high-risk rules that catch most enterprise agents apply from late 2027.

Does the EU AI Act apply to AI agents?

Yes, when an agent qualifies as high-risk under Article 6 and Annex III - typically because it influences consequential decisions about people or accesses their personal data. It applies based on where the system is used, not where the provider is based: an agent deployed in the EU is in scope regardless of where it was built.

What are the EU AI Act penalties?

They're tiered. Breaching the prohibited-practice rules in Article 5 can cost up to €35 million or 7% of global annual turnover, whichever is higher. Breaching the high-risk obligations (Articles 9 to 15) can cost up to €15 million or 3%. Supplying incorrect information to authorities carries a lower tier still. Fines scale with the severity of the breach and the size of the company.

How is EU AI Act compliance different from AI agent security?

They answer different questions. AI agent security is about defending against attacks - prompt injection, data exfiltration, adversarial misuse. Compliance is about meeting the Act's obligations for authorized operation: oversight, transparency, documentation, and accuracy. You need both, and good access control helps on both fronts, but passing a penetration test is not the same as satisfying Article 14.

Do we need new tooling, or does existing governance cover it?

If your agents already run with approval gates, an audit trail, monitoring with rollback, and permissions enforced at the data layer, you have most of what the high-risk obligations require - the work is documenting it and mapping it to the articles. If those capabilities are bolted on after the fact, that's where compliance gets expensive. The Act rewards systems that were designed with oversight and traceability from the start.

Before December 2027

The EU AI Act doesn't ask you to invent anything an enterprise agent shouldn't already have. It asks whether oversight, transparency, documentation, and governed data were built in - or whether they're a retrofit you're scrambling to add before the deadline.

The gap between those two states is roughly two years of engineering, and it closes cheaper now than under audit. Answer the design question honestly for each agent and the compliance work becomes a mapping exercise instead of a rebuild.

To see oversight and an audit trail enforced in the runtime rather than promised in a policy, explore Agent Studio, or bring a high-risk workflow to a walkthrough and watch the approval gate hold.