This is an engineering note, not legal advice. It describes what the record-keeping and traceability themes in the EU AI Act imply for how you store data. Which obligations apply to you, and when, is a question for your own counsel — the answer depends on what your system does, who you are in the supply chain, and which risk tier it falls into.
Almost everything written about the EU AI Act is about scope: which tier your system lands in, which obligations attach, which dates matter. That is necessary, and it is a lawyer's job.
What gets much less attention is the part that arrives on an engineering backlog, and it is narrower than the legislation's length suggests. Across the regime's higher-risk obligations, one requirement keeps reappearing in different clothes: you have to be able to explain, after the fact, how a particular output was produced. Logging, traceability, record-keeping, technical documentation, human oversight — these are different framings of the same underlying ask.
That is not a policy problem. It is a storage-design problem, and it is one most systems fail at by default.
The three questions a record has to answer
Strip the framing away and an auditor, a customer or your own incident review will ask the same three things about any output that mattered:
1. What evidence did the system have? Not what is in the source systems now — what was retrieved, at that moment, and used. If your retrieval step is not recorded, this is unanswerable, and "the CRM says X" is not an answer because the CRM says X today.
2. What did the system believe to be true then? This is the one that catches people. A fact in a business system is not stable; somebody corrects the renewal date in May. An answer given in March was produced against March's data. A store that holds only current values cannot distinguish a system that reasoned badly from a system that reasoned correctly over data that was wrong at the time — and those are very different findings. This is the entire argument for bitemporal storage: recording both when a fact was true and when you came to believe it.
3. Who was it acting for, and what was it allowed to do? An output produced with one person's permissions is a different artefact from the same output produced by a service account with unrestricted access. If your agent runs as itself rather than as the person who asked, you cannot answer this, and the access controls you documented were decoration.
What this means in practice
Append, do not overwrite. The single highest-leverage decision. A correction that supersedes rather than replaces leaves the original intact, which means reconstructing a past state is a query rather than a restore-from-backup exercise. Retrofitting this is genuinely hard, because history that was overwritten cannot be recovered and transaction times you never recorded cannot be invented.
Record provenance per value, not per dataset. Most pipelines can tell you a table was built from three sources. Very few can tell you which source produced the number in one particular cell. The unit of dispute is the figure, so that is the unit provenance has to work at.
Log the retrieval, not just the request. Prompt and completion logging is now standard and is the easy half. What was fetched, from where, and what came back is the half that makes an answer explicable.
Make the citation stable. A citation that breaks when the source record is edited was never evidence. If the store supersedes rather than overwrites, the citation still resolves to what it said when it was made.
Keep deletion honest. GDPR erasure and AI Act record-keeping pull in opposite directions, and anyone who tells you there is no tension is skipping the hard part. You need deletion that propagates to derived facts — which you can only do if you recorded what was derived from what. Erasure is a provenance capability before it is a privacy one.
The part that is genuinely uncomfortable
Record-keeping and data minimisation are in real conflict, and the resolution is a judgement rather than a technique. Keeping every intermediate state forever is both a storage cost and a liability: a larger surface to breach, and more to disclose. Keeping nothing makes every incident unexplainable.
The defensible middle is usually: keep the decision-relevant record indefinitely — which facts were used, where they came from, what was believed when — and keep raw payloads for a short, stated window. That distinction is only available if your architecture separates the two, which is itself a design decision somebody has to make on purpose.
Why this is worth doing regardless of the regime
Here is the pragmatic case, independent of any regulation.
Every one of these properties is what you want the first time an assistant gives somebody a wrong number and a customer asks why. Without them the conversation is unresolvable: you cannot show what was known, you cannot tell whether the data or the model was at fault, and the only available response is an apology. With them, you can show that the system answered correctly from a record that was wrong — and then go fix the record.
Teams that build this because a regulation told them to end up with the same architecture as teams that build it because they got burned once. The second group just paid for the lesson differently.
Memtro is built this way because of the second reason rather than the first: facts carry their source and validity dates, corrections supersede rather than overwrite, memory can be read as it stood on any date, every tool call runs as the person who asked, and erasure propagates to what was derived. None of that makes a company compliant — nothing a vendor sells does. It makes the three questions answerable, which is the part that was ever going to land on engineering.