How Do I Stop Staff Pasting Customer Data Into ChatGPT?

This is the question that arrives after someone in the business has already done it, usually with something they should not have. The instinct is to block the site by Monday. That instinct is understandable and it makes the problem harder to see without making it smaller, so it is worth working through what each available control actually does.

Why does blocking ChatGPT not solve this?

Blocking the domain removes your visibility without removing the behaviour. The person still has the deadline that made them reach for the tool, so the work moves to a personal phone or a home laptop where there is no logging, no data loss prevention, and no possibility of an audit trail.

It also fails on reach. There are dozens of capable alternatives, several of which are embedded inside software your organisation already licences, so a blocklist becomes a maintenance task nobody owns after the first quarter.

Why does our existing DLP not catch a paste?

Because document data loss prevention, the practice of detecting sensitive content before it leaves the organisation, is built to watch files. A paste is not a file. It never becomes an attachment, never touches a mail server, and never gets written to disk on the way out.

The same limitation applies to most of the security stack, and it is worth stating plainly because it explains a great deal of confusion. Each control observes a different object.

• Application allowlisting observes processes. A browser tab is not a process.
• Firewalls and traffic platforms observe flows. A flow shows a destination, never an intent.
• Document DLP observes files. A pasted paragraph is not one.
• TLS inspection observes payloads in transit, and only after the page has already assembled them.

None of them takes the in page interaction as the object. Forrester found more than 70% of corporate work now happens inside a browser (Source: Forrester, Digital Workplace and Employee Technology Survey 2025), which is why so much of the exposure sits in the one place nothing was watching.

What does controlling the paste itself actually look like?

It looks like a decision made at the moment of paste, inside the page, before the content reaches the tool. The control reads what is about to be submitted, classifies it, and applies a rule to that specific content rather than to the destination.

In practice that produces four different outcomes rather than one, which is what makes it usable.

1. Allow. Most pastes are unremarkable and nothing should happen.
2. Warn and confirm. Borderline content gets a prompt naming what was detected. This changes behaviour more than blocking does, because it teaches rather than obstructs.
3. Redact. Strip the customer identifiers and let the rest through, so the person still gets their answer.
4. Redirect. Send them to the sanctioned tool with the paste intact.

Why is redirecting better than blocking?

Because it moves usage into the light instead of underground. A hard block tells a person that the tool is the problem and leaves them to solve their deadline elsewhere. A redirect tells them where to do the same thing safely.

This is the single behavioural difference worth designing for. Controls that staff route around produce no data and no compliance. Controls that give people a working path produce both, and the people being governed stop noticing them.

Does this need us to ban personal accounts?

Not ban, but you do need to be able to see them, and today most organisations cannot. Akamai measured 47.11% of enterprise AI conversations running through personal identities rather than corporate managed accounts (Source: Akamai, State of the Internet: Enterprise AI Usage Risk Report 2026, August 2026).

That figure is usually quoted backwards, so read it carefully. It is not saying half of staff use AI on their work email. It is saying close to half of the activity is happening under identities your identity provider has no relationship with, which is why single sign on reports look reassuring and are not.

What about the Australian privacy obligation?

If the pasted content is personal information, the Privacy Act obligations that apply to your handling of it do not stop applying because the destination was a chat box. That is the exposure worth quantifying, and it is usually a small fraction of total AI usage rather than the whole of it.

Which is the argument for measuring before legislating internally. A policy written without knowing what is actually being pasted tends to prohibit broadly, which produces the personal phone problem, and misses the specific flows that carry real obligation.

What should we do first?

Run a read only observation for two weeks before changing anything. You want to know what is genuinely being submitted, by roughly how many people, through which accounts, and how much of it carries customer or personal information.

Then set rules against the small slice that matters rather than the whole surface. In our experience the output splits three ways: a majority that is fine and should be sanctioned, a middle group that needs a warn and confirm, and a small number of flows worth stopping outright.

What tool controls the paste rather than the domain?

One that runs inside the page. Akamai Workforce Protector is what we deploy for this, through an extension covering Chrome, Edge, Firefox and Safari, with an optional endpoint agent when coverage needs to extend to desktop AI applications and AI enabled IDEs.

Two things matter to whoever reviews the decision. It installs through the device management you already run, with no proxy and no traffic redirection, so nothing needs re-architecting. Classification happens inside the browser, and Akamai's position is that content, including personal information, stays there while only alerts reach the cloud console. For a privacy officer, that is an architectural answer rather than a contractual promise.

How does David and Goliath help?

We run the two week observation, read the output, and turn it into rules your executive can sign and your staff will not route around. That usually means far fewer prohibitions than the first draft of a policy contains, and much sharper ones.

If you have not yet established what is in use, start with how to find out what AI tools your staff are actually using. If the debate internally is still about whether to ban the tools at all, how to govern AI use without banning the tools is the argument to bring.