Writing an AI use policy your team will actually follow

Staff in most organisations are already using AI tools, with or without permission. A policy written as though adoption has not started yet will be ignored, because it describes a situation that no longer exists.

A useful policy accepts current reality, sets a small number of clear boundaries, and makes the safe path the easy one.

Start by finding out what is already happening

Before drafting anything, ask. A short, non-punitive conversation about which tools people use and what they use them for will produce a more accurate picture than any audit.

This matters because unsanctioned use is usually driven by a genuine gap. If three people are pasting client emails into a consumer chatbot to draft replies, the underlying problem is that drafting replies takes too long. A prohibition alone will not solve that.

What the policy needs to cover

That last point is frequently omitted and is one of the most important. If admitting an error is costly, errors are concealed and the organisation loses the ability to correct course.

• Which tools are approved, and how to request one that is not
• What information must never be entered into an external tool
• Where human review is mandatory before output is used
• Who is accountable when AI-assisted work goes out under someone's name
• How to raise a concern or report a mistake without penalty

Be specific about data

“Do not share sensitive information” is not actionable, because people disagree about what counts as sensitive. Name the categories directly: client identifiers, contract terms, personal data, unreleased financials, credentials, anything covered by an NDA.

Where a category is genuinely ambiguous, say so and give people a route to ask. Ambiguity handled openly is manageable; ambiguity left unaddressed produces inconsistent judgement calls.

Keep it to one page

A policy that requires a training session to understand will not shape behaviour in the moment someone is deciding whether to paste a document into a browser tab.

One page, plain language, with examples of both acceptable and unacceptable use. Detailed guidance can live in an appendix for the people who need it, but the operative rules should fit on a single screen.

Explain the reasoning

Rules with visible reasoning survive edge cases. If people understand that the concern is client confidentiality rather than institutional caution, they can apply judgement to situations the policy did not anticipate.

Rules without reasoning are followed literally where they do not apply and abandoned entirely where they are inconvenient.

Set a review date before you publish

The tooling landscape changes quickly enough that any policy will be partly out of date within a year. Putting a review date on the document at the point of publication signals that it is a working guide rather than a permanent constraint.

It also gives you a natural moment to fold in what has been learned, including the approved-tool requests and the mistakes people felt safe reporting.