On this page
What is the EU AI Act?
The EU AI Act (Regulation 2024/1689) is the world's first comprehensive legal framework for artificial intelligence. It establishes binding rules for AI systems placed on the market or put into service in the European Union, regardless of where the provider is based.
Unlike sector-specific regulations (DORA for financial resilience, GDPR for personal data), the AI Act governs AI systems directly. Its risk-based architecture divides AI systems into four tiers: unacceptable risk (prohibited), high-risk (full compliance obligations), limited risk (transparency requirements only), and minimal risk (no specific obligations).
For most enterprises deploying AI agents in regulated verticals, the operative category is High-Risk. The obligations attached to that classification are substantial, and they are now on an active enforcement clock.
Enforcement deadlines
The AI Act entered into force on August 1, 2024. Obligations have been rolling in since then, with the most consequential deadline approaching for enterprise AI deployments:
The December 2, 2027 deadline is the result of the Digital Omnibus agreement (preliminary agreement May 7, 2026), which extended the original August 2026 Annex III deadline. The path to that agreement was not straightforward, and the obligations themselves were not softened, only delayed.
December 2027 sounds distant. It is not. Building compliant audit infrastructure, classifying systems, completing technical documentation, and registering in the EU database requires six to eighteen months of preparation for most enterprises. The organizations that start in 2027 will be building under enforcement pressure.
Annex III: the 10 high-risk categories
Annex III of the EU AI Act lists the categories of AI systems classified as High-Risk. If your organization deploys AI agents in any of these areas, full compliance obligations apply from December 2, 2027. Use our classification guide to determine where your systems land.
Biometric identification
Real-time or post-hoc remote biometric identification. Emotion recognition in professional contexts.
Critical infrastructure
Safety components in energy grids, water systems, transportation networks. AI agents managing operational decisions in these environments.
Education & vocational training
AI determining access to education, evaluating learning outcomes, assessing students during exams.
Employment
Recruitment and screening. CV filtering. Performance evaluation. Task allocation. Monitoring, promotion, and termination decisions. This is the category most enterprises underestimate.
Essential services
Creditworthiness assessment for private individuals. Risk scoring for credit and insurance decisions. Life insurance and health insurance risk classification.
Law enforcement
Predictive policing. Polygraph-equivalent systems. Evidence reliability assessment.
Migration & border control
Risk assessment for visa and asylum applications. Identity verification at borders.
Justice & democratic processes
AI assisting courts in fact-finding or applying law. Influencing elections.
AI in regulated products
Safety components in machinery, medical devices, vehicles, toys. Covered by Annex I timeline (August 2028).
Critical digital infrastructure
AI systems operating as safety components in networks and information systems subject to NIS-2 obligations.
Category 04 (Employment) and Category 05 (Essential services, credit and insurance) are the categories where AI agent deployments are most common today, and compliance readiness is lowest. An AI agent that screens CVs, allocates tasks based on performance data, or prices insurance risk is almost certainly Annex III, regardless of whether the procurement team described it as an "AI assistant" or an "intelligent workflow tool."
What the Act requires: Art. 12, 14, 26, 49
For High-Risk AI systems, the EU AI Act imposes concrete technical and organizational obligations. The four articles that matter most for enterprises deploying AI agents are these:
Article 12, Logging
High-Risk AI systems must automatically log events throughout the system lifecycle. The requirements are not vague:
- Logging must be automatic, not manually triggered or opt-in
- Logs must enable post-hoc verification of system behavior
- Retention: minimum six months; longer where sectoral law requires it (DORA Article 30 requires two years for financial entities)
- For credit, insurance, and employment decisions: the log must capture sufficient context to reconstruct the decision chain
What most enterprises are missing: Article 12 does not prescribe a specific technical implementation, but a log that can be altered after the fact does not satisfy the regulation's intent. Tamper-evidence is a structural requirement, not a feature you can configure later.
Article 14, Human oversight
High-Risk AI systems must be designed and built so that human operators can effectively monitor the system's operation, detect anomalies, and intervene or override decisions when necessary.
For AI agents, systems that autonomously call tools, retrieve data, and execute multi-step tasks, this requirement has a specific implication: you must be able to reconstruct the full causal chain of any challenged decision. What did the agent retrieve? What was it shown? What did it return, and in what sequence? A log that records only inputs and outputs does not satisfy Article 14.
Article 26, Deployer obligations
This is the article most enterprises have not read carefully enough. Article 26 places obligations on the deployer, the organization putting the AI system into service, not just the provider who built it. Deployers must:
- Implement appropriate technical and organizational measures to ensure use is consistent with the instructions for use
- Designate a point of contact for competent authorities
- Maintain logs generated by the AI system for the duration of operation, including logs they did not generate themselves
- Conduct a fundamental rights impact assessment where required
The key implication: you cannot outsource Article 26 compliance to your LLM provider. The obligation sits with the deploying organization. A log that lives on Anthropic's or OpenAI's infrastructure, signed by their keys, and retrievable only through their console is a vendor report, not an independent audit trail under Article 26.
Article 49, Registration
Before deploying a High-Risk AI system, providers (and in some cases deployers) must register the system in the EU public database. Registration requires technical documentation demonstrating compliance, which means the compliance infrastructure must exist before deployment begins, not after the first audit notice arrives.
Where enterprises fall short
Most enterprises deploying AI agents today have compliance gaps across three structural areas. None of them are hard to understand. All of them are hard to fix retroactively.
Gap 1: Provider-native logs are not an independent audit trail. OpenAI, Anthropic, Azure AI, and Google Vertex all offer usage logging. These logs are useful for operational debugging. They are not what the EU AI Act requires. A log that lives on the provider's infrastructure, signed by the provider's keys, and accessible only through the provider's console is a vendor report. Regulators and courts treat them differently from an independent, cryptographically integrity-verified audit trail captured at the deployer's governance layer.
Gap 2: Application-layer logs can be silently altered. Many teams log at the application level, capturing inputs and outputs in their own database. This is better than nothing. It is not enough. Software-layer logs can be modified by a compromised host, a rogue admin, or an incident response process that cleans up before anyone checks. Without cryptographic integrity at the point of capture, a log cannot prove it has not been altered, which is precisely what a competent authority will ask.
Gap 3: Missing causal context for agent decisions. Article 14's human oversight requirement means you must be able to reconstruct not just what the agent did, but why, the retrieval context, tool calls, intermediate reasoning, and decision sequence that produced a given output. Most logging captures the outer envelope (input prompt, final response) and misses everything in between. For AI agents running multi-step tasks with tool use and retrieval, the middle is where the liability is.
How to build a compliant infrastructure
Achieving EU AI Act compliance for AI agent deployments is a six-step process. The first three can be started immediately, without procuring any new technology.
Step 1, Classify your AI systems against Annex III. Do not assume your AI tools are low-risk because they feel like internal productivity tools. An AI agent that participates in employment decisions, credit processing, insurance pricing, or critical infrastructure operations is almost certainly Annex III. Use the classification guide, and involve legal counsel, not just IT.
Step 2, Audit your current logging infrastructure. For each Annex III system, map your current logging against Articles 12, 14, and 26. The key questions: Is logging automatic, or manually triggered? Is the audit trail cryptographically integrity-verified? Is it architecturally independent of your LLM provider? Does it capture causal context, not just inputs and outputs? Does it cover all providers and all agents, or only some?
Step 3, Assess your shadow AI surface. The agents you know about are not the only agents running on your infrastructure. Shadow AI, models and agents deployed without IT visibility, creates compliance exposure you cannot audit. Any shadow AI system in an Annex III use case is an unregistered, non-compliant High-Risk AI system. Quantifying this exposure is a prerequisite for compliance planning.
Step 4, Implement an independent governance layer. The structural fix for Gaps 1 and 2 is an out-of-band governance proxy, a layer that sits between your agents and every LLM provider, captures tamper-evident logs at the point of every inference call, and does so independently of the providers being logged. This layer needs to be provider-agnostic: your agents use OpenAI today, Anthropic tomorrow, and local models on air-gapped infrastructure next year.
Step 5, Capture causal context, not just I/O. For Article 14 compliance, configure your governance layer to capture the full decision chain: system prompt, retrieval context, tool calls and their results, intermediate model turns, and final response, all as a single, hash-chained record per inference event. This is the causal context a competent authority will request.
Step 6, Complete technical documentation and register. Article 49 requires registration before deployment. The registration package requires technical documentation demonstrating that your logging, oversight, and human intervention capabilities satisfy the regulation. Build the documentation in parallel with the infrastructure, not after it.
December 2, 2027 is 18 months away. Steps 1–3 take weeks. Steps 4–6 take months. The enterprises that start now will have compliant infrastructure before enforcement begins. The ones that wait for regulatory certainty will still be retrofitting when competent authorities begin their first market surveillance reviews.
Frequently asked questions
Does the EU AI Act apply to non-EU companies? +
Is an AI agent automatically High-Risk under Annex III? +
Does my LLM provider's logging satisfy Article 12? +
What is the fine for non-compliance? +
What is the difference between the EU AI Act and DORA for AI agents? +
Does the AI Act apply to open-source AI models? +
What does 'tamper-evident' mean in practice? +
Related resources
These articles and guides go deeper on specific aspects of EU AI Act compliance for AI agent deployments:
How to Classify AI Systems Under EU AI Act
Step-by-step framework for determining if your AI systems are High-Risk under Annex III. With decision tree and worked examples per vertical.
What the EU AI Act Actually Requires for Audit Trails
Why provider-native logs fail, what tamper-evidence means structurally, and what the causal context requirement forces you to capture.
The EU AI Act Is Coming. Regardless of What Brussels Decides.
The timeline from the Digital Omnibus process, the four scenarios, and why planning against postponement is the wrong posture.
DORA and AI Agents: Why Your LLM Provider's Log Doesn't Satisfy Article 30
For financial entities: how DORA Article 30 intersects with EU AI Act obligations, and why the requirements are additive, not overlapping.
AI Governance Checklist: What to Have Before an Audit
The documentation, technical controls, and organizational measures you need in place before a competent authority requests them.
How to Detect Shadow AI in Your Organization
Identifying unauthorized AI agent deployments, the Annex III compliance exposure you cannot audit if you cannot see.
NIST and EU AI Act: Converging on the Same Requirements
NIST AI RMF and the EU AI Act were developed independently. They are converging on identical requirements for traceable identity and tamper-evident records.
KYDE Gateway
The fastest path to EU AI Act–compliant agent infrastructure.
KYDE is a model-agnostic governance proxy that sits between your agents and every LLM provider. It produces tamper-evident, cryptographically signed audit trails for every agent action, capturing causal context, not just inputs and outputs, without touching a single line of agent code. One environment variable. Any provider. Day one.