This is what the operating obligations actually look like once you take the words seriously. We’ll work outward from the policy baseline to delivery practice, ending with the artefacts a defensible AI deployment carries.
The policy baseline: what is mandatory, what is voluntary, where the bite is
There are four documents you reason from:
- Algorithm Charter for Aotearoa New Zealand — signed in 2020 by the Government Chief Data Steward and signatory agencies. Voluntary, but signed at chief executive level. For signatory agencies, operationally treat it as binding.
- Privacy Act 2020 — particularly Information Privacy Principles 1, 6, 8 and 10. Mandatory, statutory, enforced by the Office of the Privacy Commissioner.
- Public Service AI Framework — established by the Public Service Commission to set baseline principles for AI use across Public Service agencies. Increasingly being treated as the operational floor.
- OPC guidance: “AI and the Information Privacy Principles” (2023). Not law, but it tells you how the Commissioner will read your AI use against the Act. The document that decides whether a complaint becomes an investigation.
The political risk for an agency using AI sits at the intersection of these four. The Commissioner’s guidance in particular is load-bearing, because it converts the abstract IPPs into something a delivery team can be measured against.
What the Algorithm Charter actually obliges you to do
The Charter sets six commitments. In delivery terms they translate into specific work packages:
- Transparency. Plain-English explanations of how the algorithm informs decisions, published where an affected person can actually find them. “Documented in Confluence” is not transparency.
- Partnership with Māori. Engagement appropriate to the system’s impact on Māori, before design is fixed — not as a sign-off at gate three.
- Focus on people. Identifying and consulting with the people most affected by the system’s outputs.
- Data. Assessing data fitness for purpose: provenance, bias, representativeness. Models inherit the defects of their training data.
- Privacy, ethics, and human rights. A Privacy Impact Assessment plus a wider ethics review where the system materially affects individuals.
- Human oversight. Peer review during development, and human review of significant decisions before they take effect.
These are operational tasks, not statements of intent. Charter compliance lives or dies on whether the project plan names who does each one, by when, and with what evidence.
Privacy Act 2020, applied to an AI system
The Information Privacy Principles were drafted before generative AI, but they read across cleanly. Four matter most:
- IPP 1 — Purpose. Personal information can only be collected for a lawful purpose connected to a function of the agency. Training an AI model on data collected for a different purpose is a re-use under IPP 10 and needs a fresh basis.
- IPP 6 — Access. Individuals can request access to personal information held about them. If an AI model holds personal data — in training data, in retrieval indexes, or in conversation history — “access” has to mean something. The OPC’s guidance signals that providing the input-output history at minimum is expected.
- IPP 8 — Accuracy. Reasonable steps must be taken to ensure information is accurate before use. AI inferences are new personal informationbeing held about a person. The accuracy obligation attaches to the inferences, not just the source data.
- IPP 10 — Limits on use. Information collected for one purpose cannot be used for another unless an exception applies. “Improving the model” is rarely a sufficient exception for personal data.
The practical implication: a Privacy Impact Assessment for an AI system isn’t a tick-box. It has to reason about the model’s outputs as new personal information, not just the training data going in.
Te Tiriti partnership in the design loop
Charter commitment 2 is the one most often reduced to a paragraph in a closing report. Done properly it is structural. Two practical changes:
- Engagement happens before model selection. Decisions about what data to use, what to optimise for, and where to deploy the system all carry assumptions that need partnership input. By the time the team is “ready to test”, the design space has already collapsed.
- Equity of error matters as much as overall accuracy. A model that performs at 92% accuracy overall but at 70% on Māori data is failing — even when its aggregate score looks acceptable. Equity testing has to be a release gate, not an audit finding.
Operational requirements: assessment, oversight, monitoring
A defensible AI deployment in a NZ public-sector context typically carries five artefacts:
- An Algorithm Impact Assessment, combining elements of a Privacy Impact Assessment, an ethics review, and a Charter alignment statement. One artefact, one approval flow.
- A transparency notice in plain English, published where affected people will find it — not on an internal portal behind a sign-in.
- A documented human-in-the-loop design for any decision the system materially affects, with a defined override pathway and an audit trail.
- Equity testing evidence at release, with subgroup performance broken out and signed off.
- A monitoring plan — drift detection, periodic re-assessment, and a documented trigger for re-assessment when the model is retrained or its inputs materially change.
Without these, an agency is not so much non-compliant as undefended. When something goes wrong, there is no audit trail to point to.
Common failure modes
- Treating model selection as a vendor decision. The risk profile of an open-source 7B model deployed in your tenant is different from a vendor API where prompts and outputs leave the country. The procurement template doesn’t make this distinction; your assessment has to.
- Skipping the data-fitness step. Importing a dataset and treating it as canonical without provenance work. Most equity failures we’ve seen trace back to this.
- Confusing pilot with production. A pilot can sit outside the full artefact set; the pilot-to-production transition is where most of the residual risk lives, and where the assessment gap is most expensive to close late.
- One-shot impact assessment. Models change. Assessments that aren’t versioned alongside the model stop being meaningful within a release or two.
Where to start
If your agency is in the early phase, three things de-risk the work materially:
- A short AI use register — every place AI is in use or proposed, even just as a vendor add-on. You can’t govern what you don’t know about.
- An Algorithm Impact Assessment template that combines PIA, ethics, equity, and Charter alignment. One artefact, one approval flow.
- A release gate that requires assessment evidence to ship — not as a process step, but as a deployment-pipeline check that produces a refusal.
Responsible AI in the New Zealand context is more concrete than the principles documents suggest. The work isn’t writing a position; it’s wiring the assessment, oversight, and monitoring into the way the agency actually delivers systems. The agencies that get this right are the ones that treat the Charter and the IPPs as design inputs, not approval-gate paperwork.