Responsible AI Usage Policy Template: Acceptable-Use and Prohibited-Use Clauses

What this policy is, and what it isn’t

An AI usage policy is an internal document that tells staff what they are and are not allowed to do with AI tools — chatbots, coding assistants, image generators, agents connected to internal systems — in the course of their work. It is written for the people using the tools, not for the organisation’s leadership or its regulators.

That makes it a different document from an organisation-level AI governance framework, which sets out who owns AI risk, how new AI use cases get approved, what the review committee does, and how the organisation tracks and escalates incidents. A usage policy is one output of a governance framework, not a substitute for it: the framework decides who is accountable; the usage policy tells staff what the rules actually are day to day. If your organisation hasn’t yet built the governance layer, see the companion guide on building an AI governance framework first — the usage policy in this guide slots underneath it.

It is also a different document again from the public “frontier AI framework” that a law like California’s SB 53 requires the largest AI developers to publish. SB 53 obliges large frontier developers to write, implement, and publish a document describing how they identify and manage catastrophic risk across a model’s lifecycle — see our SB 53 explainer. That obligation falls on the handful of companies training frontier models. An internal acceptable-use policy is written by an organisation deploying AI tools built by someone else, for its own staff, and nothing in SB 53 requires it to be public. The two documents answer different questions for different audiences, but they are easy to conflate because both get called an “AI policy.”

Acceptable-use clauses: what they typically cover

The acceptable-use half of the policy states what staff can do, and under what conditions. Policies that hold up in practice — rather than being ignored after the launch email — consistently cover the same handful of areas:

• Approved tools and access routes. Which AI products or models staff may use for work, and through which account (a managed enterprise account with data-handling terms attached, not a personal consumer login). Unsanctioned “shadow AI” use is the single most common failure mode this clause exists to close off.
• Data handling. What categories of data may be entered into a prompt or uploaded to an AI tool, and what may not — personal data, client-confidential material, unpublished research, credentials, source code under a restrictive license. This clause typically points back to the organisation’s existing data classification scheme rather than inventing a new one.
• Human review and sign-off. Which outputs must be checked by a qualified person before they’re used or sent externally — code before merge, clinical or legal text before it reaches a patient or client, anything that will inform a decision about a person.
• Disclosure. When the use of AI has to be stated — to a client, in a publication, in a document’s metadata, or to the person it affects. This is usually the clause with the most organisation-specific detail, because disclosure norms differ sharply between, say, marketing copy and a research manuscript.
• Attribution and accountability. A default rule that a human, not the tool, is accountable for anything produced with AI assistance and used in the organisation’s name.

Prohibited-use clauses: what they typically cover

The prohibited-use half is a floor, not a wish list. Two distinct things usually end up in it, and it helps to keep them apart when drafting.

The first is a small set of uses that are unlawful outright wherever the organisation operates, independent of any internal policy choice. The EU AI Act’s Article 5, for example, bans specific AI practices as such — including AI systems designed to materially distort a person’s behaviour through subliminal or deceptive techniques that impair their ability to make an informed decision; social scoring of people based on behaviour across unrelated contexts; biometric categorisation that infers protected attributes such as political opinion, religion, or sexual orientation from biometric data; untargeted scraping of facial images to build or expand a facial recognition database; emotion-recognition systems used in the workplace or in education (outside narrow medical or safety exceptions); and, with narrow law-enforcement exceptions, real-time remote biometric identification in public spaces. An organisation subject to the EU AI Act cannot make any of these acceptable by internal policy, so a prohibited-use clause typically states them as absolute, not as a risk to be weighed. (See our EU AI Act vs. California SB 53 comparison for how the EU AI Act’s approach differs from the US state laws in this cluster.)

The second is a longer list of uses the organisation itself chooses to rule out because they carry disproportionate risk to it, even where no law names them directly — generating content designed to deceive, impersonating a real person, bypassing another system’s safeguards, or using an AI tool’s output as the sole basis for a decision about someone’s employment, credit, benefits, or care without human review. Published vendor usage policies are a useful reference point for drafting this half: Anthropic’s public Usage Policy, for instance, separates a set of universal standards that apply to all use from a smaller set of additional requirements — including mandatory human review and disclosure — that apply specifically to higher-risk domains such as healthcare, legal, financial, or employment-related use. Borrowing that same shape (universal rules, plus a shorter list of extra conditions for high-risk domains) is a reasonable starting structure for an internal policy, even though the exact prohibited categories a vendor lists are written for its own product and won’t map one-to-one onto an internal deployment context.

Disclosure and accountability requirements

A usage policy that stops at “here’s what you can and can’t do” tends to decay within a year, because nobody owns enforcing it. The clauses that keep it alive are the accountability ones:

• Named ownership. A specific role (not “IT” in the abstract) responsible for maintaining the policy, fielding questions, and approving exceptions.
• An incident path. Where staff report a suspected policy breach or an AI-caused error, and what happens to that report. This is usually the same intake as the organisation’s broader risk register — see our guide on building an AI risk register for how individual incidents should feed back into it rather than disappearing into an inbox.
• A review cadence. AI tools and their risks change faster than most policy documents; a stated annual (at minimum) review date keeps the acceptable-use list from going stale the first time a new tool category shows up.
• Consequences. What happens when the policy is breached, stated plainly enough that it’s enforceable rather than aspirational.

A working structure to adapt

There’s no single mandated format, but a policy document that a new hire can actually read in one sitting typically follows this order:

1. Purpose and scope — which AI tools, which staff, which systems this policy governs.
2. Approved tools and access — the sanctioned list, and how to request an addition.
3. Acceptable use — data handling, human review, disclosure, attribution (as above).
4. Prohibited use — the absolute, law-derived floor, followed by the organisation’s own additional restrictions (as above).
5. High-risk and regulated domains — any extra conditions for clinical, legal, financial, HR, or research use.
6. Reporting and enforcement — the incident path, ownership, and consequences.
7. Review cadence — who reviews it, and how often.

Sections 3 and 4 are the ones organisations most often draft badly — either too vague to enforce (“use AI responsibly”) or copied wholesale from a vendor’s consumer-facing terms, which aren’t written for an internal deployment context. Both fail for the same reason: they don’t distinguish what a law makes non-negotiable from what the organisation has chosen for its own reasons, so staff can’t tell which clauses are actually load-bearing.

Where this fits with the rest of your AI compliance obligations

An internal usage policy doesn’t, by itself, satisfy any of the frontier-model transparency obligations covered elsewhere in this cluster — those attach to the organisations building frontier models, not the ones using AI tools day to day. But it is usually the first concrete artefact an organisation can point to when a regulator, auditor, or client asks “how do you govern AI use internally,” and it’s a prerequisite input if the organisation later pursues a structured framework such as ISO/IEC 42001 certification, which expects a documented usage policy as one of its Annex A controls. Writing the usage policy first, and the fuller governance framework and risk register around it, is generally the more tractable order than trying to do all three at once.

How CASRAI’s NIKOLAI tracks this

CASRAI’s own NIKOLAI project — an independent, unendorsed reference dictionary of frontier-AI-safety terminology — maps the “who owns this decision” question this guide raises in its Commitments and Governance track (N9), specifically the Accountable Decision-Maker and Sign-Off element: a documented record of the named role or person approving a policy, deployment, or framework decision, including what was approved and when. The same discipline that keeps a usage policy from lapsing into an unowned committee document is what that element is designed to make explicit and auditable.

CASRAI doesn’t certify or endorse any organisation’s internal policy against this definition — NIKOLAI is a reference vocabulary, not a compliance standard — but organisations that want to state explicitly how their own sign-off practice maps to this terminology can do so through NIKOLAI’s Mapping Declarations.

Frequently asked questions

Do we need a separate AI usage policy if we already have an acceptable-use policy for IT systems generally?

Most organisations that already have a general IT acceptable-use policy add AI-specific clauses to it rather than maintaining a wholly separate document — the data-handling and disclosure questions are distinct enough from general IT use (what goes into a prompt, whether output needs human review) that a short dedicated section or annex is usually clearer than folding AI in as a single bullet point.

Who should own the policy?

Ownership varies by organisation size, but it needs to be a named role with the authority to approve or deny tool requests and to escalate incidents — not a committee with no single accountable owner, which is the most common reason these policies stop being maintained after the first year.

Does an acceptable-use policy replace the need for a governance framework?

No. The usage policy tells staff what the rules are; the governance framework establishes who set those rules, how they get updated, and who is accountable when something goes wrong. See the companion guide on building an AI governance framework.

Should the prohibited-use list just copy a vendor’s usage policy?

No. A vendor’s public usage policy is written to protect the vendor across every customer and use case, so it’s broader and more generic than a single organisation needs. It’s a useful reference for structure and categories, but the list of what’s actually prohibited should reflect the organisation’s own risk tolerance and legal exposure, plus whatever practices are prohibited outright by laws such as the EU AI Act’s Article 5.

How often should the policy be reviewed?

At least annually, and immediately after any material change in the tools staff have access to or the regulatory obligations the organisation is subject to.