EU AI Act: a practical guide for teams shipping AI agents

This is not legal advice. It is a map built for engineers: which article requires which control, which control generates the evidence an auditor will actually accept, and where the easy wins are. Work with your DPO or counsel on classification and Annex-III determinations.

The three deadlines that belong on your roadmap

The Act staggers obligations across four dates. Three of them are directly relevant to most agent teams today:

• 2 February 2025 — prohibited uses (already in force). Social scoring, manipulative profiling, predictive-policing-style models, and real-time biometric mass surveillance are banned. Most engineering teams do not operate in these zones, but check — especially if your product has a recommender component that could be reframed as behavioural scoring.
• 2 August 2025 — general-purpose AI model obligations (already in force). Providers of GPAI models face technical documentation, downstream cooperation, copyright compliance, and training-data summary obligations. Providers of GPAI models placed on the market before this date have until 2 August 2027 to come into compliance.
• 2 August 2026 — high-risk AI system obligations. This is the deadline most agent teams are building against right now. If your agent falls under Annex III (HR and recruitment, credit scoring, education, critical infrastructure, law enforcement support, biometric ID, migration and border-control decision support, administration of justice, and more), the full Article 9–17 stack — risk management, data governance, technical documentation, transparency, human oversight, accuracy, robustness, cybersecurity, record-keeping — applies.
• 2 August 2027 — high-risk AI embedded in regulated products. For AI systems that are safety components of products already regulated under existing Union legislation (Annex I — medical devices, machinery, in-vitro diagnostics, and others), obligations apply from this date, aligned with conformity-assessment cycles in those product regimes.

What an auditor will ask for

After two dozen conversations with customers preparing for the Act, the pattern is clear. Auditors ask five questions:

1. “Show me the policy that was in force when this decision was made.”
2. “Show me who approved this override, when, and on what basis.”
3. “Show me the audit trail for the last six months, and prove it hasn’t been edited.”
4. “Show me the risk assessment, and show me that it is updated when the agent changes.”
5. “Show me that a human can stop this system within a bounded time.”

If you answer those five questions with evidence, you are in good shape on Articles 9, 12, 14, 17, and 19. The rest is paperwork.

Article-level engineering checklist

The complete mapping lives in our EU AI Act docs page. Below is a condensed engineering view.

Article 9 — risk management

You need a documented, iterative risk management process. In practice: a policy engine that encodes the risks you care about, graduated enforcement modes (monitor → warn → require_approval → block), and an incident workflow. Every enforcement decision must be recorded with a reason.

Article 10 — data governance

Training, validation, and test data must be relevant, representative, and free of errors — with documented provenance. For agents in production, the operational bite is input sanitisation and PII scrubbing at the boundary. If an agent memoises a customer’s email in a retriever and later leaks it via an unrelated session, you have an Article 10 problem.

Article 12 — record-keeping

Logs must be automatically generated and retained long enough for post-market monitoring (Article 19 sets the retention floor). Append-only logs that cannot be edited are a common audit friction point: if a log line can be UPDATEd with a regular SQL statement, an auditor will flag it. Hash-chain the records or enforce append-only at the database level.

Article 13 — transparency

Users interacting with an agent must receive clear information about its capabilities and limitations. For B2B agents this usually means an agent card in the product; for B2C it means a disclosure banner plus an explanation of any automated decision that affects the user.

Article 14 — human oversight

The most operationally demanding article. You need a kill switch that actually stops the agent, an approval workflow that can pause execution mid-chain, and the ability to resume or cancel safely. Budget real engineering for this: approvals tied to identity with bounded expiry, replayability after a pause, and a dashboard that shows what is waiting.

Article 15 — accuracy, robustness, cybersecurity

Prompt-injection scanning, rate limits, circuit breakers, tenant isolation. If you can draw a line around the trust boundary of your agent, enumerate the inputs that cross it, and point to the control that guards each one, you are in good shape.

Articles 17 and 19 — QMS and log retention

Version every policy and every prompt. Keep logs for at least one year; ten for high-risk. Exportable formats an auditor can ingest without bespoke tooling (CSV and JSON are safer than proprietary formats).

Article 26 — deployer obligations

If you deploy rather than develop the model, you still owe monitoring, anomaly detection, and incident reporting to the provider. Most teams forget this one because they think it is the vendor’s job. It is a shared obligation.

The signed-compliance-report pattern

Regulators increasingly expect evidence that a third party can verify without the vendor’s cooperation. The pattern we see working: time-bounded reports that are cryptographically signed (RSA-SHA256 works), shipped with the signature and a publicly-hosted key ID. The regulator can verify offline. You can prove that the report was not modified in transit or retroactively.

Execlave produces these reports as a first-class capability. If you build this yourself, budget a week: the hard part is canonicalising the payload so the signature stays stable as your internal schema evolves.

Eight controls that move the needle first

If you only have time to ship eight things before August 2026, ship these:

1. Every tool call passes through a policy engine with a recorded decision.
2. Every override approval is tied to a human identity and a timestamp.
3. Audit logs are append-only and retained for at least one year.
4. PII is hashed at the boundary, never stored in trace bodies.
5. A kill switch stops any agent within seconds, not minutes.
6. Every released agent has a prompt version, a policy version, a deployment record.
7. Compliance reports are generated on demand and verifiable offline.
8. An SBOM is produced for every SDK release and archived for ten years.

Where to go next

The EU AI Act docs page has the full article-by-article mapping with links to each Execlave capability. If you would rather reason from the policy side, the policy reference lists every policy type and enforcement mode you can use to produce the evidence an auditor expects.

And if you just want a signed EU AI Act report generated from your own agents’ activity, start a trial — the compliance export endpoint ships on every tier.