What belongs in an AI acceptable use policy

An AI acceptable use policy needs eight things: a data classification tied to which tools may see each class, a named list of approved tools and accounts, a verification rule for anything the model produces, a disclosure rule, an ownership statement, a logging and retention line, a way to ask for a new tool, and a named owner. Everything else is commentary. A policy that bans tools without naming approved ones produces shadow use, not compliance.

Most policies we read fail in the same way: they are written to protect the company from the tool, when the actual risk is the gap between what the tool does with data and what the staff assume it does.

Key takeaways

• Classify data first. The question is never “may I use ChatGPT”, it is “may this class of data go into that account”.
• Consumer AI accounts train on conversations by default at both OpenAI and Anthropic in 2026. Business and API tiers do not. The policy has to say which accounts the company pays for.
• Every output that leaves the building gets verified by a person who is accountable for it. Fabricated citations have already cost real money in court.
• Since 2 August 2026 the EU AI Act requires that people be told when they are talking to an AI system where it is not obvious. Write the disclosure rule now.
• The policy needs an owner, a request path for new tools, and a review date. Without those it is a PDF nobody opens after onboarding.

Who this applies to

Any company whose staff can open a browser. That is the honest scope. If your people have not been told which AI tools they may use, they are already using one, on a personal account, with whatever they had on the clipboard.

This article is for the person who has been asked to write or fix the policy: an operations lead, a head of IT, a founder, an HR manager. It is not legal advice. Where the rules below touch law, the section says so and the right move is a short conversation with counsel, not a longer policy.

If you are a regulated firm with an existing information security programme, most of this is already in your data handling standard. What you probably lack is the mapping from data class to AI tool, and the verification rule. Start there.

Why most policies fail

The typical first draft is one paragraph long and says “do not put confidential information into AI tools”. It fails for three reasons.

It does not define confidential. The engineer who pastes a stack trace containing a customer email does not think of it as confidential. The salesperson who uploads a contract to summarise it does not think of it as confidential. Without a classification, everyone applies their own.

It bans without providing. A ban with no approved alternative is a ban on productivity, and it is quietly ignored. The reported Samsung case from 2023, where engineers pasted internal source code into ChatGPT within weeks of being given access, is what happens when access arrives before rules. The response was a ban, which moved the same behaviour to personal phones.

It assumes the tool is the risk. The tool is a fixed quantity. The risk is the mismatch between what the vendor does with your input under a given account type and what your staff believe it does. That mismatch is closable with one table, which most policies do not contain.

The eight sections

1. Data classification

Three classes are enough for most companies. More than four and nobody remembers them.

• Public. Already on the website, in published marketing, in a press release. Anything goes.
• Internal. Not secret, but not published. Meeting notes, internal process docs, draft copy, code that is not the core product.
• Restricted. Personal data about customers or staff, financials, credentials, unreleased product, anything under an NDA, anything covered by a regulator.

The policy states who classifies ambiguous material. The default answer is the person who created it, with restricted as the fallback when unsure.

2. Approved tools and accounts

This is the section that does the work, and it is the one most policies omit. The rule is not per tool. It is per tool and account tier, because the vendor’s behaviour changes with the tier.

The defaults as they stand in September 2026:

Two things follow. First, a personal account, even a paid one, belongs in the public column. The opt-out exists, but a policy cannot rely on every employee having found the setting. Second, the company has to actually buy the business tier for the tools it approves. A policy that approves “ChatGPT” while paying for nothing has approved the consumer tier.

Vendors change these defaults with notice and the table above will date. Give the section a review date and link the vendor’s own data-usage page rather than restating it.

3. Verification

The model is a drafting tool. A person signs.

• Anything sent to a customer, a court, a regulator, a partner or the public is read in full by a named person before it goes.
• Every citation, statistic, quotation, case reference and URL is checked at the source. In Mata v. Avianca in 2023 a federal court in New York fined two lawyers $5,000 for filing a brief containing case citations that ChatGPT had invented. The tools have improved. The rule has not changed.
• Code generated by a model goes through the same review as code written by a person. It does not skip the pull request because it was fast.
• Figures produced by a model from an uploaded spreadsheet are reconciled against the spreadsheet.
• The person who verifies is accountable for the output. “The AI said so” is not a defence the policy recognises.

4. Disclosure

Three rules cover it.

• Customers are told when they are talking to a system. Under Article 50 of the EU AI Act, in force for this obligation since 2 August 2026, providers and deployers must ensure people are informed they are interacting with an AI system unless it is obvious from context. Whether or not you sell in the EU, a bot that claims to be a person costs trust the moment it is found out, which is always.
• Colleagues are told when a document was substantially drafted by a model, so that they apply the verification rule rather than assuming a person already did.
• Nobody is required to disclose using a model for their own notes, drafts or research. A policy that demands disclosure of every use is ignored within a week.

5. Ownership and intellectual property

State three things plainly.

Prompts, system prompts, evaluation sets and fine-tuned models built on company time are company property, the same as any other work product. This belongs in the employment contract as well as the policy, and if it is not there, that is a conversation with counsel.

Output produced by a model with no meaningful human contribution may not be protected by copyright. The US Court of Appeals for the D.C. Circuit confirmed in March 2025, in Thaler v. Perlmutter, that a work generated autonomously by a machine has no human author and cannot be registered. The practical consequence for the policy: anything the company wants to own as an asset, a logo, a product description set, a body of documentation, needs a person shaping it, not just prompting it.

Confidential input into a consumer account may, under the vendor’s terms, be retained and used for training. That is not theft, it is the agreement the user clicked through. The policy prevents it by the account rule in section 2, not by a warning here.

6. Logging and retention

Say what the company keeps. If you run an internal assistant or an API integration, you hold prompts and outputs, and they may contain personal data. That makes them records under data protection law with a retention period, an access right and a deletion obligation. We cover the design of that log in building an audit trail an AI system can defend.

Say also what the vendor keeps, because it can leave your control. In 2025 a court in the New York Times v. OpenAI litigation ordered OpenAI to preserve ChatGPT output logs that would otherwise have been deleted. The order was lifted in October 2025 for logs going forward, but what had been retained stayed retained. The lesson for the policy is short: a conversation in a consumer chat tool is not a private note, it is a record held by a third party, and a court can reach it.

7. Requesting a new tool

Five lines: who to ask, what to state (the tool, the data class it will see, the account tier, the vendor’s training and retention terms), who decides, how long it takes, and where the approved list lives. If this path takes longer than a week, staff route around it.

8. Owner and review

A name, not a department. A review date no more than twelve months out, and sooner when a vendor changes terms. Both OpenAI and Anthropic changed consumer defaults in 2025; the section 2 table has a shelf life.

The one obligation most companies have and do not know about

Article 4 of the EU AI Act, as amended by the Digital Omnibus regulation that entered into force on 27 July 2026, requires providers and deployers of AI systems to take measures to support the AI literacy of their staff and of anyone operating systems on their behalf. The amended text says explicitly that it does not require guaranteeing any specific level of literacy in any individual. It is an obligation to act, not an obligation to certify.

A deployer is anyone using an AI system in a professional capacity in the EU. A company outside the EU that operates a system whose output is used in the EU is in scope. For most small companies the whole obligation is satisfied by a policy that is actually taught: a forty-minute session, the eight sections above, three worked examples of what goes in which column, and a record that it happened. That is the same session that stops the personal-account problem, so the compliance cost is close to zero.

Where we draw the lines, and why

We recommend classifying more conservatively than most companies want to. Meeting notes go in the internal column, not the public one, because meeting notes are where personal data about staff turns up unannounced. Customer support transcripts are restricted, full stop, because they contain names, addresses and order histories in every third message.

The line we hold that costs us arguments: no consumer accounts for work, even for public data. The rule is defensible in principle only for internal and restricted data. We extend it anyway, because a policy with an exception for public data requires every employee to classify correctly every time, in the moment, with the paste already on the clipboard. A rule with no exceptions is followed. A rule with a judgement call is followed on good days. The cost is a business subscription per seat, which is less than one incident.

We also refuse to write policies that require disclosure of every use. We have seen the draft, we have seen it adopted, and we have seen it produce a culture where people use the tools and say nothing, which is the outcome the policy existed to prevent. Disclose what leaves the building and what a colleague will rely on. Leave the rest alone.

When this is not worth it

When nobody is going to teach it. An unread policy has no effect on behaviour and gives a false sense of coverage. If there is no forty minutes available to walk the team through the grid, write the grid on one page and pin it, and skip the rest.

When the real problem is that no tools are approved. If the company has decided not to pay for any business tier, the policy is a ban with extra steps. Decide the purchasing question first.

When you are already under a formal information security standard with data classification and vendor assessment built in. Add the tool-to-class table to the existing standard rather than writing a parallel document that will drift from it.

A sole trader does not need a policy, they need the section 2 table and the verification rule, and they can hold both in their head.

Frequently asked questions

Should we just block AI tools at the network level?

Blocking moves use to personal devices, where you have no visibility and no policy. It is the right answer only for genuinely restricted environments where personal devices are already excluded. For everyone else, approve a business tier and teach the grid.

Does opting out of training on a consumer account make it acceptable for internal data?

The opt-out is real at both major vendors, but it is a per-user setting the company cannot verify, and it does not change the retention or the legal reach of a consumer account. Treat opted-out consumer accounts as consumer accounts.

What about tools built into software we already use?

Office suites, CRMs and help desks now embed models, often on by default. Each one belongs in the section 2 table with its own row, and the question is the same: what does this vendor do with the input under our contract. Most enterprise suites do not train on customer data; check the specific product terms rather than the vendor’s general position.

Do we need a separate policy for developers using coding assistants?

No, but section 2 needs a row for the assistant and section 3 needs the pull request rule. The code review is the control. The risk specific to developers is credentials and customer data in the files the assistant can see, which is a repository hygiene question the policy should reference.

How do we handle a breach of the policy?

The same way as any other data handling breach, through the existing disciplinary and incident process. The policy should say that rather than invent a separate one. The first breach is usually an honest mistake caused by a gap in the training, and the right response is to fix the training.

Is one policy enough for a company operating in several countries?

Usually. The data classes and the account rules do not change by country. The disclosure rule may be stricter in the EU after August 2026, and the literacy obligation is EU-specific, so the policy applies the strictest rule everywhere rather than maintaining variants.

Next step

If the policy exists but nobody follows it, the gap is the teaching, not the document. AI training and enablement is a working session with your team on your tools and your data, with the grid above built for your actual classes.

Related: Building an audit trail an AI system can defend · Automated decisions and the right to human review · Responsible AI as an engineering decision · What you own after an AI project: code, prompts and evals