Article 12, explained: what the AI Act asks of your logs, and what it doesn't

What Article 12 actually says

Article 12 is short. Its first paragraph says high-risk AI systems must technically allow for "the automatic recording of events (logs) over the lifetime of the system" ^[1]. Logging is something the system can do by itself, not something a person adds afterwards.

The second paragraph explains what the logs are for. They should make it possible to record events that help with three things: spotting situations that may lead to the system presenting a risk or being substantially modified, supporting the provider's post-market monitoring, and helping deployers monitor how the system operates ^[1].

The level of detail isn't fixed. Article 12(2) ties it to traceability that suits the system's intended purpose ^[1], which leaves room for judgement, and for disagreement later.

The third paragraph goes further for one group of systems, remote biometric identification under point 1(a) of Annex III. There, the logs must at least record when each use started and ended, which reference database was checked, the input data that led to a match, and who verified the results ^[1].

What it doesn't say

Article 12 doesn't say how logs must be protected. There's nothing in it about guarding logs against tampering, keeping them unalterable or having an independent party hold them ^[1]. Claims that the AI Act demands logs nobody can alter go further than the text.

That doesn't make protection irrelevant. Article 15 requires high-risk systems to be resilient against attempts by unauthorised third parties to alter their use, outputs or performance ^[6]. It doesn't mention logs, though, and it isn't a logging rule.

How long the logs must be kept

Retention sits in two other articles. Article 19 requires providers to keep the automatically generated logs under their control for a period that suits the system's intended purpose, and for at least six months, unless EU or national law, in particular on data protection, says otherwise ^[2]. Article 26(6) sets the same minimum for deployers, the organisations that use the system ^[3]. Financial institutions keep the logs as part of the documentation they already have to keep under financial services law ^[2][3].

Six months is a floor, not a target. A system whose decisions can be challenged years later may need its logs for much longer, within what data protection law allows ^[2].

When it applies, and to whom

The Digital Omnibus, Regulation (EU) 2026/1744, entered into force on 27 July 2026 and moved the dates for high-risk systems ^[5]. The rules for high-risk systems listed in Annex III, which includes AI used in recruitment and in assessing the creditworthiness of individuals, apply from 2 December 2027 ^[4][7]. For AI in products covered by Annex I, such as medical devices, the date is 2 August 2028 ^[4][7].

In practice, the logging capability is the provider's job, because it has to be designed into the system. Deployers keep what the system produces and use it to monitor how the system runs ^[1][3].

Until those dates, most systems aren't covered. Anything built now will probably still be running when they are, though, and logging is far easier to design in than to bolt on.

Why the evidence question doesn't go away

The law asks for the logs. A dispute asks a different question: can these logs be trusted?

Say a candidate is turned down by an AI-assisted screening tool and challenges the decision a year later. The logs show what the system did. The first question in the room will be whether the logs are the same today as they were on the day of the decision.

A log that its own organisation can quietly edit is easier to challenge on the day someone questions a decision. In Sweden, courts evaluate evidence freely and weigh it by how reliable it is ^[8]. Under the EU's new product liability rules, which apply to products placed on the market after 9 December 2026, courts can under certain conditions order a defendant to disclose relevant evidence ^[9]. In finance, DORA's technical standard on ICT risk already requires logs to be protected against tampering, deletion and unauthorised access ^[10].

None of this turns Article 12 into a rule about protecting logs. It does mean that the logs Article 12 asks for will sooner or later be read by someone who wasn't there when they were written.

Where a digital witness fits

A digital witness is one way to make a log provable. A fingerprint of the log is sealed together with a time, while the log itself stays with you. Later, anyone you share it with can calculate the fingerprint again and see whether anything has changed since sealing.

Only the fingerprint needs to leave your systems, which matters when logs contain personal data. A fingerprint that can be linked to a person can still count as personal data, though, so the usual data protection rules apply ^[11].

Two limits are worth stating plainly. A digital witness doesn't make anyone compliant with the AI Act, and it doesn't show that a log is true. It shows that the log hasn't changed since it was sealed.

What this means for you

Five questions are worth asking now, well before December 2027:

1. Which of our AI systems could be high-risk under Annex III?
2. What do they log today, and does that cover the three purposes in Article 12(2)?
3. Who controls the logs, and how long do we keep them?
4. Could we show that a log hasn't changed since it was written?
5. Who would answer if a customer, an auditor or a court asked tomorrow?

What to watch

• 2 December 2026: the transition period ends for marking AI-generated content under Article 50(2), for systems placed on the market before 2 August 2026 ^[4].
• 9 December 2026: the new product liability rules apply to products placed on the market after this date ^[9].
• 2 December 2027: high-risk rules for Annex III systems ^[4].
• 2 August 2028: high-risk rules for Annex I systems ^[4].