A policy PDF sits in a shared drive. A ChatGPT tab sits one click away. Employees choose the tab every time, and most organizations already suspect their people are pasting company data into tools the policy forbids.
The problem is rarely defiance. It is friction: vague, ownerless rules that cannot compete with a personal account. Policies that uphold name-approved and prohibited tools, define data rules in plain language, require human review for high-risk outputs, and assign a single accountable owner. They also sit behind an intake fast enough that the sanctioned path is the easiest one.
This article walks through what to put in the policy, how to write rules employees will actually follow, and how to back the document with the workflows, ownership, and review cadence that keep it working as AI use changes.
What does the AI acceptable use policy cover?
An AI acceptable use policy (AI AUP) defines who can use which AI tools, on what data, for what purposes, and who is accountable when something goes wrong.
While a general IT acceptable use policy sets broad technology rules, an AI AUP addresses generative AI risks, such as prompt inputs leaking to external servers and outputs exposing intellectual property, inaccuracies, or bias.
The scope of an AI AUP extends beyond employees to any non-employees authorized to handle company data. It also reaches beyond a single sanctioned chatbot to cover generative AI tools, AI-powered SaaS features, internally developed applications, and commercial or proprietary systems.
The scope that stops at "our approved chatbot" misses the browser extension that reads every field on the page and the SaaS feature that became a generative AI system via a silent update.
Six sections carry the weight of a workable policy:
Data classification and handling rules: the most critical section. Employees need clear rules for which data can enter which AI systems.
Approved and prohibited tools: the section employees use to decide what they can use in practice. The list should identify approved AI tools, what each is approved for, and which data classifications each tool can handle.
Approved use categories versus prohibited uses: the work AI is approved to support. NIST AI 600-1 states that acceptable use policies and guidance for GAI can help reduce risks associated with misuse, abuse, inappropriate repurposing, and misalignment.
Human oversight requirements: when a person must review AI output before acting on it.
Accountability and enforcement: who owns outputs they act on and how violations map to existing disciplinary processes.
Ownership and review cadence: one named owner and a scheduled update rhythm
These six sections turn an AI AUP from a general statement of intent into a decision framework employees can apply the moment they open a new tool or paste a new prompt.
Why most AI acceptable use policies get ignored
Most AI acceptable use policies fail because they are bloated, vague, ownerless, and stale. In practice, only a minority of organizations have AI policies that are truly aligned with how the business actually operates, and the rest tend to have documents that were never operationalized past the initial rollout.
Restriction alone backfires, too. When employees need productivity and do not have a usable approved path, blunt blocking drives usage underground, where governance cannot see it.
A policy on its own cannot fix that gap. Even a well-written AUP is one piece of a wider effort to prevent AI sprawl, and that effort has to include giving employees a safe, governable path to actually build and use AI, not just a document telling them what they can't do. Without that path, the policy becomes another rule people route around the moment it's slower than the workaround.
Bloated catch-all documents try to serve as legal disclaimers and security standards while also providing ethics guidance. Keep the policy short enough to read and move detailed steps, screenshots, and process instructions into separate procedure documents. A policy nobody can read is a policy nobody follows.
Vague language cannot guide a real decision. Ethisphere states plainly that "use AI responsibly" is too broad to guide behavior. The linked policy guidance makes the same point: high-level statements like "all sensitive data must be protected" are meaningless unless decomposed into concrete, executable procedures, and ambiguous policy language leads to hesitation and inconsistent decisions.
A named-owner gap leaves AI policy supported in theory but unmanaged in practice. AI vendor defaults can change faster than annual policy cycles can keep up with, so rules that are vague, overly restrictive, or harder than the task itself become rules people route around.
How to create AI policy rules employees will follow
Rules employees follow are specific, observable, and tied to the daily work in front of them. The section below breaks that into four concrete steps:
Step 1: Pick modal verbs deliberately. "Must" is obligatory. "Should" is a suggestion. Boise State's policy guidance is direct: use "must" instead of "shall," and be intentional with "should," because policies enforce requirements rather than communicate permissive guidelines. Audit every rule for the verb it turns on, and rewrite the ones that hedge when the intent is a hard requirement.
Step 2: Replace broad principles with observable behaviors. Instead of "handle data with care," name what employees must and must not do: do not input personal data of customers or employees into any unapproved AI tool; do not paste confidential business information, trade secrets, or privileged communications into any external AI system.
AI-generated output for regulated filings must receive professional human review before use. A rule that an auditor can check against a screen recording is a rule that employees can follow.
Step 3: Tailor examples by department. HR teams handle employee records and compensation data; engineering teams handle source code and proprietary algorithms. Write the policy for the daily work employees perform across HR, finance, engineering, legal, compliance, and security, so each team recognizes its own workflow within the rules.
Step 4: Define data classes in plain terms, with a one-question test. Classification is where the policy usually succeeds or breaks down, so a workable four-tier framework should map cleanly to AI tool permissions.
Public: published marketing materials and public-facing content. Employees may use Public data with any reputable AI tool.
Internal: internal communications and non-confidential project materials. Employees should use approved enterprise AI tools with company accounts only.
Sensitive: customer data, employee PII, financial records, regulated information. Sensitive data requires explicit approval, designated tools and data-handling agreements.
Prohibited: authentication credentials and encryption keys. Employees must never process prohibited data with AI tools under any circumstances.
Plain labels matter because employees must make quick, consistent choices. Give them a single heuristic to carry into every prompt: the Public Test. Before inputting anything, ask, "Would I post this publicly on the internet?" If no, do not input it.
Enforcing the policy through workflows
Visibility and enforcement turn written rules into practice. Policy alone is not enough. Organizations need a defined process and trained people with the authority to act when violations surface.
In a Forrester Consulting study commissioned by Tines, 88% of IT and security decision-makers said AI stays fragmented without orchestration. Unauthorized AI tools tend to stay active for months, sometimes over a year, before anyone notices. Plus, a large share of connections to generative AI tools run through personal, non-corporate accounts, with many corporate-account connections bypassing SSO entirely.
Closing that visibility gap starts with monitoring, not blocking. Immediate hard blocks across all AI services tend to drive shadow AI further underground rather than eliminate it. A practical rollout follows four moves:
Start in monitoring mode to observe how employees are actually using AI tools today.
Establish a baseline of normal usage patterns across teams and tool categories.
Identify high-risk patterns, such as bulk data uploads or after-hours activity.
Apply targeted controls to the flows that pose the greatest risk, rather than blanket restrictions.
Manual review cannot carry this. Menlo Security documented 155,005 copy attempts and 313,120 paste attempts to AI platforms in a single monitored month, which exceeds manual review limits.
Employees also need a tool-vetting and exception process they will actually use. Keep the vetting process tiered by risk. A low-risk request can use low-friction registration, while security and legal should route a high-risk system through formal review with committee sign-off before it touches production data. A vetting process that takes three weeks to approve a summarization tool teaches employees to skip it.
Put exception requests behind a governed intake workflow. An employee submits a new tool request through a standard form, which triggers an automated workflow that scores the request against your data classification tiers. Low-risk registrations route to an approver via chat-based approvals, while high-risk requests open a populated ticket for security and legal review.
Keeping the policy current as AI use changes
An AI acceptable use policy goes stale faster than most governance documents, so review cadence has to be explicit and layered rather than a single annual pass.
Review the full governance framework once a year, revisit approved tool and data rules quarterly alongside vendor evaluation criteria, and check monthly for new AI tool discoveries and for AI features added to existing sanctioned tools.
That monthly check matters because approved apps can change through a silent update, quietly turning a low-risk tool into a generative AI system overnight and making static allowlists insufficient on their own.
Treat these events as out-of-cycle triggers:
a new AI tool onboarded
a significant regulatory change
a material AI-related incident
a change to your data classification scheme
a vendor adding AI features to an existing sanctioned tool
Those triggers keep the policy responsive between scheduled reviews.
Beyond internal triggers, external frameworks reinforce the same cadence. NIST's guidance on generative AI risk calls for ongoing monitoring and periodic review of the risk management process, with explicit updates when new or unanticipated uses appear.
The EU AI Act's deployer obligations for high-risk systems, entering force 2 August 2026, add concrete requirements to bake into the review cycle: six-month log retention and worker notification before deployment, plus AI literacy obligations for anyone overseeing a high-risk system.
Taken together, layered reviews, out-of-cycle triggers, and external regulatory checkpoints keep the policy aligned with how AI is actually being used, so the document evolves at the same pace as the tools and the risks it is meant to govern.
Where AI governance is heading
AI AUPs are moving from static documents reviewed annually toward continuous visibility built into the tools employees already use. As agentic AI spreads across the business, the policies that hold up will be the ones that treat risk control as a running process, not a one-time drafting exercise.
A working policy gives real productivity demand a governed path, rather than pretending the demand can be eliminated. Drafting the policy takes less work than enforcement.
The hard parts are approving exceptions quickly and keeping continuous audits aligned with actual use. If closing that gap is the problem in front of you, book a demo to see how teams manage AI governance through Tines.
Frequently asked questions
What's the difference between an AI policy and an AI acceptable use policy?
An AI policy translates high-level governance principles into internal rules, workflows, and controls across the full AI lifecycle. An AI acceptable use policy is narrower: it governs how employees can use specific AI tools on a day-to-day basis. It covers approved tools, data employees can and cannot share, and consequences for violations. The AUP focuses on usage principles for all staff, while detailed governance policies handle technical requirements, and in case of overlap, the detailed policies govern.
How should organizations handle personal AI accounts—prohibition or governance?
Governance works better than prohibition in nearly every case. Outright bans drive usage into shadow channels when employees still need AI to do the work in front of them. Provide sanctioned enterprise-grade alternatives that are the easiest path, gain user-level visibility first, and replace blunt blocking with contextual policies that guide employees at the moment of use.
Who should own the AI acceptable use policy: IT, legal, security, or HR?
One named person should own it, and a cross-functional group should inform it, because drafting by a single department risks missing critical dimensions. Practice varies: some organizations assign it to the CISO, others to legal or compliance, and in smaller companies, it often falls to the IT lead or COO. Keep one accountable owner. Department leads can divide tool ownership and regulatory language, while HR owns training, and executive sponsorship provides enforcement credibility.