How do you control employees' use of AI tools such as ChatGPT?
Banning AI at work rarely works. A sturdier approach is to give staff an approved tool and back it with a written policy, training and technical controls. First find out which tools people actually use, then write down which kinds of data must never enter any of them. In other words, employee use of ChatGPT at work is not a question of prohibition; it is a question of data and permissions.
The problem has a name: shadow AI, meaning AI tools that employees use on personal accounts without the knowledge or approval of IT. The employee is rarely acting in bad faith. They want to draft an email, summarise meeting notes or simplify a contract clause. The trouble is that the pasted text may contain a client name, a price quote, source code or HR details, and it goes to a system whose account, country and retention rules you do not know.
That is why control works in two layers. Organisational controls set the rule: a policy, data classes, training and a named owner. Technical controls enforce it: single sign-on (SSO), company accounts, data loss prevention (DLP) and logs. One layer alone is not enough. An organisation with a policy but no visibility is blind, and one that only blocks pushes people onto their personal phones.
Where personal data is involved, the responsibility is yours. Article 12 of Law No. 6698 (KVKK) requires the data controller to take the necessary technical and administrative measures and to carry out, or commission, the audits needed to apply the law inside its own organisation. An employee pasting work data into a personal account will often be assessed within that responsibility.
Which control options can an employer choose from?
There are five common approaches. Most organisations end up combining the fourth and the fifth.
| Option | What it gives you | Main risk |
|---|---|---|
| Ban everything | Clear rule, easy message | Personal-device use, invisible risk |
| Allow freely | Speed, no friction | No idea where data goes |
| Allow with rules | Low cost, flexibility | A rule nobody enforces |
| Provide an approved tool | Data under a company contract | Selection and setup effort |
| Approved tool plus technical controls | Rules enforced, audit trail | Monitoring can overreach |
The table has one lesson in common: a ban on its own changes visibility, not behaviour. Any rule you introduce without offering an approved option that makes the work easier will simply meet the next shadow tool.
How do you first see what is being used in your organisation?
Build an inventory before you write the rule. Three sources help.
- A short survey: ask "Which AI tools do you use, and for which tasks?" and state clearly that there is no penalty. It is the most reliable way to get honest answers.
- Network and application logs: firewalls, proxies and cloud app discovery tools show which cloud apps traffic is going to. Microsoft's shadow IT discovery documentation describes scoring discovered apps by risk, marking them as unsanctioned and blocking them at the proxy or firewall.
- Department conversations: ten-minute talks with sales, legal, HR and engineering. Each team carries different risks.
Sort the result into three groups: to be approved, to be used under conditions, and to be blocked. That list is also the raw material for your first policy.
What should a written AI policy contain?
A good policy fits on one page and answers the question "What may I do?". It should include:
- Data classes: which data may go into public tools, which only into approved tools and which into none. Personal data, client contracts, source code, financial statements and HR records usually sit in the second and third groups.
- An approved tool list: name, purpose, owner and approval date. Keep it a living document.
- An account rule: company accounts only for work data. Explain the reason for the personal-account ban in one sentence.
- Responsibility for output: whoever uses an AI answer owns it. Client-facing text, legal opinions and prices go through human review.
- Incident reporting: who does an employee tell, and how quickly, after pasting data by mistake? Do not punish the report.
- A review date: tools change often, so revisit the policy every six months.
The OWASP sensitive information disclosure page likewise recommends guiding users to avoid entering sensitive information and keeping clear policies on data retention, use and deletion. Your policy should meet at least those two points.
Which technical controls can you apply?
The point of technical controls is to stop the rule depending on an employee's memory. Think in four layers.
- SSO and managed accounts: allow access to the approved tool only through company accounts. When someone leaves, access closes and the records stay with the organisation.
- Data loss prevention (DLP): sensitive information types such as ID numbers or card numbers can be caught in a prompt and blocked. Microsoft Purview's DLP documentation for Copilot explains that prompts containing sensitive information types can be blocked from processing, and that files with sensitivity labels can be kept out of responses. Equivalent features in other tools depend on the vendor, so ask before you buy.
- The network layer: unsanctioned apps can be blocked at a proxy or firewall, but this does not cover devices outside your network.
- Logging and retention: in the approved tool, you should be able to manage who used it, when, and how long data is kept.
No technical control brings the risk to zero. DLP cannot catch a data pattern it does not recognise, and a network block does not reach a personal phone. Technical controls complement the policy and the training; they do not replace them.
Where does employee monitoring go too far?
Draw the line between oversight and surveillance at the start. Recording employees' prompts or messages may amount to processing personal data. In that case the information obligation under Law No. 6698 and the principle that data must be "relevant, limited and proportionate to the purposes for which it is processed" should be assessed.
A practical approach is to tell employees in writing, in advance, what you collect, why and for how long. Where possible, monitor metadata (who, which tool, when) rather than content. Limit access to the records to the security team. Do not start content-level monitoring without speaking to your legal adviser. Monitoring personal accounts and devices may need separate, careful legal assessment.
Processing personal data with a provider abroad is a separate matter. The KVKK Guide on Generative AI and the Protection of Personal Data, published on 24 November 2025, looks at these systems from the data controller's point of view. When you choose the approved tool, ask for written answers on processing location and the transfer basis.
For example: a three-month plan in an 80-person company
For example, take an 80-person accounting and advisory firm. Management first imposed a ban, but a survey shows that 31 of the 80 people use a tool on a personal account (the figures are hypothetical).
- Week 1: a no-penalty survey and an inventory from network logs. Result: email drafts, summaries and explaining spreadsheets are the most common uses.
- Weeks 2-3: three data classes are defined. Client ID data and tax files sit in the third class, so they go into no general tool.
- Weeks 4-6: one tool on a company plan is chosen, SSO is connected and a DLP rule catches ID numbers. A switch-over date for personal accounts is announced.
- Weeks 7-8: a one-hour training session with real examples of "do not paste this, paste that".
- Week 12: usage, the number of blocked prompts and incident reports are reviewed, and the rules are loosened or tightened.
The order of decisions is what matters: visibility first, then the rule, then the tool, and monitoring last. Reverse the order and staff learn to get around you, not to follow the rule.
How do you measure whether the controls work?
- The share of employees who have moved to the approved tool.
- The monthly change in personal-account and unsanctioned-app traffic.
- The number of prompts blocked by DLP, and the false alarm rate.
- The number of incident reports; a rise often signals growing trust.
- Training attendance and the result of a short test afterwards.
Common mistakes
- Imposing a ban without offering a tool, then being surprised when use shifts to personal phones.
- Writing a single "AI policy" without defining data classes.
- Recording prompt contents without telling employees.
- Confusing a free version with a business plan; data use and retention terms differ between plans and have to be read in the contract.
- Treating training as a one-off; it should be repeated as tools and risks change.
- Sending AI output to a client without human review.
How Hatson Tech helps
Through AI consulting, Hatson Tech helps you build an inventory of use in your organisation and define data classes and approved tool options. The first meeting and discovery are free; we do not publish fixed prices, and we scope the work with you. Where data cannot leave your premises, we can also run models on your own servers.
To compare enterprise assistant options, read our article on building a private ChatGPT on company data; for personal data obligations, see our KVKK generative AI guide.