EU AI Act Article 12 & 19 logging, explained

What Article 12 actually requires

Article 12 of the EU AI Act (Regulation 2024/1689) is short and concrete: a high-risk AI system must technically allow for the automatic recording of events — "logs" — over the lifetime of the system. "Automatic" is the operative word. You cannot satisfy it with a wiki page someone updates by hand; the system itself has to emit the record.

Those logs exist to make three things possible (Article 12(2)):

• identifying situations where the system may present a risk or undergo a substantial modification;
• facilitating post-market monitoring (Article 72);
• monitoring the operation of the system as a deployer (Article 26(5)).

For remote biometric identification there is an explicit minimum (Article 12(3)): the period of each use, the reference database, the input data that produced a match, and who verified the result. Most LLM features are not biometric, but the principle generalises — log enough to reconstruct what happened, not merely that something happened.

What Article 19 adds: keep them

Article 12 says generate the logs; Article 19 says keep them. Providers must retain the automatically generated logs "to the extent [they] are under [their] control … for a period appropriate to the intended purpose of the high-risk AI system, of at least six months", unless other law says otherwise. Deployers inherit a parallel duty under Article 26.

Six months is a floor, not a target. A recruitment or credit-scoring model whose decisions can be contested years later needs a retention horizon that matches the dispute window, not the minimum.

What this is not: Article 15

A common mix-up: record-keeping is not Article 15. Article 15 covers accuracy, robustness and cybersecurity — including resilience against attempts to alter a system's use, outputs or performance (15(5)). Your prompt-injection defences and the property "the logs cannot be silently rewritten" map to Article 15's cybersecurity duty. The existence and retention of the audit trail is Articles 12 and 19. Keep the two straight in your technical documentation, because an auditor will.

The deadline moved — the demand did not

In late 2025 the Commission's "Digital Omnibus" proposed postponing the high-risk obligations for Annex III systems. Negotiators reached a provisional agreement in May 2026 and Parliament endorsed it in June 2026; pending formal adoption, the new date for stand-alone Annex III high-risk systems is 2 December 2027. This is a delay of application, not a repeal — and it says nothing about your customers. A regulated buyer running a vendor questionnaire will ask what you log, and how you would prove it, long before any deadline compels you.

What a defensible LLM audit log looks like

Translating the articles into engineering, a log you can stand behind is:

• Per call, automatic — emitted on the request path, not reconstructed later.
• Metadata-first — you rarely need raw prompts and completions to be useful: timestamps, the model and configuration in effect, shield verdicts, token counts, a data classification. Storing less is also good GDPR hygiene.
• Retained on a schedule — at least six months; longer where a decision can be contested.
• Exportable — a regulator or auditor should get a structured, readable export in reasonable time.
• Independently verifiable — the part most stacks miss.

The trust gap most logs have

Here is the uncomfortable bit. In most production AI stacks the audit record is written by the same application that runs the model. The application that can write the log can also rewrite it. So when a regulator asks "can you prove this record was not edited after the fact?", access controls alone are not an answer — a compromised or motivated insider sits inside the trust boundary.

The fix is cryptographic, not procedural: chain each record to the previous one with a hash so any change is detectable, and anchor the chain's head to an independent timestamp so you cannot silently backdate history. That is the difference between a log you ask people to trust and a log they can verify. We wrote a separate piece on exactly how: tamper-evident vs tamper-proof.

See it — do not take our word for it

You can verify a real (synthetic) Senthex audit bundle yourself: recompute the hash chain in your browser, change one byte, and watch the check fail. One honest note — Senthex's verifiable, tamper-evident chain (with the RFC 3161 anchor and offline verifier) is a pilot capability; the published release does metadata logging. We will always tell you which is which.

Sources: EU AI Act Article 12, Article 19. This is not legal advice.