Privacy Act 2020 and AI features: a practical guide for NZ builders

If you build software in Aotearoa, the Privacy Act 2020 is the law that shapes how an AI feature handles customer data. The good news is that the rules are short, principle based, and easy to turn into a checklist before you ship. Here is a practical walk through the parts that matter most when you call a hosted model from a New Zealand product.

Start with the information privacy principles

The Act is organised around 13 information privacy principles. Four of them come up in almost every AI project:

• Principle 1 and 3, purpose and transparency. Collect only what the feature needs, and tell people what it is for. If a support assistant reads customer messages, say so in plain language where the message is written.
• Principle 5, security. Keep keys, prompts and logs in places you control, and limit who on your team can read stored conversations.
• Principle 9, retention. Decide how long prompts and outputs are kept, and set the deletion job on day one.
• Principle 12, disclosure outside New Zealand. When personal information goes to a provider overseas, the Act expects you to check that comparable safeguards apply, or to get the person's informed authorisation.

The Office of the Privacy Commissioner publishes guidance on applying these principles to AI tools. It is worth reading once, then linking from your internal engineering docs.

Map the data flow before you pick a model

Draw one box for your app, one for each model provider, and one for each store of logs. Then label every arrow with the kind of data that travels along it. Three questions fall out of the picture:

1. Does the prompt contain personal information, or only public text?
2. Which provider region handles the request?
3. Where does the response get stored, and for how long?

A twenty minute sketch like this makes Principle 12 conversations with your provider much easier, because you can point at the exact arrow in question.

Strip what the model does not need

Most prompts work just as well with fewer details. Replace names with roles, trim account numbers to the last four digits, and send a short summary instead of a full thread. A tiny redaction function in your backend, run before every model call, is cheap to write and easy to test.

import re

def redact(text: str) -> str:
    text = re.sub(r"[\w.+-]+@[\w-]+\.[\w.]+", "[email]", text)
    return re.sub(r"\b\d{8,}\b", "[number]", text)

Use one gateway so policy lives in one place

When every feature calls a different provider directly, privacy settings end up scattered across the codebase. A single gateway gives you one place to set the model, log retention and key rotation. The app.nz gateway exposes an OpenAI compatible /v1 endpoint, so existing SDK code only needs a new base_url and key. You can pin a specific model for sensitive flows and let routing choose for everything else.

Check the output side too

Responses can echo personal details that were in the prompt. Treat model output like any other user data: store it under the same retention rule, show it only to people who could already see the source record, and let customers request their data back, because Principles 6 and 7 give people the right to access and correct information about themselves.

A short launch checklist

• Name the purpose of the feature in one sentence and put it in your privacy statement.
• Keep a list of every model provider and the data each one receives.
• Redact before sending, and test the redaction with real looking samples.
• Set retention for prompts, outputs and logs.
• Write down who to contact if someone asks for their information.

Privacy work done early is quick, and it gives your customers a clear reason to trust the feature. When you are ready to wire up a model, open the gateway, grab a key, and try the same prompt against a few models in the model directory. This post is general information, not legal advice, so involve your own advisor for decisions specific to your business.