Most AI usage policies I see fail the same way. Someone downloads a template, changes the company name, adds a paragraph about not entering confidential information, and circulates it. It is approved without discussion because nobody disagrees with any of it. Within a month it is ignored, because it never answered a question anyone was actually asking.
The problem is not the template. It is that a policy is the record of decisions already made, and most firms write the document before making the decisions. What emerges is a list of prohibitions with no logic behind them — and staff who now use AI tools slightly more secretly than before.
There are six decisions underneath any workable AI usage policy. Each is a genuine fork, each has a cost either way, and none of them can be answered by a template because the right answer depends on your business. Make these six, and the document writes itself in an afternoon.
Decision one: permitted tools — a list, or a standard?
The fork. Either you name the tools people may use and everything else requires approval, or you set a standard that any tool must meet and let people choose within it.
An approved list is enforceable and easy to explain. It is also perpetually out of date, and every gap in it produces either a delay or a quiet workaround. A standard — for example, no consumer tiers, must have a business agreement in place, must not train on your inputs — scales better and survives new products, but requires someone capable of assessing tools against it.
The hidden question. What are you doing about the tools already in use? Most firms discover, when they ask honestly, that staff have been using consumer AI tools for months. A policy that criminalizes what everyone is already doing drives usage underground, which is strictly worse than the status quo: you lose visibility of the very thing you were trying to control.
What usually works at small scale. A short approved list covering the eighty percent (typically your existing productivity suite’s AI features plus one or two others on a business tier), a lightweight request route for anything else, and a genuine amnesty for what’s already happening — declare it, and it gets assessed rather than punished.
Decision two: what data may go in — and who decides?
The fork. Either you enumerate what is prohibited, or you enumerate what is permitted and treat everything else as prohibited by default.
This is the decision that matters most, and it’s the one templates handle worst. “Do not enter confidential information” is not a rule — it’s a feeling. Ask five people in your firm whether a draft client email containing a company name and a deal value is confidential, and you will get five answers.
The hidden question. Do you have a data classification scheme, and does anyone use it? If you do, the policy just references it and you’re done. If you don’t — and most firms this size don’t — then the AI policy either becomes your de facto classification scheme, or it inherits the ambiguity.
What usually works at small scale. Three tiers, expressed in your own business’s nouns rather than abstract labels. Something like: never — client personal information, credentials, anything under an NDA, unreleased financials; only in approved tools with a business agreement — internal documents, draft work product, non-public operational data; anywhere — public information, general research, your own published material.
The test of whether this decision was made well is simple: a new joiner should be able to apply it correctly on their second day without asking anyone.
Decision three: when must a human review the output?
The fork. Either every AI-assisted output gets reviewed before use, or you define the specific circumstances that require it.
Blanket review is easy to write and impossible to sustain — it will be ignored for low-stakes work within a fortnight, and once staff learn that one rule in the policy is theatre, the rest lose force too.
The hidden question. What is the actual consequence of the output being wrong? That’s the only variable that matters, and it has nothing to do with which tool produced it.
What usually works at small scale. A consequence test rather than a tool test. Mandatory review, by a named competent person, whenever output will reach a client or counterparty, inform a financial or accounting figure, feed a regulatory filing or submission, influence a decision about an individual, or be represented as the firm’s professional work. Everything else — internal drafting, research, summarising, brainstorming — sits at the user’s own judgment.
Then add the part most policies omit: reviewing means being accountable for it. If your name goes on it, it is your work, regardless of what drafted it. That single sentence does more real governance work than three pages of tool restrictions.
Decision four: who approves a new use case, and how heavy is the gate?
The fork. Either new AI use cases go through a formal assessment, or they proceed unless they trip defined criteria.
A heavy gate on a firm of forty means either nothing gets approved or the gate gets bypassed. A gate that’s too light means your first material AI use case arrives fully built and nobody assessed it.
The hidden question. Who has the standing to say no? In a small firm this is rarely a committee. It’s a person — and if that person is also the one most enthusiastic about adopting AI, you have a problem your policy should name rather than hide.
What usually works at small scale. A single named owner for AI governance, a one-page assessment for anything that would touch client data, produce client-facing output, or automate a decision — and explicit permission to proceed without assessment for everything else. Keep a simple register of what’s been assessed and what’s in use. That register is your AI inventory, and you will need it for reasons beyond the policy.
Decision five: what do you disclose, and to whom?
The fork. Either you disclose AI use to clients and counterparties proactively, or you disclose on request, or you’re silent.
The hidden question. What have you already promised? Check your client agreements, your engagement letters, your privacy policy, your RFP responses, and any vendor questionnaires you have completed. Firms routinely discover they have made confidentiality or subcontracting commitments that constrain AI use — or have already answered a client’s due diligence question about AI in terms their current practice doesn’t match. That inconsistency is a real exposure and it’s cheap to find now.
What usually works at small scale. Decide the position deliberately, write it down, and make sure it matches your contracts. For financial services firms specifically, expect the question to arrive from three directions: institutional clients' vendor questionnaires, your professional liability insurer at renewal, and your own regulator or auditor. Having a considered answer ready is worth more than the answer being any particular one.
Decision six: what happens when someone gets it wrong?
The fork. Either breaches of the policy are a disciplinary matter, or they’re a learning input, or — most commonly — the policy is silent and everyone assumes the worst.
The hidden question. Do you want to know about mistakes? Because you can have deterrence or you can have visibility, and at the scale of a small firm, visibility is almost always worth more. The failure mode you should fear isn’t someone pasting the wrong thing into a chatbot. It’s someone doing that and telling no one for six weeks.
What usually works at small scale. A clearly stated reporting route, an explicit commitment that prompt self-reporting is treated as the correct behavior rather than an admission, and disciplinary consequences reserved for deliberate or repeated disregard. Then actually behave that way the first time it happens, because your response to the first incident is your real policy — everything before it was drafting.
What the policy should not try to do
Three things belong somewhere else, and putting them in the AI usage policy is why so many run to fifteen pages nobody reads.
Model risk management is a separate discipline with its own framework — tiering, validation, monitoring, lifecycle controls. If you build or deploy models that drive decisions, that’s a different document and a heavier one.
Vendor due diligence on AI providers belongs in your third-party risk process, not your staff usage policy. The questions are different and so is the audience.
Technical controls — data loss prevention, tenant configuration, logging — belong with your security documentation. The usage policy says what people may do; the security configuration is how you make some of that stick.
Keep the usage policy to what a member of staff needs to know to do their job correctly. Three to five pages is generous.
Where to start
Book ninety minutes with the three or four people who would have to live with the answers. Work through the six decisions in order — they build on each other, and decision two is where most of the debate will land. Write the answers down as you go. Then have someone draft the policy from those answers rather than from a template.
Set a review date six months out and honour it. This area is moving quickly enough that a policy written today will need revisiting, and a document with a scheduled review reads very differently to an assessor than one dated eighteen months ago with no successor.
If you’d like the six decisions worked through with someone who has designed governance frameworks for organizations rather considerably larger, and then sized them honestly for firms that aren’t, that’s exactly the conversation we have.