EU AI Act Compliance for AI Agents: Obligations and a Builder's Checklist (2026)

This is engineering guidance, not legal advice. What applies depends on your system, your role in the supply chain and your use case. Your counsel governs, and should confirm any article reference or deadline before you rely on it.

Almost nobody meets the EU AI Act through a regulator. You meet it through a vendor questionnaire from a German enterprise buyer, three weeks into procurement, asking whether your system is high-risk under Annex III and for your conformity assessment reference. Nobody on your side knows what either means, legal says "we need to scope this," and that costs a month.

The question is narrow: you are shipping an agent, some of your users are in the EU, what do you have to build? Probably less than you fear and more than you have done — and the timeline just moved. The Digital Omnibus on AI, Regulation (EU) 2026/1744, took effect on 27 July 2026 and pushed the main high-risk obligations back substantially. It did not move the transparency obligations most agents trigger, which apply from 2 August 2026.

Are you a provider or a deployer?

The most consequential question here, and the one engineers most often get wrong. Under Article 3, a provider develops an AI system and places it on the market under its own name or trademark; a deployer uses one under its own authority in a professional capacity. Provider obligations are heavier by a wide margin.

The mistake is assuming that because you did not train a model, you are a deployer. That is not the test. If you build an agent on GPT, Claude or Gemini and operate it under your name, you are very likely the provider of that AI system. The model vendor provides the underlying general-purpose AI model — a different role, a different obligation set.

Article 25 sets out how a third party inherits provider status for a high-risk system: you put your name or trademark on one already on the market, absent contractual arrangements otherwise; you make a substantial modification to one; or you modify the intended purpose of a system, including a general-purpose AI system, so that it becomes high-risk.

The third catches agent builders. A general-purpose model is not high-risk. Point it at CV screening and you have modified the intended purpose into an Annex III use case, and you are the provider of a high-risk system. Nobody at the model vendor did that. You did, in a prompt.

Build this: a role determination per system — provider or deployer, upstream model, intended purpose, author, date.

Which tier does your agent land in?

The Act sorts systems into unacceptable, high, limited and minimal risk, and being honest matters: much commentary implies everything is high-risk, and most business-automation agents are not. Prohibited practices under Article 5 — manipulation causing significant harm, exploitation of vulnerabilities, social scoring — have applied since February 2025, and ordinary business agents go nowhere near them.

High risk has two doors. Article 6(1) covers AI as a safety component of products already regulated under Annex I legislation, such as medical devices and machinery. Article 6(2) covers the standalone Annex III uses: biometrics, critical infrastructure, education, employment and worker management, creditworthiness and insurance pricing, law enforcement, migration and justice — so CV ranking, worker performance monitoring and loan scoring all plausibly qualify. If your agent's output materially affects someone's job, education, credit, healthcare access or liberty, assume high-risk until counsel says otherwise.

Article 6(3) is a real derogation: an Annex III system is not high-risk if it poses no significant risk of harm and only performs a narrow procedural task, improves the result of a completed human activity, detects decision patterns without replacing human assessment, or performs a preparatory task. But profiling of natural persons is always high-risk, and claiming the derogation means documenting the assessment and registering the system.

Everything else — internal ops agents, support triage, code assistants, most RAG over your own corpus — is limited or minimal risk: most agent work, and the Article 50 transparency set.

Build this: a tier classification record naming the Annex III point considered and why you did or did not land in it, plus the four-limb analysis if you claim Article 6(3).

The obligations that actually generate engineering work

Transparency: telling people they are talking to an AI

Article 50(1) requires systems that interact directly with people to tell them they are interacting with an AI, unless that is obvious to a reasonably well-informed person. It binds providers, applies from 2 August 2026 with no grace period, and the Commission's July 2026 guidelines require disclosure that is clear and delivered no later than first interaction — terms-of-service boilerplate does not count. Article 50(2) adds machine-readable marking of synthetic audio, image, video and text, with a transition to 2 December 2026 only for systems already on the market. Article 50(4) obliges deployers to disclose deepfakes and AI-generated text on matters of public interest.

Build this: a disclosure in the first agent turn of every channel — web, email, SMS, voice, Slack (voice and email get forgotten) — plus a marking pipeline for generated media and a test per channel.

Human oversight: what a meaningful override actually requires

Article 14(4) is a design specification, not a policy statement: overseers must understand the system's capacities and limits, stay aware of automation bias, correctly interpret output, disregard, override or reverse it, and stop the system safely. For agents this is architectural — one that has already sent the email or issued the refund cannot be overridden, only apologised for. Meaningful override means a human-approval gate in front of consequential tool calls and a reversal path for actions taken without one; if you expose capabilities over MCP, that authorisation boundary is the natural enforcement point, which is much of what our MCP server development work involves. And a confident recommendation next to an "Approve" button is a rubber stamp: make rejection as cheap as approval.

Build this: a tool-permission matrix — every tool auto-approve, human-approve or forbidden, with a reversal path for each auto-approved action. Enforce it in code, not the prompt.

Logging and record-keeping: what is retained and for how long

Article 12 requires high-risk systems to technically allow automatic event recording over their lifetime. Article 19 requires providers to retain those logs for a period appropriate to the intended purpose and at least six months, subject to other law, particularly data protection; Article 26(6) puts a matching duty on deployers. Six months is a floor, and it collides with GDPR minimisation. The useful record reconstructs a decision: input, retrieved context identifiers, model and prompt version, tool calls with arguments and results, output, and who approved what. Application logs are not this — they tell you the service returned 200.

Build this: a structured decision log as a first-class queryable store, with a retention policy and a documented deletion path for personal data — core LLMOps work.

Technical documentation: written while building, not after

Article 11 and Annex IV require documentation demonstrating compliance for high-risk systems: intended purpose, architecture and data requirements, oversight measures, testing and cybersecurity, capabilities and limitations including accuracy for specific groups of persons, foreseeable unintended outcomes, the Article 9 risk management system, and the post-market monitoring plan. Read that as a spec for a document you keep in the repo — reconstructing it eighteen months later from Slack and merged PRs costs several times more, and it will be wrong.

Build this: a SYSTEM_CARD.md mapped to Annex IV headings, reviewed in the PR that changes behaviour. Even if you are not high-risk, buyers ask for it.

Accuracy, robustness and cybersecurity: eval evidence

Article 15 requires appropriate accuracy, robustness and cybersecurity, with accuracy metrics declared in the instructions for use, and names AI-specific attacks explicitly: data poisoning, model poisoning, adversarial examples, model evasion and confidentiality attacks. For agents, prompt injection is the live version of model evasion, and it is not hypothetical when the agent reads untrusted content while holding tool credentials. "We tested it before launch" is not evidence.

Build this: a versioned eval suite in CI with a committed dataset, per-release scores and a threshold blocking deploy on regression, including injection through retrieved documents and tool output.

Data governance where you train or fine-tune

Article 10 applies where high-risk systems are developed with training. Data sets must be relevant, sufficiently representative, and to the best extent possible free of errors and complete for the intended purpose, with documented governance over collection, preparation and labelling, and examination for bias with mitigation. Article 10(5) permits processing special categories of personal data for bias detection only under strict conditions; the Omnibus extended that basis beyond high-risk systems. RAG over your own corpus is not training — but the corpus determines what the agent says, so document its provenance and access controls anyway.

Build this: a datasheet per training, fine-tuning or evaluation set — source, licence, collection method, preprocessing, known gaps, bias examination and result.

GPAI considerations when you build on someone else's model

Article 53 obligations sit on the model provider, not you: technical documentation, information for downstream providers, a copyright policy, and a public summary of training content. Models under free and open-source licences with public weights are exempt from the first two unless they present systemic risk, which Article 51 presumes above 10^25 floating point operations of training compute. Your job is downstream: collect what the provider publishes and feed it into your own documentation. Where their stated limitations conflict with your intended use, that is your risk, not theirs.

Build this: a model register — every production model, version, provider, published documentation, stated limitations, date last checked — plus upstream change monitoring.

A builder's checklist

1. Role determination per system: provider, deployer or both, naming the upstream model provider.
2. Tier classification citing the Annex III point considered, plus the Article 6(3) analysis if you claim the derogation.
3. Documented intended purpose, with a review trigger when it changes.
4. AI disclosure in the first agent turn, in every channel — web, email, SMS, voice, chat.
5. Automated test asserting that disclosure appears in each channel's first response.
6. Machine-readable marking on generated media, plus perceivable labelling where a deployer duty applies.
7. Tool-permission matrix: every tool auto-approve, human-approve or forbidden, enforced in code.
8. Reversal or compensating path for every auto-approved consequential action.
9. Approval UI showing evidence and confidence, with rejection as cheap as approval.
10. Structured decision log: input, retrieval IDs, model and prompt version, tool calls, output, approver.
11. Retention policy for those logs — six months minimum where the duty applies — with a personal-data deletion path.
12. SYSTEM_CARD.md mapped to Annex IV headings, updated in the PR that changes behaviour.
13. Versioned eval suite in CI, committed dataset, per-release scores, deploy blocked on regression.
14. Adversarial evals for prompt injection via retrieved content and tool output, plus permission escalation.
15. Model and prompt version register, with change monitoring on upstream providers.

What this looks like in the codebase

None of this is a compliance product. It is engineering hygiene with a documentation obligation attached.

A system card in the repo. One markdown file per agent, sections matching Annex IV. If a PR changes the prompt, tool set or model version and does not touch the card, that is a review comment.

An eval suite in CI. Committed golden dataset, adversarial cases, per-release scores stored durably. The time series is the point: when a buyer asks how you know the agent got better rather than worse, you show history rather than an assertion.

Structured decision logs, not application logs. One record per agent run, stable versioned schema, in a store separate from your observability stack — which has 30-day retention and was never meant for an auditor.

A documented override path. Not a runbook saying operators can intervene: a named queue, a real UI, and an audit trail of who approved or rejected what.

A model and prompt version register. Prompts in version control, with the running version in every decision log. Most teams cannot answer "what prompt was in production on 14 March," and that is exactly the question you get.

Wiring these in early costs far less than retrofitting under procurement pressure — much of what our agentic AI engagements set up in the first weeks.

FAQ

Does the AI Act apply if we are not established in the EU?

Often yes. Article 2(1)(c) reaches providers and deployers in a third country where the output produced by the AI system is used in the Union. A US company with German customers, or an India-based team whose agent outputs reach EU users, can be in scope without any EU entity. There is no establishment safe harbour and no headcount threshold.

Is our internal-only agent in scope?

Probably, if your staff are in the EU. Using an AI system under your authority in a professional context makes you a deployer; the Article 2 exclusion covers purely personal, non-professional use, which an internal tool is not. Internal use also runs into Annex III point 4 if the agent touches recruitment, task allocation, performance monitoring or promotion — an internal HR agent is a likelier high-risk candidate than most customer-facing products.

What if we just call OpenAI's or Anthropic's API?

That does not make you a deployer. The model vendor is the provider of the general-purpose AI model and carries the Article 53 obligations. If you build a system on that model and put it into service under your own name, you are very likely the provider of that AI system. Calling someone else's API changes who trained the model, not whose product it is.

Do we need a conformity assessment?

Only if your system is high-risk. Limited-risk systems — most business-automation agents — carry the Article 50 transparency obligations and no conformity assessment. If you are high-risk under Annex III, the Chapter III requirements now apply from 2 December 2027, and the route is generally internal control-based assessment with a declaration of conformity and CE marking. Confirm it with counsel.

When do the obligations actually bite?

Prohibitions and AI literacy since February 2025, GPAI model obligations since August 2025. General applicability and Article 50 transparency on 2 August 2026, with the Article 50(2) marking transition to 2 December 2026 available only for systems already on the market. High-risk moved: Annex III to 2 December 2027, Annex I to 2 August 2028. Article 99 sets fine ceilings of up to €35m or 7% of worldwide annual turnover for prohibited practices, €15m or 3% for most other breaches including Article 50, and €7.5m or 1% for supplying incorrect information — generally the higher figure, though for SMEs the lower applies.

What does an enterprise buyer or auditor actually ask for?

Six things: your role determination and risk classification with reasoning; your system card or equivalent documentation; evidence of testing, meaning eval results over time rather than a launch-day screenshot; your logging schema and retention policy; the oversight mechanism and who staffs it; and your model-provider list. Teams that have these answer a questionnaire in two days. Teams that do not spend six weeks, and often lose the deal.

Again: this is engineering guidance, not legal advice. Whether a given obligation applies depends on facts we do not have — your role in the supply chain, the intended purpose, and where outputs are used. Verify every article reference, deadline and penalty figure with your own counsel. The Digital Omnibus changed several dates within the last week, and secondary sources will lag.

If you want a second pair of eyes on the engineering side, we run a short readiness review: we look at your agent architecture, logging, evals and oversight path, and hand back a gap list mapped to the checklist above. A technical review, not a legal opinion, working alongside your counsel.