How to Write an AI Acceptable Use Policy for Your Company

The short answer: An AI acceptable use policy should define which tools employees may use, what data they may input, how outputs must be reviewed before use, and what the consequences are for violations. A complete policy covers approved tools, prohibited uses, data classification rules, disclosure requirements, and a clear owner responsible for updates. Plan for a living document, not a one-time filing.

Most companies that have adopted AI tools did so faster than their legal and HR teams could respond. A developer starts using ChatGPT to write code. A marketer pastes customer data into Claude to draft a campaign brief. A finance analyst runs projections through a public AI tool without flagging it to anyone. None of them did anything they thought was wrong. That is precisely the problem.

Without a written AI acceptable use policy, you have no shared definition of what is allowed, no accountability when something goes wrong, and no legal protection if a data breach or compliance violation follows. The policy is not a bureaucratic hurdle. It is the document that lets people move fast with AI without creating liability that trails behind them.

Writing a good one takes more than copying a template. It requires your company to make real decisions about risk tolerance, approved vendors, and how much trust you extend to AI outputs. Here is how to do it.

---

Start With the Decisions, Not the Document

The most common mistake is opening a blank document and writing rules before your leadership team has aligned on the underlying questions. That produces a policy that is either too vague to enforce or so restrictive that employees ignore it.

Before you write a single sentence, get answers to these:

• What AI tools are currently in use, sanctioned or not? Run a shadow IT audit. In most mid-size organizations, employees are using five to ten AI tools that IT has never approved. You need an accurate baseline.
• What data classification framework does your company use? If you do not have one, create a simplified version first. At minimum, distinguish between public information, internal information, confidential business data, and regulated data such as PII, PHI, or financial records.
• Who owns this policy? Someone with authority needs to own updates, answer questions, and enforce violations. Legal, IT, and HR all have stakes here. Pick a primary owner and define the others as contributors.

Once these decisions are made, writing the policy becomes a documentation exercise rather than a debate. This foundational work also sets you up to avoid common AI adoption mistakes mid-market companies make, where unclear governance leads to misaligned implementations across teams.

---

The Six Components Every AI Acceptable Use Policy Needs

1. Scope and Purpose

State plainly who the policy applies to and why it exists. Include full-time employees, contractors, and any third parties with access to your systems. A sentence like "This policy governs the use of AI tools by all personnel accessing [Company] systems or data" is specific enough to be enforceable.

The purpose statement should name the actual risks you are managing: data privacy, intellectual property protection, accuracy of AI-generated outputs, and regulatory compliance. Vague purpose statements like "to ensure responsible AI use" are not useful.

2. Approved and Prohibited Tools

Maintain a short, maintained list of approved AI tools. Microsoft Copilot for Microsoft 365, Google Gemini for Workspace, and Anthropic's Claude for Teams tier are examples of tools that have enterprise data agreements attached to them. Public free-tier versions of those same tools often do not.

The distinction matters. When an employee uses the free tier of ChatGPT, OpenAI's terms of service may allow that conversation data to be used for model training unless the user has opted out. When a company uses ChatGPT Enterprise, there is a contractual agreement that data will not be used for training. Your policy needs to name these distinctions, not assume employees know them.

Prohibited uses should be specific. Generic language like "do not misuse AI" is unenforceable. Concrete examples include: generating content that impersonates a real person, using AI to make hiring decisions without human review, submitting AI-generated legal or medical advice to clients as original professional work, and inputting customer PII into any non-approved tool.

3. Data Input Rules

This is often the highest-risk section and the most underwritten one. Employees need clear guidance on what they may and may not paste, upload, or type into an AI tool.

A practical framework:

• Public tier tools: Public, non-sensitive information only. Marketing copy based on published information. General research. Code that contains no proprietary logic.
• Approved enterprise tools: Internal information may be used, subject to tool-specific data agreements. Confidential business data requires manager approval.
• No tool: Regulated data, including PII, PHI, payment card data, Social Security numbers, and trade secrets, should never be entered into any AI tool without explicit written approval from legal and IT.

Some organizations add a simple test employees can apply: "If this information appeared in a data breach, would it cause harm?" If yes, it does not go into a public AI tool.

4. Output Review Requirements

AI outputs require human review before use in any formal context. This is not optional. State it plainly and explain why: AI tools can generate factually incorrect information with high confidence, reproduce copyrighted content, or produce outputs that reflect training data bias.

For high-stakes outputs, such as client-facing documents, financial models, or legal correspondence, require a named human reviewer. For lower-stakes uses, a general requirement to verify key facts is sufficient. Some companies have introduced a simple sign-off convention where employees who submit AI-assisted work add a note confirming they reviewed the output. This creates a paper trail without creating excessive friction.

5. Disclosure and Attribution

Decide whether employees must disclose AI use to clients, colleagues, or in external publications. Some professional contexts require it. Law firms, accounting practices, and healthcare providers often have disclosure obligations tied to professional ethics standards.

Even where disclosure is not legally required, many companies choose to require it internally. Knowing that a proposal was drafted with AI assistance helps reviewers calibrate how closely they need to check it. Transparency also reduces the risk of reputational damage if AI use becomes public unexpectedly.

6. Consequences and Reporting

Policies without stated consequences are suggestions. Define what constitutes a violation, what the reporting process is, and what the range of outcomes looks like. Violations involving regulated data should trigger your existing incident response process.

Include a way for employees to report suspected violations without fear of retaliation. People are more likely to flag a colleague's risky behavior if the process is clear and psychologically safe. For more structured guidance on governance, review this AI compliance checklist for business leaders to ensure your policy aligns with regulatory expectations.

---

Treating This as a Living Document

AI tools change faster than most policy cycles. The tool your legal team approved in January may have changed its data terms by June. New regulations are moving quickly: the EU AI Act has active compliance deadlines, several U.S. states have passed AI-specific legislation in 2026, and industry-specific guidance from the SEC, HHS, and FTC is ongoing.

Build a review cadence into the policy itself. Quarterly reviews are appropriate for most companies actively deploying AI. Assign someone to monitor vendor terms, regulatory updates, and internal usage patterns. The policy should carry a "last reviewed" date and a named reviewer.

If you are still in the evaluation phase before rolling out an AI acceptable use policy, running a successful AI pilot program can help you gather real data on how your team actually uses AI tools—information that will make your policy far more practical and enforceable.

---

Common Gaps That Create Real Exposure

Three patterns show up repeatedly in companies that have faced AI-related incidents:

No coverage of third-party AI features. Most enterprise software now includes embedded AI. Salesforce Einstein, Notion AI, HubSpot's content assistant, and dozens of others are already active inside tools your employees use daily. A policy that only names standalone AI tools misses where most AI use actually happens.

No guidance on AI-generated code. Developers using GitHub Copilot or Cursor to generate code need specific guidance about reviewing that code for security vulnerabilities, licensing issues, and correctness. Code is a category that deserves its own section or a linked technical addendum.

No training attached to the policy. A policy that employees receive once during onboarding and never see again does not change behavior. The companies that have seen measurable reduction in AI-related incidents are the ones that pair policy with structured, recurring training. The policy sets the rules. Training builds the judgment to apply them.