High-risk AI systems must log events, but the AI Act says nothing about protecting the logs

What Article 12 actually says

Article 12 of the AI Act, titled 'Record-keeping', requires high-risk AI systems to technically allow for the automatic recording of events, or logs, throughout their lifetime ^[1]. The purpose is traceability: to enable the monitoring of the system in use, to document risk situations and to support follow-up after a system has been placed on the market.

The regulation tells providers what to log. It does not tell them how to store those logs, how to control access to them or how to protect them against tampering or deletion. It is a recording duty, not a security standard.

For high-risk systems under Annex III—covering uses such as biometrics, recruitment, credit scoring of individuals and law enforcement—the requirement applies from 2 December 2027 ^[2]. For systems under Annex I, which are products covered by harmonised legislation such as machinery and medical devices, it applies from 2 August 2028 ^[2].

Why log protection matters anyway

Logs are like receipts. Nobody looks at them until there is a problem, and then they decide who pays. The difference is that a receipt is printed and handed over at the time, whereas a log sits in a database under the control of the organisation that wrote it.

When a decision made by a high-risk AI system is challenged—by an applicant, a supervisor or in court—the log is often the only record of what happened. A log that could have been edited quietly after the fact is easier to question than one that can be shown unchanged.

That question does not go away simply because the law requires the log to exist. Article 12 asks for the recording. Whether the recording holds up as evidence, months or years later, is another matter.

What the regulation leaves open

The delegated regulation on data governance and record-keeping, expected to provide further detail under the AI Act, has not yet been published. Until it is, providers are left to decide for themselves how to secure logs.

Access controls are the foundation: only authorised users should be able to read or write log entries, and every access should itself be logged. Monitoring alerts when something unusual happens. Backups preserve logs if systems fail.

But those measures do not address one thing: a person with the right access, whether an administrator or someone who has gained it improperly, could in principle change a log entry and cover their tracks. The question is how to show, long after the event, that a log is exactly what was written at the time.

How a digital witness fits

Here, the thing to seal is each log record as it is written: the input reference, the model version, the output and, if there was one, the reviewer. Sealing takes a fingerprint of the record, not the record itself, so the content never leaves your systems.

The fingerprint is sent to WitniumChain and sealed in a way that any later change would show, even one made by the organisation keeping the log. To check, anyone you share the record with calculates the fingerprint again and compares it with the sealed one. A match shows the record is unchanged since it was sealed. Change a single character and it will not match.

A sealed log does not show that a decision was right, fair or lawful, or that the log is complete. It shows one thing: that the record existed at a certain time and has not changed since. That is often enough to turn a long argument into a short one.

How it would work

1. Your logging system seals each record as it is written, with one API call that returns a witness ID.
2. If a decision is challenged six months later, you retrieve the sealed record and its witness ID.
3. The person questioning the decision, or an auditor, calculates the fingerprint and checks it against the sealed one, through a verification link.

The first 2,000 witnesses a month are free. Integration takes an afternoon with the REST API, SDK or MCP server.

What this means for you

If you are building or operating a high-risk AI system under Annex III, you have until 2 December 2027 to meet the logging requirement in Article 12. Before that date, ask these questions:

• What events does your system need to log, and in what format?
• Who can access the logs, and is every access itself logged?
• Could you show an auditor or a court that a log entry from six months ago has not been changed?
• If someone with administrator rights edited a log, would it show?

For systems under Annex I, the same questions apply, with a deadline of 2 August 2028.

The regulation asks for the logs. Protecting them is still your decision, but it is a decision worth making early, because by the time someone questions a log, it is too late to seal it.

What to watch

• 2 December 2027: high-risk requirements, including Article 12, apply to Annex III systems.
• 2 August 2028: the same requirements apply to Annex I systems.
• Delegated acts on data governance and record-keeping are expected but not yet published. They may add detail to Article 12, but as of now the article says only that logging must be technically possible, not how logs must be secured.

Until then, the gap between recording an event and proving it happened as recorded is yours to close.