EU AI Act compliance for critical infrastructure: the audit trail for safety-component AI

If your AI is a safety component in road traffic management, water, gas, heating, electricity supply, or critical digital infrastructure, the EU AI Act puts you in scope as high-risk under Annex III, point 2. The full regime is in force for Annex III systems. Some safety components also fall under Annex I sectoral legislation, which phases in on its own schedule but keeps the same obligations intact.

Critical infrastructure is the category where audit trails are not a paperwork exercise. They are the evidence a market-surveillance authority will read after a grid outage, a water-treatment misconfiguration, or a traffic-control incident.

What the audit trail looks like here

Stack the relevant articles together and the file you have to produce is dense.

• - Article 9 — a continuous risk-management system spanning the lifecycle. Identify and analyse known and foreseeable risks, including reasonably foreseeable misuse. Document the testing and the mitigations.
• - Article 11 + Annex IV — technical documentation: intended purpose, system architecture, data sources, accuracy and robustness metrics under the operating conditions you expect (and the ones you do not), the rationale for performance thresholds, human-oversight measures, the post-market monitoring plan, the EU declaration of conformity.
• - Article 12 — automatic event logging across the lifetime of the system.
• - Article 14 — human oversight with a real "stop" capability. The operator must be able to refuse, override, or reverse the system. Automation bias must be designed against, not assumed away.
• - Article 15 — accuracy, robustness, and cybersecurity appropriate to the use. For critical infrastructure, the bar is high enough to warrant its own dossier.
• - Article 17 — a documented quality management system covering testing, validation, data governance, risk management, post-market monitoring, incident reporting, and record-keeping.
• - Article 19 / Article 26(6) — log retention of at least six months. Sector law typically extends this.
• - Article 72 — post-market monitoring system with a written plan.
• - Article 73 — serious-incident reporting. For "serious and irreversible disruption of the management or operation of critical infrastructure," the deadline is two days from awareness.

Two days. That is the timeline. If your team has to assemble a forensic picture from screenshots and Slack threads when a grid event happens, you have already missed the window.

Why "the model is reliable" is not a defence

Critical-infrastructure AI fails the way silent AI always fails. The model returns an answer. The control system executes it. The graph looks normal until it does not. By the time the operator sees the anomaly, the audit trail is the thing that determines whether the next conversation is with the supervisory authority or the public prosecutor.

The Act addresses this directly. The provider must show that the system was designed and tested for the operating conditions it actually meets. The deployer must show that human oversight was real, that input data was relevant and representative, that the logs were preserved. Both must show that the post-market monitoring caught what it should have caught.

The villain is the same villain as in every Annex III industry: Ship and Pray. A successful pilot. An impressive demo. A live deployment. The evaluation set was the data engineering had. The acceptance criteria were "it looks reasonable." There is no documentation of how the model behaves under edge load, under sensor failure, under adversarial input. There is no log of who reviewed the change to the control threshold last month.

A regulator will reject that position. The operator's safety review will reject it too. Critical infrastructure already lives under NIS2, the CER Directive, and sectoral cybersecurity directives that demand documentation; the AI Act adds a layer on top of those rules, not a replacement.

The critical-infrastructure audit-trail checklist

For each AI safety component, you should be able to produce:

1. - Annex IV technical documentation — including accuracy and robustness metrics under the full range of expected operating conditions and under documented edge conditions.
2. - Risk-management dossier under Article 9 — the foreseeable misuses you considered, the mitigations you adopted, the residual risk you accepted, and the basis on which you accepted it.
3. - Quality-management records under Article 17 — the change-control workflow, the testing procedures, the reviewer training, the supplier qualification.
4. - Versioned model, prompt, and configuration files — every change captured with author, date, evaluation result, and approval.
5. - Pre-deployment evaluation reports — including adversarial and edge-case scenarios, signed off by a domain expert with the authority to refuse to ship.
6. - Runtime event logs under Article 12 — sufficient to reconstruct any decision the system took, in real time, after an incident.
7. - Human-oversight records under Article 14 — operator overrides, stop-button activations, escalations.
8. - Post-market monitoring data under Article 72 — drift detection, performance degradation tracking, retraining decisions.
9. - Serious-incident register under Article 73 — with the two-day timer baked into the workflow.

If any one of these is improvised after an incident, the answer to the regulator's questions is already "we did not have this."

Where domain experts have to lead

Article 14 demands oversight by a person with the competence to provide it. In critical infrastructure, that is control-room engineers, safety officers, reliability specialists, cybersecurity leads. They know what the system should do under nominal load. They know what failure modes look like. They know which automation behaviour will surprise the operator at 3 a.m.

Standard AI tooling shuts them out. Evaluation runs in a notebook the safety officer cannot open. Criteria are a YAML the cybersecurity lead never sees. Acceptance is whoever clicks "approve" in a Jira ticket. By the time a control-room engineer is involved, the change has already shipped to a substation that serves 80,000 households.

Lovelaice flips that. The safety officer or the reliability engineer defines the acceptance criteria before the model sees any data — accuracy under load, robustness under sensor degradation, correct refusal behaviour under adversarial input, latency floors, escalation triggers. They evaluate outputs directly through a simple interface, with blind review removing bias from the scoring. Every evaluation is captured. Every configuration version is immutable. Every result is exportable.

When the supervisory authority asks how you know the system performs safely under a specific edge condition, the answer is a report, not a guess.

Retention and reporting windows to design for

• - Annex I sectoral legislation (machinery, equipment, vehicles, lifts, etc.) phases in on a longer schedule than Annex III but applies the same provider obligations.
• - Six months minimum log retention. Sectoral rules typically extend this materially.
• - Ten years retention of Annex IV technical documentation and the EU declaration of conformity.
• - Two days to report a serious incident that seriously disrupts critical-infrastructure operation. 10 days if a person dies or a fundamental-rights infringement is widespread. 15 days otherwise.

Critical infrastructure is the category where audit trails are read in earnest by regulators, journalists, and prosecutors. Speed without proof is risk you cannot insure against. Build the audit trail before the first sensor reading hits production.

Sources

• - Regulation (EU) 2024/1689 — official text (EUR-Lex)
• - Annex III, point 2 — critical infrastructure
• - Annex IV — technical documentation
• - Article 9 — risk management system
• - Article 11 — technical documentation
• - Article 12 — record-keeping
• - Article 14 — human oversight
• - Article 15 — accuracy, robustness and cybersecurity
• - Article 17 — quality management system
• - Article 19 — automatically generated logs
• - Article 72 — post-market monitoring
• - Article 73 — serious-incident reporting
• - Article 99 — penalties

More in this series

The EU AI Act audit-trail series — one article per Annex III high-risk category:

• - Biometrics: remote identification, categorisation, and emotion recognition
• - Education and EdTech: admissions, assessment, and proctoring
• - Credit scoring and insurance: essential financial services
• - Employment and HR: recruitment, ranking, and workforce management
• - Law enforcement: risk assessment, polygraphs, and profiling
• - Migration, asylum, and border control
• - Justice and democratic processes