When does the EU AI Act apply to AI agents?

The EU AI Act entered into force on August 1, 2024. High-risk AI system obligations — including Article 12 logging, Article 9 risk management, Article 14 human oversight, and Article 26 deployer record-keeping — were originally scheduled to take full effect on August 2, 2026. In May 2026, the Digital Omnibus on AI extended this deadline to December 2027. The extension was granted because the harmonised technical standards that define how to satisfy these obligations (including ISO/IEC DIS 24970 on AI system logging) had not yet been finalised — organisations cannot be expected to conform to standards that do not yet exist. The underlying obligations under Articles 9, 12, 14, and 26 are unchanged. AI agents that perform Annex III functions — credit scoring, insurance pricing, healthcare triage, employment decisions, law enforcement assistance, access to public services — remain classified as high-risk and will be subject to full obligations from December 2027.

Which AI agents are high-risk under the EU AI Act?

AI agents are high-risk under the EU AI Act if they perform functions listed in Annex III. The categories most relevant to agentic AI deployments are: (1) biometric identification and categorisation; (2) management of critical infrastructure; (3) education and vocational training — systems that determine access or evaluate performance; (4) employment and worker management — recruitment, task allocation, performance monitoring, promotion; (5) access to essential services — credit scoring, insurance pricing, benefits eligibility; (6) law enforcement — risk assessment, evidence evaluation; (7) migration, asylum, border control; (8) administration of justice. If an AI agent makes or significantly influences decisions in any of these categories, it is high-risk. The classification is based on what the agent does, not what it is called or how it is marketed.

What does EU AI Act Article 12 require for AI agent logging?

EU AI Act Article 12 requires that high-risk AI systems 'technically allow for the automatic recording of events (logs) over the lifetime of the system.' The logs must enable: (1) identification of situations where the system may present a risk or undergo substantial modification; (2) support for post-market monitoring; (3) monitoring of operational performance. Under Article 26, deployers must retain these logs for at least six months. The operative requirement in Article 12 is that logs enable reconstruction of the sequence of events — not that events are described after the fact, but that the sequence can be independently reconstructed and verified. This requires that the enforcement decisions recorded in the logs were themselves made deterministically before execution, not inferred from outcomes.

What is the difference between a logging obligation and an enforcement evidence obligation?

A logging obligation requires that events are recorded. An enforcement evidence obligation requires that the records prove a specific policy ran for a specific action before it executed. Most application-layer logs satisfy the first: they describe what the AI agent did, usually by recording outputs after they are produced. Article 12's reconstruction requirement implies the second: to reconstruct the sequence of events, you need records that were written at the moment of enforcement — not derived from outcomes. Pre-execution enforcement receipts satisfy this. They are written before the action executes, signed before storage, and can be independently verified without re-running the system. Post-hoc application logs cannot: they were written after execution, may omit failed actions, and cannot be independently verified as reflecting the state at decision time.

What are the penalties for EU AI Act non-compliance for high-risk AI agents?

For violations of obligations applicable to high-risk AI systems — including Article 12 logging, Article 9 risk management, and Article 14 human oversight — the maximum fine is €15 million or 3% of global annual turnover, whichever is higher. For smaller providers and deployers, fines are scaled to the severity of the infringement. Lesser infringements face fines up to €7.5 million or 1.5% of turnover. Regulators can also require organisations to suspend deployment of non-compliant AI systems while they are brought into compliance — which for a production AI agent used in credit decisions or insurance pricing may be operationally significant beyond the financial penalty.

How does sequence enforcement help meet EU AI Act Article 12?

Sequence enforcement produces a pre-execution receipt for every step in an AI agent's workflow — ALLOW, DENY, or HALT — written and signed before the action executes. The receipt chain for a completed sequence is a tamper-evident record that an auditor or regulator can use to reconstruct exactly which steps ran, in which order, which policy ran for each step, which steps were blocked and why, and whether any replay attempts were made. This directly satisfies Article 12's reconstruction requirement: the sequence of events can be independently reconstructed from the receipt chain without re-running the agent or the enforcement gate. DENY receipts — for SEQUENCE_VIOLATION, REPLAY_NONCE, ACTION_NOT_ALLOWED — are as important as ALLOW receipts: they prove the enforcement layer caught violations before execution.

Published 12 May 2026 · Updated 6 June 2026 · AgenticRail

EU AI Act August 2026 — High-Risk Deadline Extended to December 2027

Dec 2027

Deadline extended — Digital Omnibus on AI, May 2026 The EU Commission extended the high-risk AI obligation deadline from August 2, 2026 to December 2027. The extension was granted because harmonised technical standards (including ISO/IEC DIS 24970 on AI system logging) had not been finalised — organisations cannot be expected to conform to standards that don't yet exist. Articles 9, 12, 14, and 26 obligations are unchanged. Only the compliance date moved.

The deadline moved. The requirement didn't. EU AI Act Article 12 still requires logs that enable reconstruction of the sequence of events — and that reconstruction still requires pre-execution enforcement evidence, not post-hoc application logs. The Digital Omnibus on AI bought 18 months. Teams that use that time to build proper enforcement infrastructure will be ahead of the next deadline. Teams that treat it as 18 months to wait will face the same scramble in December 2027 that August 2026 would have caused.

AgenticRail generates pre-execution enforcement receipts — signed before each action, verifiable offline. See the compliance report with full receipt chain.

View compliance report Try the demo →

Which AI agents are high-risk

The EU AI Act classifies AI systems as high-risk based on what they do, not what technology they use. An AI agent is high-risk if it performs functions in any of the Annex III categories. For agentic AI deployments, the most common high-risk categories are:

Annex III high-risk categories — agentic AI deployments most affected

Credit & insurance decisions

Credit scoring, loan approval, insurance pricing, risk assessment, benefits eligibility — any agent that makes or significantly influences financial decisions affecting individuals

Employment & HR

Recruitment screening, CV filtering, job matching, employee performance monitoring, promotion decisions, task allocation at scale

Healthcare triage

Patient prioritisation, diagnostic assistance, treatment recommendation systems, clinical decision support where agent output influences care decisions

Access to public services

Welfare benefit determination, tax assessment, permit processing, government service eligibility — agents used by public authorities to make or support binding decisions

Law enforcement

Risk scoring, evidence evaluation, predictive policing systems, recidivism assessment where agent output influences law enforcement decisions

Education

Admissions decisions, student assessment, examination proctoring systems that determine access to educational opportunities

If your AI agent makes or significantly influences decisions in any of these categories, it is high-risk regardless of what the vendor calls it, how it is integrated, or whether it is the primary system or an assisting layer. The classification follows the function, not the label.

The four articles that matter for agentic AI

Art. 9

Risk management system

What it requires: A documented risk management system covering the entire lifecycle of the high-risk AI system. Identification and analysis of known and foreseeable risks. Estimation and evaluation of risks that may emerge in intended use. Adoption of appropriate risk management measures.

For agentic AI: The OWASP Top 10 for Agentic Applications 2026 (ASI01–ASI10) is the natural reference for Article 9 risk identification. Documentation of which risks each control addresses — and which require compensating measures — is the Article 9 deliverable.

Art. 12

Record-keeping & logging

What it requires: High-risk AI systems must "technically allow for the automatic recording of events (logs) over the lifetime of the system." Logs must enable reconstruction of the sequence of events, identification of risk situations, and support for post-market monitoring.

For agentic AI: The reconstruction requirement is the hard requirement. A log that describes what happened is not sufficient to reconstruct why it was permitted to happen. Pre-execution enforcement receipts — written before each action, signed, immutable — satisfy the reconstruction requirement. Application logs written after execution do not.

Art. 14

Human oversight

What it requires: High-risk AI systems must be designed and developed to allow effective human oversight. Oversight personnel must be able to understand the system's capabilities and limitations, monitor for anomalies, intervene when necessary, and override outputs.

For agentic AI: DENY and HALT receipts are the anomaly detection feed. A deterministic gate that fires DENY on out-of-order steps or disallowed actions gives oversight personnel a structured, real-time signal rather than requiring them to infer anomalies from unstructured output logs.

Art. 26

Deployer obligations

What it requires: Deployers must maintain logs automatically generated by the high-risk AI system for at least six months. They must monitor the system per instructions, report risks to providers, and cooperate with competent authorities on request.

For agentic AI: The six-month retention requirement applies to the enforcement receipts, not just application logs. A receipt chain stored in immutable, append-only storage — R2, S3 with object lock, similar — satisfies the retention and tamper-evidence requirements simultaneously.

The gap most teams will miss: logging vs enforcement evidence

The gap is not about whether logs exist. Most production AI agent deployments have logging. The gap is about what the logs prove.

What most teams will have on August 2, 2026

Application-layer logs describing what the AI agent did: which tools it called, what outputs it produced, what decisions it returned. These logs were written after the actions executed — often by the agent itself or the application layer wrapping it. They may omit failed or aborted actions. They may not record which policy was in effect at the time. They cannot be independently verified without re-running the agent under the same conditions. An auditor reviewing them can confirm that events were recorded. They cannot confirm that a specific policy ran before a specific action was permitted.

What Article 12 reconstruction actually requires

To reconstruct the sequence of events in a way that satisfies an auditor, you need records that answer four questions for each step: (1) What action was attempted? (2) What policy was evaluated? (3) Was the action permitted or blocked — and why? (4) Was this recorded before the action executed?

Questions 1–3 can be addressed by good application logging. Question 4 cannot. Only a pre-execution enforcement gate can write a record before the action executes — because only a gate that sits between the agent's reasoning and the action's execution has the opportunity to record the decision before the execution happens.

What auditors will ask	Application logs	Pre-execution receipts
Which policy ran for this action?	Cannot confirm — policy may have been in effect but is not recorded in most application logs	Receipt records the exact policy evaluated — function, action type, step position
Was this recorded before execution?	No — application logs are written after the action completes or after the process exits	Yes — receipt is written and signed before the gate returns ALLOW to the caller
Were any actions blocked?	Blocked actions may not appear in application logs if execution never started	Every DENY is recorded regardless of whether execution was attempted — the denial is the record
Can the record be verified independently?	Verification requires re-running the system — the log is a description, not a proof	HMAC signature over all fields — verify offline with signing key, no system required
Was the sequence order enforced?	Application logs show what ran — they cannot prove that out-of-order execution was blocked	SEQUENCE_VIOLATION receipts prove out-of-order attempts were blocked before execution

The six-point compliance checklist

EU AI Act compliance checklist — agentic AI deployments

✓

Article 9 — Risk identification document

Documented assessment of known and foreseeable risks for each agentic AI system. OWASP ASI01–ASI10 as the risk taxonomy. Record of which controls address which risks and what residual risk is accepted.

✓

Article 12 — Pre-execution enforcement receipts

Tamper-evident receipts written before each action executes. ALLOW and DENY both recorded. Signed over all fields. Stored in append-only storage for at least six months (Article 26). Independently verifiable without re-running the system.

✓

Article 12 — Sequence reconstruction capability

Ability to reconstruct the full sequence of events for any completed workflow from the receipt chain alone — which steps ran, in which order, which policy ran for each, which attempts were blocked and with what reason code.

✓

Article 14 — Human oversight feed

DENY and HALT decisions surfaced to oversight personnel in real time or near real time. SEQUENCE_VIOLATION and REPLAY_NONCE events are anomaly signals requiring human review. Override and intervention procedures documented.

✗

Article 10 — Training and runtime data governance

Records of training data sources and runtime data access for each high-risk AI system. Personal data processing documentation. This is outside the enforcement gate's scope and requires a separate data governance programme.

✗

Article 13 — Transparency obligations

Pre-interaction disclosure to individuals that they are interacting with a high-risk AI system. Documentation of system capabilities, limitations, and intended purpose available to deployers. User-facing documentation requirement — outside the enforcement gate's scope.

Articles 10 and 13 require controls that sit outside the enforcement layer — data governance, disclosure processes, documentation. No enforcement gate addresses these. The December 2027 extension applies to all six obligations simultaneously — use the time for the full compliance programme, not just the enforcement gate.

What a compliant Article 12 receipt chain looks like

The receipt chain for a completed high-risk AI agent workflow is the Article 12 deliverable. It is a sequence of pre-execution records — one per step — that an auditor can verify independently and use to reconstruct the full enforcement history of the workflow.

Article 12 receipt — sequence: credit-eval-5519d / step 1: identity_check ALLOW

decision ALLOW — all pre-execution conditions passed

policy basis identity_check · VALIDATE_INPUT · step 1 of 5 declared in sequence contract

recorded before identity_check executed — Article 12 reconstruction anchor

hmac sha256:9f2a… — verifiable offline, no system re-run required

Article 12 receipt — sequence: credit-eval-5519d / step attempted: approve_credit DENY

decision DENY — SEQUENCE_VIOLATION

violation approve_credit attempted at step 2. Expected: fraud_check. Steps 2–4 not completed.

recorded before approve_credit executed — credit decision did not proceed

Art. 12 value Proves sequence violation was caught before execution — not discovered post-hoc

An auditor reviewing these two receipts can reconstruct that: step 1 ran and was permitted; step 2 was attempted out of order and blocked before execution; the credit decision never ran. The reconstruction is from the receipts alone — no agent, no system state, no re-execution required.

The penalty structure

€15M

or 3% of global annual turnover Maximum fine for violations of high-risk AI system obligations — Articles 9, 12, 14, 26. Whichever is higher applies.

€7.5M

or 1.5% of global annual turnover Lesser infringements — including incomplete or inadequate logging where the system was otherwise compliant. Whichever is higher applies.

The fine ceiling is not the primary risk for most organizations. The operational risk is suspension: regulators can require that a non-compliant high-risk AI system be taken offline while it is brought into compliance. For an AI agent used in production credit decisions or insurance pricing, suspension is the more significant business impact.

Why the deadline was extended — Digital Omnibus on AI, May 2026

The EU Commission extended the high-risk obligation deadline to December 2027 for one primary reason: the harmonised technical standards that define how to satisfy the obligations don't exist yet. ISO/IEC DIS 24970 (AI system logging and transparency) targets Q4 2026 finalisation. Until a harmonised standard is published and adopted, there is no definitive technical specification for what Article 12 compliant logging looks like in practice. Requiring compliance before the specification exists was recognised as unworkable.

The extension is not a signal that the requirements are weakening — it is a signal that the standards process is catching up. When DIS 24970 is finalised and adopted as a harmonised EU standard, Article 12 compliance will have a concrete technical definition. Organisations building pre-execution enforcement receipt infrastructure now will have documented evidence that predates the standard, not scrambling evidence built under deadline pressure.

Update — June 2026. That standards process has now moved a stage closer. On 28 May 2026, prEN 18229-1 — the CEN/CENELEC standard covering Article 12 logging, Article 13 transparency and Article 14 human oversight — entered its formal Enquiry ballot, the public-comment stage that precedes a final European standard, with publication targeted for Q4 2026. The ISO logging specification, ISO/IEC 24970, is being adopted in parallel into the same committee (CEN/CENELEC JTC 21) as prEN ISO/IEC 24970. Neither standard's published scope yet defines a pre-execution enforcement receipt — the record produced before an action runs, as distinct from the event log written after it. Organisations building that evidence today hold documented prior art that predates the standard rather than waiting for it.

AgenticRail's enforcement gate, receipt generation, and compliance report are production-ready. Pre-execution receipts from day one — the Article 12 evidence trail built in, not bolted on.

Try the demo View compliance report →