{"author":{"@type":"Person","name":"Alexander Bock","url":"https://abxk.ai/en/autor/alexander-bock/"},"categories":["AI Security"],"content":{"markdown":"A service agent pastes a customer complaint into a free chatbot to get a friendlier reply: name, address and order history included. A colleague in legal uploads a contract draft to a PDF summarizer she found through a search engine. Nobody wants to cause harm. But the data now sits with providers your company has no contract with, under terms nobody has read.\n\nThis is part 2 of Level 2 in our AI Security learning path. Level 0 explained [what happens to your data in an AI chat](/en/ai-security/learn/what-happens-to-your-data-in-ai-chats/). This part takes the company's view: which controls keep sensitive data where it belongs when a whole team uses AI tools. You will learn the main leak paths, how approved accounts, masking, data loss prevention, access rights, logs and contracts work together, and in which order to set them up.\n\n## Where data leaks when people use AI tools\n\n**Data leakage** means that sensitive data ends up where it should not be: with a provider you have no contract with, in a model's training data, behind a public link or in front of a colleague who should not see it. With AI tools, it rarely takes an attacker. It happens on five paths:\n\n![Five leak paths as cards: unapproved tools, the provider's processing, sharing and connections, too much internal access, copies in outputs and logs; a sixth card says controls should make the safe way the easy way](/images/learn/en/data-leakage-controls-for-ai-tools-paths.webp \"Five ways sensitive data leaves controlled space when people use AI tools.\")\n\n- **Unapproved tools.** Someone uses a personal account or a random web tool. Your company has no contract, no admin settings and no way to have the data deleted later.\n- **The provider's processing.** Even approved tools store prompts and files for some time. Depending on the plan, people at the provider may review samples, and inputs may be used for training.\n- **Sharing and connections.** Shared chat links, plugins, connected apps and agents pass data on to further services.\n- **Too much internal access.** A company assistant that searches internal files shows each user what that user is allowed to open. That includes the salary list that someone shared with the whole company by mistake. Experts call this **oversharing**.\n- **Copies in outputs and logs.** Generated documents, chat histories, exports and logs keep copies of the data long after the task is done.\n\nNo single control closes all five paths. That is why companies stack several layers, from rules for people to technical checks. Each layer catches some of what the layer above misses:\n\n![Six control layers stacked from top to bottom: rules and training, approved tools, masking before the prompt, DLP and browser controls, access rights, logs and contracts; approved tools is highlighted](/images/learn/en/data-leakage-controls-for-ai-tools-layers.webp \"The control layers of this guide. The highlighted layer prevents the most leaks: a good approved tool.\")\n\n## Start with approved tools and safe settings\n\nThe most effective control is an approved tool that is good enough for the job. If people have a business account with sensible settings, they have little reason to paste data into random websites. Part 5 of this level shows how to deal with [shadow AI](/en/ai-security/learn/shadow-ai-in-companies/), the unapproved tools that are already in use.\n\nBusiness and enterprise plans of the large providers usually come with a contract, central administration and, by default, no training on your data. Check the terms of your specific plan, then go through the admin settings before the rollout:\n\n| Setting | Why it matters | Sensible default |\n|---|---|---|\n| Training on company data | Inputs could flow into future models | Off, and confirmed in the contract |\n| Retention of chats and files | The longer data is kept, the longer it can leak | As short as your work allows |\n| Single sign-on and multi-factor login | Stops private accounts and stolen passwords | Required for all users |\n| Sharing of chats | Shared links can reach people outside the company | Off, or only inside the company |\n| Connectors, plugins and agents | Each connection sends data to another service | Only approved ones, switched on per team |\n| Memory across chats | The tool keeps personal details for later | Off for teams that handle sensitive data |\n| Data region | Some plans let you choose where data is stored | A region that your company and contracts accept |\n| Admin and audit logs | You need to know who changed what | On, readable by security and data protection |\n\n## Mask and pseudonymize before you prompt\n\nOften the AI does not need the real data at all. To improve the tone of a reply to a complaint, it does not need the customer's name, address or order number. Leaving out what a task does not need is called **data minimization**, and it works with every tool. Three techniques help:\n\n- **Masking** removes details or replaces them with a generic marker such as [NAME]. You cannot undo it.\n- **Pseudonymization** replaces details with consistent placeholders such as Customer_1 and keeps the key, the list of who is who, separately inside the company. You can put the real names back into the AI's answer later.\n- **Anonymization** changes data so that nobody can identify the person any more with reasonable effort. This is harder than it looks: a rare job title and a small town can be enough.\n\n![Example of pseudonymization: on the left, a complaint with name, email, order number and address; on the right, the same complaint with placeholders that go to the AI; below, three steps: replace locally, the AI works with placeholders, put the real data back locally](/images/learn/en/data-leakage-controls-for-ai-tools-masking.webp \"Pseudonymization in practice: the AI only sees placeholders, the key stays in the company. Example data.\")\n\n| Technique | Example | Reversible? | Still personal data under the GDPR? |\n|---|---|---|---|\n| Masking | \"Dear [NAME], your order [NUMBER] …\" | No | Only if the rest still identifies the person |\n| Pseudonymization | \"Dear Customer_1, your order Order_7 …\", key kept internally | Yes, with the key | Yes |\n| Anonymization | \"A customer in a large city reported a damaged parcel\" | No | No, if nobody can identify the person |\n\n{{\u003c callout type=\"warning\" title=\"Pseudonymized is not anonymous\" \u003e}}\nUnder the GDPR, pseudonymized data is still personal data, because whoever holds the key can identify the person (GDPR Article 4(5) and Recital 26). Placeholders reduce the risk, but they do not make an unapproved tool acceptable for customer data.\n{{\u003c /callout \u003e}}\n\nSome DLP tools and AI gateways mask data automatically: they find names, email addresses or bank account numbers in a prompt and replace them before the text leaves the company. Automatic detection misses things, especially names in unusual formats. For very sensitive data, check by hand. Level 1 shows which data classes need the most care in [what not to paste into an AI tool](/en/ai-security/learn/what-not-to-paste-into-ai/).\n\n## DLP: check prompts and uploads automatically\n\n**Data loss prevention** (DLP) is software that recognizes sensitive data and stops it from leaving through the wrong channel. Many companies already use DLP for email and file sharing. For AI tools, it checks what people type or paste into an AI website and which files they upload.\n\n![Four steps of a DLP check: detect sensitive data, decide based on data and destination, act by allowing, warning, masking or blocking, and log the event; below, a rollout in three stages: monitor, warn, block clear cases](/images/learn/en/data-leakage-controls-for-ai-tools-dlp.webp \"How DLP handles a prompt or an upload, and how to roll it out without stopping the work.\")\n\nA DLP check has four steps. It **detects** sensitive data through patterns such as card or account numbers, keyword lists, sensitivity labels like \"confidential\" and fingerprints of specific documents. It **decides** based on the data and the destination: an approved business tool is not the same as an unknown website. It **acts**: allow, warn and ask for a reason, mask, or block. And it **logs** the event for later review.\n\nRoll DLP out in stages. Start in monitoring mode for a few weeks and see what happens without blocking anyone. Then warn, and block only clear cases, such as card numbers on their way to an unapproved tool. A rule that blocks too much teaches people to work around it, for example with their private phone.\n\nMost AI use happens in the browser, so the browser is a good control point. A managed company browser can send people from unapproved AI sites to the approved tool, allow only approved extensions and restrict uploads or pasting on unapproved sites. Extensions deserve extra attention: many AI extensions ask for permission to read every page you open, including your email and your CRM.\n\n## Access rights, logs and contracts\n\n**Access rights** decide what an internal assistant can find. According to the vendors, assistants such as Microsoft 365 Copilot or Gemini in Google Workspace respect existing permissions: they show users only what those users could already open. That sounds safe, but it brings old mistakes to light, such as folders shared with everyone, forgotten guest access or outdated groups. Before you switch on such an assistant, clean up permissions in sensitive areas, label confidential documents and give the assistant no more rights than the user. Part 1 of this level lists this risk as [LLM02 in the OWASP Top 10](/en/ai-security/learn/owasp-top-10-for-llm-applications/).\n\n**Logs** show what happened: which AI tools are used and by which teams, which DLP events occurred and which admin settings changed. Prompt contents are a special case, because storing every prompt creates a new pile of sensitive data. Keep content logs only where you need them, protect them like the original data and delete them on schedule. Agree on the rules with your data protection officer; in Germany, the works council also has a say when technical systems can monitor employees.\n\n**Contracts** decide what the provider may do with your data. Before work data flows into a tool, check these points:\n\n- a data processing agreement, which the GDPR requires when a provider processes personal data on your behalf (Article 28)\n- no training on your data, in writing\n- retention periods and deletion when you leave\n- the list of sub-processors, such as the provider of the language model behind the tool\n- where data is stored and processed, and the legal basis for transfers outside the EU\n- security evidence, such as an ISO/IEC 27001 certificate or a SOC 2 report, and a duty to report incidents\n\nOur comparison lists a few tools for these layers. According to the vendors, Airia secures and governs agents, models, tools and data access, Sentaro checks the context of emails and warns users before they make a mistake, and Bitdefender protects the devices of smaller companies against ransomware and phishing. None of them replaces clean permissions and clear rules:\n\n{{\u003c tools \"airia sentaro bitdefender\" \u003e}}\n\n## Common gaps and how to close them\n\nMost leaks happen in the gaps between good intentions and daily work. Check your setup against this table:\n\n| Gap | What happens | Better |\n|---|---|---|\n| A ban without an alternative | People switch to private phones and accounts | Offer an approved tool first, then restrict |\n| DLP blocks from day one | Many false alarms, and people find workarounds | Monitor, then warn, then block clear cases |\n| Business plan with default settings | Sharing, plugins and long retention stay on | Review the admin settings before the rollout |\n| Assistant on before the permission cleanup | Users find files they should never have seen | Clean up sensitive areas and labels first |\n| Every prompt logged forever | A new store of sensitive data | Log events; keep content only where needed |\n| No contract check for small tools | Data flows to providers without an agreement | Every tool with work data goes through the same review |\n\nOur guide on [protecting personal data with AI tools](/en/ai-security/how-to-protect-personal-data-using-ai-tools/) adds more advanced techniques, such as differential privacy and federated learning.\n\n{{\u003c callout type=\"try\" title=\"A 30-minute leak check for one team\" \u003e}}\nPick one team and ask which AI tools it uses: do not guess, ask. Write each tool into a table and check it against the five leak paths. For every path that is open, choose one control from this guide and an owner. Start with the tools that see customer data or contracts.\n{{\u003c /callout \u003e}}","text":"A service agent pastes a customer complaint into a free chatbot to get a friendlier reply: name, address and order history included. A colleague in legal uploads a contract draft to a PDF summarizer she found through a search engine. Nobody wants to cause harm. But the data now sits with providers your company has no contract with, under terms nobody has read.\nThis is part 2 of Level 2 in our AI Security learning path. Level 0 explained what happens to your data in an AI chat. This part takes the company\u0026rsquo;s view: which controls keep sensitive data where it belongs when a whole team uses AI tools. You will learn the main leak paths, how approved accounts, masking, data loss prevention, access rights, logs and contracts work together, and in which order to set them up.\nWhere data leaks when people use AI tools Data leakage means that sensitive data ends up where it should not be: with a provider you have no contract with, in a model\u0026rsquo;s training data, behind a public link or in front of a colleague who should not see it. With AI tools, it rarely takes an attacker. It happens on five paths:\nFive ways sensitive data leaves controlled space when people use AI tools. Unapproved tools. Someone uses a personal account or a random web tool. Your company has no contract, no admin settings and no way to have the data deleted later. The provider\u0026rsquo;s processing. Even approved tools store prompts and files for some time. Depending on the plan, people at the provider may review samples, and inputs may be used for training. Sharing and connections. Shared chat links, plugins, connected apps and agents pass data on to further services. Too much internal access. A company assistant that searches internal files shows each user what that user is allowed to open. That includes the salary list that someone shared with the whole company by mistake. Experts call this oversharing. Copies in outputs and logs. Generated documents, chat histories, exports and logs keep copies of the data long after the task is done. No single control closes all five paths. That is why companies stack several layers, from rules for people to technical checks. Each layer catches some of what the layer above misses:\nThe control layers of this guide. The highlighted layer prevents the most leaks: a good approved tool. Start with approved tools and safe settings The most effective control is an approved tool that is good enough for the job. If people have a business account with sensible settings, they have little reason to paste data into random websites. Part 5 of this level shows how to deal with shadow AI, the unapproved tools that are already in use.\nBusiness and enterprise plans of the large providers usually come with a contract, central administration and, by default, no training on your data. Check the terms of your specific plan, then go through the admin settings before the rollout:\nData Leakage Controls for AI Tools Setting Why it matters Sensible default Training on company data Inputs could flow into future models Off, and confirmed in the contract Retention of chats and files The longer data is kept, the longer it can leak As short as your work allows Single sign-on and multi-factor login Stops private accounts and stolen passwords Required for all users Sharing of chats Shared links can reach people outside the company Off, or only inside the company Connectors, plugins and agents Each connection sends data to another service Only approved ones, switched on per team Memory across chats The tool keeps personal details for later Off for teams that handle sensitive data Data region Some plans let you choose where data is stored A region that your company and contracts accept Admin and audit logs You need to know who changed what On, readable by security and data protection Mask and pseudonymize before you prompt Often the AI does not need the real data at all. To improve the tone of a reply to a complaint, it does not need the customer\u0026rsquo;s name, address or order number. Leaving out what a task does not need is called data minimization, and it works with every tool. Three techniques help:\nMasking removes details or replaces them with a generic marker such as [NAME]. You cannot undo it. Pseudonymization replaces details with consistent placeholders such as Customer_1 and keeps the key, the list of who is who, separately inside the company. You can put the real names back into the AI\u0026rsquo;s answer later. Anonymization changes data so that nobody can identify the person any more with reasonable effort. This is harder than it looks: a rare job title and a small town can be enough. Pseudonymization in practice: the AI only sees placeholders, the key stays in the company. Example data. Data Leakage Controls for AI Tools (2) Technique Example Reversible? Still personal data under the GDPR? Masking \u0026ldquo;Dear [NAME], your order [NUMBER] …\u0026rdquo; No Only if the rest still identifies the person Pseudonymization \u0026ldquo;Dear Customer_1, your order Order_7 …\u0026rdquo;, key kept internally Yes, with the key Yes Anonymization \u0026ldquo;A customer in a large city reported a damaged parcel\u0026rdquo; No No, if nobody can identify the person !Pseudonymized is not anonymous\nUnder the GDPR, pseudonymized data is still personal data, because whoever holds the key can identify the person (GDPR Article 4(5) and Recital 26). Placeholders reduce the risk, but they do not make an unapproved tool acceptable for customer data.\nSome DLP tools and AI gateways mask data automatically: they find names, email addresses or bank account numbers in a prompt and replace them before the text leaves the company. Automatic detection misses things, especially names in unusual formats. For very sensitive data, check by hand. Level 1 shows which data classes need the most care in what not to paste into an AI tool.\nDLP: check prompts and uploads automatically Data loss prevention (DLP) is software that recognizes sensitive data and stops it from leaving through the wrong channel. Many companies already use DLP for email and file sharing. For AI tools, it checks what people type or paste into an AI website and which files they upload.\nHow DLP handles a prompt or an upload, and how to roll it out without stopping the work. A DLP check has four steps. It detects sensitive data through patterns such as card or account numbers, keyword lists, sensitivity labels like \u0026ldquo;confidential\u0026rdquo; and fingerprints of specific documents. It decides based on the data and the destination: an approved business tool is not the same as an unknown website. It acts: allow, warn and ask for a reason, mask, or block. And it logs the event for later review.\nRoll DLP out in stages. Start in monitoring mode for a few weeks and see what happens without blocking anyone. Then warn, and block only clear cases, such as card numbers on their way to an unapproved tool. A rule that blocks too much teaches people to work around it, for example with their private phone.\nMost AI use happens in the browser, so the browser is a good control point. A managed company browser can send people from unapproved AI sites to the approved tool, allow only approved extensions and restrict uploads or pasting on unapproved sites. Extensions deserve extra attention: many AI extensions ask for permission to read every page you open, including your email and your CRM.\nAccess rights, logs and contracts Access rights decide what an internal assistant can find. According to the vendors, assistants such as Microsoft 365 Copilot or Gemini in Google Workspace respect existing permissions: they show users only what those users could already open. That sounds safe, but it brings old mistakes to light, such as folders shared with everyone, forgotten guest access or outdated groups. Before you switch on such an assistant, clean up permissions in sensitive areas, label confidential documents and give the assistant no more rights than the user. Part 1 of this level lists this risk as LLM02 in the OWASP Top 10.\nLogs show what happened: which AI tools are used and by which teams, which DLP events occurred and which admin settings changed. Prompt contents are a special case, because storing every prompt creates a new pile of sensitive data. Keep content logs only where you need them, protect them like the original data and delete them on schedule. Agree on the rules with your data protection officer; in Germany, the works council also has a say when technical systems can monitor employees.\nContracts decide what the provider may do with your data. Before work data flows into a tool, check these points:\na data processing agreement, which the GDPR requires when a provider processes personal data on your behalf (Article 28) no training on your data, in writing retention periods and deletion when you leave the list of sub-processors, such as the provider of the language model behind the tool where data is stored and processed, and the legal basis for transfers outside the EU security evidence, such as an ISO/IEC 27001 certificate or a SOC 2 report, and a duty to report incidents Our comparison lists a few tools for these layers. According to the vendors, Airia secures and governs agents, models, tools and data access, Sentaro checks the context of emails and warns users before they make a mistake, and Bitdefender protects the devices of smaller companies against ransomware and phishing. None of them replaces clean permissions and clear rules:\nAiriaSecurity \u0026amp; Governance · AI at the coreOrchestration platform for enterprises to build and manage AI solutions securely. SentaroSecurity \u0026amp; Governance · AI at the coreEmail security for small and mid-sized businesses that checks the context and intent of messages and warns of phishing. BitdefenderSecurity \u0026amp; Governance · Software with AI featuresCybersecurity for small and mid-sized businesses: protection against ransomware, phishing and fileless attacks. Short descriptions from our tool comparison, based on the vendors' information — not tested by ABXK.\nCommon gaps and how to close them Most leaks happen in the gaps between good intentions and daily work. Check your setup against this table:\nData Leakage Controls for AI Tools (3) Gap What happens Better A ban without an alternative People switch to private phones and accounts Offer an approved tool first, then restrict DLP blocks from day one Many false alarms, and people find workarounds Monitor, then warn, then block clear cases Business plan with default settings Sharing, plugins and long retention stay on Review the admin settings before the rollout Assistant on before the permission cleanup Users find files they should never have seen Clean up sensitive areas and labels first Every prompt logged forever A new store of sensitive data Log events; keep content only where needed No contract check for small tools Data flows to providers without an agreement Every tool with work data goes through the same review Our guide on protecting personal data with AI tools adds more advanced techniques, such as differential privacy and federated learning.\n▸A 30-minute leak check for one team\nPick one team and ask which AI tools it uses: do not guess, ask. Write each tool into a table and check it against the five leak paths. For every path that is open, choose one control from this guide and an owner. Start with the tools that see customer data or contracts.\n","words":1909},"date":"2026-10-14","description":"How companies keep sensitive data out of the wrong AI tools: approved accounts, masking, DLP for prompts, browser controls, access rights, logs and contracts.","image":"https://abxk.ai/images/cover/data-leakage-controls-for-ai-tools.webp","json":"https://abxk.ai/en/ai-security/learn/data-leakage-controls-for-ai-tools/index.json","kind":"page","language":"en","learning_path":{"category":"ai-security","level":2,"level_name":"Intermediate"},"modified":"2026-10-14","related_tools":["Airia","Sentaro","Bitdefender"],"section":"ai-security","tags":["data-leakage","dlp","data-protection","ai-governance"],"title":"Data Leakage Controls for AI Tools","translations":[{"json":"https://abxk.ai/de/ai-security/learn/data-leakage-controls-for-ai-tools/index.json","language":"de","url":"https://abxk.ai/de/ai-security/learn/data-leakage-controls-for-ai-tools/"}],"url":"https://abxk.ai/en/ai-security/learn/data-leakage-controls-for-ai-tools/"}