AI agent risk and governance for NZ small businesses

When I bring up "governance" with a small business owner, the eyes glaze over almost instantly. It sounds like a word that belongs in a bank, not a 12-person services firm in Nelson. So I usually rephrase it: governance is the set of decisions you make once so the AI tools you use do not quietly create a problem you find out about three months later.

The shift that makes this matter now is that AI is moving from "a chat box someone uses occasionally" to agents that take action — drafting emails, sending replies, writing to your CRM, updating spreadsheets, running on a schedule. The moment software starts doing things on your behalf, you need to have actually thought about what it is allowed to do, what it is allowed to see, and who is accountable when it gets something wrong. This post is the practical version of that for an NZ SMB.

The thing the Privacy Act actually asks of you

I am not a lawyer. But I have read the Privacy Act 2020 enough times to know what it asks of an ordinary small business, and most of the owners I work with have not.

The headline is that you are accountable for the personal information you collect, including what happens to it once it leaves your laptop. That includes when you paste it into an offshore-hosted LLM. The Act does not ban this — but it does ask you to think about who can access the data, where it is stored, and whether you have told the people whose information it is.

In practice for a small NZ business, the questions you have to be able to answer are pretty simple:

• Have we told customers in our privacy notice that we use AI tools that may process their information?
• Do we know which AI vendors we use, and where their data is hosted?
• If a customer asked us tomorrow what we have done with their personal information, could we tell them?
• If something went wrong — a leak, a wrong piece of data going to the wrong customer — would we know within 72 hours? (That is roughly the window the OPC expects for a serious privacy breach notification.)

If the answer to any of those is "I would have to think about it", you do not have a governance problem yet, but you have a governance gap. And the gap gets larger every time you add another AI tool.

Where your data actually goes when you use a US-hosted LLM

This is the bit that surprises most owners. When your team pastes a customer email into ChatGPT or asks Claude to summarise a contract, that text is sent to servers in the United States (or sometimes Europe, depending on the vendor and tier). It is processed there. Whether it is retained depends on which product tier you are on — the free and lower paid tiers typically allow the model provider to use your inputs to improve their models, which means a copy persists somewhere. The enterprise tiers usually do not.

For most NZ SMBs the practical implications are:

• If you are on the free tier of any major AI tool, assume your inputs may be retained and used. Treat that as the default.
• If you are on a paid business tier, read the data processing terms once. They are usually short and they tell you exactly what is and is not used.
• If you are pasting in customer information, supplier contracts, or anything you would not want to read back to you in a different context, the tier matters more than the price.

This is not a reason to avoid AI tools. It is a reason to make a deliberate choice about which tier you are on for which kind of work, and to write that choice down somewhere your team can see it. Most of the privacy exposure I see in real businesses comes from the team not knowing where the line is, not from the line being in the wrong place.

What to put in a vendor contract — even a small one

If you are paying for an AI tool that touches anything sensitive, you have a vendor contract whether you have read it or not. For most NZ SMBs the practical move is: read it once, and look for these specific things.

The four clauses that actually matter for a small business:

1. Where data is stored and processed. You want to know the country, not the city. Most US vendors will tell you "US-based with optional EU residency on enterprise tiers" or similar. That tells you what you need for your privacy notice.
2. Whether your data is used to train models. This should be explicit in their data processing addendum. If it is not, assume yes on the free tier and read carefully on the paid tier.
3. Sub-processors. AI vendors usually use other vendors underneath them — a hosting provider, a model provider if they are not the model maker themselves. The contract should list who they are. You inherit risk from each one.
4. Notification timelines if something goes wrong. If they have a breach, when do they tell you? You need that to be quick enough that you can hit your own 72-hour notification window if you have to.

You do not need a lawyer to read this for a $30/month subscription. You do for an annual contract that touches financial or health data. The rough rule I use with clients: if the AI tool sees customer data and you are paying more than a few thousand a year for it, get someone to look at the contract before you sign it.

Governing an agent that takes action

This is where the conversation actually shifts in 2026. The chat-box version of AI is mostly a privacy and data-handling question. The agent version — software that drafts and sends emails on your behalf, writes to your CRM, updates your invoicing, runs on a schedule — is a different category of risk because mistakes leave the building automatically.

The principle I keep coming back to with clients is: separate the work the agent can do unsupervised from the work that needs a human signoff. There is no universal answer to where the line goes, but there is a universal way to draw it.

Things I am usually comfortable letting an agent do unsupervised in a small business:

• Drafting follow-ups and queueing them for someone to review before send.
• Categorising and flagging incoming leads or support tickets.
• Cleaning and standardising data inside an internal spreadsheet.
• Summarising activity into a daily or weekly report for an owner to read.

Things I always keep behind a human approval step, no matter how good the agent is:

• Anything that goes to a customer with a number in it (a quote, a price, a delivery date).
• Anything that moves money or commits the business to a payment.
• Anything that creates or modifies a contract.
• Anything that changes a customer record in a way that cannot be cleanly reversed.

The pattern is straightforward: low-stakes, reversible work can run on its own. High-stakes, hard-to-reverse work goes through a person. The agent is not less useful for that — it just does the 80% of the work that does not need judgement, and a human handles the 20% that does.

This connects directly to how I think about managed agents as real workers, not chatbots. The whole point of these systems is that they own end-to-end execution within a defined scope. The scope is the governance.

Low-stakes, reversible work can run on its own. High-stakes, hard-to-reverse work goes through a person. That is the entire shape of agent governance for a small business.

A governance baseline that is small enough to actually do

Most governance frameworks are written for organisations with a compliance team. For an NZ SMB you do not need that, and trying to copy it produces a document nobody reads. Here is the version I actually give clients.

A one-page document that lists, for each AI tool the business uses:

• What the tool is and what it does.
• Who in the team is the owner (one name, not a department).
• What data it sees and which categories are off-limits.
• Whether it can take action on its own or only draft for human review.
• What happens if it goes wrong (who finds out, who tells the customer, who turns it off).

Plus three operational habits:

1. Quarterly review. Once every three months, the owner of each tool spends 20 minutes looking at what it has been doing. Anything weird gets flagged. Anything unused gets turned off.
2. A simple log of changes. When you change a prompt, change a permission, or add a new automation, write down what changed and why. This is usually one line in a shared document. It is the difference between being able to debug a problem and not.
3. A kill switch. For every agent that takes action, you should know how to turn it off in under five minutes. If you cannot, you have given it more authority than you should.

This is not heavy. It is one document and one habit. And it covers most of the realistic risk a small NZ business carries when running AI tools.

What this looks like in practice

A six-person services firm I worked with last quarter is a good example of how thin this can be. They use ChatGPT for drafting and meeting summaries, an agent for lead qualification and follow-up drafting, and a couple of internal automations that move data between Xero and their CRM.

Their governance document is one page. It lists the four tools, who owns each one, what data they touch, and which ones can act unsupervised (none — every customer-facing message goes through their admin lead before send). They do a 20-minute review once a quarter. They have not had an incident. The document took an hour to write.

That is the realistic shape of AI governance for a small business. It is not absent. It is just proportionate. And the cost of doing it badly is a single bad customer interaction or a Privacy Act enquiry that you cannot answer cleanly — which is a much higher cost than the hour it takes to write the document.

If you want help putting this together for your own business — figuring out which controls actually matter for your situation, what to put in a vendor contract, and how to structure the human-in-the-loop steps for any agent work you are doing — that is the kind of work I do. You can start at AI consulting or, if you are already at the agent stage, AI agent implementation.