What is a company ChatGPT use policy, and why should it be written down?
A ChatGPT use policy is a short internal document that says which AI tools employees may use, with what data and under which rules. One or two pages is enough; what matters is that management approves it and staff actually read it. Without a written rule, everyone works from a personal account and makes their own judgement, and the company cannot tell which data has gone where.
The risk runs in two directions. The first is input: when an employee pastes a customer list, a draft contract or source code into a prompt, that data goes to a service outside the company's control. OWASP's LLM02 entry says that sensitive content such as personal data, financial details, confidential business data and credentials can be exposed through language-model applications, and that users need to understand the risk of entering sensitive data without realising it. The second is output: a model can produce confident but fabricated information. OWASP's LLM09 entry describes how credible-looking but false content can lead to reputational damage and legal liability.
A policy reduces both risks to one question: which tool, with which data, approved by whom? Where personal data is involved, KVKK (Türkiye's data protection law) applies too. The Personal Data Protection Authority's Guide on Generative AI and the Protection of Personal Data, published on 24 November 2025, assesses the personal data processing carried out with these systems under Law No. 6698. The guide is not a binding regulation, but it shows the bar that is likely to be treated as reasonable when an inspection or complaint arrives.
What sample clauses should the policy contain?
The table below sets out seven clauses you can adapt, with the reason each one is needed. Change the wording to fit your organisation and have your legal adviser review the final version.
| Clause | Sample wording | Why it is needed |
|---|---|---|
| 1. Approved tools | "Only IT-approved tools and company accounts may be used." | Personal accounts sit outside company control. |
| 2. Prohibited data | "Customer personal data, health data, passwords and confidential contracts are not entered." | Exposure risk starts at input. |
| 3. Output checking | "Whoever sends output outside the company verifies it and owns it." | Models can fabricate information. |
| 4. Copyright and confidentiality | "Third-party copyrighted text and competitor information are not pasted into prompts." | Risk of infringement and leaks. |
| 5. Logging and monitoring | "Tool use is logged as metadata; content logging needs separate authorisation." | Balances oversight and employee privacy. |
| 6. Training | "Every employee completes a short course each year." | A rule nobody knows cannot be applied. |
| 7. Incident reporting | "If data is entered by mistake, report it to IT and the owner the same day." | Late reporting makes harm worse. |
Name an owner next to each clause. A clause that says "everyone is responsible" usually means nobody is. Typically IT owns the tool list, information security or the KVKK officer owns the data classes, HR owns training, and one contact point receives incident reports.
Which tools and which data should be allowed?
The approved-tool list is the most useful part of the policy, because it gives people a concrete path instead of a bare "ChatGPT is banned" or "ChatGPT is fine". For each tool, check the vendor's technical documentation for the following: whether prompts are used for model training, where data is processed, how long it is kept, and what administrator controls exist. Read the contract and the privacy documentation rather than the marketing page. We cover this in more detail in building a private ChatGPT on company data.
Three data classes are enough for most companies:
- Free to use: public information, general writing and translation, drafts that contain no personal details.
- Approved tool only: internal documents, customer correspondence without names, pieces of source code.
- Prohibited: special-category personal data, passwords and keys, unsigned bid information, contracts under a confidentiality obligation.
Write the classes with concrete examples. Everyone reads "sensitive data is not entered" differently; "customer lists, salary tables and passwords are not entered" is hard to misread. For workflows with personal data, check whether the data is processed by a provider abroad. Law No. 6698 regulates transfers abroad in a separate article, and this should be assessed with your legal adviser.
How do you write the policy and roll it out?
- Find out current use. Ask employees, through an anonymous form, which tools they use and for what. Knowing real behaviour before you ban anything tells you whether the rule will work.
- Classify the risks. Place each department's typical tasks into the three data classes. Sales and accounting do not carry the same risks as the software team.
- Provide an approved tool. If you ban a tool without offering an alternative, use goes underground. An enterprise plan or an in-house assistant makes the rule workable.
- Draft the policy and have two people read it. One should be your legal or KVKK lead, the other a hands-on user. The first checks accuracy, the second checks clarity.
- Train people. In a twenty-minute session, show three real examples: correct use, incorrect use, and what to do after entering data by mistake.
- Review it. Tools and regulation change quickly. Give the policy a version number and a review date, and revisit it every six months.
The policy should sit inside a wider governance framework. The NIST AI Risk Management Framework is intended for voluntary use, and NIST released a generative AI profile for it on 26 July 2024. A small company does not need to apply the whole framework, but its logic of assigning responsibility, identifying risks, measuring and managing them is a useful guide for a short policy. Broader questions are covered in our article on enterprise AI governance.
How do output checks, logging and incident reporting work?
One rule is enough for output checking: AI drafts, a person publishes. The person who sends text, a figure, a contract clause or a piece of code outside the company checks it and owns it. Using a claim the model did not source, without verifying it independently, passes the risk of hallucination to the company.
Be balanced about logging. Recording tool use at the level of user, date and tool is often enough; storing prompt and response text can create a new store of sensitive data. In our engineering reading of the regulator's guide, KVKK's generative AI guide, we explain how to separate content-free logging from limited content logging. Monitoring employees is also a matter of notice, so state clearly in the policy what is recorded.
Set up a short reporting flow: who reports, to whom, and within what time? Where personal data is involved, agree the deadline and the owners with your KVKK lead. Encourage reporting rather than punishing people; a hidden mistake costs more than a reported one.
For example, how might a 60-person company apply the policy?
For example, take a hypothetical service company with 60 employees. An anonymous form shows that the sales and support teams summarise customer emails in personal ChatGPT accounts. The company first writes the three data classes and seven clauses. It then opens an enterprise plan, bans personal accounts for work data and makes IT the owner of the tool list.
For the first two weeks only the sales and support teams pilot it. In a twenty-minute meeting every Friday, they list where the rules chafe. In week three training opens to the whole company, and in month six the policy is reviewed again. These numbers are only an illustration; your timings and team structure may differ. The order stays the same: learn current use, open an approved route, then take the written rule to the shop floor.
What mistakes are common when writing a policy?
- A blanket ban: a tool banned without an alternative keeps being used in secret.
- Vague wording: "sensitive data is not entered" cannot be applied without examples.
- No named owner: nobody knows who updates the tool list or receives incident reports.
- Skipping training: a policy that is signed but never explained protects nobody.
- Writing it once and forgetting it: vendors' data terms change and the document ages.
- Copying another company's text word for word: your sector's data types and contract obligations differ.
How Hatson Tech helps
Hatson Tech cares that a policy works, not just that it exists on paper. In our AI consulting service we first map current use and data flows in your company, then decide together which tasks can safely be done with which tool. Where needed, we can run the model on your own servers so that data does not leave your environment. The first meeting and discovery are free; we do not publish fixed prices and quote according to scope.
For further reading, see building a private ChatGPT on company data and KVKK's generative AI guide.