How to Write an AI Acceptable Use Policy: What to Include
An AI acceptable use policy tells your team which AI tools they can use and what data they can put into them. Here's what to include and how to roll it out.
.png)
Key Takeaways:
- An AI acceptable use policy (AUP) is a short set of written rules that tells employees which AI tools they can use, what data they can put into them, and what they're accountable for.
- A working AI AUP has seven sections: scope and roles, approved and prohibited tools, the data rule, human oversight and disclosure, prohibited uses, accountability, and review.
- Set a review cadence for the policy (such as once a quarter).
Your team is already using AI. Someone in finance is drafting in ChatGPT, an engineer is pasting code into a coding assistant, and marketing is summarizing a customer call in a tool nobody approved. An AI acceptable use policy is how you turn that into sanctioned, safe use instead of a blind spot. It's the document that says yes to AI on terms you can stand behind.
This guide covers what to put in the policy, how to roll it out, and the one part most policies leave out.
What Is an AI Acceptable Use Policy?
An AI acceptable use policy (AUP) is a short set of written rules that tells employees which AI tools they can use, what data they can put into them, and what they're accountable for. It turns unmanaged AI use into sanctioned use, so people get the productivity without putting sensitive data somewhere it shouldn't go.
The word that carries the weight is acceptable. A good AUP doesn't try to list every tool or ban AI outright. It draws a clear line between the use that helps the business and the use that puts data at risk, and it makes that line easy for a non-technical employee to follow on a Tuesday afternoon.
It's also different from a general acceptable use policy. Your existing AUP covers company laptops, email, and internet use. An AI AUP addresses the thing those policies never anticipated: an employee handing company data to an outside model that stores it, trains on it, or surfaces it to someone else.
Why Your Team Needs an AI AUP Now
AI adoption at work is already ahead of most policies. People reach for whatever tool gets the job done, and every prompt is a chance for sensitive data to leave the building. A policy is how you keep the productivity and close the exposure, without becoming the team that says no to everything.
The risk is quiet, because most exposure is accidental: a deck pasted into a chatbot to reformat it, a spreadsheet dropped into a summarizer, a customer list shared with a tool to draft an email. None of it looks malicious, and all of it can put regulated or confidential data outside your control. OWASP's Top 10 for Large Language Model Applications lists sensitive information disclosure among the leading risks for exactly this reason.
A policy also gives you a foundation to build on. Without a written rule, there's no baseline for what counts as misuse, no basis for training, and no footing if data does leak. The AUP is the ground the rest of your AI governance stands on.
What to Include: The 7 Sections of an AI Acceptable Use Policy
A working AI AUP has seven sections: scope and roles, approved and prohibited tools, the data rule, human oversight and disclosure, prohibited uses, accountability, and review. Each one answers a question an employee asks before they paste something into a chatbot. Keep every section short enough that people read it.
Scope and Roles
State who the policy covers and who owns it. It should reach employees, contractors, and anyone touching company data, across every AI tool whether the company pays for it or not. Name the owner, usually security or IT with legal and HR, so there's a clear place to take questions and a clear person accountable for updates.
Approved and Prohibited Tools
List the AI tools people can use and the ones they can't. Approved tools are the enterprise versions you've vetted for data handling. Prohibited tools are consumer accounts that train on your inputs or lack a data agreement. Keep the list current, because a policy that names three tools in a market adding new ones every month ages fast.
The Data Rule: What Can and Can't Go Into AI
This is the section that prevents the leaks. Spell out which data classes can go into an approved AI tool and which never can, in plain terms, because "confidential" means little to someone in a hurry, but "don't paste a customer list" does.
Human Oversight and Disclosure
Require a person to check AI output before it's used, and require people to disclose when work is AI-assisted. AI is confident even when it's wrong, so a human owns accuracy, bias, and anything customer-facing. Disclosure keeps trust intact and stops AI-generated work from being passed off as fully original.
Prohibited Uses
Name the uses that are off the table regardless of tool. Common ones: making employment, credit, or legal decisions on AI output alone, generating content that impersonates a real person, and using AI in ways that break a customer contract or a regulation. A short, specific list beats a vague warning.
Accountability and Consequences
Say what happens when the policy is broken, and tie it to your existing conduct rules so it has teeth. Applied evenly to everyone, that consequence is what makes the policy credible rather than decorative.
Review and Governance
Set a review cadence (quarterly is reasonable while the tools move this fast), and name who runs it. The AI market changes faster than any annual policy cycle, so build the update into the policy instead of letting the document go stale.
If you also need the underlying security-controls policy and a ready-to-edit template, that's a separate document worth building alongside this one.
How to Roll Out Your AI AUP in 4 Steps
Writing the document is half the job. Rolling it out takes four steps: pull together a small cross-functional group, draft the policy from the seven areas mentioned above, set up a fast way to request new tools, and train people on the data rule. Skipping that last step is why most policies end up ignored.
First, create a small cross-functional group: security, legal, HR, and someone from the business who uses AI every day. A policy written by security alone tends to ban what people need, and a policy written without security tends to miss the data risk.
Second, draft the policy from the sections above. Published standards like NIST's AI Risk Management guidance can shape the governance language, but keep the employee-facing version plain. Two pages people read beats 20.
Third, set up a fast way to request new AI tools. If approval takes three weeks, people route around you, and shadow AI is born. A request path that turns around in days keeps usage in the open where you can see it.
Fourth, communicate and train. Walk teams through the data rule with examples from their own work, and make the policy easy to find. A rule people understand is a rule people follow.
The Part Most Policies Miss: You Can't Enforce What You Can't See
A policy sets the rule. It can't see the rule being broken. The moment an employee pastes a customer list into a chatbot, a PDF in the employee handbook does nothing, and you find out only if something goes wrong. Enforcement is the half of AI governance a document can't cover on its own.
Enforcement means two things: visibility into what data reaches AI tools, and the ability to stop the unsafe moves as they happen. That's the gap between a policy that describes safe behavior and a system that ensures it. A written rule tells people not to paste the customer list. Enforcement catches it when someone does anyway, on the tool you didn't know they were using.
This is the work ORION Security does. Instead of matching a fixed pattern, the ORION Security platform reads what's moving, who's moving it, and where it's going, and returns a verdict, not an alert, before the data leaves. It covers the surfaces where AI gets used, browser, endpoint, SaaS, email, and the AI tools themselves, so the policy you wrote has something enforcing it across every place people work. Because it watches for unsanctioned AI use, it turns shadow AI from a blind spot into something you can allow with confidence rather than pretend isn't happening.
At one ORION Security customer, a product manager uploaded a file of personal data to ChatGPT for a quick analysis, the kind of well-meaning shortcut a written policy can't prevent. The platform flagged the upload in real time, and the security team reached her and cleared it before it became an incident. That's the gap a written policy leaves, and the reason enforcement matters.
That's the difference between a policy and protection. The document sets the expectation, and enforcement makes it true. If you want to see what data your people are sending to AI tools today, ORION Security will show you, and it deploys in 30 minutes.
Frequently Asked Questions
How is an AI acceptable use policy different from a general acceptable use policy?
A general AUP covers company devices, networks, and internet use. An AI AUP addresses what those never anticipated: employees feeding company data into outside models that may store it, train on it, or surface it elsewhere. Most organizations keep them separate so the AI rules stay specific and easy to update.
Who should own the AI acceptable use policy?
Security or IT, working with legal and HR. Security understands the data risk, legal handles regulatory and contractual exposure, and HR ties the policy to conduct and training. Name one accountable owner so updates actually happen.
How often should we update it?
Quarterly is reasonable. The approved-tools list and the data rule age quickest, so review those most closely. Build the cadence into the policy itself rather than leaving it to an annual cycle.
Do we need separate rules for AI agents and coding assistants?
The same principles apply, but agents and coding assistants raise the stakes, because they read and move data on their own, at machine speed. If your teams use them, your policy and your enforcement both need to account for tools that act without a person clicking each step.

.png)
.png)