What Goes in an AI Use Policy

Most firms now agree they need an AI use policy. Far fewer can say what should be in one, which is why so many policies end up as either a one-line ban nobody follows or a vague encouragement to “use AI responsibly” that decides nothing. A policy earns its existence by answering the questions people actually face at their desks, and those questions are more specific than most policy documents admit.

What follows is the practical skeleton: the decisions a working AI policy has to make, drawn from what professional teams actually run into. A firm that answers these clearly will have a policy people can follow. A firm that leaves them open will have a document, which is not the same thing.

Where AI may be used, by data class

The first decision is not about tools but about information. Which classes of material may enter which systems? Public information, internal working notes, client-confidential documents, personal data, and regulated material do not carry the same risk, and a policy that treats them identically will be either uselessly strict or dangerously loose. The workable pattern is a short table: this data class, in these approved tools, never in those. People can follow a table. They cannot follow a mood.

This is also where approved tools belong. A policy that only bans is a policy that pushes use into the shadows; the firms that keep visibility pair every restriction with a sanctioned route that is genuinely good enough to use. If the approved path is slower than the forbidden one and no better, the policy has already lost.

When review is required, and by whom

The second decision is the review threshold. Not everything needs sign-off: a brainstorm is not a client memo. The policy should say, concretely, which outputs require a named reviewer before they are relied on: client-facing deliverables, external communications, anything feeding a significant decision, anything in a regulated area. And it should say who can be that reviewer, because accountability that could be anyone is accountability that is no one.

The strongest version makes the gate structural rather than aspirational. A policy that says important answers must stop for approval is upheld by whoever is busiest that day; a workflow with configurable approval gating enforces it regardless. The policy defines the line; the workflow holds it.

What gets recorded, and what happens when it goes wrong

The third decision is the record. If AI-assisted work is later challenged, what can the firm produce? A policy should require that significant AI-assisted work leaves a trace: what was produced, what evidence supported it, who reviewed and approved it. It should also say what happens when something slips through: how a problem is reported, who triages it, and where the record of the incident lives. A policy with no incident path is a policy that assumes it will never be tested.

These are also the elements that line up with where regulation is heading. The EU AI Act pushes organizations toward exactly this shape: oversight proportionate to risk, records that survive scrutiny, incidents that get reported rather than smoothed over. A firm that writes its policy around those elements for operational reasons ends up close to what the regulatory expectations point toward, without writing a compliance document that ignores how work actually happens.

One last test for any draft policy: give it to the newest person on the team and ask them what they are allowed to do tomorrow morning. If they can answer in a sentence, the policy works. If they hesitate, the policy is a values statement wearing a policy’s clothes, and the real decisions are still being made ad hoc, one desk at a time.

This article is for general information only and does not provide legal advice. Organisations should consult qualified legal counsel about how the EU AI Act applies to their specific systems, workflows, and obligations.