The Firm's First AI Doctrine: What You Will, and Will Not, Do With AI

What Is a Firm's AI Doctrine?

A firm's AI doctrine is a one-page statement of how the firm has decided to operate with AI day to day: which materials may go into which class of tool, what the firm will and will not automate, and who owns the system. It sits in front of formal policy, and it replaces nothing.

The word doctrine is deliberate. Pilots have checklists, surgical teams have protocols, the military has doctrine — high-stakes fields all rely on something short enough to use in the moment, because nobody reads the long manual when a decision has to be made. Contracts, training and regulatory obligations all continue to apply beneath it.

Why One Page Rather Than a Longer Policy?

Because the document has to work in the moment of deciding — the few seconds in which someone chooses whether a client file goes into a tool. A 40-page policy gets filed and ignored; a single page gets read, remembered and used. For behaviour under time pressure, length is the enemy.

The constraint is productive. A firm that cannot state its position in three short sections has not yet decided its position — it has delegated the deciding to whoever happens to hold the document. Writing the page is how the deciding gets done.

There is a human reason too. Amy Edmondson, Novartis Professor of Leadership and Management at Harvard Business School, has built a body of work — most publicly The Fearless Organization — on psychological safety, which she defines as a shared belief that the team is safe for interpersonal risk-taking: that asking a question, admitting a mistake or raising a concern will not be held against you. Her research is about teams rather than about AI, and it is not evidence that any particular page works. But the mechanism it describes is the one at work here. Where nobody is sure what is allowed, capable people improvise in private. A clear, blameless one-page doctrine is the kind of instrument that makes hidden use visible — not by forbidding things, but by making the permitted path obvious and making it safe to say you strayed from it.

What Belongs on the Page? The Three Sections

Three sections, each settling one question. The tier line: which materials go into which class of tool. The judgement line: what the firm automates freely, where AI assists under a named owner, and what it never delegates. The accountability line: who maintains the system and keeps the page current.

1. The tier line — what goes where

The first section is the firm's confidentiality posture in plain language — not a blanket ban, not a free-for-all: which materials may go into which class of tool, at four levels.

• Public and non-confidential work goes into ordinary, firm-approved tools.
• Client and commercially sensitive material requires an approved business-tier tool — a data-processing agreement in place, and the training-use and retention settings checked on the actual account rather than assumed from the plan name. Whether your work can be used to improve someone else's model is a question of the provider's terms and how the workspace is configured, and it is worth reading rather than inferring.
• The most sensitive material stays inside a walled-off or local environment.
• A short, honest never-list names what does not go near a general AI tool at all.

Four levels, one line each. The point is not to be restrictive; it is to be unambiguous — so the question "can I put this here?" already has an answer everyone knows.

Two details decide whether this section survives contact with the work. The first is that the levels must be written in terms of materials the firm actually handles — the proposal, the client file, the interview notes — rather than abstract categories such as "confidential information", which every reader will interpret differently at the exact moment interpretation matters. The second is that the middle tier does most of the load-bearing. For a great many expert firms, an approved business-tier tool with a data-processing agreement and the settings checked is what makes the bulk of client work usable at all, with the walled-off level reserved for the genuinely exceptional — subject, always, to whatever the firm's own client contracts and professional obligations already require of it. A doctrine that pushes everything to the strictest tier is not cautious; it is unused — and unused doctrine is how work quietly migrates to personal accounts.

2. The judgement line — what we automate, and what we never delegate

The second section maps the work itself. The firm names, out loud, what it will automate freely — the friction, the first drafts, the recurring preparation that quietly eats the week. It names the work where AI may assist but a named human owns the output. And it names the small, protected set it will never delegate: the judgement that is the product, the moment a client is really asking, "can I rely on you?"

Writing the line down lets the whole firm automate confidently: everyone shares one picture of where it sits. You cannot delegate the right things until you have named the few you never will. The doctrine needs only the firm's three lists — the fuller map of where expert judgement actually lives is a separate conversation, and a longer one.

3. The accountability line — who owns the system

The third section is the one firms most often leave out, and it is what separates a document from a practice. The doctrine names a person, or a small group, who owns the firm's AI operating system: who maintains the shared instructions, who approves a new tool before it touches client work, and who reviews this one page each quarter. Naming an owner on the page is the easy half; the harder half is whether the team can actually run the system without that person.

It also sets the rule for the in-between moments: if in doubt, ask the owner before uploading — and an accidental upload is reported quickly and without blame, so the firm can act rather than hide. Without an owner, nothing keeps the page current as the tools move, and it quietly becomes a historical document. Software has a maintainer; so should the way a firm uses AI.

How Do You Write the Doctrine in an Afternoon?

With the right three people in one working session: a senior partner who can commit the firm, the person who knows which tools are actually in daily use, and one thoughtful sceptic. Work from real materials rather than abstract categories, name the protected work first, and appoint the owner before the session ends.

1. Put real materials on the table. Not categories — the actual proposal, the actual client file, last week's interview notes. Sorting 20 real items into the four tiers takes an hour and settles debates abstraction would run for weeks.
2. Name the never-delegate list first. It is the conversation that matters most, and it goes best while attention is fresh. Once the firm knows what it will never hand over, the automate-freely list almost writes itself.
3. Appoint the owner in the room. Five minutes, and the step most often skipped. An unowned doctrine is a nice statement; an owned one is a system.
4. Sign and date it the same day. A draft that leaves the room becomes a project; a signed page becomes the firm's position.
5. Put it where the work happens. On the wall, in onboarding — and inside the firm's AI workspaces: pasted into the shared instructions of a Claude Project or a Claude Code workspace, so the firm's assistants carry the tier line as standing context rather than needing it restated every time. Treat that as guidance rather than enforcement. What actually holds a boundary is which tools people can reach and how those accounts are configured; the page tells everyone where the boundary is.

What Does the One-Page Template Look Like?

Copy the page below, complete the bracketed lines with your partners, and date it. Every line is meant to be edited: the value sits not in the wording but in the decisions the wording forces. A line that survives unchanged from a template is a prompt to look harder.

[FIRM NAME] — AI DOCTRINE
What we will, and will not, do with AI.
Version 1.0 — [date] · Owner: [name] · Next review: [date + 3 months]

1. WHAT GOES WHERE — THE TIER LINE
   Public and non-confidential work → [approved general tools]
   Client and commercially sensitive work → [approved business-tier tools:
      data-processing agreement in place; training-use and retention checked]
   Our most sensitive material → [walled-off or local environment]
   Never near a general AI tool → [the short, honest list]

2. WHAT WE AUTOMATE — THE JUDGEMENT LINE
   We automate freely → [first drafts, summaries, recurring preparation]
   AI assists; [role] owns the output → [the assisted middle]
   We never delegate → [the judgement clients pay for]

3. WHO OWNS IT — THE ACCOUNTABILITY LINE
   System owner: [name] — maintains the shared instructions; approves any
   new tool before it touches client work; reviews this page quarterly.
   If in doubt: ask the owner before uploading.
   If something goes wrong: report quickly and without blame, so we can act.

Signed: [the partners] — [date]

Where Do First Doctrines Go Wrong?

Four failure modes account for most of them, and the first two are visible on the page itself, before anyone has to test it in practice.

The page with no owner. Section three gets written as a principle rather than a name — "the leadership team reviews this periodically" — and the review never happens, because a responsibility shared by everyone belongs to nobody. The fix is a person, and the person's actual name.

Length creep. The one page becomes two, then a policy annex, then a document that requires an introductory session to explain. Each addition is individually reasonable and collectively fatal, because the page stops being readable in the moment it is needed. If something genuinely needs 12 pages, write those 12 pages separately — and keep the one page in front of them.

The adopted template. A firm downloads a doctrine, changes the name at the top, and circulates it. The page looks right and governs nothing, because the value was never in the wording — it was in the argument the wording forced. Two partners disagreeing for 20 minutes about whether a particular client file belongs in the middle tier is not a delay in the process; it is the process.

The never-list as a wish-list. The never-list runs to a dozen items, most of them aspirational rather than genuinely absolute — and a rule the firm is not willing to keep is a rule that takes the rest of the page down with it when it is broken. Two or three items the partners would actually defend are worth more than a comprehensive list nobody believes.

What Changes Once the Doctrine Is Written?

Confidence, before control. The first effect a doctrine is designed to produce is not that AI use tightens but that it releases: the page exists so that people who were quietly unsure whether they were allowed to use AI on a given task no longer have to guess, because the boundaries are explicit and shared.

That is the part observers miss, and it is a claim about design rather than a measured outcome. A doctrine reads like a restriction and works like a release. The page is built so that the energy going into private worry can go into the work instead — and so that the firm can see its own AI use, which is the precondition for governing it at all.

A doctrine is how a firm stops being a dozen private guesses and becomes one operating system.

Where Does the Doctrine Sit in the Wider Operating System?

It is the governance page of a larger build, and usually the first page. The doctrine states the boundaries; the operating model is what runs inside them — the configured workspaces, shared instructions, skills and scheduled routines that turn AI from browser habits into firm infrastructure.

In the work I do with clients, firms move through three stages — from AI in a browser tab, to configured workspaces, to an owned operating system: the journey from the web to the workshop. The doctrine makes that journey governed rather than accidental. The tier line decides where each class of work may run; the judgement line decides what the system may touch; the accountability line gives the build a maintainer, so the page moves with the tools. One page, three decisions, no new bureaucracy.

It scales, too. In larger organisations the same page becomes the first component of a frame that lets many teams build without fragmenting — doctrine, a shared platform, a registry of who owns which agent, and a route by which a proven team asset becomes company property. The page is small in every version of this. That is the feature.

The firms that operate well with AI are not the ones with the longest policies. They are the ones whose single page everyone has actually read — what goes where, what we automate, who owns it — kept current as the tools move. Write the page. It is an afternoon's work, and it is the afternoon that makes everything after it coherent.

Frequently Asked Questions

Who should write the firm's AI doctrine?

A senior partner who can commit the firm, together with the person who knows which tools are in daily use and one thoughtful sceptic. Do not delegate it to a committee or adopt an external template unchanged: the value is in the decisions, and the decisions belong to the people accountable for client work. Partner sign-off is what makes the page real.

How long does it take to write?

One working session — a genuine afternoon. Sorting real materials into the four tiers takes about an hour. Naming the never-delegate list takes longer, because it is the conversation that matters most. Appointing the owner takes five minutes and is the step most often skipped. Signing the page the same day prevents the draft from drifting into a project.

How often should the doctrine be revised?

Quarterly, by the named owner, with the next review date written on the page itself. The tools change quickly enough that an unreviewed page starts describing a world the firm no longer works in. Expect most reviews to change very little — a tool added to a tier, a line clarified. The discipline of the review, not the volume of change, is what keeps the page alive.

What is an AI doctrine not?

It is not a legal policy, and it does not replace one. Contracts, regulatory obligations, training and any formal information-security policy all continue to apply beneath it. The doctrine is the daily-use layer that sits in front of them: the short statement of how the firm has decided to operate, written so that people can actually follow it in the moment.

Does a small firm really need one?

Small firms need it soonest, because they are the least likely to have any other instrument. A 40-person firm without a doctrine has 40 private positions on what may be pasted into a tool. The page takes the same afternoon whether the firm has 6 people or 60, and in a small firm the owner is usually obvious — which removes the step most large firms get stuck on.

What if the firm already has an AI policy?

Keep it, and put the doctrine in front of it. The two documents do different jobs: the policy is written for obligations and scrutiny; the doctrine guides behaviour in the seconds before someone uploads a file. The test is simple — if the people doing the work cannot answer the tier question out loud, the policy is not reaching the moment where it matters, and the page is what closes that gap.

If your firm is ready to write its page — or would like it mapped to your actual tiers and judgement zones — send me a note; I am happy to share the working template. You can see how the engagements work. This thinking develops first in The AI Operating System, my LinkedIn newsletter — you are welcome to subscribe there. If you would like the evidence behind the argument, the questions business leaders actually ask is the companion piece.

Dr Bruno Oliveira — PhD · Associate Professor, University of Bath. Founder of GustoMind.ai. Builds and installs AI operating systems for expert-led firms, running the same system daily in his own work.