Do AI summaries of tickets remove personal data?

Do AI summaries remove personal data from tickets?#

AI summaries do not reliably remove personal data from tickets, because summarization is designed to preserve the important facts and personal details are often part of them. A ticket about a billing error at a named hardware store, with an account number and a callback phone, tends to produce a summary that mentions the store, the account and the callback.

Instructions such as leave out personal information reduce leaks rather than eliminate them. Models apply instructions unevenly across large ticket volumes, and a rare failure repeated across a whole help desk archive becomes a real exposure that nobody sees without checking.

Summaries also change the product. Many AI buyers license support history to learn how agents diagnose and resolve problems over several turns. A one-paragraph summary removes the turn-by-turn reasoning that made the records worth licensing in the first place.

What summaries keep and what they drop#

Summaries keep details that look central to the issue and drop conversational filler. That pattern is predictable, which makes it testable, and it explains why the riskiest details tend to survive.

Summaries can also hallucinate: a model may attach a plausible name, date or product to the wrong ticket, or merge two customers' issues into one. That creates inaccurate personal data, which becomes its own problem when records are licensed with accuracy or provenance representations.

How to test a summarization pipeline before relying on it#

Testing a summarization pipeline means measuring what it misses on tickets where the answer is already known. Automated detection helps, but it cannot be the only check.

• 1Build a test set of real tickets, reviewed by hand, with every personal and confidential detail marked.
• 2Include hard cases: names in signatures and body text, nicknames, misspellings, and identifiers inside pasted logs or screenshots.
• 3Run the pipeline and compare each output against the marked details, ticket by ticket.
• 4Run an automated detector over the outputs as a second check, and review its misses by hand.
• 5Look for indirect identifiers: small-company names, unique incidents, exact dates and locations.
• 6Repeat the test whenever the model, the prompt or the ticket source changes.

Why automated detection needs a human check#

Automated PII detection is a useful layer, and its own maintainers describe its limits. Presidio, an open-source SDK for detecting and anonymizing PII in text and images, warns in its documentation that automated detection cannot be counted on to find all sensitive information and that additional systems and protections should be used. The project is now community-governed under the Data Privacy Stack organization rather than owned by Microsoft.

The same caution applies to a summarization model used as a de-identification step, with an extra weakness: a detector reports what it found, while a summarizer silently decides what to keep. Human review of a sample, focused on the cases the tools are worst at, is what turns a pipeline into something a privacy lead can sign off.

Redact first, summarize second#

Redacting before summarizing is the safer order because the model never sees the details it might repeat. It also leaves a clean, de-identified version of the full thread, which is often the more useful dataset.

A redaction pass for tickets should cover the structured fields (requester, organization, assignee), the message bodies, attachments and the internal notes agents add, which often hold the most candid details. Replace identities with consistent tokens so the thread still shows that the same customer wrote back and the same agent escalated, and keep the token key inside the company.

Where the model runs matters too. Sending raw tickets to an external model API is a disclosure to that provider, so its retention, training and subprocessor terms need the same review as any other vendor that touches customer records.

Illustrative: a SaaS team tries summarize-to-anonymize#

Illustrative: a fictional B2B software company with years of Zendesk tickets and Intercom chats wants a quick way to prepare its support history. An engineer builds a pipeline that summarizes each ticket with a hosted model and instructs it to omit personal information.

A manual review of a sample finds that summaries routinely keep business customer names and order numbers, and occasionally a contact's name when the customer complained about a specific person. A few summaries merge two customers' problems into one. The CTO stops the pipeline, moves detection and redaction ahead of any model call, runs redaction on the company's own infrastructure and keeps the redacted full threads as the licensing candidate. Summaries become an optional extra, generated only from redacted text.

How SourceX approaches summaries#

SourceX treats summarization as a transformation to document, not as de-identification. In the Preparation step of the SourceX five-step transaction, ticket threads are de-identified first, including internal notes and attachments, and checked by people as well as tools; any summaries a buyer asks for are generated only from that treated text.

Whether a package contains full threads, summaries or both is settled with the buyer before Preparation starts, because the choice changes both the value and the review effort. The summarization step, the model used and the sample review results are then listed alongside the redaction method in the SourceX Evidence Packet.