An AI Acceptable Use Policy That Holds Up in Court

On January 5, 2026, a federal judge in the Southern District of New York settled a question most acceptable use policies never considered: are the things employees type into an AI chatbot private? The answer, in the consolidated copyright litigation brought by The New York Times and other news organizations against OpenAI, was no. District Judge Sidney Stein affirmed the discovery order compelling OpenAI to produce 20 million de-identified ChatGPT logs, rejecting the company's request to hand over only the conversations that touched the plaintiffs' copyrighted work.

That ruling should reframe how security teams think about AI acceptable use policies. Most were written around a narrower fear: that a prompt might end up training a competitor's model. The more immediate risk is procedural. A prompt is a record. Records get subpoenaed. Once a court decides that AI conversations carry no special privilege, every organization whose employees paste customer data, financial figures or legal strategy into a chatbot has created a document that opposing counsel, in some future dispute that has nothing to do with AI, can ask a judge to compel.

This post covers what belongs in an AI acceptable use policy, a full copy-paste template built around those components and, since a policy nobody enforces is just a document, where enforcement needs to live.

What Is an AI Acceptable Use Policy?

An AI acceptable use policy is a written set of rules that defines how employees may use AI tools and services in the course of their work: which tools are approved, what data may go into them, what uses are prohibited and what happens when someone breaks the rules. It is a subset of the broader data security policy most organizations already maintain, addressing the specific and fast-moving risks that generative and agentic AI introduce.

The policy exists because employees are already using AI whether or not anyone approved it. Drafting assistants, code completion tools, meeting summarizers and increasingly autonomous agents show up inside workflows faster than most governance processes can evaluate them. A written policy gives employees a clear answer to whether they can use a given tool for a given task, instead of leaving that judgment call to whoever is under deadline pressure that day.

Why It Matters Now

Two forces are converging on this policy type at once. The first is legal exposure of the kind the OpenAI ruling just confirmed: AI conversations are discoverable, and courts are treating the fact that they involve a chatbot as legally irrelevant. The second is that the tools themselves have changed faster than most policies have. Generative AI security risks that seemed hypothetical two years ago, an employee pasting a customer record into a public chatbot, a retrieval pipeline surfacing a file nobody meant to expose, are now routine incident categories. And this year's agentic AI risk adds a dimension most existing policies never anticipated: software that takes action on an employee's behalf, sometimes without a human reviewing the output before it reaches a system of record.

An acceptable use policy written for 2023's tools, one prompt, one human, one chat window, does not cover 2026's reality. It needs rebuilding around what AI actually does inside your organization today, not what it did when the last version was drafted.

What Belongs in an AI Acceptable Use Policy

Whether you are drafting one from scratch or updating something written when ChatGPT was the only tool anyone worried about, these are the components that separate a policy that holds up from one that quietly gets ignored.

Scope

State plainly who the policy applies to (employees, contractors, third parties acting on the organization's behalf) and what counts as an AI tool for the policy's purposes. Definitions matter more here than in most policy types, because AI now includes standalone chatbots, AI features embedded inside approved software such as productivity suites and CRM platforms, and autonomous agents acting without a human initiating each step. A policy that only defines the first category has already left two open.

Sanctioned, tolerated and unsanctioned tools

List the AI tools employees are approved to use and, for each one, the business purpose it is approved for. Approval should specify the tenant and account type, not just the tool name. A consumer ChatGPT account and an enterprise ChatGPT account carry different data retention terms and different risk profiles, and a policy that says "ChatGPT is approved" without specifying which version leaves that distinction to chance.

Tool vetting has a geopolitical dimension now, not just a data retention one. In May 2025, Microsoft President Brad Smith told a Senate hearing that Microsoft employees are barred from using the DeepSeek app, citing user data stored on servers in China, where it is subject to laws requiring cooperation with state intelligence agencies. That is a different category of risk than a tool simply training on prompts, and a policy that only screens for data retention terms misses it. Your shadow AI problem grows in exactly the gap between what is approved and what employees find useful enough to use anyway, so pair every prohibition with an approved alternative that does the same job. A ban with nothing to replace it just moves the behavior somewhere you can't see it.

Data classification and permitted use

Map your existing data classification tiers, public, internal, confidential, restricted, to what each tier is allowed to touch. Public data can generally go into any approved tool. Restricted data, including regulated categories such as PHI, PCI and trade secrets, should be prohibited from any AI tool by default unless a specific, documented exception exists. This section only works if your organization already has a functioning classification scheme in place; classifying data for AI use is downstream of classifying it at all, so that gap needs to close first if it hasn't already.

Prohibited uses

Be specific rather than categorical. Telling employees not to use AI irresponsibly gives them nothing to act on. Telling them not to paste customer PII, source code or unreleased financial figures into a public AI tool does. Cover the technical attack surface too, not just data handling: employees should know what a prompt injection attempt looks like and who to report it to, since a policy that only addresses what employees type in misses what a compromised document or web page might feed the model on their behalf. Securing AI prompts is as much a training question as a technical control.

Human review and accountability for AI output

Define who owns an error when AI-generated content reaches a customer, a regulator or the public with something wrong in it. The safest default: AI output used in any customer-facing or decision-making context requires human review before it goes out, and the human who approved it, not the tool, is accountable for what shipped. State this explicitly. Employees who assume the AI's word is a defense need to hear otherwise before it becomes a problem rather than after.

Agentic AI

This is the component missing from nearly every AI acceptable use policy template in circulation, most of which were written for a world where a human types a prompt and reads the answer. That world already has company. AI agents now take autonomous action, querying systems, drafting and sending communications, updating records, without a human approving each individual step. An agent inherits whatever access its connections give it, and that access is rarely scoped as narrowly as the human user it was set up under.

Your policy needs its own clause for this: an inventory requirement for every agent and what it can reach, least-privilege access scoped to the agent's actual task, and human-in-the-loop approval for any action with real consequences, a financial transaction, an external communication, a change to a system of record. Forcepoint AI Agent Gateway is built around exactly this problem, brokering credentials, enforcing field-level permissions and routing approvals through Teams, Slack or email rather than assuming an agent should hold the same access as the person who deployed it. If your policy treats agentic AI security as a future problem, it already has a gap that matters today.

Incident reporting and review cadence

Define what happens when the policy is violated: who gets notified, what the escalation path looks like and what documentation the incident produces. This section should connect to your broader regulatory compliance requirements, since a violation involving regulated data may trigger breach notification obligations independent of anything internal to the policy. Set a review cycle of at least once a year, with an out-of-cycle trigger whenever a major new tool category emerges. AI tooling changes fast enough that an annual-only review will always be catching up.

Where Policy Meets Enforcement

A written policy states intent. It does not stop an employee from pasting a customer record into an unapproved chatbot, and it does not know that an agent just queried a database it had no documented reason to touch. That gap closes by extending controls you likely already run for other channels, not by building an entirely separate stack for AI.

Forcepoint DLP applies the same classifiers and policy logic that already govern email, endpoint and SaaS data to AI prompts and outputs, so a rule that blocks a customer record from leaving through email applies with the same logic when the exit point is a chatbot instead. Forcepoint DSPM feeds the classification layer this whole policy depends on, discovering and tagging sensitive data before it ever reaches an AI workflow, so the restricted data tier in your policy has something concrete behind it rather than an assumption about where sensitive files live. Forcepoint CASB extends that enforcement into the sanctioned tools list itself, governing which AI applications employees can reach and applying per-application rules, including the tenant-level distinction between a consumer account and an enterprise account that the tool vetting section above depends on. For organizations securing Microsoft Copilot specifically, that enforcement extends to catching oversharing risk inside SharePoint and OneDrive before Copilot can surface it to someone who shouldn't see it.

None of this replaces the policy. It's what makes the policy something other than a document nobody checks. For a deeper look at the broader case for treating AI governance as a continuous program rather than a static policy review, see our AI security policy piece.

The AI Acceptable Use Policy Template

Copy this into your own document and fill in the bracketed sections. It's built around the seven components covered above, so nothing here should be new, only put into a form you can circulate for sign-off.

[Company Name] AI Acceptable Use Policy

Effective date: [date]  |  Policy owner: [name/title]  |  Review cycle: [annual/semi-annual]

1. Purpose and Scope

This policy governs the use of artificial intelligence tools, including generative AI, embedded AI features and autonomous AI agents, by [employees, contractors and third parties acting on behalf of Company Name]. It applies to any use of AI in connection with company business, regardless of whether the tool is provided by the company or accessed independently.

2. Definitions

• AI tool: Any standalone application, embedded feature or autonomous agent that generates text, code, images or decisions based on user input or defined triggers.
• Sanctioned tool: An AI tool approved for use under this policy, including its specific tenant or account type.
• Restricted data: [Define per your existing data classification policy, e.g., PHI, PCI, trade secrets, unreleased financials.]
• Agentic AI: An AI system capable of taking autonomous action, such as querying systems, sending communications or modifying records, without step-by-step human approval.

3. Approved AI Tools

Tools not listed here are unsanctioned. Employees may request evaluation of a new tool by contacting [contact/process].

4. Data Classification and Permitted Use

5. Prohibited Uses

• Submitting restricted or confidential data to any unsanctioned AI tool.
• Using AI output in customer-facing or regulatory communications without human review.
• Using personal AI accounts for company business.
• [Add industry- or role-specific prohibitions, e.g., using AI for automated hiring or credit decisions without human oversight.]

6. Human Review and Accountability

AI-generated content used in any customer-facing, regulatory or decision-making context requires review and approval by a qualified human before use. The approving employee, not the AI tool, is accountable for the accuracy and appropriateness of the output.

7. Agentic AI and Autonomous Systems

• All AI agents must be inventoried, including the systems and data each agent can access.
• Agent access must follow least privilege and must not inherit the full access rights of the employee who deployed it.
• Actions with material consequences (financial transactions, external communications, changes to systems of record) require human-in-the-loop approval before execution.
• Agent actions must be logged with full attribution to the responsible human, team or agent identity.

8. Violations, Incident Reporting and Review

Suspected violations of this policy should be reported to [contact/process] within [timeframe]. Violations may result in disciplinary action up to and including termination. This policy will be reviewed at least annually by [policy owner] and on an ad hoc basis when new AI tool categories or material regulatory changes emerge.

The Fix Isn't Refusing to Use AI

When Microsoft, JPMorgan and other early movers first restricted employee use of ChatGPT in 2023, most treated it as a temporary block while they figured out what came next. JPMorgan's answer wasn't a permanent ban. It was LLM Suite, a proprietary AI platform now used by more than 60,000 employees for the same tasks the ban had prohibited on the public tool, built with data controls the public tool couldn't offer.

The same lesson applies to the discovery risk this post opened with. The fix isn't refusing to use AI, since that just pushes usage to unmanaged tools you can see even less of. It's writing a policy specific enough to say what's allowed, pairing it with enforcement that makes the rule real and drafting every clause as though a court might read it one day, because one already has.

Ready to see how Forcepoint AI Data Security enforces AI acceptable use across the tools you already run, instead of requiring a separate stack for AI? Talk to an expert to see how it works.