Short answer
AI data residency in New Zealand is about where data is stored, where model inference runs, and where logs and copies end up. The Privacy Act 2020 does not require personal information to stay onshore, but IPP12 applies if an overseas provider uses it for its own purposes. As of October 2026, AWS and Azure run Auckland regions, yet most hosted model inference runs in Australia or further afield.
- The Privacy Act regulates overseas disclosure, not storage location; providers acting only on your behalf fall under section 11.
- IPP12 applies when an overseas provider uses the data for its own purposes, such as training.
- AWS (ap-southeast-6) and Azure (New Zealand North) operate Auckland regions; Google Cloud does not yet.
- Amazon Bedrock’s Australia and New Zealand routing from Auckland can process in Auckland, Sydney or Melbourne.
- OpenAI and Anthropic’s own APIs offer no New Zealand processing region as of 19 October 2026.
What data residency means for an AI system
Data residency for an AI system is three questions, not one: where data is stored at rest, where the model processes it during inference, and where the side copies go (logs, caches, embeddings, backups, support access). A provider can answer the first with “Australia” and the second with “anywhere”, and both can be true of the same request.
Residency is location; sovereignty is whose laws and control apply, and an overseas-headquartered provider can be subject to its home country’s laws while your data sits in Auckland. Māori data adds a question of governance. Te Mana Raraunga’s Māori Data Sovereignty Principles state that, whenever possible, Māori data shall be stored in Aotearoa New Zealand.
What New Zealand law requires
The Privacy Act 2020 regulates disclosure, security and use, not storage location. Three provisions decide most AI architecture questions.
- Section 11: providers acting on your behalf. If a provider holds personal information only to store or process it for you, the information is treated as held by you, and section 11(4) says it does not matter that the provider is outside New Zealand. Sending data to that provider is not a disclosure. If the provider also uses the information for its own purposes, it holds it as well.
- IPP12: disclosure outside New Zealand. IPP12 allows disclosure to a foreign person or entity only on specific grounds: informed authorisation by the individual; the recipient is subject to the Act; comparable safeguards through its laws, a prescribed scheme or a prescribed country; or an obligation, such as a contract, to protect it comparably.
- IPP5: security. You must protect information with safeguards that are reasonable in the circumstances, wherever it is processed.
The Privacy Commissioner’s guidance on AI and the information privacy principles applies this directly: using offshore technology providers to store or process data is not treated as a disclosure under IPP12, so long as they are not using it for their own purposes. Whether IPP12 applies can therefore turn on the provider’s terms, for example whether your prompts are used to train its models. The Commissioner’s guidance on working with third-party providers adds the contract terms to look for: use only for your services, breach notification, retention and deletion, and consultation where there are Māori data sovereignty implications.
This is general information, not legal advice; contracts, sector regulators and public sector policies can impose onshore requirements the Act does not. Our lesson on protecting customer information when using AI covers the everyday practice.
Cloud regions in and near New Zealand
As of 19 October 2026, two of the three large cloud providers run regions in Auckland.
| Provider | Region | Status as of 19 October 2026 |
|---|---|---|
| AWS | Asia Pacific (New Zealand), ap-southeast-6, three Availability Zones | Open since September 2025 |
| Microsoft Azure | New Zealand North, Auckland, three Availability Zones | Open since December 2024 |
| Google Cloud | A New Zealand region was announced in 2022 | Not listed in Google’s regions and zones; nearest are Sydney (australia-southeast1) and Melbourne (australia-southeast2) |
Microsoft 365 also treats New Zealand as a local region geography eligible for Advanced Data Residency, which covers storage of Microsoft 365 Copilot and Copilot Chat content. Storage is not processing: Microsoft’s in-country processing plan for Microsoft 365 Copilot, as updated in April 2026, lists Australia, India, the United Arab Emirates, the United Kingdom and the United States by the end of 2026, and does not list New Zealand.
Where each AI provider runs inference
A cloud region in Auckland does not mean model inference in Auckland. As listed on 19 October 2026:
| Service | Processing options relevant to New Zealand | Notes |
|---|---|---|
| Amazon Bedrock | Requests can be made in Auckland since March 2026. The Australia and New Zealand geographic profile routes them to Auckland, Sydney or Melbourne; the global profile routes worldwide | At launch the geographic profile covered Anthropic Claude models; data at rest stays in the source region |
| Microsoft Foundry (including Azure OpenAI) | Deployment types: Global (any Azure region), Data Zone (US, EU or Asia Pacific), Standard (within the chosen Azure geography) | Geography-based types reach new models last, with no guaranteed date |
| OpenAI API | Data residency storage regions include Australia; regional processing is offered only for the United States, Europe and the United Arab Emirates | Where a region lacks regional processing, content may be processed outside it; non-US regions require approved retention controls |
| ChatGPT Enterprise and Edu | Storage at rest available in Australia among others; inference residency only in Europe, the United States and the United Arab Emirates | Connected apps and web search follow their own providers’ terms |
| Claude API (Anthropic, direct) | Inference geography is “global” or “us”; workspace storage geography is “us” only | For Australia and New Zealand processing, use Claude through Bedrock’s geographic profile |
| Vertex AI (Google Cloud) | Regional endpoints; Google’s data residency page lists Australia (australia-southeast1) for in-country processing of Google models | The global endpoint gives no residency guarantee; check per-model support |
| Open-weight models you host | Wherever you run them, including your own servers and the Auckland cloud regions | Full control, and the operations work that comes with it |
Inference guaranteed to stay in New Zealand currently means self-hosted open-weight models, covered in running open models for business. Regional model lists change with every release, so treat region checks as part of AI model migration.
Pin the region and verify where inference ran
Configuration states your intent; logs prove it. Pin regional endpoints and profiles in code, block the alternatives with policy, and check where requests were actually processed.
import boto3
ALLOWED_INFERENCE_REGIONS = {"ap-southeast-6", "ap-southeast-2", "ap-southeast-4"} # Auckland, Sydney, Melbourne
bedrock = boto3.client("bedrock-runtime", region_name="ap-southeast-6")
response = bedrock.converse(
modelId="au.anthropic.claude-sonnet-4-6", # geographic profile, not the global one
messages=[{"role": "user", "content": [{"text": "Summarise this tenancy notice: ..."}]}],
)
def out_of_region(cloudtrail_events: list[dict]) -> list[dict]:
"""Bedrock records the processing region in additionalEventData.inferenceRegion."""
return [e for e in cloudtrail_events
if e.get("eventSource") == "bedrock.amazonaws.com"
and e.get("additionalEventData", {}).get("inferenceRegion") not in ALLOWED_INFERENCE_REGIONS]
Other providers expose similar evidence: on Claude 4.6 and later models, Anthropic’s API returns the inference geography in each response’s usage object. Run the check daily and alert on any result. AWS’s announcement also shows service control policies that confine Bedrock to the three Australia and New Zealand regions.
Map every data flow, not just the model call
Most residency surprises come from the side flows. List each one with its location and retention.
| Flow | Question to answer |
|---|---|
| Prompts and retrieved context | Where does inference run, and is it pinned? |
| Stored conversations, files and threads | Which storage region, and how long are they kept? |
| Embeddings and vector index | Where is the database hosted, including backups? OWASP warns embeddings can be inverted to recover text, so treat them like the source documents |
| Provider safety logs | Retention period and location; OpenAI’s API, for example, keeps abuse monitoring logs for up to 30 days by default |
| Your own traces and monitoring | Where does your observability vendor store them? |
| Tools and connectors | Web search, MCP servers and third-party APIs receive data under their own terms |
| Support access and sub-processors | Who can access data, and from which countries? |
| Evaluation and fine-tuning data | Where are datasets stored, and with which provider? |
Our AI data inventory template has columns for each, and building private AI search covers the permission questions retrieval adds.
Choose an architecture by data class
| Data | Typical requirement | Workable approach as of October 2026 |
|---|---|---|
| Public or non-sensitive business content | Standard contract terms | Any reputable provider, global routing acceptable |
| Personal information about customers or staff | Provider acts only on your behalf, no training, sensible retention, IPP5 safeguards | Business or API terms with training off; Australian processing where available and accepted |
| Contractually onshore data (some public sector and enterprise customers) | Storage and inference in New Zealand | Self-hosted open-weight models in Auckland regions or your own data centre; confirm any hosted route processes only in New Zealand |
| Māori data | Governance and, whenever possible, storage in Aotearoa | New Zealand hosting by default, and engagement with the communities the data concerns |
| Health information | Its own code of practice under the Act, plus sector requirements | Specialist advice before design |
Where residency plans go wrong
| Failure | Example | Control |
|---|---|---|
| Storage mistaken for processing | An Australian storage region with no regional processing | Read the processing column, not the storage one |
| Global defaults left on | Global routing profiles, global endpoints, Global deployment types | Pin regional options in code and block the rest with policy |
| Logs leave the region | Traces shipped to an overseas observability service | Include observability vendors in the data flow map |
| Expanding zones | Microsoft says it can add regions to a data zone without prior notice | Monitor provider documentation; prefer geography-level options where required |
| New features outside scope | OpenAI says new ChatGPT features are not residency-eligible unless listed | Review residency scope before enabling features |
| Embeddings treated as harmless | Vector backups stored with weaker controls | Same tier as the source documents |
Recording these decisions is part of AI governance work, and vendor questions to ask before signing are in the AI vendor evaluation checklist.
- Every data flow is listed: inference, storage, embeddings, provider logs, your traces, tools, support access and datasets
- Each provider’s terms confirm whether it uses your data for its own purposes, such as training
- The section 11 or IPP12 position is recorded for each provider in a privacy impact assessment
- Regional endpoints, profiles or deployment types are pinned in code, and global options are blocked by policy
- Processing location is verified from provider logs or response fields, with alerts on exceptions
- Embeddings, vector backups and traces are hosted and protected like the source documents
- Contracts cover use limits, breach notification, retention, deletion and sub-processors
- Māori data and health information have an explicit, reviewed decision
- Provider residency pages are re-checked on a schedule, with the date recorded
Sources
- Privacy Act 2020, New Zealand Legislation, 2020
- Principle 12: Disclosure outside New Zealand, Office of the Privacy Commissioner, 2026
- Working with third-party providers: understanding your privacy responsibilities, Office of the Privacy Commissioner, 2026
- Artificial intelligence and the Information Privacy Principles, Office of the Privacy Commissioner, 2023
- Te Mana Raraunga Māori Data Sovereignty Principles, Te Mana Raraunga, 2018
- Now Open: AWS Asia Pacific (New Zealand) Region, AWS News Blog, 2025
- Run Generative AI inference with Amazon Bedrock in Asia Pacific (New Zealand), AWS Machine Learning Blog, 2026
- New Zealand’s First Hyperscale Cloud is Open for Business, Microsoft New Zealand News Centre, 2024
- List of Azure regions, Microsoft Learn, 2026
- Understanding deployment types in Microsoft Foundry Models, Microsoft Learn, 2026
- Microsoft offers in-country data processing to 15 countries for Microsoft 365 Copilot, Microsoft, 2026
- Advanced Data Residency overview, Microsoft Learn, 2026
- Data controls in the OpenAI platform, OpenAI API documentation, 2026
- Data residency and inference residency for ChatGPT, OpenAI, 2026
- Data residency, Claude Platform Docs (Anthropic), 2026
- Regions and zones, Google Cloud Compute Engine documentation, 2026
- OWASP GenAI LLM Top 10 2026, OWASP Gen AI Security Project, 2026
- Data residency (generative AI on Vertex AI), Google Cloud documentation, 2026
Written by the Levy Street team in Wellington. Last updated 19 October 2026.