Read Closely: The European Union AI Act's Record-Keeping Articles Are an Evidence Standard, Not a Logging One

A logging requirement is not a logging feature

Open the European Union Artificial Intelligence Act (EU AI Act) to the parts almost nobody quotes at conferences, and you find something quietly radical. Article 12 requires high-risk artificial intelligence (AI) systems to keep automatic records of events, the logs, over the system's lifetime. Article 19 requires providers to keep those logs and make them available. Article 26 pushes the same duty onto deployers, the organisations actually running the system. The headlines went to bans on social scoring and to the penalties, which can reach a substantial share of global turnover. The record-keeping articles got read as plumbing. They are not plumbing. They are the part of the law that decides whether any of the rest of it can be enforced. And read closely, they describe a property that the logging stacks most companies already own do not have.

I am Micky Irons. I founded Mickai and I run it. I am going to take the record-keeping obligations seriously, line by line, the way a security person reads a contract rather than the way a marketer reads a press release. My claim is simple and a little contrarian. The high-risk obligations that bite from August 2026 are not going to be failed by companies who forgot to log. They are going to be failed by companies who logged everything, confidently, into systems that cannot prove what the log said yesterday. The gap is not effort. The gap is the kind of record.

What Article 12 actually asks for

Article 12 says high-risk systems must technically allow for the automatic recording of events, the logs, over the lifetime of the system. It then names what those logs are for. They must enable the identification of situations that may result in the system presenting a risk, support post-market monitoring, and, for certain biometric systems, record the period of each use, the reference database checked, the input data, and the natural persons involved in verifying the results. The recital language around it talks about traceability, and about logs being appropriate to the intended purpose of the system.

Notice the verbs. Identify. Support monitoring. Record. These are not asking for a stream of console output. They are asking for a record that can be returned to, after the fact, possibly long after the fact, and used to reconstruct what the system did and why a particular decision happened. The lifetime of the system is the operative phrase. A log that exists while the service is running but that nobody can vouch for two years later does not satisfy a lifetime traceability obligation. It satisfies an operations dashboard, which is a different thing wearing the same word.

There is a second quiet word in Article 12: automatic. The recording has to be a property of the system, not a discipline imposed on the people running it. A process where an engineer is supposed to remember to capture the right events is exactly the kind of arrangement the word automatic is written to exclude. If a human can choose not to log, the log is not automatic, and a regulator reading the article closely will say so. The obligation is structural. It asks for a system that records because of how it is built, not because the people operating it were conscientious that day.

The articles that turn a log into evidence

Article 12 rarely travels alone. Article 19 requires providers to keep the automatically generated logs, for a period appropriate to the intended purpose and at least six months unless other applicable law says otherwise, and to keep them under the provider's control. Article 26 makes deployers keep the logs they control too. Article 18 requires the technical documentation to be kept for ten years after the system is placed on the market. And Annex IV, the technical documentation annex, expects you to describe the logging capabilities themselves, so the description of how you record becomes part of the record.

Stack those together and the obligation changes shape. It is no longer record events. It is keep records, under your control, for years, such that a market surveillance authority can ask for them and you can produce them in a form that means something. That is an evidentiary standard, not a telemetry standard. And evidence has a property that telemetry does not care about at all: it has to be trustworthy to a party who does not trust you. The market surveillance authority is not your colleague. They are the adversary in the room, in the precise and non-hostile sense that they are not going to take your word for it, and the law gives them the standing to demand more than your word.

Why most logging will fail this, concretely

Walk through how logs are produced in a normal modern stack, because the failure is in the mechanics, not in anyone's intentions. An application emits a line. It goes to a collector. The collector ships it to a centralised store, often a managed search index or an object bucket. People with operational access can read it, and a meaningful subset can write to it, reindex it, set retention policies that delete it, or run a bulk operation that rewrites fields. The store is mutable by design, because mutability is what makes it fast and cheap to operate. Every property that makes a logging platform pleasant to run is a property that makes it weak as evidence.

Now ask the question a regulator or a litigator will ask. How do you know this log line is the one the system actually produced at the time, and that it has not been altered, reordered, or quietly dropped since? In the normal stack the honest answer is: because we trust our own access controls and our own people. That is a fine answer for running a service. It is a worthless answer as evidence, because it is precisely the thing in dispute. You are being asked to prove the integrity of your own records using a system you yourself control and can change. The proof is circular, and a circular proof persuades nobody who was not already inclined to believe you.

There are three specific ways the ordinary log fails the close reading. First, mutability: nothing in the store makes after-the-fact editing detectable, so the absence of tampering can never be demonstrated, only asserted. Second, gaps: if the logging is best-effort and a component can fail to emit, you cannot prove a missing record was never there rather than deleted, and an unfalsifiable silence is no defence. Third, the after-the-fact write: the most consequential logs in any incident are the ones written by the system right around the moment something went wrong, and those are exactly the records an interested party would most want to revise. A scheme that logs an action only after it has executed gives you no way to distinguish the genuine record from the convenient one.

The order of operations problem nobody budgets for

Here is the distinction I want to draw sharply, because it is the hinge of the whole argument. There is a difference between recording that a thing happened and committing to what you were about to do before you did it. Almost all logging is the first kind. It is a description, written after the event, by the same system that performed the event. The EU AI Act's traceability goal, taken to its logical end, wants the second kind. It wants a record that constrains the system, not one that merely narrates it after the outcome is already known.

Consider a high-risk credit decisioning system that declines an applicant. An after-the-fact log says: at this time, this model version, these inputs, this score, declined. Useful. But every field in that record was written by the system after it already knew the outcome, and every field is editable by whoever controls the store. If the same record were instead signed before the decision executed, sealing the inputs, the model version, and the policy in force at the moment of action, then the log stops being a description and becomes a commitment. The system has bound itself in advance. You can now check whether what executed matches what was committed. That is the difference between a diary and a contract.

This order of operations is not pedantry. It is the entire reason audit records can be doctored. A record produced after the action, by a party with an interest in the action, is structurally weak no matter how detailed it is. A record produced before the action, signed, and made impossible to alter without detection, is structurally strong even if it is terse. Detail is not the same as trustworthiness. A long, rich, after-the-fact log is still a story told by an interested narrator. The EU AI Act, read closely, is reaching past richness toward trustworthiness, and those are not the same axis.

Retention is a security problem in disguise

Article 19's six-month minimum and Article 18's ten years for documentation introduce a constraint people underestimate. You are not keeping these records for a sprint. You are keeping them across reorganisations, vendor changes, key rotations, staff turnover, and at least one migration of your logging platform. Over that horizon, a second problem arrives that has nothing to do with the EU AI Act and everything to do with cryptography: the move to post-quantum cryptography. The retention clock and the cryptographic clock are running at the same time, and most teams only watch one of them.

The migration to post-quantum cryptography is no longer speculative. The United States National Institute of Standards and Technology (NIST) finalised its first post-quantum standards in 2024, including the Module-Lattice Digital Signature Algorithm (ML-DSA), published as Federal Information Processing Standard 204 (FIPS 204). The guidance from serious bodies is to migrate now, because data and signatures created today must survive an adversary who acquires a cryptographically relevant quantum computer later. A log you are legally required to keep for years is exactly a record whose integrity guarantee must outlive today's cryptography. If your records are signed at all, and most are not, they are usually signed with classical algorithms that have a known expiry. Sign a ten-year record with a signature scheme expected to weaken inside that window and you have built your evidence on a fuse that is already lit.

So the record-keeping articles quietly couple two obligations most teams handle in separate departments: regulatory retention and cryptographic durability. The honest reading is that a compliant high-risk log needs to be both tamper-evident from the moment it is written and tamper-evident for the entire mandated lifetime, which means its integrity scheme has to be post-quantum from the start. Retrofitting that later, across years of accumulated records, is the kind of project that does not happen until a regulator forces it, at which point the old records cannot be retroactively strengthened. You cannot re-sign the past with a better algorithm and have the new signature mean anything about what was true years ago.

Offline verifiability is the part everyone skips

There is one more property the close reading demands, and it is the one I care about most. A market surveillance authority must be able to verify your records without trusting you. Re-read that. Not with your cooperation, not through your portal, not by querying your database with credentials you issue. Without trusting you. If the only way to check a log is to ask the vendor's system to confirm the vendor's records, the verification is theatre. The party being audited controls the instrument of the audit, and a measuring instrument owned by the thing it measures measures nothing.

Genuine verifiability means a third party can take the record, the signature, and the public key, and check the chain themselves, on their own machine, offline, with no live connection to your infrastructure and no software they have to trust you to have written honestly. In an ordinary browser, ideally, using standard cryptographic primitives, so the checker depends on mathematics rather than on your goodwill. This is the property that converts a log from something you assert into something anyone can falsify. A claim that cannot be independently falsified is not evidence, and a compliance regime built on unfalsifiable claims is one bad incident away from collapse, because the first time a record is seriously challenged, an assertion is all you will have to put on the table.

What this means for liability, not just compliance

It is tempting to treat all of this as a box-ticking exercise that ends in August 2026. That underrates where the law is going. AI liability is rising across the European Union and beyond, and liability turns on evidence. When an automated decision causes harm and the dispute reaches a court, the question is not whether you had a logging policy. It is whether you can produce a record of what the system did that the other side cannot plausibly accuse you of having edited. The party with tamper-evident, independently verifiable records is in a completely different position from the party holding a mutable search index and a sworn statement that nobody touched it.

This is the part that should change how engineering leaders budget. Record-keeping that merely satisfies an inspector on a quiet day is a cost. Record-keeping that holds up when someone is actively trying to discredit it is an asset, because it transfers the burden. If your records are signed before execution, hash-chained, post-quantum, and verifiable offline, then the burden of showing they were tampered with falls on whoever alleges it, and they cannot meet it. That is the difference between logging as an expense and logging as a defence, and it is a difference you can only buy in advance, before the incident that makes you wish you had.

How we built for the close reading, not the headline

I will be plain about what we built, because it is the reason I read these articles the way I do. Mickai is a Sovereign Intelligence Operating System (SIOS). It is built and in production, not in development. It runs fifty brains, twenty-five domain and twenty-five operational, on a silicon substrate we call Poseidon. Underneath all of it sits one mechanism that exists specifically for the problem the EU AI Act's record-keeping articles describe. We call it the Open Audit Record (OAR).

The OAR inverts the usual order of operations. Every AI action is signed before it executes, not described after. The records are hash-chained, so each one commits to the one before it and the sequence cannot be reordered or have a gap hidden inside it. The records are append-only, so the after-the-fact edit is not a policy you promise to avoid, it is a thing the structure makes detectable. The signatures are post-quantum, using the United States National Institute of Standards and Technology standard ML-DSA-65 (FIPS 204), so the integrity guarantee is built to outlive the retention period rather than expire inside it. The whole chain is verifiable offline, in an ordinary browser, with no trust in us as the vendor, which is the property the auditor actually needs and the one almost no logging stack provides. The audit root is anchored to Bitcoin through Pantheon, our sovereign Layer 1 chain, so the chain's history is pinned to something we cannot quietly rewrite either.

We are training our own models now, fine-tuning and specialising open foundations including Llama 3.2 and Qwen 2.5 while building a sealed corpus, and funding scales that work toward fully native weights. We hold one hundred and one filed United Kingdom patent applications, about two thousand two hundred and thirty-four claims, owned by Mickai LTD, covering this and the rest of the substrate. I mention the patents not as a trophy but as a marker that the record mechanism is the thing we treated as foundational, not a feature bolted on for a compliance deadline. You build it this way when you decide, early, that the record is the product and the rest is what produces records worth keeping.

Read the articles, then read your stack

My advice is unglamorous. Before August 2026, do not ask whether you are logging. You are. Ask the harder question the articles actually pose. Can a stranger who does not trust you take one of your high-risk decision records and verify, on their own machine, with no help from you, that it is the genuine, unaltered record the system produced at the moment of the decision, and will that still be true in ten years when today's cryptography is tired? If the answer is no, you do not have a logging gap. You have an evidence gap, and the law is, on a close reading, about evidence.

The companies that struggle with the record-keeping articles will not be the careless ones. They will be the diligent ones who logged exhaustively into systems that were never designed to prove anything to an adversary. The fix is not more logs. It is a different kind of record, one that is committed before the act, sealed against revision, durable against future cryptography, and checkable by anyone without your permission. That is the standard the EU AI Act is quietly describing. It is also, as it happens, the standard we built to. Read the articles closely. They are asking for proof, and proof is a higher bar than a log.