Why AI Policies Fail (And What to Do Instead)

Unless they become part of the operating system that makes AI use visible, safe and useful.

AI policies are not worth writing.

Not because AI governance doesn't matter. It does. More than most boards currently appreciate. But because a policy sitting in a shared drive, attached to an onboarding email, referenced in a code of conduct that nobody reads, does almost nothing. It creates the impression of governance. It is not governance.

The harder truth: in most organisations, AI use has already started. The policy is being written after the fact, to manage something that is already happening. Which means the first question isn't "what should our policy say?" It's "what are people already doing, and can we see it?"

It is already in the building

The assumption underneath most AI policies is that use hasn't begun and that the policy will establish the rules before the activity starts. This is almost never true.

AI is arriving through personal accounts, free browser tools, and apps people already had before the organisation formed a view. Employees are using it to draft communications, summarise meetings, rewrite strategy documents, shortcut research, and check their own thinking. They are not doing this because they are reckless. They are doing it because it works, and because nobody told them not to in a way that felt specific or serious.

The more conservative the organisation's stance, the greater the risk of hidden AI use. When a leadership team signals anxiety about AI without providing clear guidance, people don't stop using it. They stop disclosing it. The AI use continues. The visibility disappears. And that is a far more dangerous position than any failure to write a policy.

The risk is not AI use. The risk is invisible AI use.

The hack day is not the answer

A pattern I have seen: an organisation realises it needs to form a view on AI, so it runs a hack day. Teams experiment for a day, explore use cases, share what they built. It generates enthusiasm, produces a few prototypes, and — in most cases — changes nothing about how AI is actually used in day-to-day work.

Hack days are not governance. They are education events with a demonstration component. They are valuable when they are part of a broader programme. But as a substitute for building actual visibility into AI use across the organisation, they are not enough. The problem they solve is awareness and culture. The problem that remains is structure.

The shift that needs to happen is not from "we don't know about AI" to "we've run an event about AI." It is from controlling AI use — which is largely impossible — to harnessing what is already happening, making it visible, and building the organisational capacity to make coherent decisions about it over time.

That is a different problem. It requires a different response.

Not all AI use is the same

One of the most useful distinctions in AI governance is also one of the least made. There is a significant difference between internal operational AI — tools that change how employees work — and user-impacting AI, which changes what customers, clients, or the people you serve actually receive.

Using AI to tidy a meeting summary is not the same as using AI to recommend support to a child. Treating all AI use as one anxious category means organisations over-govern the simple things and under-govern the serious ones.

Internal AI use is mostly a people, workflow, and enablement problem. It requires clarity about what tools are permitted, guidance on data handling, and enough organisational honesty to bring use into the open. It is manageable if you approach it as a change management challenge with a technology dimension, not as a compliance problem with a culture dimension.

User-impacting AI is a different matter entirely. This is the domain of product ethics, safety, privacy, trust, and accountability. It requires genuine scrutiny: of the model, the training data, the edge cases, the failure modes, the disclosure to users, and the governance of ongoing model behaviour. The stakes are higher, the obligations are more specific, and the consequences of getting it wrong are not internal. They are experienced by the people the organisation exists to serve.

When governance doesn't distinguish between these two categories, it tends to produce policies that are either too restrictive to be useful or too vague to mean anything. The distinction is not complicated. It is just rarely made explicit.

On registers

Many AI governance frameworks include a register: a list of the AI tools in use, the purpose they serve, and the risk level assigned to each. This is a reasonable starting point. It is not governance.

A register that does not change a decision is not governance. It is archaeology.

The value of a register is not the list. It is what the list makes possible. Does it connect to procurement decisions? To vendor assessment? To the question of which tools are permitted and which are not? Does it inform what the board sees? Does it get reviewed when a tool's use expands significantly? Does it capture not just the tool but the context in which it is used?

If the register sits in a document and is updated when someone remembers to update it, it will not protect the organisation from anything. If it is operationalised — connected to real decisions, reviewed regularly, owned by someone — it becomes a useful instrument. The same information, in different hands, with different processes around it, is the difference between documentation and governance.

What boards actually need to see

Boards are increasingly being asked to have a view on AI. This is appropriate. What is less appropriate is the way that view is typically sought: through occasional briefings, external speakers, and strategy discussions that feel important but don't change anything downstream.

The 2026 Think & Grow Board Director Pulse identified AI governance as the top risk issue for Australian boards this year. What that survey also surfaces, quietly, is the gap between recognising AI as a risk and having the organisational infrastructure to actually govern it. Recognition without infrastructure is just awareness. It is not oversight.

Boards do not need to see every prompt. They need to know whether the organisation can see the pattern.

Specifically: Is AI use visible to leadership? Is the distinction between internal and user-impacting AI clear and operationalised? Are the highest-risk uses subject to appropriate scrutiny? Is there a clear owner, not just a policy? And is the board receiving enough signal to know when something has changed in a way that matters?

Those are governance questions. They are not answered by a policy document. They are answered by the operating model that sits underneath the policy.

The operating system underneath

What makes AI governance work is not the policy. It is whether the organisation has built the infrastructure to make AI use visible, make decisions about it clearly, and learn from what happens over time.

That infrastructure includes: clarity about which AI uses require approval and which do not; a process for bringing new tools into the organisation; someone accountable for maintaining visibility into what is in use and how; a connection between AI governance and product governance, technical governance, safety, and board reporting; and a feedback loop that catches problems early rather than after they have already affected the people the organisation exists to serve.

AI governance must not sit as a standalone island. A policy that exists separately from how the organisation makes product decisions, manages data, handles safety obligations, and reports to the board is a policy that will be bypassed by the reality of how work actually happens. Governance that is not connected to the operating model is decoration.

The policy is not the protection. The protection is whether the organisation knows what happens next.

The real question

The question most organisations are asking is: how do we control AI?

The more useful question is: how do we build an organisation that is capable of making coherent AI decisions over time?

Control implies a static position — a set of rules established in advance that will hold against a moving technology and a changing workforce. Coherent decision-making over time implies something different: visibility, clear accountability, a governance model connected to operations, and the organisational honesty to surface what is actually happening before it becomes a problem.

That is a harder thing to build than a policy. It is also the only thing that will actually work.