Writing an AI policy your fee earners will actually read

I have read a lot of law-firm AI policies, and most of them share a quality: they are thorough, carefully drafted, and almost entirely unread. They run to a dozen pages. They define “artificial intelligence” with great care. They list principles - transparency, accountability, human oversight - that nobody would disagree with and nobody could act on. And when a fee earner is sitting at their desk at 6pm wondering whether they can paste a clause from a client’s contract into a tool, the policy is no help at all, because they’ve never opened it and wouldn’t find the answer quickly if they did. A policy that doesn’t change what people do in that moment isn’t controlling any risk. It’s documenting the firm’s good intentions. Here’s how I’d write one that works.

Know who you’re writing for

The root problem is that most AI policies are written for the wrong reader. They’re drafted to satisfy a risk committee, an insurer, a client questionnaire, a future regulator - audiences that reward completeness and defensibility. Those audiences matter. But they aren’t the people whose behaviour the policy is meant to govern.

So write two documents. Keep the long one, because you need it for governance and for the questionnaires. Then write the short one, for the people actually doing the work, and treat that as the real policy. The long version explains the firm’s position. The short version tells someone what to do on a Thursday afternoon.

Start from the decision, not the principle

Every useful AI policy is really an answer to a handful of practical questions a fee earner asks themselves. Can I use this tool? Can I put this information into it? Do I need to tell anyone? Do I need to check the output, and how carefully?

Build the policy around those questions, in that order, in the words people actually use. “Human oversight is required for AI-generated work product” is a principle. “You are responsible for anything you send. Check every citation against the source before it leaves the building” is an instruction. The first is easy to agree with. The second is easy to follow.

Name the tools

Policies love categories - “generative AI tools”, “approved platforms”, “third-party AI services”. Fee earners don’t think in categories. They think in tools, and many of the tools they reach for now have AI quietly built in. A policy that says “only approved tools may be used” without saying which ones are approved forces every person to work it out alone, and they’ll each work it out differently.

So name them. Here are the tools the firm has approved, here’s what each one is approved for, and here are the common ones that aren’t approved and why. Update the list whenever it changes. In every policy I’ve seen that genuinely works, this is the most-read section, because it’s the only one that answers a real question at a glance.

Draw the lines with examples

The hardest call for a fee earner is what counts as information they shouldn’t share. Abstract definitions of “confidential” and “personal data” don’t settle it in the moment. Examples do. Set out a handful of realistic scenarios - summarising a published judgment, redrafting your own email, uploading a client’s draft agreement, pasting in a witness statement - and say clearly which are fine anywhere, which are fine only in particular tools, and which are never fine.

A simple traffic-light approach works well, as long as it’s anchored in examples rather than definitions. People remember cases. They don’t remember clauses. And a lawyer who has seen five worked examples will reason by analogy to the sixth far more reliably than one who has memorised a definition.

Give the reasons, briefly

Rules without reasons get gamed or ignored. If the policy says “don’t use personal accounts on consumer AI tools for client work”, add one sentence explaining why: the firm can’t control where that data goes or how long it’s kept. Lawyers are professionally trained to find the edges of rules, and a rule they understand is one they’re far more likely to respect at the edge - which is exactly where the policy will fail to anticipate the situation in front of them.

Give it an owner and keep it alive

An AI policy dates faster than almost any other document a firm has. Tools change, terms change, new features appear inside software people already use. So give the policy a named owner, a visible version date, and a simple way to ask a question and get an answer the same day. If the only route to clarity is an email to a general inbox that takes a week to reply, people will stop asking and start guessing.

The questions themselves are the best possible input for the next version. Every question someone asks marks a gap in the policy, and tells you precisely where the next edit should go. Treat the policy less like a document and more like a product: shipped, used, watched, and improved on a regular cadence rather than revisited once a year.

The test of an AI policy isn’t whether it would satisfy an auditor. It’s whether a trainee, alone at their desk with a deadline, can find the answer in thirty seconds and is willing to follow it. Write for that person. Keep it short, specific and current, and the policy stops being something the firm points to and starts being something its people actually use - which, for once, is exactly what it was meant to be.