Compliance regimes

ConceptWhat it is

A compliance regime is a set of obligations attached to a category of data or a category of use. Most of what they require of an AI system is ordinary good practice already covered elsewhere on this tile. A small number of clauses genuinely constrain the architecture, and those are worth knowing before the index is built.

Three recur. Erasure — a person can require their data be deleted. Purpose limitation — data gathered for one purpose may not be freely used for another. Explainability — a decision affecting someone may have to be explained. Each collides with a default choice in a typical retrieval or fine-tuning pipeline.

How it worksThe mechanics

Erasure is the sharp one. Deleting a source document does not remove it from the vector index, from a cache, from a log, or from a model that was fine-tuned on it. A design that can honour erasure keeps a mapping from subject to every derived artefact, and treats fine-tuning on personal data as a decision requiring a retraining plan rather than a one-way door.

Purpose limitation decides whether production traffic may become training data, which is a question about consent rather than about tooling. Explainability is answered by the audit record and by grounding — an answer that cites its retrieved sources is explainable in a way an unsourced generation is not.

At a glanceSee it

An erasure request has to reach every derived copy. The index and the logs are deletable; fine-tuned weights are a retraining commitment made at design time.

When to use itWhere it fits

• Before choosing whether to fine-tune on personal data, which is the decision hardest to reverse.
• When the corpus contains health, financial or biometric records, where the category alone triggers obligations.
• When deploying into the EU, where the AI Act adds duties keyed to the use rather than the data.
• At procurement, because a buyer's security review will ask these questions whether or not you prepared for them.

When NOT to use itLimits & anti-patterns

• As a reason not to build — most obligations are satisfiable by design choices that are also good engineering.
• By copying another organisation's controls; obligations attach to your data and your use, not to a template.
• As a substitute for legal advice, which this page is not — it names the clauses that change designs.
• As an end-of-project review gate; every clause here is cheap before the index exists and painful after.

Trade-offsAdvantages & costs

ExampleIn the real world

A recruitment screening tool fine-tunes on historical applications to match house style. A candidate exercises erasure. The application row is deleted and the index entry with it, but the model trained on that text cannot be unwound, so honouring the request means a retraining cycle nobody scheduled. Choosing retrieval over fine-tuning at the start would have made this a delete.

ToolsHow to implement it

• A subject-to-artefact data mapthe unglamorous register that makes erasure a query rather than an investigation.
• Soft-delete plus index tombstonesso a removal propagates to the vector store on the same transaction as the source.
• Retrieval instead of fine-tuningthe single most effective compliance decision available for personal data.
• Citation-carrying answersthe audit record and the visible source together answer most explainability duties.

Cost & effortWhat it takes

No runtime cost. The expense is entirely in design freedom and in engineering the data map and deletion paths — days if planned, a re-architecture if not. The one genuinely large cost is retraining to satisfy erasure on fine-tuned weights, which is why the recommended answer is to avoid creating that obligation.

RelatedGo deeper