What the AI Act asks of your logs

First, the dates

From when

The logging, oversight and retention duties below sit in Chapter III, Sections 2 and 3 (Articles 12, 14, 19 and 26). Regulation (EU) 2026/1744 amended Article 113, which now applies those sections:

2 December 2027

to AI systems that are high-risk under Article 6(2) and Annex III (the list of uses: credit scoring, recruitment, access to essential services and the rest);

2 August 2028

to AI systems that are high-risk under Article 6(1) and Annex I (AI that is, or is a safety component of, a product covered by the EU product legislation listed there).

The Regulation as a whole applies from 2 August 2026, with other exceptions listed in Article 113. A system designed now will still be running in December 2027, so the logging it needs is a design decision today, not a retrofit later.

What the Act asks

Six obligations, in the Act’s words

Article 12(1)

High-risk AI systems “shall technically allow for the automatic recording of events (logs) over the lifetime of the system.” Logging is a property of the system, built in, not a procedure someone remembers to follow.

Article 12(2)

The logs must enable recording of events relevant for identifying situations that may make the system present a risk or amount to a substantial modification, for the provider’s post-market monitoring (Article 72), and for the deployer’s monitoring of its operation (Article 26(5)). That is a test of purpose, not a field list: each event you record should serve one of the three.

Article 12(3)

Only for remote biometric identification (Annex III, point 1(a)) does the Act name fields: the period of each use, the reference database, the input data that led to a match, and who verified the result.

Articles 19 and 26(6)

Providers and deployers keep the logs under their control “for a period appropriate to the intended purpose of the high-risk AI system, of at least six months”, unless other EU or national law, “in particular” on personal data, provides otherwise. Financial institutions keep them as part of the documentation their financial-services law already requires.

Article 14(4)(d)

The people overseeing the system must be able “to decide, in any particular situation, not to use the high-risk AI system or to otherwise disregard, override or reverse the output”. If an override can happen, it is an event worth recording, with who did it and why.

Article 86(1)

A person affected by a decision taken on the basis of an Annex III system’s output can obtain “clear and meaningful explanations of the role of the AI system in the decision-making procedure and the main elements of the decision taken”. You can only explain one decision months later if you recorded that decision, not just the request that led to it.

What it leaves to you

What the Act does not say

It prescribes no format, no schema and no storage. Outside remote biometric identification it names no fields. It does not say logs must be tamper-evident, held by a third party or signed. Six months is a floor, and the GDPR pulls the other way: personal data in a log is personal data, kept no longer than needed.

So the Act asks you to have logs. Whether anyone believes them later, when a supervisor, an auditor or a court asks what the system did in one case, is a different question, and the Act leaves it to you. A log that its own administrators could have edited is your account of events, not evidence of them.

For the engineers

Logs that hold up

1. Record the decision, not just the call

For each decision: the system and its version, a reference to the case (never a name), a digest of the input and the output exactly as they were, the output in words, the role the output played, the decision taken, and whether a person reviewed it. For each oversight action: who (by reference), what they did (confirmed, overrode, reversed, did not use, stopped) and why. That is what Articles 14 and 86 will ask you to show.

2. Keep personal data out of the log where you can

Put references and SHA-256 digests in the log and keep the content in your own store with its own retention. The digest still proves the content later, and the log does not become a second copy of personal data to manage.

3. Make it append-only where you keep it

Write-once storage, or a database that refuses UPDATE and DELETE on the log table by trigger, so a mistake or a bad day cannot rewrite history quietly.

4. Make it evident to people who are not you

Chain the entries by hash or put them in a Merkle tree, then publish the head somewhere you do not control: a time-stamping authority (RFC 3161), independent witnesses, or a public log. Then even your own administrators cannot change an old entry without it showing. This is the part that turns a log into evidence.

5. Check that you can prove an old entry

Pick an entry from six months ago and prove, from what you kept, that it is the one written then. If you cannot do that today, you will not be able to when someone asks.

How to do it

Yourself, or with an existing log

You can do all of the above without us. Open-source transparency-log software such as Trillian or Tessera gives you the Merkle tree; free RFC 3161 authorities will time-stamp a head; write-once object storage covers the rest. It is work, but it is ordinary engineering.

Or keep the records where they are and seal only their salted digests in an existing log. RiskRouter’s recorders are Apache-2.0 and have no dependencies; the record and its salt stay in your journal, and only the digest and a kind are sent. With the AI Act pack’s kinds:

pip install riskrouter-recorder

import os
from riskrouter_recorder import Recorder
recorder = Recorder(api_key=os.environ.get("RISKROUTER_API_KEY"), journal="evidence.jsonl")

recorder.record({"pack": "ai-act", "pack_version": 1, "kind": "ai.decision",
    "record_id": "dec-2026-118305", "system_ref": "credit-scorer", "system_version": "4.2.1",
    "case_ref": "app-552091", "output_summary": "Score 612 of 1000; band C.",
    "role_of_system": "The score set the band; an analyst confirmed it.",
    "decision": "Credit offered at EUR 5 000 at the band C rate.",
    "human_involved": True, "decided_at": "2026-09-26T11:42:10Z"})

Without a key, the recorder keeps the journal and sends nothing, so you can try it locally first. The integration page has the Node version, the logging handler, the decorator and the OpenTelemetry, LangChain and OpenAI Agents adapters; the specification and the offline verifiers show how a receipt is checked without us.