Skip to main content
Viithiisys
Back to blog
AI Engineering7 min readTue, Oct 20, 2026

AI Data Privacy Compliance: A Build Guide

A practitioner guide to AI data privacy compliance: residency, PII redaction, retention, deletion and audit trails for LLM projects under GDPR and PIPEDA.

Gaurav Saini

Founder, Viithiisys

AI Data Privacy Compliance: A Build Guide

What four questions shape AI data privacy compliance?

The four questions are: where does the data physically go, which personal data is in it, how long does each copy live, and how will you prove all of that later. Answer them before choosing a model, because AI data privacy compliance is mostly decided by those answers.

Compliance trouble in AI projects often starts with skipping one of these. A team picks a model API, wires it to production data, and discovers during a customer security review that nobody can say which region processed a prompt or where a support transcript ended up.

Each question maps to one control: residency to deployment region, PII to a redaction layer, retention to a deletion pipeline, and proof to an audit log. This guide takes them in that order.

Viithiisys has engineering in Mohali and a Canadian office in Markham, Ontario. These controls are easy to design in during the first sprint and painful to bolt on after launch, when prompts, logs and vector stores already hold live customer data.

Four controls sitting between an application and a language model: region, redaction, retention and audit log

What do EU, UK and Canadian clients actually require for residency?

Clients rarely require "no data leaves the region" in law. They require it in contracts. The legal baseline is controlled transfers; the commercial baseline is often in-region processing, in-region storage and named subprocessors.

Does GDPR require data to stay in the EU?

No. Chapter V of the GDPR regulates transfers to third countries and permits them under an adequacy decision or safeguards such as standard contractual clauses. EU processing avoids that analysis, but the regulation does not mandate it.

Fines for the most serious infringements reach €20 million or 4% of worldwide annual turnover, whichever is higher, per Article 83 of the same regulation.

What does LLM data residency really cover?

LLM data residency covers more than where inference runs. A residency promise to a client should account for each of these:

  • the prompt in transit
  • the compute that processes it
  • abuse-monitoring logs
  • the vector store
  • fine-tuning data
  • your own application logs

Watch for silent routing. AWS documents that cross-region inference in Amazon Bedrock can send requests to other regions to manage capacity. Microsoft's Azure OpenAI data privacy documentation describes an abuse-monitoring retention window and a process to apply for modified monitoring. Read both before you promise a client anything, and record the settings you chose so a reviewer can see that the region was configured on purpose rather than left at a default.

How do UK and Canadian rules differ?

The UK runs its own transfer mechanisms under UK GDPR, so an EU-only contract template is not enough. Canada's PIPEDA permits cross-border processing but keeps you accountable for processors abroad.

Quebec's Law 25 adds an assessment requirement before personal information leaves the province.

For Canadian buyers, a delivery partner with an Ontario office makes the accountability conversation simpler.

PII redaction before the model sees it

Put a redaction layer between your application and every model call. It detects personal data, replaces it with placeholders, and restores values only where the business function requires them.

Where should the redaction layer sit?

Place it in a gateway that every LLM call passes through, not in each feature. One gateway gives you a single place to enforce policy, collect metrics and swap detectors.

Per-feature redaction tends to drift over time, because each team handles edge cases differently and fixes land in one feature but not the others.

The gateway should also cover retrieval. Documents pulled from a knowledge base can contain personal data the user never typed, so redact or filter them before they join the prompt.

How accurate is PII detection?

Not accurate enough to be your only control. Structured identifiers like card numbers and emails are caught well; names in free text, nicknames and context-dependent details are the failure mode.

Managed detectors such as Amazon Comprehend return entity types with confidence scores, and open-source options exist. Tune the threshold toward recall for high-risk fields, accept more false positives, and sample redacted output weekly to check what slips through.

Is pseudonymised data still personal data?

Yes. Article 4(5) of the GDPR defines pseudonymisation as processing that stops data being attributed to a person without additional information, and such data remains personal data.

If you keep a token vault to restore names in the response, the vault is in scope and needs the same residency, access and retention controls as the original records.

A redaction gateway swapping names for placeholders before a prompt, with a separate vault holding the mapping

Retention and the right to delete

Every copy of personal data in an AI system needs a retention period and a deletion path. That includes prompts, outputs, embeddings, caches and logs, not only the source database.

Where do copies of personal data hide?

Teams list the database and forget the rest. A typical retrieval system also holds:

  • chunked text in a vector index
  • cached completions
  • conversation history
  • evaluation datasets built from real traffic
  • provider-side logs

OpenAI's API data documentation describes default retention of API inputs and outputs for abuse monitoring, plus zero data retention for eligible endpoints. Map each provider's retention to your own policy before the first production call, and write down who is responsible for revisiting it when a provider changes its terms.

Can you delete a person's data from a model?

Not in any dependable way today. That is why personal data should stay out of training and fine-tuning sets unless the legal basis and deletion plan are settled first.

For retrieval systems the answer is better. Store the source record ID on every chunk and embedding, so an erasure request deletes by ID. Article 12(3) of the GDPR sets one month to respond to a request, so test the delete path end to end, including backups and caches, before a request arrives.

What audit trail does AI data privacy compliance need?

A useful audit trail lets you reconstruct what happened to a specific person's data: who triggered the call, which model and region handled it, what was redacted, and what was retrieved. Confirm the exact expectations against your client contract and the guidance of the regulator that applies. Raw conversation dumps are rarely needed to answer these questions, and they add risk of their own.

What belongs in the log?

Record these fields for every model call:

  • request ID
  • caller identity
  • model name
  • model version
  • processing region
  • count and type of redactions
  • retrieved document IDs
  • the policy decision taken

Store references and hashes instead of raw prompts. The reason is practical: a log full of full prompts is a second database of personal data, with its own residency, retention and breach exposure. The EU AI Act requires high-risk systems to support automatic event logging, and deployers must keep those logs for at least six months.

How do you make logs tamper-evident?

Write logs to append-only storage with object lock or equivalent, restrict write access to the gateway, and ship them to a separate account from the application.

An auditor will ask who can alter a record, and "nobody on the engineering team" is the answer you want. Verify it by trying to edit or delete a log entry with an ordinary engineering role, and keep the failed attempt as evidence.

An append-only log stream flowing into locked storage while the application can write but not edit

Architecture patterns by compliance regime

The right pattern depends on which regime binds the data. Use the list below as a starting point, then confirm each entry with counsel, since regulators judge the facts of a deployment, not a pattern name.

  • GDPR (EU residents' data): Host the model in an EU region, or document transfer safeguards. Minimise fields through the redaction gateway, delete by record ID within the one-month response window, and audit region, subprocessors and lawful basis.
  • UK GDPR (UK residents' data): Use a UK or EU region with UK transfer terms. Handling and retention match GDPR; the audit focus is the transfer mechanism for each vendor.
  • PIPEDA and Quebec Law 25 (Canadian customer data): Prefer a Canadian region. Combine redaction with accountability clauses, document purpose and retention, and audit processor accountability and the impact assessment.
  • HIPAA (US protected health information): Use a provider covered by a business associate agreement. De-identify before calls where possible, retain per policy and law, and audit access logs and minimum necessary use.
  • EU AI Act (high-risk use cases): Hosting follows GDPR. Apply data governance to inputs, keep logs for at least six months, and audit event logging and human oversight.

How should you pick a starting pattern?

Start from the strictest regime your client base triggers, and build once. A single regional deployment with a redaction gateway and an append-only audit log covers most of the list above, and regional variants are configuration, not rewrites.

If your team lacks the capacity, AI development services from a partner that has shipped under client security reviews can compress this.

Clean pipelines matter too: data engineering work upstream decides whether deletion by record ID is even possible.

For a bounded first step, a fixed-scope Moonship MVP can prove the architecture. If the open question is who owns these decisions, fractional CTO leadership can take them on.

Compliance in AI systems is decided by where copies of personal data live, and the model is the smallest of them.

If you are unsure which of these controls your current build is missing, book a broken workflow assessment and we will walk through your data flows, from model region to log retention, with you.

FAQ

Does GDPR require LLM data to stay in the EU?
No. GDPR restricts transfers of personal data outside the EU, not processing outside it. Transfers are allowed with an adequacy decision or standard contractual clauses. Many enterprise contracts still demand in-region processing, so check the customer agreement as well as the regulation.
Can you delete a person's data from a trained or fine-tuned model?
Not reliably. Current models cannot remove one person's data on request. The practical answer is to keep personal data out of training and fine-tuning sets, and to hold personal data in stores you control, such as a retrieval index, where deletion by record ID works.
Is redacting PII before an LLM call enough for GDPR compliance?
No. Redaction reduces exposure but detection is never perfect, and reversibly pseudonymised data is still personal data under GDPR. Redaction works as one layer alongside regional processing, retention limits, access control and audit logging, not as a substitute for them.
What should an AI audit log contain?
Log a request ID, the user or service identity, the model and version, the processing region, redaction counts, the IDs of retrieved documents, and policy decisions. Avoid storing raw prompts in the log, because the log itself then becomes a store of personal data.