Customer data and PII: what an AI system may see
An AI system copies data into more places than a normal app: prompts, model providers, logs, traces, vector stores, memory and eval sets. Each copy is a place personal data can leak or outlive a deletion request.
Draw where the data goes
Before building, draw one support ticket's journey. For a typical agent it passes through at least these, and each one is a question for the customer's security team:
| Where it goes | The question to answer |
|---|---|
| Your application | Which fields does it actually need to read? |
| The model provider | Is the provider approved, in which region, and does it keep or train on requests? |
| A gateway or proxy | Does it log full prompts and answers, and who can read those logs? |
| Traces and observability | How long are traces kept, and do they contain customer text? |
| Vector stores and memory | Can a stored chunk or memory be found and deleted for one customer? |
| Eval datasets | Were real tickets copied into test files, and were they cleaned first? |
PII, personally identifiable information, is anything that identifies a person on its own or combined with other data: names, emails, phone numbers, addresses, account and order numbers, and free text that mentions them. Customers often have their own, stricter list.
Send less
- Only the fields the task needs. Sorting a ticket needs its text, not the customer's address and payment history.
- Replace identifiers before sending. Swap an email for
CUSTOMER_1in the prompt, keep the mapping in your own system, and put the real value back in the answer if needed. - Keep secrets out of prompts entirely. A tool that needs an account number should look it up on the server side, not receive it from the model.
Logs, traces and eval sets
The easiest leak is the one built for debugging. Tracing every step of an agent stores every prompt and tool result, often in a third-party service. Decide per environment what is logged, redact before logging, and set a retention period.
Golden datasets built from real tickets are valuable and dangerous: they get committed to repositories and shared with vendors. Clean them once, when they are created, and label the file as containing cleaned customer data.
Deletion
When a customer asks to be forgotten, every copy counts: application records, vector store chunks, long-term memories, logs and cached answers. A memory layer needs a delete path by user, which is why the Mem0 course covers delete and history. A cache keyed on prompts that contain personal data needs an expiry.
Where the tools help
- LiteLLM: one gateway where provider choice, logging and keys are controlled centrally
- Guardrails AI: validators that check what goes out before it leaves
- Agent Governance Toolkit: a policy on which tools an agent may call, with an audit trail
- Topic: SSO, OAuth and RBAC: who may see what in the first place
- Draw the data's path before choosing tools
- Send and store only what the task needs
- Logs, traces, caches and eval sets are copies too
- Deletion must reach every copy
- Draw the data flow of a system you built and mark every place a customer's email could end up
- Write a function that replaces email addresses and order ids with placeholders and restores them afterwards
Every expert started right here.