MICKAI
Article · 13 June 2026

The clause most AI logging will fail

The EU AI Act asks high-risk systems to log. The harder, unwritten question is whether your logs are evidence or just a story, and most are built to be edited.

The clause most AI logging will fail
Author
Micky Irons
Published
13 June 2026
Follow Micky Irons
LinkedInX
EU AI ActAI complianceaudit loggingtamper-evident recordspost-quantum cryptography

The clause most AI logging will fail

Read the high-risk record-keeping obligations of the European Union (EU) Artificial Intelligence (AI) Act carefully and you find a quiet sentence that most teams are going to break. Not break loudly, with a missing log or an empty database. Break in the subtle way that only surfaces in a dispute, two years later, when a regulator or an opposing lawyer asks the one question your system was never built to answer. Can you prove this record was not altered after the fact, and can you prove it without asking us to trust you.

That is the clause. Article 12 of the Act requires high-risk AI systems to keep automatic logs over their lifetime, and the surrounding obligations require providers and deployers to retain those logs and hand them over for oversight. Everyone reads the first half. The system must log. Almost nobody engineers for the second half, which is implicit but unavoidable once you think like an investigator. A log that proves nothing is not a record. It is a story, and stories can be edited.

Logging is not the same as proof

Here is the uncomfortable truth from the security world. Almost every logging stack in production today is built for debugging and observability, not for evidence. The logs flow into a search index or an object store. They are mutable by anyone with the right credentials. They sit in the same trust domain as the application that produced them, often under the same administrator, often with retention controlled by the same people who would be embarrassed by what the logs contain. We have spent a decade optimising logs to be cheap, queryable, and disposable. The Act asks for something that is none of those things. It asks for records that survive an adversary who has every reason to change them.

Think about who that adversary is. It is not only the outside attacker. It is the rushed engineer who deletes an awkward week to make a dashboard look clean. It is the insider with database access and a motive. It is, in the eyes of a regulator, the provider itself. When a high-risk system causes harm, the operator is no longer a neutral narrator. They have an interest in the record reading a particular way. A logging design that cannot defend its own integrity against the people who run it is not compliant in spirit, whatever the retention policy says. It simply has not been tested yet.

The standard answers do not hold up. Write once read many storage stops casual deletion but not a privileged rewrite at the layer above it. A managed security information and event management (SIEM) platform centralises logs and then asks you to trust the platform, which is the very assumption under audit. Database checksums detect corruption, not motivated tampering by someone who can recompute them. Each of these raises the cost of cheating. None of them lets an independent party verify, on their own, that nothing was changed. That gap between deterrence and proof is exactly where the clause will bite.

What tamper-evident actually requires

To satisfy the spirit of the record-keeping obligation you need three properties, and most systems have none of them. First, append-only integrity that is mathematical, not procedural. Each record is hash-chained to the one before it, so removing or editing any entry breaks every link after it, and the break is detectable by anyone, not just by you. Second, signatures created at the moment of the action, not stitched on afterwards. A log written after the decision can be written to suit the decision. A record signed before the action executes commits you to a version of events while the outcome is still unknown. Third, and this is the property almost everyone forgets, independent verifiability. The party checking the record must be able to confirm its integrity using only public mathematics and the records themselves, with no call to your servers and no faith in your good character.

Marble hand pressing a signet ring into a stone tablet carved with an unbroken chain of links, lit by a thin gold rim light on void black.
A record signed before the action commits you to a version of events while the outcome is still unknown.

That last property is the line between a real record and a convincing one. If verifying my logs requires running my software, querying my database, or believing my dashboard, then I am still the single source of truth about my own conduct. An auditor who has to trust the audited has not audited anything. The whole point of evidence is that it speaks for itself in a room where nobody trusts anyone. Build for that room, not for the friendly review where everyone assumes good faith, because the friendly review is not the one that ends in liability.

The post-quantum footnote that is really a headline

There is a second timer running underneath all of this. The signatures that make a record tamper-evident depend on cryptography, and the classical schemes most systems use are on a migration path away from quantum-vulnerable algorithms. A high-risk AI log is meant to last the lifetime of the system, which can be a decade or more. A signature scheme expected to weaken within that window is not a sound foundation for evidence you are legally required to keep. If the proof can be forged before the obligation expires, the proof was never proof.

This is why standards bodies have published post-quantum signature standards, including the United States National Institute of Standards and Technology (NIST) standard for lattice-based digital signatures, the Federal Information Processing Standards Publication 204 (FIPS 204), which specifies the Module-Lattice Digital Signature Algorithm (ML-DSA). If you are building a record meant to outlive the next cryptographic era, you build it on those foundations now, not after the migration becomes a fire drill. The regulator will not accept that your proof expired before your obligation did, and the attacker who copies your archive today and breaks it later does not need your permission.

Build the record so it does not need you

This is the principle I built Mickai around, and it is the one I would defend to any auditor in any jurisdiction. Mickai is a Sovereign Intelligence Operating System (SIOS), built and in production, and at its core sits the Open Audit Record (OAR). Every AI action across the fifty brains, twenty-five domain and twenty-five operational, on the Poseidon silicon substrate, is signed before it executes, not after. Each entry is hash-chained to the last, append-only, so the record is a single unbroken sequence in which any tampering is visible. The signatures are post-quantum, using the NIST ML-DSA-65 parameter set, so the proof is built to last as long as the obligation. And the whole record verifies offline, in an ordinary browser, with no trust in the vendor. You do not have to believe me. You run the check yourself and the mathematics answers.

A single intact marble Doric column with a visible horizontal fracture in one drum, gold rim light tracing the crack against void black.
Hash-chained and append-only: remove or edit any entry and the break is visible to anyone, not just to you.

For the highest assurance the audit root is anchored externally. Pantheon, our sovereign Layer 1, anchors the OAR root to Bitcoin, so even Mickai cannot quietly rewind history without the discrepancy being visible to the world. That is the difference between a vendor asking to be trusted and a system designed so that trust is unnecessary. It is the same discipline behind the 101 filed UK patent applications, about 2,234 claims, owned by Mickai LTD: the architecture is written down, and it is meant to be checked. The Act does not use these words. But when the dispute comes and the question is finally asked, prove this was not altered, those are the words that decide it.

The question to ask before August

High-risk obligations under the Act phase in through 2026, and the gap between a passing audit and a failing one will rarely be whether you logged. Everyone logs. It will be whether your logs constitute evidence. So ask your team one question, plainly, before a regulator does. If we were accused of altering our own AI records, could an outsider prove we did not, using nothing but the records and public mathematics.

If the honest answer is no, you do not have a record-keeping system. You have a story, and you are betting your liability on nobody ever doubting the narrator. The clause most AI logging will fail is not the one that asks you to write things down. It is the one that asks you to prove you did not change them. Build for that question now, because the day it is asked is the day it is too late to start.

Subscribe
Get every new Mickai article by email.

Long-form essays on sovereign AI from Micky Irons. One email per article. No tracking, no marketing, no third parties. Every email includes a one-click unsubscribe link.

Prefer RSS? Subscribe at /articles/feed.xml.

Originally published at https://mickai.co.uk/articles/the-clause-most-ai-logging-will-fail. If you operate in a regulated sector or want sovereign AI on your own hardware, the audit form on mickai.co.uk is the entry point.
More articles