HomeServicesPortfolioAboutContactBlogCareers
Book a call
E-commerce

How AI Support Agents Handle Customer Data: PII in Prompts, Logs, and Transcripts

September 2026 · ISTRALLEN Team

The data surface is wider than the chat window

An AI support agent touches more personal data than the conversation shows. AI support agent data privacy is about knowing every place customer information lands — the prompt sent to the model, the retrieval index, tool-call arguments, transcripts, logs, the escalation payload, analytics — and having a defensible answer for retention and deletion at each one.

Where PII flows

  • The model context. Whatever you put in the prompt goes to the model provider — name, email, order history, address, the customer's own messages (which can contain anything they paste).
  • Tool calls. Arguments and results — an order lookup returns an address; a refund call carries an amount and an order ID.
  • The knowledge base. Usually policy text, but check nothing customer-specific leaked into it.
  • Transcripts and logs. The full conversation, plus application logs and error traces that may capture request payloads.
  • The escalation payload. Transcript and collected data handed to a human console.

Minimise what reaches the model

Pass the fields a step actually needs, not the whole customer record. The agent needs "this order's status" and "the returns policy," not the full profile and lifetime value. Redact free-text where you can. A smaller context is cheaper, and it shrinks the data you've shared with a sub-processor.

Sub-processors

The model API is a sub-processor. Know the data-processing terms: retention on their side, region, and whether prompts and outputs are used to train their models — on most API and enterprise tiers they are not, but confirm it and opt out where the option exists.

Retention and deletion

Transcripts and logs need a retention policy and a deletion path that actually reaches every store — the transcript database, the log aggregator, analytics, and backups as they age out. An erasure or data-subject request has to be executable, which means designing for it: one retention policy, one deletion routine per store, not "we'll figure it out when someone asks."

Logging discipline

Keep a structured audit record of tool calls and outcomes for dispute resolution. Keep PII out of application logs and error traces, which have wider access and looser retention. On our support agent project every action writes an audit record — which customer, which tool, what arguments, what result, and the agent's stated reason — and that record is the deliberate, access-controlled place customer data lives, separate from debug logging.

Walk a deletion request through

The test of the design is a single question: a customer asks you to erase their data — can you? Trace it. The transcript store has their conversations, keyed how? The audit records reference the customer ID — do those get anonymised or removed, and does that break the append-only guarantee you need for disputes? The log aggregator may have request payloads with their email in them. Analytics has aggregated events, some possibly identifiable. Backups hold copies of all of it until they age out. If you can't name the routine that handles each of those, the request isn't executable yet — and that's a gap to close before launch, not after the first request arrives.

Consent and disclosure

Tell customers they're talking to an AI assistant, and make sure your privacy notice covers the processing — what's collected, where it goes, how long it's kept. If a conversation will be reviewed by a human on escalation, that's part of the processing to disclose.

Where this stops being right

  • Scale to sensitivity. An apparel store's data surface is not a pharmacy's — health, financial, or children's data raises the bar.
  • Jurisdiction sets the specifics. GDPR, UK GDPR, CCPA and others differ on retention, consent, and deletion timelines — confirm with counsel.
  • A purely informational bot that never reads a customer record has a much smaller surface and a lighter version of this list.

FAQ

Does the model provider train on our support conversations? On most API and enterprise tiers, no — but check the terms for your tier and opt out where offered.

Can we honour a deletion request if transcripts are spread across systems? Only if you designed for it — one retention policy, a deletion routine for each store, and backups that age out. Retrofitting this is painful.

Should the agent see full payment details? No. The last four digits at most, and only if a tool genuinely needs them. Full card data should never enter the model context.

ISTRALLEN builds support agents with data minimisation, a structured audit trail, and a real deletion path designed in; see AI for E-commerce.

See it in production
AI for E-commerce → Support agent case study →
← All articles