Building a Firm AI Policy

Start From Actual Behaviour

The most common policy failure is writing rules for a firm that does not exist. By the time most firms formalise a policy, people are already using these tools, often on personal accounts, and often without telling anyone. A policy written in ignorance of that reality regulates an imaginary organisation and drives real use further underground. The first step is an honest, non-punitive survey: what is being used, for what, by whom. Amnesty framing matters here — the objective is accurate information, and disciplinary framing guarantees you will not get it. Firms that skip this step typically produce a restrictive policy, achieve nominal compliance, and discover the actual position only when something goes wrong.

• Adoption precedes policy in almost every firm — write for the organisation you have
• Survey use honestly and without penalty; disciplinary framing guarantees inaccurate answers
• Policy written in ignorance drives shadow use further out of sight
• Nominal compliance with a restrictive policy is the most common and least useful outcome

What the Policy Has to Contain

A policy that functions covers a specific set of things. An approved-tools list identified by product tier and agreement, not by vendor name. A data classification mapping each sensitivity tier to permitted tools. Task rules stating what is permitted, permitted with verification, and prohibited outright. Verification requirements with defined depth, named ownership, and a required artefact. Disclosure rules for courts and clients, with a maintained per-forum register. Supervision expectations for AI-assisted work. Billing treatment. An incident procedure covering what to do when a fabricated citation is discovered. And a review cadence, because a policy written against last year's tools will be silently wrong within months.

• Approved tools by product tier and agreement; data classification mapped to permitted tools
• Task rules in three tiers: permitted, permitted with verification, prohibited
• Verification depth, named owners, artefacts, plus disclosure rules and a per-forum register
• Incident procedure and a scheduled review cadence — this material dates quickly

Making It Survive Contact With Practice

Policies fail for predictable reasons: too long to read, too slow to comply with, no named owner, no route to get a new tool approved, no consequence for ignoring it, and no update when the tools change. The countermeasures are unglamorous. Keep the operative rules to a page that fits next to a desk. Provide a fast, low-friction approval route for new tools so the answer to a good idea is not simply no. Name an owner with actual authority. Build the verification artefact into existing workflow rather than adding a parallel system. Review on a fixed schedule. And treat the first reported near-miss as the most valuable thing that will happen to the policy, because it is the only real feedback you are going to get.

• Operative rules on one page; the long version can exist but nobody will consult it
• Provide a fast approval route for new tools or people will route around the policy entirely
• Name an owner with authority and build artefacts into existing workflow, not a parallel system
• Treat the first reported near-miss as the policy's most valuable feedback, and respond accordingly

Try It Yourself

A policy is far easier to argue about than to write. Draft one section of it properly and the gaps become obvious.

Tier 1 — public or non-client material. Permitted tools:
Tier 2 — client material, not privileged. Permitted tools:
Tier 3 — privileged or highly sensitive. Permitted tools:
Prohibited outright:
How a new tool gets approved, and by whom:
Owner of this section, and review date: