I’ve been working through director training with the Institute of Directors this year. Finance and reporting, risk, and AI. I started my study of AI governance with a slightly unfair advantage, and I’ll admit, a bit of scepticism. I work in technology. I spend my days on cloud and AI use cases. I wanted to know what New Zealand directors are actually being told.

How many of them understand what AI really is, and how to govern it? And should we even expect them to, when central governments and expert groups can’t reach consensus on it themselves?

Overall, the advice is sound. It mostly comes down to three key things:

• Establish and regularly review AI policies and controls
• Ensure compliance with New Zealand laws and ethical standards
• Document roles, responsibilities and key risks

All of that makes sense. None of it is wrong.

But there’s a gap between advice and the situation the business is dealing with on Tuesday morning (i.e. the practical, real life application). What’s missing is the practical detail: a framework an organisation can actually apply and real and practical support for the people trying to work out what any of this means to them (as they make judgement calls on balancing speed of innovation with security, compliance and alignment to values each day).

The law hasn’t caught up, and enforcement is further behind again

In most jurisdictions (possibly all of them?) the pace of AI development has significantly outrun the legislative process. Enforcement is further behind still. The EU has possibly the most comprehensive regime in the world and it has already pushed its high-risk obligations out to December 2027, because the machinery to enforce them wasn’t ready. New Zealand has taken a pretty light-touch approach: no AI-specific legislation, and reliance on the Privacy Act and sector regulators…

So when a director is told to “ensure compliance with New Zealand laws,” the honest answer is that there isn’t much AI-specific law to comply with. That sounds like relief. But I don’t think it is.

It leaves organisations in an interesting position. Either you agree an ethical and operational framework for AI yourselves, or you leave it to the judgement of individuals. Individuals who may not understand the risk as it relates to data privacy, reputational damage, or data breaches. Not through carelessness. They’re solving a problem in front of them with a tool that works, and nobody has told them where the edges are. So, they keep going until someone tells them to stop.

So where do you start?

This is what I would do.

It’s based on what I know, and on what I’ve watched go well and go wrong with organisations I’ve mentored or been involved with. It’s loosely modelled on ISO 42001, the international AI management system standard, though I’m not suggesting anyone rush off and get certified. Certification is a real cost and a much later question.

The value here is in the questions, the process of going through them, the process of building an understanding and assessing risk. The process of navigating and reaching stakeholder alignment on a topic that is inherently complex and where finding consensus on the ethical side of things matters more than ever before.

1. Find out what AI is actually in use across the organisation.

Start here, because you will not know all of it. Go and ask, and ask what teams are working on as well as what’s already running. Some categories to consider:

• AI embedded in solutions you already pay for, with features switched on by vendors, often by default, usually without anyone approving anything. Many if not most SaaS products have AI embedded in them. You may not even know.
• End-user tools like Copilot, Claude, ChatGPT, whatever approved tools people use or whatever other (non approved) tools they have found.
• Internal agentic AI or generative AI. Most of these solutions will be built using some sort of AI service such as Amazon Bedrock, Azure AI Foundry and the like, supporting agents and internal workloads. This is a really interesting space, one where the most consequential things may get built.
• Your own customer facing AI product, or AI embedded in the services you sell.

There will be more. There always is. The gap between what a leadership team believes is in use and what is actually in use is the single most interesting finding in this whole exercise.

2. Do we have an AI policy, and is anyone assuring against it?

The second half of that question is the one that matters. Plenty of organisations have a policy. Far fewer can tell you who checks whether it’s followed, how often, or what happened the last time it wasn’t. A policy nobody assures against is just a document…and not a very useful one.

3. What will we absolutely not do?

Not just from a legal perspective. This is where your Board values and ethics come in.

Set the thresholds and name the scenarios early, while it’s still an abstract conversation rather than an argument about someone’s project. For example: we won’t let teams build their own AI solutions outside policy controls, accepting that this will slow down innovation, accepting that we may not grow revenue as fast as we’d otherwise do. We won’t put client information into tools we haven’t assessed. We won’t use AI to make a decision about a person without a human able to explain and override it.

Bright lines are much easier to draw before anyone has crossed them. They’re also far cheaper to enforce than a case-by-case judgement every time.

4. Who approved each use case?

Ask this for production and development. Two things usually surface. First, a number of things that nobody approved, which is useful to know. Second, that “approval” in some cases meant a single person nodding in a stand-up, which is more useful still, because now you know what your approval process actually is rather than what the process document says it is.

5. Who owns the risk for each one, and do they understand it?

Make sure the answer is not IT. If IT owns AI risk, you’re asking an infrastructure function to make calls on privacy, discrimination, employment law and reputation. That’s not a criticism of IT but if you leave it there, you’ll eventually need a legal department instead.

Risk ownership belongs with the person accountable for the business outcome the AI supports. And “owns the risk” has to mean they can describe it, not just that their name is in a column.

6. What data goes into these tools?

Where does it reside? Who can access it? Who manages that access, and who knows they manage it? This is the question I’d ask first if I only had one (I’d bring people into a room and ask them to raise a hand if they manage it). Most organisations discover here that they cannot name the owner, and that is usually the largest single exposure they have.

7. Support: who owns the map, and who keeps this running?

This one is under-asked and it’s where I’ve seen the most avoidable damage. Who owns the map of the data infrastructure? Was support considered as part of the use case design and deployment, or bolted on afterwards? Who is responsible for supporting the AI solutions, and do they have the capacity to keep it compliant with data policy as it evolves?

8. Third party risk and supplier obligations.

For most organisations, most AI arrives through vendors. So: what do our contracts say about data use, retention, and training on our information? Who is responsible for what along the chain? What can our suppliers turn on without asking us? This is real exposure sitting almost entirely in someone else’s business, which is exactly why it needs to be in writing.

Why this matters more than it looks

Here’s the part that should interest a board most, and it’s the risk that isn’t reduced by the absence of AI legislation.

Directors owe duties of care and diligence under the Companies Act, and there are equivalents for incorporated societies and charitable trusts. The standard is what a reasonable director would do.

Put plainly: a board that has never discussed AI, has no policy, and cannot say what AI its organisation uses is in a materially worse position in front of a tribunal or an inquiry than a board that considered it and made a documented decision, even if the decision was to do very little. The meeting minutes here are important.

There’s a commercial edge to this too. AI governance questions are now appearing in security questionnaires and RFPs. Not having answers loses deals, and slows down growth.

And then there’s the opportunity cost, which has nothing to do with law or sales. Your people are already using these tools. Without any framework, that use is invisible, ungoverned, duplicated across teams, and impossible to build on. So you get all the risk of adoption and none of the compounding benefit.

So where to start?

If a board wants to reduce its exposure in an absence of a budget, they can still achieve a lot.

Know what AI is in use. Have at least one short policy. Name an owner. Put AI risks on the risk register. Minute the discussion.That’s a few hours of management time, and it addresses most of the directors’ duties exposure. Certification, frameworks and maturity models are a separate and much later conversation.