Article 12 is a logging requirement your pipeline probably fails
Most teams answer the traceability question by pointing at their observability stack. Debugging logs and traceability records are built to opposite specifications, and the substitution is where the failure hides.
The conversation goes the same way every time. Someone asks whether the organisation can meet the logging expectation, and an engineering lead says yes, we log everything, and opens a dashboard with six months of traces in it.
The dashboard is real. The answer is still wrong, and I want to be precise about why, because this is not a gap in effort. It is a category error. Observability logs and traceability records are designed to opposite specifications, and a system optimised for one is close to worst-case for the other.
I am not a lawyer and none of this is legal advice. What follows is an engineering argument about what the requirement implies for the way you build.
The requirement, stated qualitatively
The EU AI Act’s Article 12 obliges automatic logging of events relevant to identifying risk and ensuring traceability. Records must be tamper-evident and retained for at least six months, twenty-four for biometric and law-enforcement uses. Enforcement began on 2 August 2026.
That is the whole of what I will assert about the text. The interesting work is in the words “automatic”, “relevant to traceability” and “tamper-evident”, each of which describes a property your observability stack does not have, and was never trying to have.
The two systems have opposite goals
An observability system exists to answer a question you have right now about a system that is currently misbehaving. Everything about its design follows from that. It samples, because complete capture at production volume is unaffordable and unnecessary for its purpose. It ages out fast, because a trace from March is worthless for an incident today. It is written by the component being observed, because that is the cheapest place to instrument. It is mutable in practice, because retention policies, index rebuilds and cost controls delete and rewrite constantly. And its contents are chosen by whoever wrote the instrumentation, changed at will, in a shape nobody outside the team can interpret.
A traceability record exists to answer a question somebody else will have, later, about an event nobody remembers. Complete rather than sampled, because the sampled-out event is exactly the one they will ask about. Retained by rule rather than by cost. Written at a boundary rather than by the actor. Append-only. And legible to a reader who was not there.
Optimised for debugging
- Sampled, because volume costs money
- Short retention, because old traces are dead weight
- Emitted by the component being watched
- Schema changes whenever the team wants
- Read by people who already have the context
Optimised for traceability
- Complete for the defined event set
- Retention set by rule and question horizon
- Recorded at a boundary the actor does not control
- Stable schema, because it is read years later
- Read by people who were not there
Where agent pipelines fail specifically
Take a routine agentic change. An agent is given a ticket, reads part of the repository, produces a diff, opens a pull request, CI runs, a human approves, it merges.
Now list what survives six months in a typical setup. The diff, permanently, in git. The pull request metadata, as long as the forge keeps it. CI logs, for however many days the retention setting says, usually between seven and ninety. The agent’s inputs, which is to say the context it was handed, the criteria it was given and the model it ran against, usually nowhere at all. The reasoning for the approval, in a comment box if you are lucky.
So the durable record is the artifact, and the ephemeral record is everything that would explain it. You end up with a perfect account of what changed and almost nothing about why, on whose authority, or against which stated criteria. That is precisely inverted from what a traceability question needs, because nobody has ever asked me what a diff contained. They can read the diff. They ask what it was supposed to do and who said so.
The second failure is subtler. In an agentic pipeline, the agent frequently has write access to the repository that contains the code emitting the audit events. A component that can modify its own instrumentation is not a witness to its own behaviour in any meaningful sense. This is not a hypothetical attack; it is a routine consequence of giving an agent broad repository scope, and it is invisible unless you go looking.
What “automatic” is doing in that sentence
The word I would underline is automatic. A record a person produces on request is a reconstruction, and reconstructions are interpretation. A record the pipeline emits without anyone deciding to is an observation.
The practical test is whether the record exists for a change nobody thought was interesting. Every organisation can produce beautiful evidence for the change that caused the incident, because someone assembled it afterwards. The requirement is about the other ten thousand.
The cheapest thing that works
You do not need a new platform. You need to decide, once, what your event set is, and then emit those events somewhere your build pipeline cannot rewrite.
Start with merge. A merge is a good boundary because it is enforced by the forge rather than by your code, it already carries identity, and it is the moment at which a change becomes the organisation’s problem rather than an individual’s. Record, at merge: the change identifier, the stated criteria it was built against, what verified it and with what result, who approved, and whether generation was involved and by what. Five fields, emitted automatically, retained by rule.
Our own product records exactly this class of event, and I will say plainly that having such a record does not make anybody compliant with anything. Compliance is the outcome of a programme assessed against an environment, and a log is one input to it. What the record does is turn a week of archaeology into a query, which is a smaller and much more honest claim.
Where this breaks down
Most teams building software are not in scope, and I have written as though everyone is. The obligations attach to systems in defined categories. If yours is not one, the correct response is a written determination explaining why, filed once, and then getting on with your life. Building a traceability programme you do not need is a real cost with no return.
Complete capture has a genuine price. Append-only storage retained for two years, at the volume a large monorepo generates, is not free, and the operational burden of a schema you cannot change casually is worse than the storage bill. For a team with no regulatory exposure, that spend buys very little.
The event set is where the judgement lives, and I have made it sound easy. Deciding which events are “relevant to traceability” is exactly the hard part, it is contested, and getting it wrong in the expansive direction produces an unreadable archive that satisfies nobody.
Boundary recording is not absolute. Someone with sufficient privilege on the recording system can still alter it. Tamper-evident means detectable, not impossible, and I would rather say that than let the word do more work than it can carry.
And a complete log can make a weak process look rigorous. An organisation that can prove precisely how an unreviewed change reached production has documented the problem rather than fixed it. Evidence is not control.
The takeaway
Pointing at your observability stack is not an answer to a traceability question, because the two systems are built to opposite specifications and the substitution hides the failure rather than resolving it. Debugging logs sample, expire and are written by the actor. Traceability records must be complete, retained and recorded at a boundary.
In agentic pipelines the inversion is worse than usual: what changed is durable, and everything that would explain it is not.
If you take one thing into next week: write down the five things you would need about a merge from eight months ago, then check which of them your pipeline still holds. The ones that are gone are your event set.