Your AI Policy Describes a Company That Doesn't Exist Anymore

Why Most AI Policies Describe a Company That Does Not Exist

Most AI policies I see are written for an organisation that exists largely in the author's imagination.

In that organisation, everyone uses the one approved tool. They read the policy, follow the rules, ask for permission when they need something new, and wait patiently while governance catches up.

That is not usually what is happening.

Across the organisations I have worked with over the past few years, a recurring pattern has emerged. A company rolls out an approved AI tool, often Microsoft Copilot in New Zealand, and builds a policy around it. The policy is long on restrictions: what staff must not enter, what they must not use, what requires approval, and what could go wrong.

Six months later, leaders notice that adoption is disappointing. The tool is not making much of a difference. The expected productivity gains have not appeared.

Then you spend time with the people doing the actual work.

They are using AI. They are using it on their phones, at home, through personal accounts, or in tools outside the approved stack. ChatGPT, Claude, Gemini, niche tools built for design, research or content. They use them because they help them get a job done that the sanctioned tool does not do as well.

They are just not talking about it.

This article is for boards, executives and the people who own AI policy, and it argues that the document you have may be measuring the wrong thing entirely.

Unreported AI Use Is a Governance Failure, Not a Discipline Problem

We often call this "shadow AI". I have never really liked the phrase. Shadow implies something observable at the edge of the light. Much of this use is not observable at all. It is simply unreported, because the organisation has made disclosure feel like a compliance problem.

That is the governance failure.

The scale of it is not a secret. Microsoft and LinkedIn's Work Trend Index, which surveyed 31,000 knowledge workers across 31 markets, found that 78% of people using AI at work bring their own tools, and 52% are reluctant to admit they use AI for their most important tasks. The second number is the one that should concern a board. It is not describing rule-breakers. It is describing people who have concluded that honesty about their best work carries a risk.

The aim of AI policy should not be to make AI use disappear from the organisation's view. It should be to make safe, useful use visible enough to learn from, improve and govern.

Classify the Information Before You Write the Rules

This matters because the risks are real. In New Zealand, the Privacy Act creates clear obligations around personal information. Many organisations hold commercially sensitive material: client data, financials, product plans, pricing, legal advice, intellectual property or information entrusted to them in confidence. Those things deserve proper boundaries. "Put anything into any tool and hope for the best" is not a serious position. But neither is "use this one tool for everything, and here is a list of reasons not to use AI".

The latter approach confuses control with governance.

A useful policy starts by recognising that information is not all equally sensitive, and neither are the jobs people need to do. A finance team, marketing team, communications team, customer-service function and executive team do not use AI in the same way. Nor should they be expected to.

One client expressed the practical test rather well: if you left this information on a bus, would it actually matter? Very often, it is already in the public domain or otherwise low-risk information that would not cause harm if it were exposed.

It is not a substitute for proper data classification or legal advice. But it is a useful starting point. It helps people distinguish between material that genuinely requires a controlled environment and material that is already public, low-risk or readily reconstructable.

The formal version of that instinct is data classification, and it is worth doing properly before a single rule is written. IPP3A came into force on 1 May 2026 and changed what New Zealand organisations must tell people when personal information is collected indirectly, which is exactly the situation many AI workflows create. Our guide to data, AI and NZ law sets out a six-level classification framework and the obligations attached to each level. For anything genuinely uncertain, the Office of the Privacy Commissioner at privacy.org.nz is the authority, not your AI vendor.

For the first category, personally identifiable information, client records, sensitive commercial material and intellectual property that cannot afford to wander, the organisation should specify the approved environment clearly. It should explain why that boundary exists, what it protects, and what staff need to do when they are uncertain.

The Second Category: What Policy Should Actively Encourage

For the second category, the policy should do more than permit experimentation. It should encourage it.

That might include public-domain research, first drafts, image generation, presentation concepts, non-sensitive process design, market scanning or improving a piece of writing. Give people examples. Give them training. Ask them to share what worked, what did not, and where a different tool produced a better result.

That is how organisations become good at AI: not by issuing a policy, but by building feedback between governance and the work itself.

The distinction matters. In a restrictive model, staff see policy as a barrier placed between them and useful tools. In a more mature model, they understand the non-negotiable information boundary, but have room to solve real problems inside it. They can say, "This tool helped me reduce a two-hour task to 20 minutes," without inviting a lecture about unauthorised software.

That information is valuable. It tells leaders where the gains are occurring, which tools suit which functions, where training is needed, and whether the organisation is actually receiving a return on its investment. Managers are the layer where this either works or quietly does not, which is the subject of a separate guide for the people leading those teams.

Why One Approved Tool Is Not an AI Strategy

It also exposes a weakness in the "one tool for everyone" idea.

A single enterprise platform may be the right controlled environment for sensitive material. That does not make it the best tool for every job. The cost-control concern is understandable: nobody wants a software estate that looks like a household subscription list, Netflix, Disney+, Prime Video and five others nobody remembers buying.

But the answer is not to pretend one tool can meet every need. It is to make deliberate choices. Approve a small number of tools for defined purposes. Review whether they are delivering value. Retire what is not. Let departments make a case for specialist capability when the gain is material.

The related argument is that IT cannot support a varied AI environment. That concern made more sense when every new application required installation, integration and ongoing desktop support. Many modern AI tools do not. They are secure, browser-based services with little technical overhead beyond identity, payment, data boundaries and sensible guidance.

The harder work is not technical support. It is leadership.

What Boards and Executives Should Actually Be Asking

Boards and executives need to ask a more honest question than, "Have we rolled out an AI tool?" They need to ask: "How is work actually being done, where is AI already involved, and what are we learning from it?"

If the answer relies only on usage data from one approved platform, they may be measuring compliance theatre rather than capability. I call it AImaxxing: optimising the appearance of AI adoption rather than the substance of it. Seat licences assigned, policy acknowledged, dashboard green, and no idea what is actually happening in the work.

If you want a structured view of where the organisation genuinely sits rather than what the licence report says, the AI Maturity Benchmark takes about five minutes and asks the questions a usage dashboard cannot.

What an AI Policy That Works Actually Contains

The best policies I have seen are short, specific and written to be used rather than filed. They tend to contain eight things:

• A named information boundary. Not "sensitive data" in the abstract, but the actual categories: personal information, client records, financials, legal advice, unreleased product and pricing work. Name the approved environment those must stay inside.
• The reason the boundary exists. People follow rules they understand and route around rules they do not. State what the boundary protects and who it protects.
• A named route for uncertainty. One person or one channel to ask when something does not fit the categories, and a commitment to answer within a day rather than a quarter.
• Explicit encouragement for low-risk work, with examples. Not grudging permission. A short list of jobs people are actively expected to try, so the default is use rather than hesitation.
• An obligation to check outputs. AI drafts, people verify. Say it plainly, and say who carries that responsibility for each kind of work.
• Human accountability for decisions and client-facing work. Named, not implied. This is the line that matters most as tools start taking actions rather than answering questions.
• A disclosure channel that carries no penalty. Staff should be able to say that a tool outside the approved stack did the job better, and expect a conversation rather than a warning.
• A review date. The tools change every few months. A policy written once and filed will be describing a different market within a year.

None of that is exotic. The Public Service AI Framework and responsible GenAI guidance published by the Government Chief Digital Officer covers much of the same ground for agencies, and is a reasonable reference point for private-sector organisations too.

Good governance does not mean lowering the bar on privacy, confidentiality or human accountability. It means placing those controls where they genuinely matter, then creating enough room for people to learn. The best policies I have seen are clear about what must stay inside the approved environment, clear about the need to check AI outputs, and clear that humans remain responsible for decisions and client-facing work. They are also written in a way that makes staff want to bring problems forward.

This is the same argument that runs through our guide to responsible AI practices: the organisations that treat ethics and governance as an advantage rather than a brake are the ones that end up trusted with the work that matters. And the accountability line becomes considerably harder to hold once AI stops answering questions and starts taking actions on its own. A policy that cannot describe today's tools will not survive that shift.

That is the real test. If your policy makes people hide the tools that help them do their job, it is not protecting the organisation. It is separating the organisation from the knowledge it needs to govern AI well.

The policy may be technically correct. But it is describing a company that does not exist anymore.

Director's Takeaway

Do not judge AI governance by whether you have an approved tool and a restrictive policy. Judge it by whether staff can safely disclose how they are actually using AI, whether sensitive information has a clear home, and whether the organisation is learning from the useful work happening around it.