PII, Data Retention, and Provider Policies
Know where user data flows: provider retention and training policies, zero-data-retention options, PII redaction, regional processing, and user consent.
A prospective Deskmate customer sends over a security questionnaire. Which third parties receive our ticket data? How long do they keep it? Is it used to train models? Where is it processed? Can you delete it on request? Before you added AI features, those answers took ten minutes. Now ticket text flows to a model provider, an embedding provider, a moderation API, a tracing tool, and a few copies inside your own database, and nobody has written down where.
This lesson is about knowing, and controlling, where user data goes once AI is involved. You'll map your data flows, learn which questions to ask about each provider's retention and training policies, decide when zero data retention is worth it, redact personal data the model doesn't need, choose where inference runs, and handle consent and deletion in your own product. None of this is legal advice; the goal is to make you a builder who can answer the questionnaire, and who knows when to bring in a lawyer.
Map where user data goes
PII (personally identifiable information) is any data that identifies a person directly (name, email, phone number) or in combination (a job title plus a company plus a city). Support tickets are full of it, and so are most other inputs to AI features.
AI features multiply the copies of that data. A single drafted reply in Deskmate touches all of these:
| Where the data lands | What's there | Who controls it | Typical retention |
|---|---|---|---|
| Model provider request | Ticket text, customer name, help articles | The provider | Per their policy (next section) |
| Embedding provider | Ticket and article text, at index time | The provider | Per their policy |
| Moderation API | Customer messages | The provider | Per their policy |
| Vector store | Chunk text and embeddings | You | Until you delete it |
| LLM traces and logs | Full prompts and outputs | You or your observability vendor | Often "forever" by default |
| Eval datasets | Real tickets copied for testing | You | Often "forever" by default |
| Response caches | Prompts and outputs | You | Until expiry |
Look at the bottom four rows. The model provider is the copy everyone worries about, but your own traces and eval sets frequently hold more personal data, for longer, with weaker access controls. A trace store that keeps every full prompt indefinitely is a second database of customer conversations that nobody designed. Logging and Tracing LLM Calls shows how to capture what you need for debugging while keeping that store under control.
Draw this map for every AI feature, keep it in the repo next to your risk register, and update it whenever you add a vendor or a store. It's also the document your customers' security teams will ask for.