The hard boundary most companies refuse to face
Public LLMs are sealed systems. No enterprise, regulator, or court can inspect who submitted which prompt to OpenAI, Anthropic, Google, or Perplexity. There is no backdoor. There is no audit API. There is no retroactive proof mechanism. Once sensitive data crosses that boundary, attribution is probabilistic at best and legally weak at worst.
This single fact defines the security reality of the AI era. If your strategy depends on checking what went into a public LLM, your strategy is already broken.
The real control surface is not the model
The real control surface is the environment the employee operates in, not the model they talk to. Data leakage is not an AI problem. It is a network, device, and governance problem. LLMs are just high-efficiency extraction interfaces.
You cannot observe what the model stores. You can, however, observe what your systems transmit. That is the only layer you truly control.
What is actually detectable
You can detect:
- Which employee device accessed a public LLM site
- When and how often access occurred
- How much data left the network
- Whether transmitted data matched sensitive patterns
- Which files were accessed immediately before transmission
You cannot detect:
- Whether the model retained the data
- Whether the data was used in further training
- Whether it will reappear in future outputs
- Which staff at the model provider could access it
Detection exists only on your side of the boundary, never after it.
The only defensible technical stack
A credible approach is layered, with each layer handling a different part of the causal chain from employee intent to data exfiltration.
1. Network-level telemetry
Firewalls, secure web gateways, and DNS logging provide behavioural visibility. They track which domains are accessed, how often, and by whom. Typical domains include:
- chat.openai.com
- api.openai.com
- claude.ai
- gemini.google.com
- perplexity.ai
This layer reliably answers three questions: who used public LLMs, at what frequency, and from which device. It does not inspect content. It maps risk posture.
2. Data Loss Prevention as the core control
Data Loss Prevention (DLP) is the only mechanism that directly controls content rather than behaviour. It scans outbound data in real time for:
- Identity numbers and personal identifiers
- Financial records and statements
- Customer or client databases
- Contracts and legal documents
- Pricing models and commercial terms
- Source code and internal repositories
- Internal strategy documents and language patterns
DLP can then enforce:
- Blocking copy-paste into browser fields
- Preventing file uploads to unknown services
- Masking or redacting sensitive fields
- Triggering real-time alerts to security teams
Without DLP, AI policy is largely ceremonial. It exists on paper, not in the data path.
3. Endpoint telemetry closes the human loop
Endpoint monitoring ties behaviour to specific user actions. It can observe sequences such as:
- An internal document or system is opened
- Sections of content are copied
- A browser tab with a public LLM is focused
- Data is transmitted out of the environment
This sequence reveals intent and context. Attribution does not come from the LLM side. It comes from reconstructing what the user did on the endpoint.
4. Watermarking and honeytokens enable attribution
You can embed synthetic markers inside internal content:
- Uniquely phrased sentences in strategy decks
- Fake but realistic client entries in CRM exports
- Controlled financial tables and assumptions
- Distinctive wording in confidential memos
If these markers later appear in:
- Public AI-generated outputs
- Competitor material
- Leaked documents on the open web
You gain forensic evidence that data has leaked and a strong indication of where the leak originated.
Why policies alone fail
Policy without telemetry delivers three failures in a row:
- No reliable detection of violations
- No credible attribution to individuals or systems
- No enforceability that stands up to internal review or external scrutiny
Once data leaves the environment, there is no technical recall. Only legal exposure remains. For that exposure to be manageable, the policy must be explicit, signed, and backed by live controls that show you actively tried to prevent the breach.
Anything softer is theatre intended to comfort management, not protect data.
The behavioural risk curve
Leakage risk is not evenly distributed. It clusters where speed and pressure are highest, for example:
- Sales teams under aggressive quota pressure
- Marketing teams trying to produce content faster
- Junior developers relying on public AI copilots
- Finance teams analysing spreadsheets in browser-based tools
- Legal teams summarising long-form contracts externally
The pattern is simple. Wherever “just paste it into ChatGPT” feels like the fastest route to progress, you have concentrated risk.
What does not work, regardless of budget
Some ideas are attractive but structurally unsound, regardless of how much money is available:
- Asking model providers to supply detailed prompt logs per employee
- Relying purely on trust-based or honour-system compliance
- Running occasional manual spot audits on devices
- Using NDAs as the primary protection against misuse
- Relying on “we anonymise before pasting” patterns that are often reversible
These approaches break under real operational pressure and time constraints.
The correct mental model
Public LLMs should not be treated as internal tools with slightly weaker controls. They are more similar to public broadcast channels with zero transparency once data is submitted.
Once your data touches a public LLM, the risk profile shifts from internal governance to external litigation and regulatory exposure. That shift is one-way.
The executive reality in one table
The practical question is not whether you can investigate ChatGPT. You cannot. The question is whether you can investigate your own infrastructure with enough fidelity to demonstrate control.
| Lever | Function |
|---|---|
| Network logging | Behaviour visibility over who uses public LLMs and how often |
| DLP | Content enforcement that stops sensitive data crossing the boundary |
| Endpoint telemetry | Reconstruction of user actions for attribution and root-cause analysis |
| Watermarking | Evidence that specific internal assets have leaked externally |
| Legal policy | Authority to act on violations and prove due diligence |
Remove any one of these levers and accountability collapses. Either you cannot see violations, cannot prove who caused them, or cannot act decisively when they occur.
Final principle
Data leakage into public LLMs is not fundamentally an AI governance problem. It is a failure of internal control design.
Control the environment. The model is just the exit door.