What the EU AI Act requires you to log
The regulation says what has to be possible. It does not say how to build it, and that gap is where most teams get stuck. This is the record-keeping obligation translated into what it means for a system you have to design, with the dates that apply and the parts that are commonly misread.
What the regulation says
- Article 12(1): high-risk AI systems must technically allow for the automatic recording of events — logs — over the lifetime of the system. The capability has to be built in, not bolted on.
- Article 12(2): those logs must be adequate to identify situations where the system may present a risk or undergo a substantial modification, and to support post-market monitoring.
- Article 12(3) sets a specific minimum list — period of use, reference database, matched input data, the people who verified results — but that list is written for remote biometric identification systems, not for every high-risk system. It is widely quoted as if it were universal. It is not.
- Article 19: providers must keep the logs automatically generated by their high-risk systems, where those logs are under their control, for at least six months unless other Union or national law requires longer.
- Article 26(6): the same six-month floor applies to deployers, for the logs under their control.
- Article 11 and Annex IV: technical documentation has to exist before the system reaches the market, and it describes design decisions being made now.
What that means for a system you have to build
‘Over the lifetime’ rules out adding it later
A log that starts the day the auditor asks proves nothing about the eleven months before. This is the single most expensive misreading: teams treat logging as a reporting feature to add near the deadline, when the obligation is that the system was recording all along.
‘Adequate to identify risk’ is a design decision, not a setting
The regulation does not enumerate fields for most systems. It states a purpose: someone must be able to reconstruct what happened. In practice that means the inputs, the retrieved context, the output, the versions of every component involved, and a timestamp — because without versions, a reconstruction from three months ago describes a system that no longer exists.
Six months is a floor, and it interacts with data protection
Logs of an AI system usually contain personal data, which puts them under GDPR at the same time. Keeping everything forever is not the safe option: you need a retention period you can defend in both directions, and a way to honour a deletion request without destroying the audit trail.
Provider and deployer are roles, not company types
The same organisation is often both: a provider of the system it built and a deployer of the one it runs. Each role carries its own retention duty. Deciding which you are is the first question, and it is a legal question, not an engineering one.
The documentation describes decisions you are making today
Annex IV documentation covers architecture, data, and the choices behind them. Reconstructing that in 2027 from a system already in production costs several times what recording it as you go does, because by then nobody remembers why.
Where systems usually fall short
The output is logged, the input is not
An answer is recorded without the retrieved context that produced it. When someone asks why the system said that, the answer is unreconstructable: the same question against a changed index gives a different result.
Nothing is versioned
Model, prompt, retrieval index and configuration all change independently, and none of them is recorded with the output. Six weeks later the logs describe a system that no longer exists.
Retrieval ignores permissions
One index for everything, with access checked after generation or not at all. This is not only a compliance gap: it is a data leak, and the log will faithfully record it happening.
Retention was never decided
Either logs rotate away in thirty days, below the floor, or they accumulate forever with personal data in them. Both are problems, and the second one is worse.
There is a policy document and no mechanism
The most common finding. A written commitment to record things the system does not record. That gap is visible to the first person who asks for a sample.
Six questions to ask about your own system
- Can you produce, for any answer your system gave, what it retrieved to produce it?
- Can you say which model, prompt and index version were in use at that moment?
- Can you show that the person who asked was allowed to see every source that fed the answer?
- Do your logs survive at least six months, and do you have a defensible reason for the period you chose?
- If someone exercises a deletion right, does your audit trail survive it?
- Does your technical documentation describe the system running today, or the one you designed originally?
Questions this raises
Is this legal advice?
No. This is an engineering reading of a legal text, written by the engineers at Devsitia who build these systems. Which obligations apply to your organisation, and which role you hold, are questions for your counsel. What we can tell you is what a system has to do to produce the evidence those obligations describe.
When do these obligations actually bite?
2 August 2026 is the binding date for the high-risk obligations covering providers and deployers. The most consequential requirements for Annex III systems were deferred to 2 December 2027 by the Digital Omnibus on AI. That deferral moves the deadline, not the work: the records have to describe decisions being taken now.
Does the four-item list in Article 12 apply to my system?
Probably not, and it is the misreading Devsitia sees most often. That list is written for remote biometric identification systems. For other high-risk systems, Article 12 states a purpose — logs adequate to identify risk and support post-market monitoring — and leaves the design to you. Copying the biometric list is not compliance, and it may miss what your system actually needs to record.
We are outside the EU. Does any of this reach us?
It can. The regulation follows the use, not the address: placing a system on the EU market or serving users there can bring you in scope. Separately, enterprise procurement increasingly asks for the same evidence — ISO 42001, SOC 2 — regardless of jurisdiction.
Our AI is not high-risk. Do we need any of this?
The obligation may not apply, but the capability is still worth having, and for a plain commercial reason: the first enterprise customer who asks what your system did with their data will want an answer, and ‘we do not record that’ ends the conversation. Building it later, into a running system, is a migration rather than a design decision.
What is the cheapest moment to do this?
Before the system exists. Records, versioning and permission-aware retrieval designed in from the start are a few decisions. Added to something already in production, they are a project — and one that has to be done without losing the history you do not have.
Start a conversation
Tell us what you are building, or what is currently breaking. You will get a straight answer from an engineer, not a sales script.