The thesis in one line: a policy you cannot execute is not a policy, it is a disclaimer. It exists to be shown in an audit and it does nothing to change what the system does on Tuesday afternoon. The difference between the two is not how rigorously it is written: it is whether somebody translated each sentence into a condition a machine can check before it lets an action out.
An AI use policy you cannot execute is not a policy
The pattern repeats in every company past the enthusiasm phase. Somebody drafts the AI use policy in the workplace — six pages, well written, reviewed by legal — it goes up on the intranet, gets announced by email, and the matter is closed. Three months later there are agents writing to customers, committing amounts and publishing claims about the product, and none of those actions passes through anything resembling what the document says. Not because anyone is breaking it on purpose: because the document was never wired to anything.
The genre is saturated with the easy half. There are templates, checklists and guides on what to document: scope, roles, prohibited uses, risk classification, owner. All of it is necessary and none of those texts explains the hard part, which is this: how a sentence written in plain English becomes a check that runs in production and can stop an action. That jump is the real work, and it is the one almost nobody does.
Worth saying plainly, because there is money on the table: a policy that only exists as a PDF protects you from nothing except, with luck, part of the liability. It does not prevent the error, it does not detect it, and it leaves no trace that anyone tried to prevent it. If you want the AI to behave, the document has to come down three levels: from principle to rule, from rule to checkable condition, and from condition to evidence.
Step 1: break the obligation into checkable conditions
Take every sentence in the policy and ask it one question: what would have to be true, in a specific action, for this sentence to be holding? If the answer is long, ambiguous or depends on who is looking, the sentence is not a rule yet: it is an intention. Split it until every piece is verifiable with a yes or a no.
A typical example. "AI will be used transparently with customers" is not checkable. Broken down, it turns into three conditions that are: in every conversation started by an automated system, the first message declares that it is an automated system; in any channel where the customer can ask for a person, there is a visible way to do it; and no message states or implies that a specific member of the team wrote it. Three conditions, three possible checks. The original principle is still there, only now you can wire it.
Two warnings about this step. First: the breakdown is where the hard decisions get made, not in the drafting of the principle. "Transparent" sounds like everybody already agrees; "the first message declares that it is an automated system" opens a real argument about marketing, conversion and tone. That argument has to happen, and having it here is far cheaper than having it after an incident. Second: if an obligation cannot be broken into checkable conditions, write that down too. Some obligations only hold with human judgement, and flagging them as such is useful information, not a failure.
Step 2: decide what evidence proves each condition
A condition with no evidence assigned is a condition nobody checks. And here comes the bias that ruins most attempts: if the evidence is picked by whoever has to implement it, they will pick the one that is easy to get, not the one that actually proves compliance. It is human and it is predictable, so you fix it by design.
For each condition you fix three things: what data proves it, at what moment you look, and who answers if it is missing. The evidence can be very simple — the text of the first message sent, the amount in the deal field, the list of sources the system used to draft — and the simpler the better: a check that only works when the whole pipeline is healthy is not a check, it is a hope.
The moment matters as much as the data. Checking before execution — the system stops and nothing happens — is not the same as checking after — the system acts and you find out. Both are valid and they do not cost the same. The practical rule: anything irreversible or visible to the customer gets checked before; the rest can be checked after, as long as somebody is actually reading the log and there is a written deadline for reading it. The mechanisms that make this possible — logging, scoped permissions, a handbrake and audit — are worked out in governance and control of AI automation; what we add here is the layer above: what gets checked and why, not what does the checking.
Step 3: define what happens when it fails
This is the step almost nobody writes and the only one that decides whether the control exists at all. A check with no defined consequence always ends up in the same place: an alert on a dashboard nobody opens. For each condition you decide, up front, one of four responses: block the action, escalate to a person with the case already assembled, log it and let it through, or degrade to a more conservative version of the same action.
Choosing "block" for everything is as bad a design as choosing "log" for everything. Block everything and the system becomes useless, and the organization learns to route around it very fast; log everything and you produce a perfect archive of breaches nobody read. The question that settles the choice is the usual one: how much the error costs and how long it takes to show. Expensive and visible, escalate. Expensive and invisible, block. Cheap and visible, log. And one extra condition people forget: "escalate" is only legitimate if there is real human capacity for that volume. Escalate more cases than your team can look at and the queue gets bulk-approved unread, which is worse than having no control, because it also generates a false record of review. That is exactly the problem taken on in human oversight of AI at scale.
Three concrete, cheap controls to start with
You do not have to wire the entire policy for the exercise to pay off. Three well-chosen controls cover most of the real risk of a company that is starting out, and all three ship in days, not quarters.
- Disclose that it is AI. Condition: every conversation started or held by an automated system declares that it is one in the first message. Evidence: the text sent. Moment: before sending. Failure: the send is blocked. Beyond being the right thing to do, from 2 August 2026 there is a European transparency obligation that applies to systems intended to interact directly with people, which must be designed so the person knows they are interacting with an AI, unless it is obvious. Source: European Commission, Transparency obligations under Article 50 of the AI Act (Regulation (EU) 2024/1689), consulted 14 September 2026. Worth going through it with your counsel: the scope and which role applies to you — provider or deployer — depend on your case, and this is not legal advice.
- A cap on what an agent can commit. Condition: no action that commits money goes over the threshold set per transaction and per day. Evidence: the amount in the field, plus a running daily total. Moment: before execution. Failure: escalate to a person with the case assembled. It is the cheapest control of all and the one most people discover late, usually right after the first scare.
- Claims that require an approved source. Condition: any customer-facing message containing a product fact, a price, a timeline or a condition rests on a source from an approved list. Evidence: the sources the system retrieved to draft it. Moment: before sending. Failure: degrade — the system sends an answer without that fact and offers a handoff — instead of blocking, which here would be overkill.
Notice what the three have in common: each one fits on a single line, each one has an obvious piece of evidence, and each one carries a different consequence. That asymmetry is the sign the exercise was done properly. If all three ended in "block", nobody stopped to think about the cost of each error. The scope of what the agent can touch to begin with is another decision from this same exercise, and it lives in what permissions to give an AI agent.
The expensive mistake: letting engineering write the policy alone
When the translation from policy to control is handed over entirely to the technical team, something perfectly reasonable and perfectly wrong happens: you end up checking what is easy to check, not what the policy requires. The result looks good — there are rules, there are logs, there are dashboards — and it leaves out exactly what matters most, because what matters most is almost never the most measurable.
It shows in small details. You check that the message does not exceed a length, not that it does not promise a delivery date you cannot meet. You check that the answer cites a source, not that the source is approved. You check that the transaction carries an amount, not that the amount respects the limit somebody set in a committee. Every one of those checks is correct and none of them is the one the policy asked for.
The antidote is process, not technology: the breakdown in step 1 is done by whoever owns the obligation — business, legal, operations — and the evidence in step 2 is agreed between that person and whoever is going to implement it. Engineering gets a veto over the impossible, not over the inconvenient. And the final document gets signed on both sides, with a date. Without that cross signature, what you have is not an executable policy: it is a list of what turned out to be convenient to measure.
There is an ordering detail worth respecting too, and it cuts against what looks obvious: the policy does not get written first. It gets written once you know what you are regulating, and you find that out by looking at what your people already do with AI without asking permission — the full argument is in why banning shadow AI does not work. A policy drafted before that inventory regulates an imaginary company.
What an executable policy looks like when it is finished
It does not look like a legal document. It looks like a table, and it fits on one page per area. Each row has six columns: the obligation it comes from, the checkable condition, the evidence, the moment you look, what happens when it fails, and who answers. Underneath, a separate list of the obligations you decided are not automatable and therefore depend on a person, with their name and their review cadence.
That table has a property the PDF does not: you can audit it against reality. Take a row, take a case from last week and check whether the condition was evaluated, on what evidence, and what happened. Either the log shows up, or the row is a lie. It is a five-minute test and it is the only honest way to know whether your AI use policy is alive or decoration.
And it has another: it ages visibly. When an obligation changes, one row changes and you can see which controls need touching. When the PDF changes, nothing changes, because it was not wired to anything. That is why the deliverable we leave behind in AI adoption for teams is not the document: it is that table, with an owner and a review date, and the first tranche of controls already built. You still need the document — you have to be able to show it — but it is the consequence of the work, not the work.