What an AI policy is actually for

I have now read a great many enterprise AI policies — government, banking, ASX 200 — and most of them share a quiet, structural confession. Read closely, they are not documents about how the organisation will use AI. They are documents about how the organisation will avoid being embarrassed by AI. The distinction sounds rhetorical. It is not. It determines every clause.

The embarrassment-avoidance policy is easy to recognise. It leads with prohibitions. It enumerates the tools people must not use and the data they must not paste. It requires approvals from committees that meet monthly for decisions people face hourly. Its verbs are must not, only with, subject to. And its practical effect, observable within weeks of publication, is the one its authors least intend: the organisation's actual AI usage moves off the books. People do not stop using these tools — the tools are too useful and too available. They stop telling anyone. Personal devices, personal accounts, quiet workarounds. The policy has not reduced the risk. It has removed the visibility, which is to say it has converted a manageable risk into an unmanageable one, at the cost of also forfeiting the upside.

This failure is so common that it is worth asking what a policy is actually for — what job the document can realistically do.

The real job of the document

A policy cannot make ten thousand daily decisions about AI use. The decisions are too numerous, too contextual and too fast-moving; by the time a case reaches the committee, the tool has updated twice and the deadline has passed. The people facing the decisions are the only ones positioned to make them. Which means the policy's real job is not to make the decisions. It is to equip the people making them — to transmit the organisation's judgement to the point of use, so that a manager at 4pm with a deadline and a model in the next tab makes roughly the call the organisation's wisest heads would make.

Seen that way, a policy is a teaching document, and its quality is measured by a simple test: does a reasonable person, having read it, make better decisions than before? Prohibition lists fail this test almost by construction. They tell people what not to do, and nothing about how to think when — as is the case for nearly every real decision — the situation is not on the list.

The policies that pass the test share a shape. They are built on principles with reasons attached: not "never paste client data into external tools" full stop, but here is what happens to data in these systems, here is why it matters differently for public models and our enterprise deployment, and here is the underlying commitment — client information does not leave our control — that your judgement should serve when the specific case is novel. A rule with a reason travels. It equips people for the ten thousand cases the drafters never imagined. A rule without a reason is brittle: it invites exactly the literal-minded circumvention it deserves.

They define escalation, not permission. The weak policy asks people to seek approval before acting, which at real-world frequency means the policy is either ignored or the organisation stalls. The strong policy makes the default decide, within these principles — and is then extremely clear about the narrow class of situations that must go up: novel data categories, external-facing outputs above a threshold, anything touching regulated processes. Fewer gates, better guarded.

And they are honest about the two-sided risk. Most policies price only the risk of action — the leak, the hallucinated citation, the biased output. Almost none price the risk of abstention: the compounding cost of being the organisation whose people are not building fluency while competitors' people are. A policy that only sees one side of that ledger will always drift toward prohibition, because every individual prohibition looks prudent. The document should say, in plain words, that non-adoption is also a risk the organisation is managing. Very few do, and you can tell.

The tell-tale clause

If you want a fast read on any AI policy — including your own — look for one thing: what happens when someone makes a reasonable judgement call that goes wrong?

If the answer is silence, or process language that translates to "the individual carries it", then whatever the policy says, the organisation has told its people the truth about the game: honesty is dangerous, initiative is dangerous, and the safe play is either quiet non-use or quiet unreported use. Judgement cannot grow in that climate, because judgement grows on the record of calls made, examined and learned from — and the record only exists where disclosure is safe.

The strong policies say the opposite, explicitly: use within these principles is backed. If you follow the reasoning this document teaches and the outcome is bad, that is the organisation's risk, accepted knowingly, and the response will be to examine and improve the principles — not to burn the person. That single clause does more for both safety and adoption than every prohibition in the document combined, because it is the clause that keeps the real usage visible, and visibility is the precondition for governing anything.

Policy as curriculum

There is a final reframe that the best organisations have made and the rest have not. They treat the policy not as a compliance artefact but as the syllabus for an ongoing conversation. The document is short — principles, reasons, escalation lines, the backing clause. Around it sits the actual mechanism: worked examples that get discussed in teams, updated quarterly as the technology moves; a visible channel where edge cases are asked and answered in the open; senior leaders talking about their own calls, including the ones they got wrong. The policy is the seed of the organisation's judgement, not the container of it.

This also resolves the update problem that plagues the compliance version. A prohibition list is out of date the month it ships, because it is indexed to specific tools and specific limitations. Principles with reasons age slowly, because they are indexed to the organisation's commitments — to clients, to regulators, to its own people — which move at the speed of the institution, not the speed of the model release cycle. The examples refresh; the spine holds.

So, the honest test for your own document. Pull it up and ask three questions. Could a thoughtful person reconstruct our reasoning from it, or only our fears? Does it make the default decide or ask? And does it anywhere say what we will do when good judgement meets a bad outcome? If it fails those tests, the fix is not a redraft of the prohibitions. It is a different document with a different job: producing judgement at the point of use.

Writing that document — and building the fluency that makes it workable — is work we do with leadership teams regularly, often as the first concrete artefact of a wider program. If yours needs the rewrite, talk to us.