Writing an AI usage policy for a small firm

For a firm of ten, a usable AI policy fits on two sides of paper. It names the tools your team already uses, answers four questions about each of them, reserves the decisions that carry money or risk for a named person, and carries a date and a signature. Anything longer will be filed and forgotten, which is the same as having none.

This is guidance for writing your own, and there is no template attached. The reason for that is in the second question below. After it come the shape, the four questions, and the three ways these documents usually fail.

If anyone on your team is already using AI, yes, and most teams are using it well before anyone decides they should. A written policy exists to make one boundary visible to everybody at once. Without it each person quietly invents their own rule about what client information may go into a chat window, and you discover which rule they picked on the day something goes wrong.

In most firms the trigger has already passed unremarked: somebody pasted a client document into a tool nobody had looked at, on an ordinary Tuesday, and nothing went wrong that time. Compliance deadlines arrive later, and they arrive after the habit has set.

As a checklist at most. A template is written for no firm in particular, so it lists categories and names none of your tools, none of your regulatory duties, and none of the people who sign things off. Read one to see what you have forgotten, then write the specifics yourself. The specifics are the policy, and everything else is formatting.

Take each tool your team uses and answer four questions about it. Who directs it. What it may say. What gets recorded. Who holds the data. Four answers per tool, one line each, and most of the document writes itself. These are the same four we settle in writing before an AI employee handles a live enquiry, and working with AI employees shows what each answer looks like on a live build.

Anything that spends money, accepts an obligation, or changes a client relationship. Prices outside a published range, engagement letters and contracts, complaints, and anything your regulator would call advice. Put it in one sentence a person can quote back at you, so the boundary survives a busy Friday afternoon when the sentence is all anyone has time to read.

In regulated work the line is drawn for you in places, and it is drawn tighter than most policies assume. We have set out where administrative handling stops and regulated activity begins across four markets in the rules on AI and client intake. Where your regulator has spoken, quote it in the policy and cite it, so nobody has to guess whose rule they are following.

Whoever runs the work writes it, and whoever carries the liability signs it. In a firm of ten those are often the same person, which is an advantage worth using. Before it is signed, have it read by one person from each part of the business that touches client data, because they are the ones who know the shortcuts the policy has to name.

Date it, attach it to a named list of tools, and review it whenever that list changes. Most policies die because they were written about a category and the category moved underneath them. A dated policy naming five tools tells you exactly when it stopped being true, which is the morning somebody starts using a sixth.

The first is abstraction. A policy about 'AI tools' names nothing, so nobody can tell whether the thing in front of them is covered. Name the tools, and add a line saying that anything unnamed needs approval before client data goes near it.

The second is length. A document of thirty pages is a statement that nobody is expected to read it. Two sides can be read by a new starter in the ten minutes between their induction and their first client email, which is the only moment it will ever have their full attention.

The third is silence about the supplier. If a third party runs an AI system on your behalf, the policy should say who they are, who holds the data, and what happens when you want it deleted. Ours is published on security, including the certifications we do not hold, and a supplier who will not answer those questions in writing has told you something.

A signed document changes nothing on its own. What changes behaviour is a short policy, a named owner for each tool, and someone reading the logs often enough to notice drift. The policy is where the rule is written down. The monthly reading is where you find out whether it held, and how to audit an AI employee's output walks through one.

Start with one tool this week. The one your team reaches for most, four answers, one line each, one name against it. The second goes faster once the first is written, and a handful of tools later you have the document. Nobody has to approve that first page for you, and nobody outside the firm needs to be involved in writing it.