The EU AI Act's High-Risk Rules Slipped to December 2027. Your Logging Problem Did Not Move

The EU AI Act's high-risk obligations did not become enforceable on 2 August 2026. They were deferred, days before the deadline, by Regulation (EU) 2026/1744 — the Digital Omnibus on AI — which was published in the Official Journal on 24 July 2026 and entered into force on 27 July. Stand-alone high-risk systems listed in Annex III now have until 2 December 2027. High-risk AI embedded as a safety component in products already covered by sectoral legislation, under Annex I, has until 2 August 2028.

Something did commence on 2 August 2026. Be precise about what. Article 50 transparency duties went live on schedule: if a person is interacting with an AI system, they must be told, and synthetic content must be marked. The Commission's power to fine providers of general-purpose AI models under Article 101 also switched on that day, and member state market surveillance authorities took up their supervisory role. None of that touches the requirements engineers actually have to build.

So you have roughly fifteen months you did not think you had. The reason to spend them now is that the deferral was granted because the harmonised standards were not ready — CEN-CENELEC work slipped into 2027 — not because the obligations got easier. Article 12 asks for something most organisations running agents cannot produce today.

First, work out whether any of this applies to you

Most readers of this publication are not in scope, and should stop reading after this section. High-risk classification under Article 6 has two doors, and both are narrower than the panic suggests.

Article 6(1) catches AI that is a safety component of, or is itself, a product covered by the EU harmonisation legislation in Annex I — medical devices, machinery, lifts, vehicles — where that product already requires third-party conformity assessment. Article 6(2) catches the Annex III list: biometrics, critical infrastructure management, education, employment and worker management, access to essential public and private services including creditworthiness, law enforcement, migration, and administration of justice.

Then Article 6(3) takes some of them back out. An Annex III system is not high-risk if it poses no significant risk to health, safety or fundamental rights and it only performs a narrow procedural task, improves the result of a previously completed human activity, detects decision-making patterns or deviations without replacing human assessment, or performs a preparatory task. There is one hard carve-out: any system that performs profiling of natural persons stays high-risk, full stop.

The derogation is not self-executing. A provider relying on it must document the assessment before placing the system on the market and register under Article 49(2). The Commission was due to publish guidelines on Article 6 classification, with practical examples, by 2 February 2026. That deadline was missed, which is a live problem for anyone trying to defend a borderline call.

The logging requirement lands where you have no instrumentation

Article 12(1) says a high-risk system must technically allow for the automatic recording of events over the lifetime of the system. Article 12(2) says those logs must be sufficient to identify situations where the system may present a risk or has been substantially modified, to support post-market monitoring, and to support the deployer's own monitoring duty under Article 26(5). Article 19 makes the provider keep the logs for at least six months where they are under its control. Article 26(6) puts the same six-month floor on the deployer.

What the Act does not do is specify fields, formats or schemas. That vagueness is the trap. Most teams read "logging" and point at the application logs they already ship, which record HTTP status codes and model latency. That is not what Article 12(2) describes.

For an agentic system, the risk-relevant events are the tool invocations. Which function the agent called, with what arguments, against which downstream system, on whose authority, with what returned, and whether a human saw it. An agent that queries a customer record, calls an internal scoring API, and writes a decision back to a case management system has performed three consequential acts. If your telemetry captures the prompt and the final completion, you have recorded none of them.

A log that captures the model's answer but not the tool call that fetched the data is not a record of what the system did. It is a record of what the system said.

Integrity matters as much as coverage. The Act does not use the phrase "tamper-proof", but a log's evidentiary value collapses if the service that wrote it could also have rewritten it. Writing in Help Net Security in April 2026, Asqav founder João Marques argued for cryptographic signing with keys held outside the agent's trust boundary, so that alteration becomes detectable rather than merely unlikely. That is a reasonable design position rather than a legal requirement, and Marques runs a company in this space.

Salt Security, an API security vendor with an obvious commercial interest in the framing, argues that the Article 12 and Article 15 perimeter extends to the interfaces through which AI systems act on the world — in practice APIs and MCP servers — and that in a chain of agents the compliance boundary follows every agent performing a high-risk function. The Act text does not name MCP or APIs. But nothing in Article 12(2) confines the recording duty to the model layer either, and post-market monitoring of a system that acts through tools is unintelligible without the tool traffic.

Human oversight is an architecture decision, not a policy document

Article 14 requires that a high-risk system be designed so that a person can effectively oversee it. Paragraph 4 lists what the overseer must be able to do: understand the system's capacities and limitations, monitor for anomalies, stay alert to automation bias, correctly interpret the output, decide not to use the system, and disregard, override or reverse a result. It also requires the ability to halt the system — the text refers to a stop button or a similar procedure that brings the system to a safe state.

Ask what a stop button means for an agent midway through a multi-step workflow with three writes already committed. If the answer is "we kill the container", you have an abort, not a safe state. Compensating actions and transaction boundaries are the engineering work behind that clause, and they are not retrofittable in a quarter.

Article 14(5) adds a specific control for remote biometric identification under Annex III point 1(a): no action may be taken on an identification unless at least two competent persons have separately verified it, with exceptions where EU or national law makes that disproportionate in law enforcement, migration, border control and asylum.

Article 15 is the part your security team already recognises

Article 15 covers accuracy, robustness and cybersecurity. Paragraph 3 requires declared accuracy metrics in the instructions for use — you will need a defensible number, not a vibe. Paragraph 4 requires resilience to errors and faults through redundancy, backup or fail-safe design, and for systems that keep learning after deployment, mitigation of feedback loops that introduce bias.

Paragraph 5 enumerates AI-specific attacks you must prevent, detect, respond to, resolve and control: data poisoning, model poisoning of pre-trained components, adversarial examples and model evasion, and confidentiality attacks. If your threat model for AI systems currently consists of prompt injection and rate limits, that list is your gap analysis.

What to do with the fifteen months

1. Produce a written Article 6 classification for every AI system you operate in or into the EU. Record the reasoning. Where you rely on the Article 6(3) derogation, confirm the system does not profile natural persons — that single fact overrides the derogation.
2. Instrument tool invocations, not just completions. Emit a structured event per tool call carrying caller identity, tool name, arguments, target system, outcome and correlation ID back to the originating session.
3. Write the logs to a store the producing service cannot modify. Append-only, separate credentials, separate retention policy. Six months is the statutory floor under Articles 19 and 26(6), not the target.
4. Test that you can reconstruct a single agent session end to end from storage. Pick a day last month and try. If reconstruction takes an afternoon of manual joins, it will not survive a regulator.
5. Define the safe state for each agent workflow and build the halt path to reach it, including compensating writes.
6. Extend adversarial testing to cover Article 15(5) categories explicitly, including training and fine-tuning data provenance.
7. Stand up serious incident reporting now. Article 73 gives providers 15 days from awareness, 10 days where death is involved, and two days for widespread infringement or disruption of critical infrastructure. Two days is shorter than most existing incident processes assume.

The grandfathering clause will not save an agent platform

Article 111 exempts high-risk systems already placed on the market before the application date, unless those systems undergo significant changes in their design. Systems intended for use by public authorities get no such relief and must comply by 2 August 2030.

Read that against how agentic systems are actually operated. You swap the underlying model, add three tools, change the orchestration graph, adjust the system prompt that governs escalation. The exemption is built for a certified medical imaging device shipped in a fixed configuration. It is not built for a platform that changes every sprint. Any organisation planning to sit on legacy status should assume its first significant model or tool change resets the clock, and should ask now whether it could even prove which configuration was in production on a given Tuesday.