An Employee Pasted Customer Data Into ChatGPT. Now What?

Key takeaways

Establish what was actually pasted before doing anything else. One redacted email and a 400-row customer export require very different responses.
Deleting the chat limits who can see it inside your account, but vendor-side copies may persist under retention terms. Treat deletion as a step, not the resolution.
Check the account tier and its training setting. A business tier that contractually excludes training on your data changes the exposure picture significantly.
If the data includes personal information about customers or employees, notification obligations may apply — bring in a qualified professional early, because timelines can be short.
Do not lead with discipline. The reporting behavior you want is worth more than the satisfaction of assigning fault.

Someone on your team pasted a customer's information into ChatGPT to get help drafting a reply. They mentioned it in passing, or you noticed it, and now you need to know how bad this is.

Most likely: not very. But "probably fine" is not the same as knowing, and the difference is about an hour of specific work.

Here is that work, in order.

1. Find out what was actually pasted

Everything downstream depends on this, and it is the step people skip in favor of reacting.

Sit with the person and look at the actual conversation. You need:

How much. One support email, or an exported spreadsheet of every customer? This single fact drives the entire response.
Which fields. A first name and a description of a problem is different from names with email addresses, phone numbers, account numbers, dates of birth, payment details, or health information.
Whose. Customers, employees, or a business contact.
Which tool and account. The company workspace, or a personal free login?
When. Today, or six weeks ago?

Ask without heat. You need an accurate account, and you will not get one if the conversation feels like an investigation.

2. Check the account tier and its settings

This changes the picture more than anything else you will find.

Open the account and check:

Which tier is it? Business, team, and enterprise tiers generally commit contractually that customer content is not used to train models. Consumer tiers vary — several major ones default to training on conversations, while at least one requires you to turn it on — so check this tool rather than assuming.
Is training on your data enabled? On consumer tiers this is usually a setting, and its default varies by provider. Check what it was set to at the time, if you can tell.
Who else can see this conversation? In a shared workspace, conversation history may be visible to other members. That is a second, separate exposure.

A business-tier account with training disabled is a substantially better position than a personal free login. If it turns out to be the latter, that is worth noting as a finding of its own — how to read AI vendor terms covers why the tier matters this much.

3. Delete the conversation — and know what that does not fix

Delete it. In a shared workspace this genuinely matters, because it removes ongoing visibility to colleagues who have no reason to see customer records.

But be clear about the limit: vendor-side copies may persist. Most providers retain data for some period after deletion — commonly for abuse monitoring or legal holds — under terms independent of what your interface shows. Deletion reduces your internal exposure. It does not undo the transmission.

So do not let deletion end the process. Record what was exposed, because that record is what you will need if questions come later.

4. If credentials were involved, stop and rotate them

If the paste included an API key, password, access token, or connection string, that is a different and more urgent situation. Rotate the credential now, before continuing with the rest of this list. Exposed credentials are actively exploitable; a leaked customer email is not.

5. Decide whether this needs outside help

Here is the honest boundary of what you should resolve internally.

If the data was a small amount of low-sensitivity information — a first name, a description of a problem, no contact details — you are likely in log-it-and-improve-the-process territory.

If it included personal information about identifiable customers or employees, and particularly if it included health information, financial account details, government identifiers, or a significant volume of records, then whether you have a notifiable event is a legal question that depends on your jurisdiction, your industry, and the specifics of what was exposed.

Bring in a qualified professional at that point, and do it early. Notification timelines in some regimes are measured in days from awareness, and a week of internal deliberation can consume the window. This is not a matter to reason out from a blog post — including this one.

6. Write it down today

Six fields, while the details are still accurate:

Date and time it happened, and when you learned of it
Who was involved
Which tool, account, and tier
Exactly what data was involved — volume and fields
What you did in response
Whether you sought professional advice, and what was concluded

This log is not paperwork for its own sake. If a customer or regulator asks in six months, a contemporaneous record of a proportionate response is a materially better position than a recollection.

7. Fix the cause, not the person

Ask why it happened, and take the answer at face value:

They did not know it was a problem. The most common answer by a wide margin. This is a training gap, and a fifteen-minute briefing addresses it. Prompt safety tips covers the habits worth teaching, starting with redacting identifying details before pasting.

They knew but had no approved way to do the task. The second most common. If redacting the data would have taken twenty minutes on a deadline, the rule lost to reality. Fix that by giving people a workable path — an approved tool with acceptable terms, and permission to use it for that task.

There was no rule. Then write one. It does not need to be long: no credentials, no customer PII, no internal financial data, approved tools only. How to write an AI usage policy covers the one-page version.

And resist opening with discipline. The employee who told you about this is the reason you can respond at all. Make that expensive and the next incident surfaces in a quarterly review instead of within the hour — which is the genuinely costly outcome. If there is a real pattern of disregarding clear rules, handle it separately and later.

Prepare for the next one before it happens

You now know what this process looks like. Writing it down as a one-page procedure means the next time it is not improvised — AI incident response for small businesses covers the four incident types and severity bands, and the small business AI governance checklist shows where the incident log sits among the other controls worth having.

Reduce the odds of a repeat

The Prompt Safety Checker checks a draft prompt for credentials, personal data, and internal financial information before anyone sends it — free, no account, running entirely in your browser so nothing you paste into it is transmitted anywhere.

For an incident response procedure, an incident log, data input rules, and employee guidance you can distribute as-is, see the Starter Pack.

This article provides practical operational guidance for AI usage management. It is not legal advice and does not guarantee regulatory compliance. Data breach notification requirements vary significantly by jurisdiction and industry — consult qualified professionals about obligations that apply to your business.