AI acceptable use policy: nine clauses, each tied to the NIST framework

contents10 sections

key points

1. An AI acceptable use policy needs nine clauses: scope, approved tools, data rules, human review, disclosure, agents and embedded AI, incident reporting, exceptions and enforcement, and training and review. NIST's Generative AI Profile has a suggested action for most of them ¹.
2. Approve an account type, not a brand: the terms can depend on the plan. Anthropic's August 2025 consumer-terms update let Free, Pro and Max users choose whether chats train future models and did not cover its Team, Enterprise and API services, while Microsoft says Copilot prompts and responses are not used to train its foundation models ^2,3.
3. Put the data rule in the policy itself, using four classes (Public, Internal, Confidential, Restricted) tied to your existing data governance, which NIST suggests connecting new AI policies to ¹.
4. Roll out in order: audit current use, name an owner, ship an approved tool, then train and enforce. Gallup reported in 2025 that 30% of employees said their organization had AI guidelines or formal policies ⁴.
5. NIST's framework is voluntary, and its Playbook page says AI RMF 1.0 is being updated, so treat the mapping as a starting point and recheck it at each review ^5,6.

An AI acceptable use policy is a short written rule set that tells employees which AI tools they may use, what data must never go into them, when a person has to check the output, when to say AI was used and how to report a mistake. Nine clauses cover it, and most can be tied to a suggested action in NIST's Generative AI Profile ¹. Keep the policy to one or two pages, then put the effort into rollout: an audit of current use, an approved tool people want, training and a review date. The wider program is in our AI implementation plan.

What does an AI acceptable use policy need to say?

The table uses action IDs from NIST AI 600-1, the Generative AI Profile of the AI Risk Management Framework, which presents them as suggestions, not requirements ¹. Where no single action fits, it names the NIST subcategory instead.

3 columns: the table scrolls sideways inside its frame

Who is covered, and which tools are approved?

Scope. NIST's GV-6.1-010 says to update acceptable use policies for proprietary and open-source generative AI and data, and for contractors, consultants and other third-party personnel ¹. Add personal devices used for work.

Approved tools. Approve an account type, not a brand name, because the terms that apply can depend on the plan. When Anthropic updated its consumer terms in August 2025, users of its Free, Pro and Max plans could choose whether their chats train future models, and the update did not apply to its Team, Enterprise and API services ². Microsoft's Copilot documentation states that prompts, responses and data accessed through Microsoft Graph are not used to train its foundation LLMs, and that Copilot only surfaces organizational data to which a user has at least view permissions ³. The second Microsoft point has a policy consequence: an assistant that respects permissions will still surface files shared too widely, so fix over-shared folders before switching it on.

NIST suggests inventorying third parties with access to organizational content and keeping approved technology and provider lists (GV-6.1-007), and updating vendor due diligence for intellectual property, data privacy, security and products that embed generative AI (GV-6.1-009) ¹. In practice, keep a one-page register: tool, account type, owner, data classes allowed, last review date, and a request route with a published response time. Buy versus build is a separate decision, covered in build vs buy for AI; the policy only needs the result.

Draft wording. Employees may use only the AI tools on the approved list, signed in with a company account. Personal accounts and free consumer tools may be used only with Public data. Request a new tool through [owner]; we will answer within [time].

Which data should never go into an AI tool?

Use your existing data classification if you have one: NIST suggests connecting new generative AI policies to existing data, IT governance, legal and compliance work (MP-4.1-003) ¹. If you have none, four classes are enough.

3 columns: the table scrolls sideways inside its frame

The Restricted row reflects how these models behave. NIST notes that they can leak, generate or correctly infer sensitive information about individuals, and that inferences drawn from personal data can feed adverse decisions about people ¹. Health, financial and other regulated data usually carry legal duties of their own, and GV-1.1-001 is to align use with applicable data privacy, copyright and intellectual property law ¹. Have your compliance lead set the Restricted list instead of copying ours.

Draft wording. Never enter Restricted data into an AI tool unless the tool is approved for that class in writing. Never paste passwords, keys or tokens into a prompt.

When must a person check AI output, and when must you say AI was used?

NIST describes confabulation as confidently stated but false content that can mislead users, and automation bias as excessive deference to automated systems ¹. It says generative AI use may warrant additional human review, tracking and documentation, and GV-3.2-003 asks for acceptable use policies that cover human-AI configurations, including decision-making tasks ¹. The clause should name an owner and scale the checking with the stakes:

• Low stakes (brainstorming, internal drafts): the user reviews and owns the output.
• Medium stakes (customer-facing text, figures, code that ships): the user verifies every fact, number and source against an original, and a second person reviews anything external.
• High stakes (hiring, pay, discipline, credit, legal or safety decisions): AI may inform the decision but is never its sole basis, and the accountable manager records the review.

Employment law on AI in decisions about people can vary by place, so check it before allowing any use in the high-stakes tier.

Disclosure. NIST suggests considering disclosure of generative AI use to end users in relevant contexts, weighing the purpose, the context, the likelihood and size of the risk, the audience and the frequency (MP-5.1-003) ¹. Legal duties differ by sector and country. A workable default: disclose when a contract or regulation requires it, when a customer would reasonably expect to know, and to your manager when AI produced a substantial part of a deliverable.

Draft wording. You are responsible for everything you send, publish or act on, including AI-assisted work. Verify facts and figures against an original source. AI may not be the sole basis for a decision about a person.

How do agents and AI features inside other software change the policy?

A policy written for chat windows misses AI that acts: automations, browser extensions, meeting note-takers, and AI features inside software you already approved. NIST suggests adding generative AI systems to the inventory and defining any inventory exemptions for AI embedded in application software (GV-1.6-001, GV-1.6-002) ¹.

Agents add a security problem. The UK's National Cyber Security Centre argues that prompt injection may never be properly mitigated the way SQL injection can be, because current language models do not enforce a security boundary between instructions and data. It advises against giving a model that processes untrusted input, such as email from outside parties, access to privileged tools, and recommends logging enough to spot suspicious activity, potentially including the model's full inputs and outputs and its tool and API calls ⁷. For the policy, an agent that reads outside content such as email, web pages or uploaded files needs a named owner, the least access that works and logging. We also recommend human approval before it sends external messages or changes records.

Draft wording. Any AI agent, automation or plug-in that can read company data or act for us must be registered with [owner], use minimum access and keep logs. It may not send external messages or change records without human approval.

What should employees do when AI goes wrong?

NIST suggests agreeing minimum fields for an incident report (GV-4.3-002), such as the reporter, system, date, description, impacts and stakeholders affected. It also suggests recording errors and near-misses (MG-4.3-002), reporting incidents as law and regulation require (MG-4.3-003) and reviewing them afterward (GV-1.5-002) ¹.

Define reportable events in plain words: Restricted data pasted into a tool, wrong AI output that reached a customer, an agent that did something unexpected. Require a report the same working day, and say that prompt reporting of an honest mistake is not itself a violation. Otherwise people hide mistakes, and you cannot respond to what you never hear about.

Draft wording. Report any suspected AI incident to [channel] the same working day: the tool, what happened and what data was involved. Prompt reporting of an honest mistake is not a violation.

How do you roll out and enforce the policy?

Start from evidence about your own staff, because public numbers vary. Pew's February 2025 report found 9% of U.S. workers using AI chatbots every day or a few times a week ⁸. Gallup's August 2025 survey found 45% of U.S. employees used AI at work at least a few times a year ⁹. A 2024 Microsoft and LinkedIn survey of 31,000 knowledge workers found 78% of AI users bringing their own AI tools to work ¹⁰. The questions, populations and dates differ, so do not average them. Gallup also reported that 30% of employees said their organization had general guidelines or formal policies for AI ⁴.

1. Audit current use. Ask teams what they use and why, check single sign-on and expense records, and say plainly that it is not a hunt for offenders.
2. Name an owner and a small review group from security, legal, HR and one business lead, so roles are documented and clear (GV-2.1) ¹.
3. Ship an approved tool before restricting others. If the sanctioned route is worse than a personal account, the policy loses.
4. Pilot with one team for a few weeks, and rewrite whatever they could not follow.
5. Train by role in under an hour, using cases such as a wrong answer sent to a customer, a pasted contract and an agent given too much access.
6. Collect acknowledgments and publish a one-page version.
7. Set the review date. NIST asks organizations to plan periodic review and decide its frequency (GOVERN 1.5) ¹. We suggest quarterly in the first year, then twice a year, plus a review whenever a tool is approved or an incident occurs.

Enforcement. NIST's profile has no action on sanctions ¹, so tie breaches to your existing code of conduct instead of inventing penalties. A first honest mistake earns coaching and a fix. A repeated or deliberate breach, especially Restricted data in an unapproved tool, goes through the normal HR process. Technical controls such as company sign-in for approved tools, blocking known consumer endpoints on managed devices and data-loss prevention rules can help, but we cite no head-to-head evidence on which work best. Run any new block in monitor-only mode first.

Training in the EU. The Commission's AI Act service desk says Article 4 requires providers and deployers to take measures to support AI literacy among staff and others using AI for them, without guaranteeing any specific level. It shows the article as amended by the Digital Omnibus, so check the current text ¹¹.

What does this approach leave open?

Law is the largest gap. Sector rules, state and local employment rules, and the EU AI Act beyond Article 4 are outside this guide; NIST's GOVERN 1.1 outcome is that legal requirements are understood, managed and documented ¹. Vendor terms were read on October 23, 2026 and can change. NIST's Playbook page says AI RMF 1.0 is being updated ⁶, so recheck the mapping at each review. The Microsoft and LinkedIn figure comes from a vendor-commissioned survey of self-reported behavior.