An engineer pastes part of a configuration file into an AI chat to find a bug — together with the access key to the production database. A lawyer uploads a customer contract because she needs it compared with a template. A salesperson asks an assistant to tidy up a CRM export with names and phone numbers. These scenarios are illustrative, but typical. None of these events is an attack, and none of them will trigger an alert in a system that watches e-mail and USB drives.
A data leak to ChatGPT and other AI assistants is first of all a problem of controlling data and accounts, not of the tool itself. Here we show how data reaches AI services, where the capabilities of classic DLP end and how AI data loss prevention combines four layers of control — business accounts, browser and endpoint controls, CASB and data classification — without pushing employees towards tools the company cannot see at all.
How do data leaks to ChatGPT and other AI assistants happen?
Data leaks to ChatGPT and other AI assistants usually happen without an attack: the employee hands the information to a service the company does not control. There are more channels than the chat box.
The most common channel is the prompt, that is, pasted text: a fragment of a document, correspondence, code or a table. The second is an uploaded file — a contract, a presentation, a spreadsheet. The third is connectors and integrations to which the employee has granted access to the drive, mail or calendar. The fourth is browser extensions with AI features that read the content of open pages. The fifth is the API: keys created on personal accounts and used in scripts that send data to the model, bypassing the browser.
The OWASP GenAI Security Project describes this risk as LLM02:2025 Sensitive Information Disclosure in the OWASP Top 10 for LLM Applications 2025. The list covers personal data, financial and health data, confidential business data, credentials and legal documents, and the document warns that sensitive data provided unintentionally may later be disclosed in the model’s output.
One question is decisive: did the data reach a tool with which the company has a contract and over which it has administrative control? If not, the company does not know how long the data is stored or who has access to it.
How does AI data loss prevention differ from classic DLP?
AI data loss prevention applies the same data leak protection principles to a channel classic DLP usually did not cover: text pasted in the browser into AI services. You will find the definition of the system itself in the DLP glossary entry, and the overall strategy — classification, channels, approaches and an implementation plan — in the article on data leak protection and DLP strategy.
Classic policies watch e-mail, removable media, printing and file transfers. Data reaches AI tools mainly as fragments of text rather than whole files, over encrypted connections to many different domains. On top of that comes a problem no configuration will solve: an employee can summarise a confidential document in their own words, and a pattern-based rule will not recognise the paraphrase.
The limits are visible even in vendor documentation. In its endpoint DLP settings documentation (page dated June 2026), Microsoft states that the Service domains list applies only to file uploads to websites, and that pasting into a browser does not follow that list. The same page says the paste to browser action does not support advanced classification, such as exact data match or trainable classifiers. In practice, pasting is therefore protected by simpler sensitive information types, such as document and card numbers, rather than by recognising “this is our tender offer”.
Key takeaways:
- Data reaches AI mainly as pasted text rather than files — a channel classic DLP policies often overlook.
- No pattern-based rule will recognise a paraphrase of a confidential document.
- Paste and file upload controls have different limits — check them before designing the policy.
What data most often ends up in AI tools?
The data that most often ends up in AI tools is whatever the employee needs help with right now: code, documents, correspondence and system exports.
In technical teams it is source code, logs and configuration files, and with them secrets: API keys, passwords and connection strings. In sales and customer service — CRM exports, correspondence and offers. In legal and procurement — contracts, commercial terms and tender documentation. In HR — candidate and employee data, appraisals and HR correspondence. In finance — results before publication, budgets and analyses.
Each of these groups carries different consequences. Secrets open the way into systems, personal data triggers GDPR obligations, and contracts and offers may breach confidentiality clauses and trade secret protection. That is why controls are designed by data class, not by tool — tools change, data classes stay.
How do personal accounts differ from business plans of AI tools?
A personal account is a contract between the employee and the vendor, a business plan is a contract between the company and the vendor; that determines who decides about the data. On a personal account, the company does not set retention, does not see logs and cannot revoke access when the employee leaves.
Business plans usually add account administration, single sign-on, a data processing agreement and settings for history, retention and the use of data for training. The details differ between vendors and change over time, however, so do not infer them from the plan name. Before deciding, check the current documentation and the contract: whether data from prompts and files is used to train models, how long it is stored, where it is processed, which subprocessors have access to it, whether the administrator has logs and export, and whether connectors and conversation sharing can be switched off. Record the date of the check — it is your evidence of due diligence.
In its description of LLM02:2025, OWASP recommends that owners of LLM applications clearly describe in their terms of use the option of excluding user data from model training. If a vendor does not answer these questions clearly, that is also information.
A business plan also puts the legal side in order: Article 28(1) of the GDPR requires the controller to use only processors providing sufficient guarantees, and that cannot be demonstrated for an employee’s personal account. A business plan will not stop anyone who pastes the same data into another service, however — which is why further layers are needed.
How do you control data uploads to AI in the browser and on endpoints?
Browser and endpoint controls work closest to the user: they warn or block when recognised sensitive data is pasted or uploaded to an AI service.
Microsoft Purview is one example. According to the Purview documentation for AI apps (page dated May 2026), Windows computers onboarded to Purview can have endpoint DLP policies that warn or block users from sharing sensitive information with third-party generative AI sites in the browser — for example, pasting credit card numbers into ChatGPT. Endpoint DLP has separate actions for pasting into the browser, which evaluate the pasted content regardless of how the source file is classified, and for uploading files to restricted domains (Microsoft Learn, August 2026). The default DSPM for AI policies use the “Generative AI Websites” group, which cannot be edited or deleted. Microsoft Edge for Business enforces Purview DLP policies directly in the browser, including blocking the sharing of sensitive information with unmanaged generative AI apps (Microsoft Learn).
Other platforms have similar mechanisms under their own names, but every control has a limit worth knowing before you promise the board to “stop the leaks”:
| Leak channel | Control | Limit of the control | Who is responsible |
|---|---|---|---|
| Pasted text | Browser or endpoint DLP for AI service domains | Recognises only the data types described in the policy; will not detect a paraphrase | Security and the data owner |
| Uploaded file | Blocking uploads to domains outside the list, label-based rules | Works in browsers and on devices covered by the policy | Security and IT |
| Connectors and integrations | Restricting OAuth consents and reviewing granted permissions | Does not see what the vendor does with the data on its side | Identity team |
| Browser extensions | Allowed extensions list in the managed browser | Extensions installed earlier have to be removed separately | Endpoint IT |
| API and scripts | Centrally issued API keys, secrets kept out of code, repository scanning | Keys on personal accounts remain outside control | Development teams and security |
| Personal devices | Access to company data only through a managed browser or a controlled session | Will not stop data being retyped by hand | IT and security |
How do CASB and SSE help control AI apps?
A CASB and SSE platforms control AI apps at the service level: they show which ones the company uses, let you sanction or block them and control actions during a session. They complement endpoint DLP with a view of the whole organisation.
The first function is visibility and decision: which AI services are in use and which of them the company allows. The detailed process — DNS and proxy logs, app categories, extensions and OAuth consents — is described in the article on how to detect and reduce shadow AI. The second function is session control. In Microsoft Defender for Cloud Apps, session policies let you allow access to an app while monitoring the session and block selected actions, for example copying to the clipboard (Microsoft Learn, June 2026). This is useful especially for access from unmanaged devices.
Other vendors’ SSE platforms offer similar inline controls, but feature names and the range of supported AI apps differ — check them in your platform’s documentation, not in marketing materials.
How do data classification and labels support AI controls?
Without data classification, DLP controls have nothing to enforce: a rule has to know what is confidential in order to warn or block. Data classes should follow from the rules the company has already adopted — the AI acceptable use policy says which classes may be entered into which tools.
Sensitivity labels applied to documents give more precise rules than content patterns, because they describe what a document means, not just what it looks like. They work best for files: an upload rule for an AI service can be based on the document’s label rather than on patterns in its content. When a fragment of text is pasted, the label of the source file does not always follow the content, so this layer complements content-based DLP rather than replacing it. The general principles of building a classification scheme are covered in the article on data classification in the organisation.
Labels also work inside office suites with a built-in AI assistant. Microsoft Purview DLP, for example, lets you restrict Microsoft 365 Copilot and Copilot Chat from processing files and e-mails with sensitivity labels (Microsoft Learn, November 2026). The details of permissions and labels in that environment are covered in the article on Microsoft 365 Copilot security.
The last technique is masking data before it reaches the model. In LLM02:2025, OWASP lists tokenization and redaction, that is, detecting and removing confidential content before processing, and Article 32(1) GDPR lists pseudonymisation among the security measures appropriate to the risk. In company applications that use models through an API, masking is often simpler to implement than any browser control.
How do you match AI DLP controls to the level of risk?
Controls are matched to the data class: the higher the class, the fewer tools allowed and the firmer the response to an attempt to pass the data on. The table shows an example mapping — replace the classes and tools with your own.
| Data class | Risk with AI tools | Control | Example tool | Evidence of effectiveness |
|---|---|---|---|---|
| Public | Low | No restrictions, company account recommended | Approved AI tool | AI use rules |
| Internal | Disclosure to a third party | Only approved tools on company accounts | CASB, single sign-on | Report on the share of company accounts |
| Confidential: contracts, offers, finance | Breach of confidentiality clauses and trade secrets | Warning with justification on paste and upload; only tools under contract | Browser or endpoint DLP | Log of warnings and justifications |
| Personal data | GDPR breach and notification duty | Block in tools without a data processing agreement; pseudonymisation before the model | DLP with sensitive information types | DLP event log, data processing agreements |
| Secrets and code | System compromise | Block; secret scanning; centrally issued API keys | DLP, secret scanner in repositories | Scan results, key rotation |
| Specially protected data | Regulatory sanctions and loss of customer trust | Prohibited outside tools approved for this class | DLP and sensitivity labels | Quarterly review of exceptions |
The table also has a legal dimension. If personal data has reached a tool without a data processing agreement, the controller must assess whether a personal data breach has occurred — Article 33(1) GDPR then requires notification to the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of it, unless the risk to individuals is unlikely. Entities covered by the NIS2 directive should remember that Article 21(2)(d) lists supply chain security, including relationships with direct service providers, among the cybersecurity risk-management measures — and an AI tool vendor is such a service provider.
Key takeaways:
- Design controls by data class, not by tool name.
- Warning mode with a justification shows the scale of the problem before you switch on blocking.
- Personal data in a tool without a data processing agreement is a signal to assess a breach under Article 33 GDPR.
How can nFlo help assess controls against data leaks to AI?
A review of controls against data leaks to AI tools is part of the shadow AI assessment and AI use policy service. nFlo establishes which AI tools teams use and what data goes into them, and then checks which existing rules, CASB settings and identity settings actually stop those flows. The outcome is a list of control gaps and rules for AI use, not another tool to buy.
The assessment belongs to the area of AI security, where cybersecurity meets governance, risk and compliance. You will find more articles in the AI security knowledge base, and an assessment of the tool itself from the user’s perspective in the article is ChatGPT safe. The background of the phenomenon is also described in the shadow AI glossary entry. Want to check what your controls stop today? Contact us.
What else is worth knowing about AI data loss prevention?
Does a ChatGPT business plan solve the data leak problem?
Only partly. A business plan usually provides account administration, single sign-on and a contract with the vendor, but it will not stop an employee who pastes the same data into another tool or a personal account. Training and retention terms have to be checked in the vendor’s current documentation and in the contract, and data controls kept in place regardless of the plan.
Is a classic DLP system enough to protect data from AI?
Usually not in its current configuration. Classic rules watch e-mail, removable media and file transfers, while data reaches AI tools mainly through text pasted in the browser. The policy has to cover AI service domains, the paste action, browser extensions and integrations.
Does a personal data leak to ChatGPT have to be reported to the supervisory authority?
If the event is a personal data breach, Article 33 GDPR requires notification to the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of it, unless the breach is unlikely to result in a risk to the data subjects. The controller carries out the assessment with the data protection officer.
Can you completely block pasting data into AI tools?
On managed devices and in browsers covered by the policy you can block pasting and uploading recognised sensitive data to AI service domains. A complete block is impossible, however: personal devices are outside the reach of policies, and no rule will recognise text that was retyped by hand or summarised.
Where should you start protecting data from leaks to AI?
Start by establishing which AI tools employees use and what data goes into them, then move on to data classification and an approved tool on company accounts. DLP controls are best switched on in warning mode first, with blocking enabled for the highest data classes.
