AI Controls and Governance
How do GDPR and AI audit requirements interact?
One law gives individuals the right to have their personal data erased. Another requires organisations to keep records of what their AI systems did, in some cases for a decade. Both apply to the same system at the same time, and the team responsible for that system is entitled to ask how it can possibly comply with both.
The honest answer has two parts. The legal conflict is narrower than it first appears, because neither obligation is as absolute as its reputation. And the conflict that genuinely remains is, in most cases, not a legal problem at all — it is a data architecture problem wearing legal clothing.
A necessary note before anything else: this page describes how the two regimes fit together. It is not legal advice, and the specifics of any organisation's position need a lawyer who can see that position.
What Each Side Actually Requires
The GDPR's right to erasure (Article 17) lets an individual require deletion of their personal data — but the right is conditional, not absolute. It applies on specific grounds, the most common being that the data is no longer necessary for its original purpose. And it carries explicit exemptions, the most relevant here being Article 17(3)(b): the right does not apply to the extent processing is necessary to comply with a legal obligation. Where the law requires you to keep something, the erasure right yields — but only as far as the obligation reaches. If you can satisfy the obligation and still delete, the exemption stops covering you.
On the AI side, the EU AI Act's record-keeping obligations for high-risk systems are layered, and the layers matter. Article 12 requires high-risk systems to automatically log events across their lifetime. Article 19 requires those logs to be kept for at least six months, and the article itself defers to data protection law: the period applies unless personal data protection law provides otherwise. Article 18's ten-year retention applies to technical documentation — model versions, conformity records, system-level evidence. It is a requirement about documentation and metadata, not a mandate to hold raw personal data for a decade.
Read carefully, the two regimes were drafted to interlock rather than collide: the AI Act's retention rules explicitly defer to data protection law, and the GDPR explicitly exempts legally required retention. The collision people experience in practice comes from somewhere else.
Where the Real Conflict Lives
The genuine tension arrives when personal data and audit records are entangled — when the record that proves what an AI system did is built out of the personal data of the people it did it to.
Consider a credit-decisioning agent. The audit question is "what was this system working from, and why did it decide as it did?" If the only record that answers it is the applicant's full file — the personal data itself — then an erasure request and an audit obligation are now pointing at the same bytes, and the team is stuck doing case-by-case legal analysis of which obligation wins, for how long, for which fields. Multiply by every individual the system touched and the compliance position becomes an ongoing negotiation rather than a settled design.
Now consider the same system where the records are separated by design: the operating context the system worked from — the lending criteria, the risk constraints, the policy decisions and when they changed — held as one record, and the personal data of individual applicants held as another, linked but separable. An erasure request deletes or anonymises the personal record. The audit record — what the system was permitted to do, what rules it applied, who set them, what changed and when — survives intact, because none of it was the applicant's personal data in the first place.
This is the insight that dissolves most of the apparent contradiction: the parts of the record that explain policy, intent, and operating constraints are often organisational knowledge rather than personal data. Goals, constraints, policies, configuration changes, the reasoning behind them — a record architecture that keeps these entangled with personal data inherits a conflict it never needed to have. The parts that can contain personal data — prompts, conversation traces, case files, human annotations — are real, and they are exactly the parts the separation has to be designed around.
The conflict that survives separation is real but smaller than it first looked: cases where the personal data itself is the evidence — and there, the legal exemptions (legal obligation, legal claims) do the work they were written for, with anonymisation and pseudonymisation as the recognised techniques where they don't.
A Note on Timing, Lightly Held
The AI Act's high-risk obligations were scheduled to apply from 2 August 2026. At the time of writing, a provisional EU agreement — the Digital Omnibus on AI, not yet formally adopted — would defer those obligations to December 2027. Two things are worth taking from this, and neither is relief.
First, the GDPR is untouched by the deferral. The erasure right, and every other data protection obligation, applies now and has since 2018. Any AI system processing personal data is already inside the regime that creates this page's tension.
Second, the architectural question doesn't move with the deadline. An organisation that builds entangled records now will face the separation problem eventually, with more data and less room. The deferral changes when the AI Act's auditors arrive. It doesn't change what a defensible record architecture looks like.
Engramic's approach
How Engramic Approaches it
There are multiple ways to keep audit records and personal data separable. This is one approach.
Engramic's record is the agent's operating context: the goals it was given, the constraints it was under, the decisions it was built from, and how those changed over time. That record is organisational knowledge — it explains what the agent was working from without being constructed out of the personal data of the people the agent dealt with. When the audit question arrives, the answer is retrieved from a record the erasure right was never pointed at, because the record's contents were never an individual's personal data.
The honest boundaries: where personal data does enter the graph, the GDPR applies to it exactly as it applies anywhere else — Engramic does not exempt anyone from data protection law. And the separation argument covers the operating-context record, not every record an AI deployment generates; transaction logs and individual case files remain the organisation's to govern under the usual rules. For the specifics of any compliance position, that conversation belongs with counsel.
In short
The GDPR's erasure right and AI audit retention requirements look contradictory and mostly aren't: the erasure right yields to legal retention obligations, and the AI Act's retention rules explicitly defer to data protection law. The conflict that organisations actually experience comes from entangling two different records — the personal data an AI system processed and the operating context that explains its behaviour. Separate them by design and most of the tension dissolves, because the parts of the record that explain policy and intent were never personal data to begin with. The recent deferral of AI Act deadlines changes none of this: the GDPR applies now, and record architecture decided today determines which problem you have later.