How to Write an AI Acceptable Use Policy People Follow

Direct answer: An AI acceptable use policy that people follow is short, concrete and enforceable. It names which tools are allowed and which are not, states plainly what data must never go into a model, says who is accountable for what a model produces, and carries a signed attestation proving everyone read it. Writing the rules is the easy part. Scoping them to how your company actually works, rolling them out, and keeping the attestation record are what turn a document into a control a buyer or an auditor will accept.

Step 1: Scope it to reality, not to fear

A policy written against an imagined worst case gets ignored, because it bans things people need to do their jobs and says nothing about what they are actually doing. Start by finding out which AI tools are already in use. Some are obvious assistants. Many are AI features bolted onto tools you already pay for, and some are personal accounts people reach for when the sanctioned path is slower. Write the policy to cover the general-purpose assistants, the embedded features in your existing stack, and anything your own product builds on top of a model. If you do not know what is in use, that discovery is step zero, and our shadow AI risk checker is a quick way to surface it.

Step 2: Write the data rules in plain language

This is the clause that matters most and the one most policies fumble by being vague. People cannot follow do not share sensitive data when nobody has told them what counts. Tie the rule to your data classification. Say, in words an engineer or a salesperson can act on without a lawyer, what must never be pasted into a public model: customer personal information, anything under NDA, credentials and secrets, source code if that is your position, and regulated data such as health or payment information. Then say what is fine, because a policy that is all prohibition teaches people to route around it. If you run an approved enterprise tool where data is not used for training, say so, because that is the path you want people to take.

Step 3: List approved tools and a path to add more

Name the tools people may use and the account type that is allowed, since the free tier and the enterprise tier of the same product often have different data terms. Then give a fast route to request a new one. The reason shadow AI thrives is that the sanctioned list is short and the approval process is slow, so people solve their problem and tell no one. A request path that returns an answer in days rather than weeks is the single biggest thing that keeps the policy honest.

Step 4: Make a human accountable for the output

The clause that keeps you out of trouble is the one that says a model produces a draft, and a named person is accountable for what gets used, sent or shipped. AI output is a starting point until a human reviews and accepts it. That principle covers the obvious risks, code that was never read, a client email that invented a fact, a hiring or credit decision that leaned on a model, and it is also what buyers increasingly ask about. State where human review is mandatory rather than advisory, and who owns it.

Step 5: Roll it out so it is read, not filed

A policy nobody read is not a control, and an auditor or a buyer can tell the difference. Fold the AI policy into the same flow as the rest of your security awareness training rather than emailing a PDF and hoping. Walk people through the data rules with examples from their own work, because the abstract version does not stick. Tie it to onboarding so new starters get it on the way in, and refresh it when the tool list changes, which with AI is more often than annually. The generator produces the document; the rollout is what makes it operate.

Step 6: Keep the attestation record

The evidence that turns the policy into a control is the attestation: a dated record that each person in scope read and acknowledged the current version. Keep it per person, keep the version, and refresh it when the policy changes materially. This is the artefact a security questionnaire is really asking about when it asks whether you have an AI usage policy, and it is the one most companies cannot produce because they wrote the policy and never captured the acknowledgement.

Where the policy fits in the bigger picture

An AI acceptable use policy is one document inside AI governance, not the whole of it. It governs how your people use AI tools. It does not by itself cover how you classify AI risk across the business, how you assess AI vendors, or how you would approach a management system standard such as ISO 42001. If your buyers are starting to ask broader questions, the policy is the right first move and the cheapest, but it is a first move. Review it on a set cadence and whenever your tool list or your regulatory exposure changes, because an AI policy dated eighteen months ago describes a world that no longer exists.

How long should the policy be?

Short enough to be read in one sitting. A page or two of rules people can act on beats a long document that covers every contingency and gets filed unread. Depth belongs in the data classification and the approval process it points to, not in the policy text.

Does an AI policy satisfy a security questionnaire?

It answers the question, but only if you can also show the attestation record and name the person accountable for AI use. A questionnaire that asks for an AI policy is asking whether the policy operates, which means the document plus evidence it was read and is enforced.

How do we handle a tool someone wants that is not approved?

Give it a named route and a short turnaround. The request names the tool, the account type, the data it would touch and the business reason, and the owner of the policy approves, declines or approves with conditions within days. The alternative is not that people stop using unapproved tools. It is that they use them quietly and the policy becomes fiction.

Do we need one if we only use AI features inside tools we already have?

Yes, and those embedded features are exactly where the data rules matter, because people do not think of them as AI tools and will paste things into them that they would hesitate to put into a standalone assistant. The policy should name those embedded features explicitly, because a rule aimed only at standalone assistants quietly exempts the riskiest everyday habit in the company.