# EU AI Act August 2026: The High-Risk Deadline Moved to December 2027 > Markdown mirror for AI agents, generated 2026-08-12 from the live page. > Canonical: https://agenticrail.nz/blog/eu-ai-act-agentic-ai-august-2026/ > Site context: https://agenticrail.nz/llms.txt Published 12 May 2026 · Updated 10 August 2026 · AgenticRail # EU AI Act August 2026: The High-Risk Deadline Moved to December 2027 2 Dec 2027 **The August 2026 date did not happen** Under the Digital Omnibus on AI, high-risk obligations for stand-alone Annex III systems were deferred from 2 August 2026 to **2 December 2027**, and to 2 August 2028 for high-risk AI embedded in products regulated under Annex I. The Article 50 transparency rules and the Article 4 AI literacy duty were left where they were. If you had 2 August 2026 in a compliance plan, the date moved and the obligations did not. This note sets out what Article 12 actually says for a non-biometric high-risk system, which is less than most summaries claim; why the concrete minimum list everybody quotes applies only to biometric identification; and the one thing Article 12(2)(a) asks for that a log written after the fact structurally cannot supply. ## What moved, and why The European Commission published the Digital Omnibus proposal on 19 November 2025. The Council and Parliament reached political agreement on 7 May 2026. Obligations for stand-alone Annex III high-risk systems move to 2 December 2027; obligations for high-risk AI embedded in regulated products under Annex I move to 2 August 2028. The stated reason matters more than the date. **The harmonised technical standards that define how to satisfy the obligations did not exist.** An obligation to conform to a specification nobody has finished writing is not an obligation anyone can meet. That gap is now closing. [ISO/IEC 24970](https://www.iso.org/standard/88723.html), the international standard on AI system logging, reached Final Draft International Standard stage on 18 May 2026 and is in its approval ballot. Its European counterpart under CEN/CENELEC JTC 21, *prEN 18229-1* — the AI trustworthiness framework covering logging, transparency and human oversight, supporting Articles 12, 13 and 14 — is at Enquiry stage, and **its public comment period runs to 20 August 2026**. When those publish and are cited in the Official Journal, Article 12 acquires a technical definition it does not currently have. **Which means the eighteen months are not waiting time.** They are the window in which the specification lands and organisations discover whether the evidence they have been generating fits it. ## What Article 12 actually says Most summaries of Article 12 describe a substantial logging specification. The text is shorter than that. Here it is in full for a non-biometric high-risk system. **Article 12(1).** "High-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system." **Article 12(2).** "In order to ensure a level of traceability of the functioning of a high-risk AI system that is appropriate to the intended purpose of the system, logging capabilities shall enable the recording of events relevant for: (a) identifying situations that may result in the high-risk AI system presenting a risk within the meaning of Article 79(1) or in a substantial modification; (b) facilitating the post-market monitoring referred to in Article 72; and (c) monitoring the operation of high-risk AI systems referred to in Article 26(5)." Regulation (EU) 2024/1689, Article 12 That is the whole of it. **Article 12 specifies what the logs must be good for. It does not specify what they must contain.** No field list, no format, no schema, and no retention period — the six months lives in Article 26(6), which is a deployer obligation, not in Article 12 at all. This is why the standards matter so much, and it is worth being honest that a great deal of published guidance fills the silence with detail the Article does not contain. ### The minimum content list applies to biometrics only Article 12(3) does contain a concrete list — period of each use, the reference database checked against, the input data that produced a match, and identification of the natural persons involved in verification. It is the most quoted part of Article 12 and the most often misapplied, because of how the sentence opens. "**For high-risk AI systems referred to in point 1(a) of Annex III**, the logging capabilities shall provide, at a minimum: (a) recording of the period of each use of the system...; (b) the reference database against which input data has been checked by the system; (c) the input data for which the search has led to a match; (d) the identification of the natural persons involved in the verification of the results, as referred to in Article 14(5)." Regulation (EU) 2024/1689, Article 12(3) Annex III point 1(a) is **remote biometric identification**, and it is narrower still than it sounds: the sub-point expressly excludes systems used for biometric *verification* whose sole purpose is confirming that a person is who they claim to be. Unlocking a phone with a face is not in scope; identifying an unknown face against a database is. So that minimum content list does not apply to credit scoring, employment screening, education, healthcare triage, benefits eligibility, or any other Annex III category. If your system is not a remote biometric identification system, Article 12(3) is not your requirement, and a vendor telling you Article 12 obliges you to log the identity of every human verifier has quoted the wrong sub-paragraph. ## Which AI agents are actually high-risk Not all of them, and not all sectors. An agent is high-risk if it performs a function in Annex III, or is a safety component of a product already regulated under Annex I. Annex III has eight categories. These are the ones agentic deployments most often land in. Annex III categories — where agentic deployments commonly sit Essential services — credit & insurance Creditworthiness evaluation and credit scoring — **expressly excluding systems used to detect financial fraud** — plus risk assessment and pricing for life and health insurance Employment & worker management Recruitment, CV filtering, targeted job advertising, promotion and termination decisions, task allocation, performance monitoring Education & vocational training Access and admission decisions, evaluation of learning outcomes, assessing the level of education a person will receive, monitoring for prohibited behaviour during tests Access to public services Eligibility for public assistance benefits and services, emergency call triage, dispatch prioritisation for emergency services Law enforcement Risk assessment of natural persons, evidence reliability evaluation, profiling in the course of detection and investigation Critical infrastructure Safety components in the management and operation of critical digital infrastructure, road traffic, and the supply of water, gas, heating and electricity The remaining two categories are migration, asylum and border control, and administration of justice and democratic processes. **The classification follows the function, not the label** — an agent that materially influences a credit decision is inside the category whether it is sold as a copilot, an assistant, or a workflow tool. ## Where the hard part is: Article 12(2)(a) Of the three purposes in Article 12(2), two are ordinary. Post-market monitoring under (b) and operational monitoring under (c) are both continuous-observation duties, and a competent application log serves them. If someone tells you their logging product is differentiated on (b) or (c), it is not. **(a) is structurally different.** It asks for logs that enable identification of *situations that may result in the system presenting a risk* — and Article 79(1) defines that by reference to risks to the health, safety or fundamental rights of persons. The structural problem A situation in which an AI agent attempted something harmful and **was stopped before it ran** produces no action. No action produces no output. No output produces nothing for a post-hoc log to describe. The most important class of event under Article 12(2)(a) — the risk that materialised and was caught — is precisely the class that leaves no trace in a record written after the fact. This is not a quality difference between logging products. It is a property of *when* a record is created and *who* creates it. A record of a refusal can only be written by whatever did the refusing, at the moment it refused. Anything downstream of the decision never sees the event, because the event is that nothing happened. An enforcement gate that evaluates each step before it executes writes a record either way. Permitted steps produce an ALLOW record; refused steps produce a DENY record carrying the reason. The refusals are the Article 12(2)(a) material, and they exist only because something recorded them at the boundary rather than describing them afterwards. ## What an auditor can and cannot get from each | Question | Application logs | Pre-execution enforcement records | | Which policy was evaluated for this action? | Often absent — the policy may have been in force but is rarely recorded alongside the event | Recorded as part of the decision: function, action type, position in the declared sequence | | When was the record created? | After the action completed, or after the process exits | Constructed and cryptographically signed at the moment of the decision, before the gate returns a permit. The durable write is dispatched at the same moment and completes independently, so storage latency can never delay or block the decision itself. | | Which actions were attempted and refused? | Frequently missing entirely — an action that never executed has no output to log | Every refusal is a record in its own right, with a machine-readable reason code | | Can the record be checked without the operator's cooperation? | No — verification means trusting the system that produced the log, or re-running it | Ed25519 signature over the canonical record, checkable offline against a published public key | | Was the order of steps enforced, or only observed? | Logs show what ran; they cannot show that an out-of-order attempt was prevented | An out-of-order attempt produces its own refusal record, naming the step presented and the reason it was rejected | ## What this does not cover Being precise about this is more useful than a longer list of claims, and there is a lot of compliance-washing in this market to be distinguished from. **No component satisfies the EU AI Act.** Providers and deployers carry obligations; a component is part of how they meet them. An enforcement layer contributes to the record-keeping cluster and nothing else. Where an enforcement record contributes, and where it does not ✓ **Article 12(2)(a) — risk-situation identification** Records of attempted actions that were refused, written at the boundary. The one class of event a post-hoc log structurally cannot hold. ✓ **Article 12(1) — automatic recording** Generated by infrastructure rather than by the application, so the recording is a property of the architecture and not of anyone remembering to instrument a code path. ✓ **Article 26(5) and 26(6) — deployer monitoring and retention** Refusals form a structured monitoring signal rather than anomalies inferred from output. Signed, chained records stay checkable across the six-month minimum and beyond. ✓ **Articles 72 and 11 / Annex IV — post-market monitoring and technical documentation** Enforcement records are monitoring evidence, and a per-sequence report is a documentation artefact that can be produced on request. ✗ **Article 9 — risk management system** Not addressed. A record can evidence that a process ran; it cannot perform the risk assessment. That remains a substantive judgement about your specific system. ✗ **Article 14 — human oversight** Not addressed. A gate can require that a human-gated step was passed and bind whatever token is supplied as evidence. It cannot establish that a person read, understood or meaningfully considered anything. ✗ **Articles 10, 13 and 15 — data governance, transparency, accuracy and robustness** Not addressed. Training data quality, user-facing disclosure, and accuracy and cybersecurity testing require separate programmes and separate evidence. ## The penalty tiers, correctly attributed Breach of the high-risk obligations, Article 12 among them, sits in the Article 99(4) tier: **up to €15 million or 3% of total worldwide annual turnover, whichever is higher.** The €7.5 million / 1% figure that circulates as a lesser logging penalty is **Article 99(5), and it is not about logging at all** — it applies to supplying incorrect, incomplete or misleading information to notified bodies or national competent authorities in reply to a request. Two different wrongs. One detail that is regularly reported backwards: for SMEs and start-ups, each tier is capped at the **lower** of the euro amount and the percentage, not the higher. In practice the ceiling is rarely the operative risk. Market surveillance authorities can require a non-compliant high-risk system to be withdrawn or taken out of service while it is brought into conformity, and for an agent sitting in a live credit or triage pipeline, suspension is the more consequential outcome. ## What to do with the eighteen months The specification is being written now and the obligation starts in December 2027. Both facts point the same way: evidence generated before the standard lands is evidence that exists when the standard arrives, rather than a retrofit under deadline pressure. The narrower point is the one worth acting on. Whatever else your logging does, check whether it can answer this: **for a given attempted action that was blocked, is there a record of the attempt, written by something other than the system that attempted it?** If the answer is no, that is the Article 12(2)(a) gap, and it does not close by adding fields to an application log. AgenticRail is an enforcement gate that produces those records. You can run a sequence against the production gate on the [demo page](https://agenticrail.nz/demo/) and check the resulting receipts yourself at the [public verification tool](https://report.agenticrail.nz/report) — signatures, the exact bytes that were signed, and the published keys to verify them offline without contacting us. Related [Audit Logs for AI Agents: What They Prove and What They Don't →](https://agenticrail.nz/blog/ai-agent-audit-log-best-practices/) [Pre-Action Authorization for AI Agents →](https://agenticrail.nz/blog/pre-action-authorization-ai-agent/) [ISO/IEC 42001 for Agentic AI: The Certification Evidence Gap →](https://agenticrail.nz/blog/iso-42001-agentic-ai/) [EU AI Act vs NIST vs ISO 42001: Side-by-Side Comparison →](https://agenticrail.nz/resources/ai-governance-frameworks-2026/) [Back to AgenticRail](https://agenticrail.nz/) · [API documentation](https://agenticrail.nz/docs/) · [Live demo](https://agenticrail.nz/demo/)