How to Prevent Employees from Leaking Data into ChatGPT

Why blocking doesn't work

The instinct of most security teams is to block. Add chatgpt.com to the deny list, push the config via your proxy, done. Except:

• Employees with 4G or a personal hotspot are invisible to your proxy.
• ChatGPT is embedded in browser extensions (Grammarly, Notion AI, Arc Browser) that don't route through known domains.
• Claude, Gemini, Perplexity, Poe, and 19 other AI tools exist. Blocking one moves traffic to the next.
• Sophisticated users use VPNs or incognito sessions on personal laptops.

Blocking creates the illusion of control while the actual risk continues. The people who most need oversight, the ones who don't know better, will comply. The people who actually understand what they're doing will route around it.

The five-layer defence model

Effective AI data loss prevention requires controls at multiple layers. Here is the architecture that enterprise security teams are deploying in 2025:

Layer 1: Browser-level classification (highest efficacy)

A Chrome extension deployed via Google Workspace Admin or Microsoft Intune sits inside the browser, at the point where data enters the AI tool's input field. It classifies data types (SSN, API key, credit card, customer email) on-device before the content is transmitted, and logs only the classification to a security dashboard.

This approach has several properties that make it uniquely effective:

• Works regardless of network path (WiFi, 4G, VPN)
• Covers all AI domains simultaneously without maintaining block lists
• Produces zero employee privacy risk (raw content never stored)
• Deploys without employee action via force-install MDM policy

Layer 2: Acceptable use policy with teeth

Policies fail when they are vague. A policy that says “do not share confidential information with AI tools” is useless. Employees do not know what “confidential” means in this context.

Effective AI acceptable-use policies specify:

• Exact prohibited data types (customer names+emails, employee records, financial forecasts, API keys, source code above a certain sensitivity classification)
• Approved tools and their approved data tiers (enterprise plans with DPAs only)
• The consequences, both regulatory (GDPR violation) and internal
• Positive examples: what AI can and cannot be used for

Layer 3: Enterprise plans for approved tools

If employees are going to use ChatGPT regardless of policy (and they will), your best option is to route that usage through sanctioned enterprise plans. OpenAI's ChatGPT Enterprise and Team plans disable conversation training and offer a Data Processing Agreement. Google Workspace's Gemini for Business has equivalent terms. These do not solve shadow AI. They reduce the risk of approved tool usage.

Layer 4: Training and awareness

Most employees who share sensitive data with AI tools are not acting maliciously. They are unaware that their inputs may be retained, used for training, or potentially accessible to the AI provider's team under certain circumstances.

A 15-minute training module covering: what the tool retains, what a DPA requires, and concrete examples of prohibited inputs (showing an actual CSV being pasted, for example) dramatically reduces accidental leakage from non-technical employees.

Layer 5: Risk-based monitoring and response

Even with the above controls in place, incidents will occur. The difference between a GDPR fine and a letter you can write to the ICO is whether you had a monitoring system and can demonstrate you identified, investigated, and responded to the incident.

Risk-based monitoring assigns scores to employees based on the severity and frequency of sensitive data detected in AI inputs. High-scoring employees trigger automatic Slack alerts to the security team, enabling targeted intervention rather than reactive forensics.

A realistic 30-day implementation plan

1. Days 1–3: Deploy browser monitoring extension via MDM (silent, no employee action). Begin data collection.
2. Days 4–7: Analyse the first week of data. Identify the top 5 departments and data types by volume.
3. Days 8–14: Draft and review acceptable-use policy with legal. Get board sign-off on the AI risk appetite statement.
4. Days 15–21: Roll out training module to highest-risk departments first. Set up Slack alerts for critical events.
5. Days 22–30: Review week-3 data against week-1 baseline. Report to leadership. Configure approved enterprise AI plans for sanctioned tools.

Measuring success

The metrics that matter for an AI DLP programme are not tool adoption or policy sign-off rates. They are:

• Critical severity events per week (trending down over time)
• Percentage of events involving customer PII (target: zero)
• Mean time to detection for credential leaks (target: under 60 seconds)
• Audit log coverage: percentage of employees with the monitoring extension installed

Tools like AIovert surface all four metrics in the dashboard. The trend chart gives you week-over-week comparison, and the risk score per employee shows whether training and policy changes are having the intended effect.