Category:
AI Governance
AI Policy
Published date:

An AI usage policy is a written rule set defining which AI tools employees may use, what data they may put into them, and who approves new ones. A workable policy covers nine areas: scope, approved tools, data classification, prohibited uses, human review, disclosure, security, ownership, and enforcement. Most policies fail not because they are badly written but because nobody can see whether they are being followed.
Almost every enterprise wrote an AI policy in the last 18 months. Almost none of them can tell you whether it is working.
That is the uncomfortable part. A policy is a statement of intent. Without a way to observe actual behaviour, it is a document that makes the legal team feel better and changes nothing about what happens in the browser tab.
Why do you need an AI usage policy?
Because your employees are already using AI, whether you have a policy or not.
Microsoft's Work Trend Index found 78% of employees who use AI at work bring their own tools rather than company-approved ones. Harmonic Security, analysing 22.4 million enterprise prompts, found 73.8% of ChatGPT use ran through personal accounts and 82.8% of sensitive data entering AI tools travelled through those same unmanaged accounts.
So the choice is not whether AI gets used. It is whether it gets used inside rules you set or outside them.
Why it matters | The number | Source |
|---|---|---|
Employees bringing their own AI tools | 78% | Microsoft Work Trend Index |
Enterprise ChatGPT use on personal accounts | 73.8% | Harmonic Security |
Sensitive data flowing through unmanaged accounts | 82.8% | Harmonic Security |
Extra cost of a shadow-AI-related breach | $670,000 | IBM Cost of a Data Breach 2025 |
Breached organisations with no AI access controls | 97% | IBM, 2025 |
That last figure is the one worth sitting with. Of the organisations that suffered an AI-related breach, 97% had no AI access controls in place. Not weak controls. None.
What should an AI usage policy include?
Nine sections. Anything shorter leaves a gap somebody will find.
1. Scope. Who it applies to, including contractors and interns, and what counts as an AI tool. Be broad here. If your definition only covers chat assistants, you have excluded coding assistants, meeting bots and every AI feature bundled into software you already own.
2. Approved tools. A named list, maintained, with the tier each tool is approved for. A policy that says "use approved tools" without naming them is not a policy.
3. Data classification. Which data classes may enter which tools. This is the heart of the document. Most breaches trace back to someone pasting the wrong category of data into the wrong tier of tool.
4. Prohibited uses. Specific and concrete. Customer PII into consumer accounts. Source code into unapproved assistants. Unreleased financials anywhere outside a contracted enterprise tool.
5. Human review. Where a human must check AI output before it reaches a customer, a regulator or production. Name the workflows, not the principle.
6. Disclosure. When employees must say AI was involved. Client deliverables, published content, hiring decisions, code review.
7. Security requirements. SSO where available, no personal accounts for work data, no pasting credentials or keys, extension review.
8. Ownership and IP. Who owns AI-assisted output, and the licensing terms of the tools you approved. Read the vendor terms before you write this section, because they vary more than people expect.
9. Enforcement and exceptions. What happens when the policy is broken, and the route to request a new tool. Skip the exception path and you have guaranteed shadow AI, because the only way to get work done becomes going around you.
The AI usage policy template
Copy this, replace the bracketed parts, and have counsel review before you circulate it.
[Company] AI Usage Policy Effective [date] · Owner: [role] · Review cadence: quarterly
1. Purpose. This policy sets out how [Company] employees may use artificial intelligence tools, so we get the productivity benefits without exposing customer data, source code or confidential information.
2. Scope. Applies to all employees, contractors and interns. "AI tool" means any software using generative AI or machine learning to produce content, code, analysis or decisions. This includes standalone assistants, AI features inside approved software, coding assistants, browser extensions and AI agents or automations.
3. Tool tiers.
Tier 1, approved for confidential data: [list enterprise-contracted tools with a DPA and no-training terms]
Tier 2, approved for internal non-confidential data: [list]
Tier 3, personal or unvetted tools: not permitted for any company data
New tools require approval from [role] before use. Request via [channel], typical turnaround [X business days].
4. Data rules.
Data class | Tier 1 | Tier 2 | Tier 3 |
|---|---|---|---|
Public / marketing material | Allowed | Allowed | Allowed |
Internal non-sensitive | Allowed | Allowed | Not allowed |
Customer PII | Allowed with approval | Not allowed | Not allowed |
Source code | Allowed | Not allowed | Not allowed |
Financials, legal, M&A | Allowed with approval | Not allowed | Not allowed |
Credentials, keys, secrets | Never | Never | Never |
5. Prohibited uses. Entering credentials or secrets into any AI tool. Using AI as the sole basis for hiring, termination, credit or other decisions affecting individuals. Presenting AI output as original work where disclosure is required. Bypassing tool tiers via personal accounts.
6. Human review required. AI output must be reviewed by a qualified human before: release to a customer, merge to production, submission to a regulator, publication under the company name, or use in an employment decision.
7. Disclosure. Disclose AI involvement in client deliverables where the client requires it, in published content per [editorial standard], and in code review per [engineering standard].
8. Security. Use SSO where available. Never use personal accounts for company data. Browser extensions with AI capability require [role] approval. Report suspected data exposure to [security contact] within 24 hours.
9. Ownership. Work produced with approved AI tools in the course of employment belongs to [Company], subject to the licensing terms of each tool. Employees are responsible for confirming output does not infringe third-party rights.
10. Enforcement. Violations are handled under [existing conduct policy]. Deliberate exposure of customer data may result in termination. Good-faith self-reporting of a mistake will be treated as such.
11. Exceptions. Request an exception or a new tool from [role] via [channel]. Do not use an unapproved tool while a request is pending.
Why AI usage policies fail
Three reasons, and only the third is really about the policy.
Nobody read it. It arrived as a PDF attachment during onboarding and was never mentioned again. Policies need to live where the work happens.
It was too restrictive to follow. If the approved list cannot do the job, employees route around it. A policy that blocks productivity does not reduce AI use, it just moves it somewhere you cannot see. Every over-restrictive policy is a shadow AI generator.
Nobody can tell whether it is being followed. This is the real problem. You wrote rules about data classes and tool tiers, and you have no instrument that shows which tools are actually in use, by whom, with what data class. The policy is unenforceable by construction.
That third failure is why we built Guickly. Discovery across SaaS, cloud and the IDE, so a policy becomes something you can observe rather than something you hope about. Metadata only, so we never see the prompts themselves.
How do you enforce an AI usage policy?
Four steps, in this order. The order matters more than any individual step.
Discover first. Establish what is actually in use before you write another rule. You cannot set a sensible approved list without knowing what people already depend on.
Sanction the popular things. If 40% of engineering already uses a tool, the answer is usually to bring it under an enterprise contract with proper data terms, not to ban it. You get the productivity and the governance.
Monitor continuously. Quarterly surveys measure memory, not behaviour. Continuous discovery catches new tools in the weeks after they appear, which is when the data exposure happens.
Then restrict, narrowly. Block what is genuinely unsafe. A short blocklist that is enforced beats a long one that is theatre.
Visibility comes before control. A policy without visibility is a wish.
How often should you update it?
Quarterly at minimum, and immediately when a major vendor changes its data-training terms. This category moves faster than annual policy cycles. A policy written 12 months ago does not mention agents, and agents are now most of the risk.
To see which AI tools your policy is actually competing with, book a 15-minute walkthrough with the founder of Guickly.
FAQ
What is an AI usage policy? An AI usage policy is a written rule set defining which AI tools employees may use, what data they may enter into them, and who approves new tools. It typically covers scope, approved tools, data classification, prohibited uses, human review, disclosure, security, ownership and enforcement.
What should an AI usage policy include? Nine sections: scope and definitions, an approved tool list with tiers, data classification rules mapping data classes to tiers, prohibited uses, workflows requiring human review, disclosure requirements, security requirements, ownership and IP terms, and enforcement plus an exception path.
Why is it important to establish generative AI usage policies? Because employees use AI whether a policy exists or not. Microsoft found 78% bring their own tools, and Harmonic found 73.8% of enterprise ChatGPT use runs on personal accounts. A policy determines whether that use happens inside rules you set. IBM found 97% of organisations breached through AI had no AI access controls in place.
Do we need an AI policy if we already have an acceptable use policy? Yes. A general acceptable use policy governs software and internet use. It does not address data classification for prompts, model training on your inputs, human review of AI output, disclosure, or ownership of AI-assisted work. These are specific to AI and need explicit treatment.
How do you enforce an AI usage policy? Discover what is in use, sanction the tools people already depend on under proper contracts, monitor continuously rather than by survey, then restrict narrowly. Enforcement requires visibility into actual tool use, which most organisations lack, making their policy unenforceable by construction.
How often should an AI usage policy be reviewed? Quarterly at minimum, and immediately when a major AI vendor changes its data-training or retention terms. The tooling landscape shifts faster than annual policy cycles, and policies written a year ago typically do not address AI agents.
Can employees use ChatGPT at work? That depends on tier and data class. Enterprise ChatGPT with a data processing agreement and no-training terms can generally handle confidential data. Free or personal ChatGPT accounts should not receive any company data, because the content leaves your environment under no contract. The distinction is the account type, not the tool.
What happens if an employee breaks the AI policy? Handle it under your existing conduct policy, scaled to intent and impact. Deliberate exposure of customer data warrants serious consequences. Good-faith mistakes should be treated as learning and self-reporting should be encouraged, because punishing disclosure guarantees the next incident stays hidden.
