TL;DR
Staff are pasting company code and documents into personal AI accounts, and a ban has not stopped it. Treat the use as demand you have not yet supplied. Find out what people use and why, give them a business account that is easier and better than their own, write the rule in terms of data rather than tools, and have management sign the risk that remains. The intended end state is use you can see, on terms the company agreed.
In this article
8 min read
You get control by moving the use, not by forbidding it. Provide an approved AI route that is at least as good as the personal account, make the rule about which data may go where, and put the residual risk decision with management instead of IT. A ban mostly changes where the use happens.
The Dutch data protection authority, the Autoriteit Persoonsgegevens, put the core problem plainly on 6 August 2024: it had received several breach notifications after employees entered personal data of patients or customers into AI chatbots, often on their own initiative and against their employer’s agreements. When that happens, it said, it is a data breach, and notifying the authority and the people affected is in many cases mandatory.
A ban moves the use somewhere you cannot see
The two questions behind this article come from opposite ends of the same problem. In September 2025 an IT professional in a Microsoft 365 organisation asked on Tweakers (archived copy) how others handle shadow IT: staff resisted being told that free services such as ChatGPT were risky and wanted ChatGPT rather than the Copilot the company provided. Should IT accept the risk, facilitate more tools or block, and who writes and enforces the policy? In November 2025 an IT director at a company of about 100 people wrote on Reddit’s r/ChatGPT forum that staff kept using personal ChatGPT accounts and pasting internal documents despite a ban, and concluded the company had to provide its own tool.
In Microsoft’s 2024 Work Trend Index, a survey of 31,000 knowledge workers in 31 markets run by Edelman Data & Intelligence between February and March 2024, 78% of AI users said they bring their own AI tools to work (Microsoft, 8 May 2024). Microsoft sells the alternative, so read that as a vendor’s survey, but the direction matches independent work: the University of Melbourne and KPMG study of 48,340 people in 47 countries (fieldwork November 2024 to January 2025) reports that many employees have used AI in inappropriate ways at work and hidden that use (Gillespie, Lockey et al., Trust, attitudes and use of artificial intelligence: A global study 2025, DOI 10.26188/28822919).
People use these tools because they help with real work. A rule that removes the help without replacing it leaves the work unchanged, so the task moves to a phone or home laptop, with no company account, log or contract.
The account decides the terms that apply
The Tweakers thread framed the choice as ChatGPT against Copilot. The more useful line runs between consumer accounts and business accounts of the same product.
Anthropic’s update to its consumer terms of 28 August 2025 shows the difference clearly (Anthropic). On the Free, Pro and Max plans, including Claude Code used from those accounts, users choose whether their chats and coding sessions may be used for model training, and retention extends to five years for those who allow it. The update does not apply to services under Anthropic’s commercial terms, such as Claude for Work or the API. A developer running a coding agent on the company repository from a personal Pro subscription is therefore working under the personal terms, whatever the company thinks it agreed with the vendor.
On the business side, Microsoft’s documentation for enterprise data protection in Copilot (last updated 18 August 2026) states that prompts and responses are not used to train foundation models, and that Copilot respects the organisation’s permissions, sensitivity labels and retention policies and supports audit of interactions (Microsoft Learn). Which controls you get depends on the subscription.
Retention periods, training settings and vendor access still need their own review before you approve a tool for confidential code; that review sits alongside this work.
Find out what people use, and why, before you decide
An inventory tells you what to provide. Ask three things for each tool in use: what it is, what people use it for, and what they put into it. Then ask why they went outside the approved tools. The answers usually fall into three groups: the approved tool lacks a capability, getting a new tool approved takes too long, or the habit started with a personal account at home. Each needs a different fix.
Honest answers come when people expect no punishment for giving them. An anonymous survey, team conversations and expense claims for AI subscriptions are a reasonable start. Network-based discovery tools go further: Microsoft Defender for Cloud Apps, for example, analyses traffic logs to show which cloud apps are in use and lets administrators mark apps as sanctioned or unsanctioned (Microsoft Learn).
In the Netherlands, check one thing before switching that on. If you have a works council (required from 50 people), under Article 27(1)(l) of the Works Councils Act (Wet op de ondernemingsraden), the employer needs its consent for arrangements concerning facilities aimed at or suitable for observing or checking employees’ presence, behaviour or performance (wetten.overheid.nl). A tool that can show which person used which app is plausibly such a facility, and its logs are personal data under the GDPR. Aggregate figures per team avoid most of that; per-person monitoring needs the works council and your privacy officer first.
Make the approved route the easier one
The approved route wins only when it is less effort than the workaround and at least as useful. In practice that means:
- Business accounts with single sign-on, so starting the approved tool is one click and leaving the company removes access.
- The capability people went outside for. If staff chose ChatGPT over a basic Copilot for a reason, find the reason. One Tweakers reply described onboarding the tool the business asked for through the normal IT process, and only where that failed, offering a worthy alternative with an explanation.
- A request path with a deadline, so a team that needs a new tool gets a decision in days.
- A short list of what may go where, published where people work.
For engineering teams the route can do more than match a personal account. A sanctioned coding agent that loads the team’s own conventions, documentation and checks produces work that fits the repository, which a personal account on a laptop does not. Whether that reduces personal-account use has not been measured; it does remove one reason to prefer the workaround.
Write the rule around data, and give the risk to management
A rule people follow names data classes, not brands. Customer and employee personal data go only into approved business accounts covered by a processing agreement, if at all. Credentials and secrets go nowhere. Source code and internal documents go into approved accounts. Public information can go anywhere. The tool list changes every quarter; the data classes do not.
The GDPR asks for this kind of instruction. Article 5(1)(f) requires appropriate security of personal data, Article 24 makes the controller responsible for appropriate measures, including data protection policies, and Article 32(4) requires the controller to ensure that anyone acting under its authority processes personal data only on its instructions. A written data rule is that instruction. A company that provides an AI system to staff also has to take measures on their AI literacy under Article 4 of the EU AI Act, applicable since 2 February 2025 (its wording has since been amended, so read the current text); training on the rule is part of that.
IT and security assess the risk; the business decides how much risk the work justifies. One Tweakers reply described the escalation in three steps: try to onboard the tool people want, otherwise provide an alternative and explain it, and where a gap remains, write a risk waiver with probability and impact and have the board sign it with an end date. Proportion follows the data: an approved list for tools that see only public material, a vendor assessment for tools that touch code or personal data, and a signed, dated risk acceptance where the business wants something the assessment did not clear.
For an engineering team, the approved route is where Eliyce works. The AI Delivery Programme spends five weeks with one team on one application, writing down its conventions and turning the testable ones into checks that the sanctioned coding tools load, with blocking enforcement on Claude Code and Codex CLI. Tool choice, licences and any monitoring stay your decisions. If unapproved AI use in your engineering team is the problem you are working on, fix this for your team starts with a fit conversation. For a team that has already approved its tools, Security approved the AI tool, but not the workflow covers the next gap, and Enterprise AI breaks when every agent has different rules covers what happens when each approved tool carries its own instructions.
Frequently Asked Questions
How do we get control of personal AI accounts and unapproved tools without banning AI?
Start with a statement people can trust: the inventory is for planning, not discipline. Without that, the inventory measures how well people hide their use, and every later step builds on the wrong picture.
What are people actually using, and what are they putting into it?
Ask per task, not per tool. “I summarise customer emails” tells you which data is involved and which capability you must provide; “I use ChatGPT” tells you neither. Expect developers to use coding agents and chat assistants for different jobs, and ask about browser extensions and meeting transcription tools too, which often send content to a vendor without anyone thinking of them as AI tools.
Who should own the risk decision: IT, security or the business?
The business owner of the work signs, because they carry the benefit and the consequence. IT and security own the assessment and must be able to say no for data that may not leave at all, such as credentials. Record each decision with its scope, its data classes and an end date, so it is reviewed rather than forgotten.
How might people still route around an approved tool, and what do we do when we find out?
Phones and home laptops stay outside any technical control, so no route is airtight. When you find out, ask what the approved tool was missing before deciding anything else; repeated workarounds point at a gap in the supply. If personal data went into a personal account, treat it as a possible breach: the GDPR gives 72 hours to notify the authority unless the breach is unlikely to result in a risk to people, so the person who reports it quickly should not be the one who pays for it.
What signals show that control is improving, and which can we collect lawfully?
Useful signals that need no per-person monitoring: the share of licensed seats in active use, the number of tool requests and the time to a decision, voluntary breach and near-miss reports, and the same anonymous survey repeated after six months. Per-person usage logs are personal data and, in the Netherlands, a likely works-council consent subject; decide whether you need them before you collect them.
