Summarising support tickets with AI, without shipping the customer

Support transcripts are an obvious candidate for AI summarisation. They are long, repetitive, and full of things a model is genuinely good at extracting: the actual complaint, the resolution, the sentiment.

They are also the densest concentration of other people's personal data most teams touch, and the person whose data it is never agreed to any of this.

What redaction handles well here

Transcripts are rich in exactly the formats pattern matching is reliable at. In a typical ticket you can expect the customer's email address, a phone number, sometimes an order or account reference, and occasionally a password the customer pasted because they misunderstood a request.

Emails and phone numbers are caught by the default rules. The password case is worth calling out because it happens more than people expect, and it produces a transcript where a customer's actual credential sits in your ticketing system.

The two things it will not touch

Names. "I spoke to Priya and she said the refund was approved" contains a person, a claim about a colleague, and no pattern whatsoever. Names are the single most common identifier in a transcript and the least detectable.

Circumstances. A support conversation frequently reveals why someone contacted you: a bereavement causing an account transfer, a medical situation behind a cancellation, financial hardship behind a payment plan. Redacting the email address does nothing about a sentence describing someone's illness, and in most privacy regimes that sentence is a more sensitive category than the address was.

A workable approach

Rather than redacting a transcript and hoping, change what you send.

Summarise structurally, not verbatim. Instead of pasting a full transcript, paste the parts that carry the question. "Customer reports checkout fails at payment step with error 402, using Safari" contains the entire technical content of a ticket and no personal data at all.

Batch by pattern rather than sending individual cases. If the question is "what are people complaining about this week", you need the complaints, not the conversations. Extract the complaint lines, redact, then summarise.

Check whether you are allowed to do this at all. If you handle EU customers, transcripts are personal data and sending them to a third-party processor has requirements: a lawful basis, a processing agreement, and a record of it. Redaction reduces the exposure but does not by itself make the processing lawful. This is a question for whoever owns privacy compliance at your organisation, and the honest answer is that it is above what any tool can decide for you.

The asymmetry worth remembering

When you paste your own API key, you are taking a risk with your own asset and you will deal with the consequences.

When you paste a customer's transcript, you are taking a risk on behalf of someone who is not in the room, did not agree, and will not be told. That asymmetry is a good reason to be more careful with other people's data than with your own, and it is the reason "other people's private details" is on the manual checklist rather than left to the rules.