The EU AI Act's obligations for high-risk AI systems become enforceable on August 2, 2026 — now under two months away. Regulation (EU) 2024/1689 is the binding text, and the date for high-risk systems has survived the round of Omnibus simplification negotiations that ran through spring 2026. A conditional delay was floated, but it does not take effect unless and until the Commission formally confirms that the supporting standards and tools are available — and that confirmation has not happened. The planning baseline for any enterprise selling into, or operating in, the EU is still August 2, 2026.
Most large enterprises have spent the run-up building documentation: policies, model cards, risk registers, data-governance memos. Those are necessary. But the requirement most teams have quietly mis-built is the audit trail — and the gap is not how much they log. It is when the log happens relative to the inference.
If your audit architecture records what the model did after it did it, you have built post-hoc logging. The EU AI Act, read at the level of Article 9, asks for something architecturally different.
What "post-hoc" actually means — and why it fails the test
The default enterprise pattern looks like this: an employee or application sends a prompt to an LLM, the model returns a completion, and somewhere downstream a logging service writes a record of the exchange. The record is durable, searchable, maybe even tamper-evident. It is also too late.
By the time a post-hoc log captures a prohibited input — a customer's medical history pasted into a consumer chatbot, a credit-decision prompt that leaks protected-class proxies, a source-code secret sent to an external model — the inference has already run and the data has already left your perimeter. The log is a record of an incident, not a control that prevented one.
This matters because the EU AI Act does not treat logging and control as the same obligation. They are separate articles, and they ask for different things.
Article 9 asks for a continuous control, not a record
Article 9 requires providers of high-risk AI systems to establish, implement, document, and maintain a risk management system. The text is explicit that this is not a one-time artifact: it is "a continuous iterative process planned and run throughout the entire lifecycle of a high-risk AI system, requiring regular systematic review and updating." The system must identify and analyse foreseeable risks, evaluate risks that may emerge in use, and adopt measures to address those risks — not merely to observe them after the fact.
Read that against a post-hoc logging architecture. A log that fires after the completion returns cannot "address" the risk in the run it just recorded. It can only inform the next one. For a single dangerous inference — the data exfiltration, the non-compliant decision — the post-hoc log is structurally incapable of being the risk-management measure Article 9 describes. It is evidence that the measure was absent.
Article 12 ("Record-keeping") requires that high-risk systems technically allow for the automatic recording of events (logs) over the lifetime of the system, to a degree appropriate to the intended purpose. This is the logging obligation — and it is real. But Article 12 is the evidence layer. It is not a substitute for the control layer that Article 9 demands. Satisfying Article 12 with a comprehensive log does not discharge Article 9 if no measure ever intervened.
Article 17 layers a quality management system on top: documented procedures, including for the risk-management and record-keeping processes above. And Article 72 adds post-market monitoring — the obligation to actively collect and review system performance in the field. None of these is satisfied by storage alone. Together they describe an operating capability: detect, decide, and act, continuously, with the evidence to prove you did.
The penalty for getting the high-risk obligations wrong is up to €15 million or 3% of worldwide annual turnover, whichever is higher. That is an order of magnitude beyond the cost of the engineering bug you would otherwise be debugging — and it attaches to the organization operating the system, not only the vendor that built the model.
Pre-submission enforcement vs. post-hoc logging: the architectural difference
The distinction the EU AI Act draws maps cleanly onto two system designs.
Post-hoc logging sits beside or after the inference path. The request goes to the model; the response comes back; a record is written. The logging system is a passive observer. Its latency relative to the inference is, by construction, positive — it always learns about the event after the event. Its only intervention lever is retrospective: alert a human, open a ticket, start an investigation, after the data has moved.
Pre-submission enforcement sits in the inference path, in front of the model call. The request is inspected against policy before it is allowed to complete. A non-compliant prompt — wrong data class, wrong destination model, missing a required control — is blocked, redacted, or routed for human approval before the inference runs. The enforcement decision and the inference are not two events separated by latency; the enforcement is a precondition of the inference. And every decision — allow, block, redact, escalate — is itself logged, so the Article 12 evidence layer is a byproduct of the Article 9 control, not a separate bolt-on.
That second architecture is what Article 9's "continuous iterative process" that "addresses" risk actually looks like in running code. The first is what most enterprises have, and it is the one that produces a beautiful audit trail of exactly the violations it failed to stop.
What "real-time" has to mean for the technical documentation to hold up
Article 11 and Annex IV require technical documentation sufficient for authorities to assess conformity, and Article 14 requires human oversight that lets a person "intervene" in the system's operation. "Intervene" is a present-tense, in-the-loop verb. You cannot intervene in something that has already concluded.
So when a conformity assessment asks how your high-risk system manages risk in operation, the defensible answer is not "we retain six months of logs." It is: "here is the control that evaluates every submission against policy before the model runs, here are the policies, here is what it blocks and redacts, and here is the per-decision record proving it ran on every request." The log is the proof. The pre-submission control is the substance. A documentation package that has only the former describes a system that watches; the Act asks for a system that acts.
Where Containment.AI fits
This is the architecture Containment.AI was built around. Policies are enforced in real time, at the proxy layer and in the browser — before the submission reaches the model, not after the completion returns. A prompt carrying a disallowed data class to an unsanctioned model is blocked or redacted at the boundary; every allow / block / redact / escalate decision is written to a per-policy audit trail that maps to the EU AI Act's record-keeping obligation.
That ordering is the whole point. The block happens before the inference, so the risk is addressed in the run — Article 9, not just Article 12. And because the enforcement decision generates the log, the evidence trail is a record of controls that fired, not a forensic reconstruction of controls that were missing.
It also closes the gap that post-hoc API logging cannot see at all: an employee pasting regulated data into a consumer AI tab in their browser. That path sits outside every API-layer logging product, outside M365 Copilot's view, outside a proxy that only sees sanctioned API calls. Under the EU AI Act, if that activity touches an EU data subject through a high-risk system, the obligation is still yours. Enforcement has to live where the submission happens — the browser and the proxy — to be a control rather than a record.
What to do before August 2
- Audit the ordering of your audit trail. For each in-scope high-risk system, ask one question: does the control fire before the inference, or does the log fire after? If it is after, you have evidence, not enforcement.
- Map your stack to the right articles. Article 12 (logging) is likely covered. Article 9 (a continuous risk-management measure that addresses risk) and Article 14 (in-the-loop human intervention) are where most post-hoc designs fall short.
- Stand up enforcement on your two highest-volume AI paths — typically a sanctioned API and one consumer browser tool — so the control runs on real traffic before the deadline, not after a regulator asks.
- Make the log a byproduct of the control. A per-decision record generated by the enforcement layer is both your Article 9 substance and your Article 12 evidence. Two birds, one architecture.
August 2 is not a documentation deadline. It is the date your AI systems have to behave a certain way in production — and a log that arrives after the inference is the wrong shape for the law that is about to bind.
See how Containment.AI enforces AI policy before the inference runs →
Containment.AI enforces AI governance policies in real time — at the proxy layer and in the browser, before a submission reaches the model — and generates a per-policy audit trail aligned to the EU AI Act's record-keeping and risk-management obligations. Learn more or start free.
Source: Regulation (EU) 2024/1689 of the European Parliament and of the Council of 13 June 2024 laying down harmonised rules on artificial intelligence — EUR-Lex consolidated text. Article references: Art. 9 (risk management system), Art. 11 & Annex IV (technical documentation), Art. 12 (record-keeping/logging), Art. 14 (human oversight), Art. 17 (quality management system), Art. 72 (post-market monitoring).