Governed AI
A model inherits every obligation your data already had
Adding an AI feature does not create a new compliance regime. It moves personal data into a component that is harder to inspect, and the duties travel with it.
The question that stalls AI features in regulated organisations is rarely "does it work". It is "what happens when someone asks us to delete their data, and some of it went into a prompt eight months ago".
That question has an answer. It is just easier to answer if you designed for it than if you are reverse-engineering it under a deadline.
The boundary is where the data leaves your control
Draw one line: the point where personal data crosses into something you cannot inspect after the fact. A hosted model is on the far side of that line. So is a vector store you did not configure. So is a logging pipeline that captures full request bodies.
Everything on the far side needs an answer to four questions:
- What is sent — the field list, not "the user's context"
- Where it is processed — jurisdiction, and under whose contract
- How long it is kept — by them, not by you
- What happens on erasure — including anything derived from it
If a question has no answer, that is the finding. Write it down as a gap rather than as a risk to be assessed later.
Retrieval is a copy, and copies have their own lifetime
The part teams consistently under-model is retrieval. A document indexed into embeddings is a derived copy. Deleting the source row does not delete the vector, and a vector that still returns the right neighbours still carries the information — which is exactly what a regulator means by personal data.
The workable pattern is boring:
- Index by reference, never by value, so the chunk carries an id and not the text
- Rebuild rather than patch when the source changes, because partial updates leave orphans
- Give the index the same retention clock as the source, enforced by the same job
Evaluation sets are personal data too
A test suite assembled from real conversations is a dataset of real people, sitting in a repository, copied to every laptop that clones it. It needs the same handling as production data, or it needs to be synthetic. Choose deliberately; the accident is choosing neither.
What to write down before the first prompt ships
| Question | Where it belongs |
|---|---|
| Which fields reach the model | Data-flow record |
| Which processor, under what terms | Processing register |
| Retention on their side | Contract, then register |
| Erasure path, including derived copies | Runbook, tested |
| What a bad answer costs | Risk assessment |
None of this slows a good feature down. It slows down a feature that was going to be stopped at review anyway, and it slows it down earlier, when changing the design is still cheap.
Read next
- Event contracts between bounded contexts
Two teams agree on a payload, ship, and discover six months later that they never agreed on what it meant. The schema was never the contract.
- Runbooks that survive a reorganisation
Operational documentation is usually written for the person who already knows. Write it for the third reader instead — the one who arrives at 03:00, eighteen months from now.