What an AI policy is actually for

When I sit down with a leadership team, I usually ask to see their AI policy. Most of them have one now, and by this point I have read a great many of them, from government, banking and the ASX 200. They are careful documents, written by careful people, and most of them share the same quiet 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.

It decides every clause that follows.

The embarrassment-avoidance policy is easy to recognise once you have seen a few. It leads with prohibitions. It lists the tools people must not use and the data they must not paste. It asks for approval from a committee that meets monthly, for decisions people face hourly. Its verbs are must not, only with, subject to.

And within weeks of publication it produces the one outcome its authors least intended. The organisation's real AI usage moves off the books. People do not stop using the tools, because the tools are too useful and too easy to reach. They stop telling anyone. Personal laptop, personal account, quiet workaround, nothing in writing. The risk has not gone anywhere. The visibility has. A manageable risk has become an unmanageable one, and the upside has been forfeited on the way through.

I want to be fair to the people who write these documents, because I understand the pull. If my name were on the policy and the first bad story landed on the front page, I would want a clause I could point at too. And yet the clause that protects the drafter is rarely the clause that protects the organisation.

The real job of the document

Not the thing we usually ask of it. A policy cannot make the ten thousand small decisions an organisation faces about AI in a week. Those decisions are too many, too specific to their moment, and too fast. By the time a case reaches the committee, the tool has updated twice and the deadline has gone. The people in front of the decisions are the only ones close enough to make them.

So the policy's job is not to decide. Its job is to equip the people deciding, to carry the organisation's judgement all the way to the point of use, so that a manager at 4pm, with a deadline and a model open in the next tab, makes roughly the call the wisest heads in the building would have made.

That makes a policy a teaching document, and a teaching document has a simple test. Does a reasonable person, having read it, make better decisions than they made before? A list of prohibitions fails that test almost by construction. It tells people what not to do and nothing about how to think, and nearly every real decision is one the list never imagined.

The policies that pass share three habits.

They give the reason with the rule. Not "never paste client data into external tools" and stop, but: here is what happens to data in these systems, here is why it works differently for a public model and for our enterprise deployment, and here is the commitment underneath it, that client information does not leave our control, which your judgement should serve when the case in front of you is new. A rule with a reason travels into situations nobody drafted for. A rule without one is brittle, and invites the literal-minded workaround it deserves.

They define escalation, not permission. A policy that asks people to seek approval before acting gets ignored, or the organisation stalls. The strong ones make the default decide, within these principles, and are then very clear about the narrow set of situations that must go up: a new category of data, an external-facing output above a stated threshold, anything touching a regulated process. Fewer gates, better guarded.

They price both risks. Most policies price only the risk of acting: the leak, the invented citation, the biased output. Almost none price the risk of not acting: the slow cost of being the organisation whose people are not building fluency while their competitors' people are. A document that sees one side of that ledger will drift towards prohibition every time, because each individual prohibition looks prudent on its own. The strong ones say plainly that non-adoption is also a risk the organisation is managing. Very few do, and you can feel the difference in the room.

The tell-tale clause

If you want a fast read on any AI policy, including your own, look for the answer to that one question.

If the answer is silence, or process language that means "the individual carries it", then the document has told the organisation's people the truth about the game, whatever else it says. Honesty is dangerous, initiative is dangerous, and the safe play is quiet non-use or quiet unreported use. Judgement cannot grow in that climate, because judgement grows on a record of calls made, examined and learned from, and that record only exists where owning up is safe.

The strong policies say the opposite out loud. Use within these principles is backed. If you follow the reasoning this document teaches and the outcome is still bad, the organisation carries it, knowingly, and the response is to examine and improve the principles rather than burn the person. That single clause does more for safety and for adoption than every prohibition in the document combined, because it is the clause that keeps the real usage visible, and nothing can be governed that cannot be seen.

Policy as curriculum

The organisations doing this well have made one more shift. They treat the policy as the syllabus for an ongoing conversation rather than as a compliance artefact.

The document itself is short: principles, reasons, escalation lines, the clause that backs people. Around it sits the part where people do the real work. Worked examples that teams talk through, refreshed as the tools change. An open channel where edge cases are asked and answered where everyone can read the answer. Senior people describing their own calls, including the ones that did not land. The policy is the seed of the organisation's judgement, not the container for it.

This also solves the update problem that makes the compliance version so tiring. A list of prohibitions is out of date the month it ships, because it is pinned to particular tools and their particular limitations. Principles with reasons age slowly, because they are pinned to the organisation's commitments to its clients, its regulators and its own people, and those move at the speed of the institution rather than the speed of the release cycle. The examples refresh. The spine holds.

The honest test for your own document is short. Open it and sit with three questions.

1. Could a thoughtful person reconstruct our reasoning from this, or only our fears?
2. Does it make the default decide, or ask?
3. Does it say anywhere what we will do when good judgement meets a bad outcome?

If your document fails those, the fix is not another pass over the prohibitions. It is a different document doing a different job: producing judgement at the point of use, in the hands of the people who already carry the decisions. That is a better place for an organisation to stand, and a much better place for the people inside it.

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.

Attribution

Written by Andrew Ramsden. AI tools assisted research and drafting; all outputs verified.

Accountable

Andrew Ramsden.

Limitations

No external sources.

References

No external sources. Claim labels are in the SOURCED sidecar.