Here's the question that tells you whether you have a policy. Not "which tools are approved." The one that gets asked in the incident review, timeline on the screen, everyone quiet: who decided this was correct? If the honest answer is a shrug, or four names, or "the model wrote it and CI went green," you don't have a policy. You have a memo.
I run MentorCruise with a team of five and I started out writing code, so I'll say the uncomfortable part early. A policy that regulates which tools your engineers are allowed to open is regulating the input. Every failure you're worried about is in the output.
The short version
- Name one accountable human per shipped artifact. "The team" is not an answer and neither is the model.
- Give the policy one owner, and make it whoever is already accountable for the team's output. Not legal, not security, not a committee.
- Route work by blast radius rather than by tool. Three tiers, one required gate each, so your finite senior attention lands on auth, money movement, data deletion, and permissions.
- Don't write "review AI output carefully." Automation bias shows up in experts and can't be prevented by training or instructions [Parasuraman and Manzey, Human Factors, 2010]. Move the load instead.
- Copy the template at the bottom. It's two pages, it's free, and it works with zero involvement from us.
Why AI usage policies fail the only test that matters
An AI usage policy fails the only test that matters when it can't name who is accountable for a specific shipped artifact. An AI usage policy is the document that says who is accountable for AI-assisted output, which tools are approved, and what has to happen before that output ships. Everything else in it is packaging.
Run the test now. Open a pull request your team merged last week. Ask who is accountable if it turns out to be wrong. Count the names in your answer. One name means you have a policy, whatever the document says. Any other number means the document is doing something other than the job.
The tempting answer here is "the team is responsible," and it sounds like the mature one. It fails for a structural reason rather than a cultural one. Helen Nissenbaum wrote this up thirty years ago in Accountability in a Computerized Society (Science and Engineering Ethics, 1996), naming four barriers that erode accountability in software. The first she called the problem of many hands:
Where a mishap is the work of "many hands," it may not be obvious who is to blame because frequently its most salient and immediate causal antecedents do not converge with its locus of decision making.
Hold that against your PR queue. The person who typed the change, the person who approved it, the person who wrote the module it leans on, and the person who set the deadline are four different people, and the harm doesn't trace cleanly back to any one of them. Nissenbaum was describing software teams in 1996. No AI required.
AI adds one more hand, and it's a strange one. Every other hand in that chain has a locus of decision-making you can interrogate. You can ask a contractor what they were thinking. You can ask the engineer who approved it what they checked. Ask a model why it produced something and you get a fluent, confident account generated after the fact, which is worse than silence, because silence doesn't get pasted into a postmortem.
So the accountability question doesn't get harder when you adopt AI. It gets more urgent, because you've added throughput to a chain that was already bad at converging on a name.
Who owns the policy
Whoever is already accountable for the team's output owns the policy. Under about 50 engineers that's your head of engineering. Above that it's the engineering manager who owns the service. Not legal, not security, not a committee, and not a working group with a rotating chair. A policy with no named owner is a wiki page with a timestamp.
I'm committing to that rather than laying out a fork, because the fork is how this question stays open for a quarter. Four reasons, and you can check all of them against your own org.
The policy's load-bearing clause assigns accountability for output. Only someone who already holds that accountability can hand it out and be believed. If the person distributing accountability carries none of it, the clause reads as paperwork.
The owner has to feel the review load, or they'll write a policy that spends other people's attention. This is the part that gets missed. A policy is a budget for senior review time, and budgets written by people who don't pay them are always generous.
Legal and security own the constraints the policy has to satisfy. They don't own the policy. Give it to legal and it optimises for liability, which is their job and the wrong objective function for a document engineers have to follow at 5pm on a Thursday. A policy optimised for liability gets routed around, and the next section covers what that costs you.
Committees produce documents that survive review and change nothing. That's the problem of many hands applied to the policy itself: a document authored by everyone has the same accountability profile as a codebase authored by everyone, which is to say none. If you take one thing from Nissenbaum, take that the failure mode reproduces at every level, including this one.
Where this recommendation gets weaker: in a supervised regime, medical devices or a licensed financial institution, your engineering owner still holds the pen but can't sign off the constraints alone, and the approval chain is genuinely longer. Own the document, borrow the constraints, don't pretend the sign-off is yours.
There's a fair question underneath all of this, which is who reviews the reviewer. Your Tier 1 reviewers, the people this policy will name in a minute, apply a standard that mostly lives in their heads. Nobody audits it. The honest answer is that at most companies nothing checks it except incidents, which is a slow and expensive auditor.
The accountability clause, and why "review it carefully" is not one
Your accountability clause has to name a person rather than a behaviour. "Engineers must review AI-generated code carefully" names a behaviour, and behaviour is the one thing the research says you can't get by asking for it. Parasuraman and Manzey reviewed the human-factors literature on automation in Complacency and Bias in Human Use of Automation (Human Factors, 2010) and their conclusions are blunt.
Automation complacency, they found, "occurs under conditions of multiple-task load, when manual tasks compete with the automated task for the operator's attention." It is "found in both naive and expert participants and cannot be overcome with simple practice." Automation bias, its sibling, "occurs in both naive and expert participants, cannot be prevented by training or instructions, and can affect decision making in individuals as well as in teams."
The mechanism is the whole design constraint here. Complacency isn't driven by carelessness. It's driven by load. Reviewers under-check the machine when the machine's output is competing with everything else for their attention, seniority doesn't inoculate them, and a training session doesn't either. Your policy cannot ask for diligence and expect to receive it. It can only change how much there is to be diligent about, and who has to sign.
DORA's 2025 report shows the same shape at org scale. AI adoption now has a positive relationship with delivery throughput and a negative one with delivery stability. In the report's words, "AI accelerates software development, but that acceleration can expose weaknesses downstream." More change volume arriving at a review capacity that never grew. That's Parasuraman's finding one level up.
So the clause is short, and it points at a human:
Every artifact we ship has exactly one author of record. The author of record is the human accountable for the artifact being correct, whether they typed it, prompted it, pasted it, or accepted a suggestion. "An AI tool generated it" is not a defence.
And then the sentence that stops the policy going punitive, which matters more than it looks:
"An AI tool generated it" is also not an accusation.
If disclosing AI assistance carries a cost, your engineers will stop disclosing it, and you'll lose the only signal that tells you whether your tiers are calibrated. Hiding it is the problem. Using it isn't.
One thing this post deliberately doesn't cover: how an individual engineer should validate their own AI-generated code before it reaches your queue. That's a real question with a different answer, and it's already written up in the software engineer's validation playbook. Send it to them. Your job is the layer above it.
Route the work by blast radius, because your review capacity is finite
To route AI-assisted work by blast radius, sort every change by what breaks if it's wrong rather than by which tool wrote it, then attach exactly one required gate to each tier. Three tiers is enough. Senior review is your scarcest input, and blast radius is the only sorting key that spends it where a failure is expensive.
| Tier | What is in it | Required before merge | Who is accountable |
|---|---|---|---|
| 1 - High blast radius | Auth and session handling, money movement, data deletion or migration, permissions and IAM, PII handling, cryptography, public API contracts, infrastructure and IaC, anything you can't roll back inside your incident window | A reviewer from the named Tier 1 list, plus a written note in the PR of what was verified and how | Author of record; named Tier 1 reviewer co-signs |
| 2 - Standard | Application code on the deploy path, covered by existing tests, reversible in one deploy | One reviewer who can explain the change with the author out of the room | Author of record; reviewer co-signs |
| 3 - Contained | Tests, internal tooling, docs, spikes, prototypes off the deploy path | Author of record signs. Normal review. No extra gate | Author of record |
Three of those choices are doing the work, so let me defend them.
Sorting by tool is the mistake everyone makes first. The tool isn't the risk. The same model writes your docstring and your database migration, and one of those two can end your quarter. A tool-based policy spends its enforcement budget on the wrong axis and has nothing left for the migration.
The Tier 2 gate is a specific test, chosen deliberately against the automation-bias finding. Reading a diff for approval is a monitoring task, and monitoring tasks are exactly where complacency lives. Having to explain the change to someone else is a production task, and it fails loudly when the reviewer has been nodding along. It costs about ninety seconds and it's the cheapest anti-complacency mechanism I know of.
Tier 1 is a list of names rather than a role. "A senior engineer must review" is not a gate, because seniority is a title and what you need is someone who has actually held the pager for that subsystem. Write the names down. Which brings us to the part that stings, and I'll come back to it at the end: when you fill in that list, you find out how many people can really sign off a change to your auth path. For a lot of teams the honest number is one.
If you're not sure which tier a change is in, treat it as the more sensitive one. And nobody is ever the sole reviewer of their own Tier 1 change, which sounds obvious until you look at who merged the last IAM change on a Friday.
Shadow AI is a symptom of a slow approval route
Your engineers use tools you never approved because the approved route is slower than their deadline. That's the whole mechanism. Somewhere between half and four-fifths of employees are already doing it depending on whose survey you read, and the people doing it most are usually the people under the most delivery pressure. Treating that as a discipline problem gets you a quieter version of the same behaviour.
Hold the numbers loosely. UpGuard's shadow AI research, covering 500 security leaders and 1,000 employees across seven countries, puts it at 81% of employees and 88% of security leaders using unapproved AI tools. BlackFog's survey of 2,000 UK and US employees at organisations over 500 people, fielded in November 2025, puts it at 49%. Both are vendor surveys, both are selling something adjacent to the answer, and the gap between them is wider than most people quoting either would like. Read them as a range and not as a measurement. The range is still enormous.
Prohibition is the intuitive response and it has a predictable cost: you lose visibility while the usage continues. You end up with the same AI-generated code in your repositories, with no author-of-record field, no tier, and no reason for anyone to tell you which model produced it.
Four mechanisms, in the order I'd do them.
Publish a default-permit list instead of a default-deny one. Most of your engineers want to be legible. Give them a list they can say yes to.
Put a response SLA on tool requests, in working days, with a named person on the hook. "Open an issue, someone will look at it" is how you get shadow AI. "Open an issue, Priya answers within five working days, and if she doesn't you can treat it as approved for Tier 3 work and chase her" is a route people will actually use.
Run an amnesty the week you publish. Tell us what you're already running, nothing happens to you. You'll learn your real tool list, and it won't be your approved list. That delta is the most useful data you'll get all quarter and it's free.
Make the approved tool the easy one. If it's already on your SSO with data terms you can live with, approval is the path of least resistance and the policy mostly enforces itself.
What this policy is not, and where to stop
This template is an engineering artifact and not legal cover. MentorCruise is an online mentoring marketplace founded in 2018. We're not a law firm and we're not a governance certification body, and a policy pretending to be legal advice is worse than one that doesn't pretend, because it stops you asking counsel the questions only counsel can answer.
Nissenbaum has the sharpest version of why those are separate jobs. "Appraisals of liability are grounded in the plight of a victim," she writes, "whereas appraisals of accountability are grounded in the relationship of an agent to an outcome." Accountability starts from your engineer's relationship to the change. Liability starts from someone else's harm. Your policy can do the first with precision. It can't do the second, and merging them produces a document that reads like a waiver and functions like nothing.
Two places to stop, concretely.
Don't restate your vendors' data terms in your policy. Anthropic's, OpenAI's, and Cursor's enterprise terms change without notice, and a copy pasted into your wiki goes stale the first time someone updates a page you don't watch. Link them, and name the owner who re-reads them on a schedule. That's section 3 of the template.
Do keep a record of what a human contributed. The US Copyright Office's January 2025 report on copyrightability says human authorship is required for copyright, that prompts alone don't confer it however detailed they are, and that using AI to assist doesn't bar copyrightability. What that means for your IP position is a question for your counsel and I won't guess at it. What it means for your policy is narrower and you can act on it this week: keep the record. That's section 5.
That's the entire legal section. I'm not hedging every clause below with "consult your lawyer," because a document that does that is a document nobody reads.
The AI usage policy template
Here's the template. Copy it, fill in the angle brackets, delete what doesn't apply, and put your own name in the owner field before you publish. It runs to about 750 words filled in, so roughly two pages. It costs nothing and it needs nothing from us. If you take this section and never read another word I've written, this post did its job.
Four things to settle before you paste it anywhere:
- Decide the owner. One name, and it should probably be yours.
- Write the Tier 1 reviewer list before you publish, not after. A tier with no named reviewers is decoration.
- Set the tool-request SLA to a number you'll actually hit. Five working days you meet beats two you don't.
- Pick a review date and put it in the document. Ninety days is a reasonable default.
# AI Usage Policy - <TEAM OR COMPANY>
Owner: <NAME>, <ROLE>
Last reviewed: <DATE>
Next review: <DATE + 90 DAYS>
Applies to: everyone who commits to <REPOS / SERVICES IN SCOPE>
## 1. Why this exists
We use AI tools to write code. They make us faster at producing changes and no
faster at being sure the changes are right. This policy keeps one named human
accountable for every artifact we ship, and spends our review time where a
failure would actually hurt.
This is an engineering policy. It is not legal advice and it is not a contract.
## 2. Author of record
Every artifact we ship has exactly one author of record.
The author of record is the human accountable for the artifact being correct. It
does not matter whether they typed it, prompted it, pasted it, or accepted a
suggestion. If your name is on the pull request, you are the author of record.
The author of record must be able to explain, without help:
- what the change does
- why this approach rather than the obvious alternative
- how they know it works
- what happens if it is wrong
"An AI tool generated it" is not a defence.
"An AI tool generated it" is also not an accusation. Nobody at <COMPANY> is
penalised for disclosing that a change was AI-assisted. Hiding it is the
problem. Using it is not.
## 3. Approved tools
Default-permitted for all work in scope:
- <TOOL>, <TOOL>, <TOOL>
Not permitted for <SCOPE - e.g. any repository containing customer data>:
- <TOOL>, <TOOL>
- any AI tool not on the permitted list above
To get a tool added: <ROUTE - e.g. open an issue in <REPO> with the tool name,
the data it would touch, and a link to its data-retention terms>. <OWNER NAME>
answers within <N> working days. If we do not answer within <N> working days,
treat the tool as permitted for Tier 3 work only and chase us.
We do not restate vendor data-retention terms in this document, because they
change without notice. <OWNER NAME> re-reads the terms for every permitted tool
every <N> days and updates the list above.
## 4. Routing by blast radius
Every change lands in exactly one tier. Sort by what breaks if the change is
wrong, not by which tool wrote it.
| Tier | What is in it | Required before merge |
|---|---|---|
| 1 - High blast radius | Auth and session handling, money movement, data deletion or migration, permissions and IAM, PII handling, cryptography, public API contracts, infrastructure and IaC, anything that cannot be rolled back within <N> minutes | A reviewer named in section 7, plus a written note in the pull request of what was verified and how. |
| 2 - Standard | Application code on the deploy path, covered by existing tests, reversible in one deploy | One reviewer who can explain the change with the author out of the room. |
| 3 - Contained | Tests, internal tooling, docs, comments, lockfiles, dependency bumps inside a minor version, generated code with a checked-in generator, spikes, prototypes off the deploy path | Author of record signs. Normal review. |
If you are not sure which tier a change is in, treat it as the more sensitive one.
Nobody is the sole reviewer of their own Tier 1 change.
## 5. What we record
On every Tier 1 pull request, record in the description:
- author of record
- reviewer
- whether an AI tool produced the first draft (yes / no / partly)
- what you verified, and how you verified it
We record the AI-assist field to find out whether our tiers are calibrated, not
to allocate blame. If Tier 2 changes keep causing Tier 1 incidents, the tiers
are wrong and <OWNER NAME> fixes the tiers.
## 6. What this policy does not cover
- Legal liability, IP ownership, and licensing exposure. Those go to
<LEGAL CONTACT>, not into this document.
- Vendor contract terms. See section 3.
- Any use of AI outside the scope named at the top of this document.
- Anything a human has not put their name to. If no author of record is named,
the change does not merge.
## 7. Tier 1 reviewers
<NAME> - <AREA>
<NAME> - <AREA>
<NAME> - <AREA>
If this list has one name on it, <OWNER NAME> owns closing that before the next
review date.
## 8. Changing this policy
<OWNER NAME> owns this document. Propose changes at <ROUTE>. Reviewed every
<N> days whether or not anyone proposes anything.
Version <N>, <DATE>.
Rolling it out so it doesn't become a document nobody reads
Publish it with your name in the owner field on day one, run the amnesty in week one, and pick your Tier 1 reviewers before anyone reads the document rather than after. Policies die in the space between publishing and enforcing, and each of those three closes part of it on the day you publish rather than in a quarter.
Then measure it, and don't survey it. Self-report is unreliable here in a specific, documented way. METR ran a randomised controlled trial in 2025 with 16 experienced open-source developers across 246 issues, on repositories the developers already knew well. With AI tools allowed, they took 19% longer. Afterwards, those same developers estimated AI had sped them up by 20%.
Read METR's own caveats before you quote that at anyone, because they're more interesting than the headline. The sample is 16 people. METR say explicitly that this is not evidence AI fails to speed up most developers, and that their participants may not represent most software work. And METR themselves now head that study with a notice saying the results are out of date, superseded by a continuation study current as of early 2026. In that newer study, 30% to 50% of developers said they were choosing not to submit some tasks because they didn't want to do them without AI - a selection effect that makes the new estimate harder to read, rather than a flaw anyone found in the old design. Don't carry the 19% around as a fact about your team. The finding that survives isn't the number, it's the gap: the same developers who were measured getting slower reported getting faster.
Carry the direction of the error instead. In that trial, people's sense of their own AI-assisted speed pointed the opposite way to the clock. Self-report was the thing that broke, which is why your rollout check is a count of unsigned merges and Tier 1 incidents rather than a question in a retro.
Whether the tiers made your team faster is a bigger measurement question than this post can carry honestly. What a policy owes you is narrower: at any moment, for any artifact, a name.
Where this stops being a document problem
The template runs out at exactly one place, and section 7 is where you'll find it. Write down every person who can sign off a change to your auth path or your payment flow. If that list has one name on it, the document has already done its job. It just told you your real constraint is a person, and no document has ever fixed a person.
Most teams reading this should take the template, fill it in, and go. I mean that literally, and it's why the template is written the way it is. For most of you it's worth more than anything I could sell you on top of it.
The teams it doesn't finish the job for are the ones where the Tier 1 list is short for a particular reason: only one or two people have a settled view of what "correct" looks like for auth, or for a migration, or for the subsystem that will page someone at 2am. That's a standard living in one head. You can grow it internally, and if you have the senior bandwidth to run that, do it. It's cheaper and it sticks better. If you don't have the bandwidth, which is the situation most teams are actually in, bringing in an outsider is one way to get the standard written down and argued over in a compressed window rather than across the years it takes to grow another senior. Our leadership workshop page lists formats from $250 and has a request form on it.
The honest shape of it: the policy is free and it works alone. The workshop is for the one problem the policy just found.
Questions you'll get when you publish this
How long should an AI usage policy be?
Two pages. The template above lands around 750 words once it's filled in. If yours is longer, the extra pages are usually restating your vendor's terms, which go stale, or restating your existing code review policy, which you already have. The only section that should grow with your org is the Tier 1 reviewer list, and that grows by hiring and mentoring rather than by writing.
Does legal need to approve our AI usage policy?
They need to see it. They don't need to own it. Legal owns the constraints your policy has to satisfy: data residency, what you've signed with your vendors, and what your customer contracts say about subprocessors. The policy itself assigns accountability for engineering output, which is an engineering decision made by someone who carries engineering outcomes. Send it over, ask what constraints you've missed, keep the pen.
Should we ban any AI tools outright?
Yes, but by scope rather than by name. Ban unapproved tools from touching specific things, like customer data, production credentials, or anything under an NDA. A blanket ban on a tool your engineers find genuinely useful produces a quieter version of the same usage. Name the scope in section 3 of the template, and give people a route to request an addition with a real answer date attached.
How do we enforce this without reading every pull request?
You don't read every pull request. That's the premise. Enforcement lives in three cheap places: the author-of-record field, which is a required template field rather than a culture ask; the Tier 1 reviewer list, because a small named set of people notices when it's bypassed; and the incident review, where the first question is who the author of record was. If that answer comes back blank twice, you've found your enforcement signal, and it cost you nothing to collect.
We're a team of five. Is this worth writing down?
Yes, and it'll take about twenty minutes. At five people the accountability question feels obvious, which is exactly why it's worth writing: everyone knows who owns what right up until the person who owned it has left, and a change from four months ago pages someone at 2am. Keep sections 2, 4, and 7. Drop the rest until you need it.
