How to Handle Personal Data in an AI Pipeline

What handling personal data in an AI pipeline actually requires

This is the engineering half of the problem. The legal half, which is your lawful basis, your privacy notice and your contracts, belongs to whoever owns it in your organisation, and nothing here is legal advice. What engineering owns is the map, the controls and the proof. If you cannot draw the map, the legal half has nothing to stand on, because every answer becomes a description of what the system is supposed to do rather than what it does.

The pipeline makes copies, and the copies are the compliance problem

Follow one request through the system with a debugger and write down every place bytes stop moving. The architecture diagram shows three boxes. The debugger shows nine, because your logging library, your tracing tool, your error handler and your cache all made copies without asking. Each copy has its own retention, its own access control, and its own deletion story, and none of that was a decision anybody made. Deciding what belongs in those records in the first place is covered in what to log in AI systems; this guide is about what happens to the records once they exist.

The Copy Ledger

Turn that table into a file that lives beside the code and changes in the same pull request. A privacy answer sourced from a file is a lookup. A privacy answer sourced from memory is an opinion, and it goes stale the week someone adds a caching layer.

# data-map.yml, one file per flow, kept beside the code and updated in the same pull request.
subject_key: customer_id          # the one identifier that means one person, everywhere
flow: support-summariser
lawful_basis_owner: dpo           # engineering records this decision, it does not make it

fields:
  - name: customer_email
    class: direct_identifier
    to_model: false               # tokenised before the call, rehydrated after
    token_format: EMAIL_{n}
  - name: message_body
    class: free_text_unbounded    # may contain anything a customer chose to type
    to_model: true
    redaction: detector_v3
    measured_recall_percent: ??   # measure this on your own held-out sample. never copy a
                                  # vendor figure, and re-measure when the document type changes
  - name: account_balance
    class: financial
    to_model: false               # the task never needed it

copies:
  - place: app_log
    purpose: debug
    ttl_days: 14
    enforced_by: retention_policy_prod
    delete: by_subject_key
  - place: trace_store
    purpose: incident_replay
    ttl_days: 30
    enforced_by: vendor_project_setting
    delete: vendor_api
  - place: prompt_cache
    purpose: cost
    ttl_days: 2
    enforced_by: cache_ttl
    delete: by_key                # key must contain subject_key or this row is a lie
  - place: vector_index
    purpose: retrieval
    ttl_days: null
    enforced_by: deletion_worker
    delete: by_document_id_then_reindex
  - place: eval_dataset
    purpose: regression_testing
    ttl_days: null
    enforced_by: none             # FINDING: synthesise these cases, then close this row
    delete: none
  - place: provider_logs
    purpose: none
    ttl_days: contractual
    enforced_by: agreement + account setting
    delete: provider_request
    checked_on: 2026-08-19        # this row expires, so record the date

drill:
  subject: staging_subject_0042
  last_run: 2026-08-19
  places_that_failed: [error_tracker_breadcrumbs]
  fix: strip request body from exception context, ticket PLAT-2214

Redaction reduces risk, it does not remove the obligation

Redaction is worth doing, and it is not a control you can lean on the way a firewall rule is a control, because detector recall is never one hundred percent on free text. Run the arithmetic on your own numbers before you describe redaction to anyone as the reason a field is safe. The second output below is the one that changes minds.

At the default numbers, a detector that catches ninety eight percent of identifiers still leaves at least one identifier in roughly one document in nine. That is the shape of the problem: per-identifier accuracy sounds excellent and per-document accuracy is what a regulator or a customer actually experiences. Design accordingly, which means redaction sits alongside minimisation rather than instead of it.

Embeddings, caches and fine-tunes are copies too

The three places teams forget are the three with the worst deletion stories. Each one needs a decision at ingestion time, because retrofitting the decision means reprocessing everything you have.

• Vector indexes. An embedding is derived from the text, and published work on embedding inversion has shown that meaningful parts of the original can be reconstructed from vectors alone. Treating a vector store as an anonymiser is not a position worth defending. Deletion needs a mapping from subject key to document id to chunk ids, built during ingestion, because reconstructing it later means re-embedding the corpus.
• Caches. A prompt cache keyed by hash holds the prompt in full. If the key does not contain a subject key, you cannot remove one person from it, and eviction is not deletion because you cannot say when it happened or prove it did.
• Fine-tunes. A record that entered training cannot be lifted back out of the weights. The delete method is retraining from a filtered dataset, on your schedule and at your cost, which is why the fields allowed into a training set are decided before the first run and not after the first request.
• Backups and snapshots. A point-in-time restore puts deleted records back. Either the deletion job runs against restores as part of the restore procedure, or the backup window is short and documented, and somebody has written down which of those two you chose.
• Enrichment APIs. Sending a record to a third party to append a company size or a phone number creates a copy in someone else's system and a processor relationship you now own, complete with its own row in the ledger.

What the provider boundary gives you, and what it does not

It gives you contract terms and configuration settings. Nothing on the provider side is verified by testing, it is verified by reading, and everything in it can change without a deploy on your part. So record the claim, the evidence, and the date you last checked, then re-check on a calendar rather than on a rumour.

Deletion is a system property, and a drill is how you prove it

A deletion path that has never been executed end to end does not work. This is not cynicism, it is the consistent result of running the exercise: something in the chain was built before the pipeline existed and nobody rewired it. Run the drill quarterly, in staging first, then once in production with a consenting internal subject.

1. Create a traceable subject10 minutes

   Seed a staging subject whose text contains a unique, greppable token in every free-text field. A random string is better than a fake name, because you can search for it across stores without false positives and without needing exact-match support.

2. Push them through the full pipelinean hour

   Upload a document, raise a ticket, trigger a summary, force an error so the exception path runs, and let a scheduled job touch the record. Errors matter most, because the error path is the one that copies the request body somewhere nobody planned.

3. Delete through the normal pathminutes

   Use the same route a real request would take, including any manual step. If the route includes a person doing something by hand, that person is part of the system and their step belongs in the runbook with a named backup.

4. Search every resting place for the tokenthe real work

   Every row of the ledger, one at a time, including backups and the error tracker. Anything that still returns a hit is a gap with a ticket number, not a discussion.

5. Time it, then record the longest intervalone number

   The slowest store sets your true deletion time. Publish that number internally so nobody promises a shorter one to a customer, and so the next person to add a store knows what standard they are joining.

6. Fix one thing and re-runnext quarter

   The drill is only useful if the gap list shrinks. A drill that finds the same gap three quarters running is a governance problem rather than an engineering one, and it needs to be raised as such.

Answering a subject request without rebuilding the pipeline

Access requests are answered from the same ledger as deletion requests, which is the argument for building it once. The statutory clock is set by your regime and is short, so check yours and write down who starts it, because the clock usually starts at a support inbox rather than at an engineer's terminal. The failure mode is not refusing the request. It is spending nineteen of your days discovering where the data was.

If your system produces answers from retrieved documents, the access request also has to cover what was retrieved and shown, not only what was stored. That is one more argument for keeping citation records with each response, which citations and grounding covers from the quality side and which turns out to pay for itself twice.

Definitions your engineers and your lawyers have to share

Most arguments in this area are two teams using one word for two different things. Agree these five in writing, then use them consistently in tickets, in the ledger and in customer answers.

Five terms, agreed once

Personal data

Any information relating to an identified or identifiable person. The test is whether someone can be singled out using that data plus anything else reasonably available, which is why a pseudonymised record stays personal data for as long as the mapping exists.

Pseudonymisation

Replacing identifiers with tokens while keeping a separate mapping that can reverse the replacement. It reduces risk substantially and it does not take the record out of scope, because the mapping exists. Almost all AI redaction is pseudonymisation.

Anonymisation

Removing the ability to single out a person permanently and irreversibly, including by combining the data with other available sources. Genuinely anonymised data falls outside the rules, which is exactly why the bar is high and why free text rarely clears it.

Data minimisation

Sending only the fields a task actually needs. In an AI pipeline it is the cheapest control available, because a field that never reaches the model cannot leak from a prompt, a log, a trace, a cache or a provider.

Processor

An organisation that handles personal data on your instructions rather than for its own purposes. Adding a model provider, a tracing vendor or an enrichment API adds a processor, and each one adds a row to your record of processing and a row to the ledger.

Two habits keep this alive after the first push. Add the ledger row in the same pull request that creates the copy, and re-run the deletion drill on a calendar rather than after an incident. If you want the map, the drill and the guardrails built as one piece of work on a system already in production, that is evaluation and guardrails, and it pairs with the pre-ship review in security questions to answer before you ship AI.