The Same Model, Two Regimes: What 10 December 2026 Requires of Trans-Tasman AI Architecture
There is a date sitting in the Australian statute book that most New Zealand enterprise architecture roadmaps have not yet absorbed.
On 10 December 2026, amendments to Australia's Privacy Act take effect. They were enacted in 2024, they have been on the books for nearly two years, and they arrived with none of the attention that greeted this month's announcement from Canberra about national AI standards. They are also the more immediate of the two, because they are already law.
From that date, Australian Privacy Principles 1.7, 1.8 and 1.9 require any APP entity to state in its privacy policy which computer programs it uses to make decisions about people, what kinds of personal information those programs use, and what kinds of decisions they make. The disclosure must be in plain language. It must be specific enough to be meaningful. It must be structured so that a person can understand the decision well enough to contest it.
The obligation does not care whether the system is a large language model, a decision tree, or a set of business rules written in 2011. It applies to any automated assessment technology using personal information to make a decision that could reasonably be expected to significantly affect an individual's rights or interests. It is not grandfathered. A model deployed in 2019 is caught on the same terms as one deployed next month.
New Zealand's Privacy Act 2020 contains no equivalent requirement.
That single sentence is the architecture problem this chapter is about.
Two tracks, not one announcement
It is worth separating what happened this month from what happens in December, because they are different kinds of instrument and they are moving at different speeds.
On 15 July 2026, the Australian Prime Minister announced an Office of AI inside the Department of the Prime Minister and Cabinet, effective immediately, and committed to legislating national AI standards. The announced standards include obligations on large AI data centres: underwriting the full cost of their own new power connections, reducing power draw on demand to support grid stability, maximising water efficiency, and involving state and local input in siting decisions. The government stated that AI data-centre growth will not raise household power prices, and that Australian creative works should not be used to train AI without the creator's control. National Cabinet considers the approach in August 2026. Legislation is targeted for early 2027.
That is an institutional track. It is real, it is funded, and it has an office with a door on it. It is also, as at today, a commitment to legislate rather than legislation. No penalty amounts have been published. No capacity threshold defining a "large" data centre has been published. The word the government used to describe the standards was "world-first", which is the government's own characterisation of its own policy rather than an independently benchmarked comparison, and it should be read that way.
The Privacy Act amendment is a statutory track. It has a commencement date, and no remaining legislative steps. Legal analysts covering the change report that the regulator has begun preparing to review privacy policies ahead of it; read that as a law firm's characterisation of the regulator's posture, not as a regulator's own statement. Either way, it is four months away.
For an enterprise architect the distinction matters more than the headlines suggest. The Office of AI track tells you what to watch. The Privacy Act track tells you what to build, and by when. Conflating them into a single "Australia is regulating AI" narrative produces a roadmap that tracks a 2027 policy process while missing a 2026 statutory deadline.
There is a second point in the December obligation that is easy to miss. It is not an AI law. It is a privacy law that happens to catch AI systems alongside every other automated decision technology. Australia is regulating the effect, which is decisions made about people without a person making them, through the sectoral instrument it already had. It is building AI-specific institutional capacity in parallel. Two mechanisms, two timelines, one policy direction.
The New Zealand position, stated accurately
New Zealand's national AI Strategy, "Investing with Confidence", was published by MBIE in July 2025. It is adoption-focused rather than regulatory. It concentrates on AI application rather than foundational model development, and it relies on existing technology-neutral law rather than new AI-specific legislation.
The strategy is explicit that this is a chosen alternative to the European approach of a single all-encompassing AI statute. The named operative frameworks are the ones that already exist: the Privacy Act, the Fair Trading Act, the Commerce Act, the Copyright Act and the Human Rights Act. MBIE's accompanying Responsible AI Guidance for Businesses is voluntary.
That is a stated policy position, published and reasoned, not a gap awaiting attention. For architects the practical consequence is straightforward: existing law is the operative compliance surface today, and on current settings, for the foreseeable future. Plan against what exists rather than against an anticipated New Zealand AI Act.
On automated decision-making specifically, the Office of the Privacy Commissioner published guidance in September 2023 applying the thirteen Information Privacy Principles across the AI system lifecycle. That guidance does not treat automated decision-making as a discrete regulated category, and IPP 3A, the notification principle we covered at length in Chapter 9, does not regulate it either. The Office of the Privacy Commissioner has identified automated decision-making as a reform priority since 2023, on the reading of legal commentators describing its published position. No legislative change has followed as at today's date.
Then there is the part that decides the architecture. A New Zealand organisation that carries on business in Australia, or that holds personal information about Australian residents, is an APP entity in its own right. It is caught by the December obligation directly, on Australian terms, regardless of how completely it complies with New Zealand law. Domestic compliance does not travel. Buddle Findlay's analysis for New Zealand organisations puts this plainly: reliance on New Zealand-only compliance is insufficient for the Australian-facing part of the business.
For most New Zealand enterprises of any scale, that is not an edge case. It is the org chart.
The same model, two answers
Here is the concrete shape of the problem.
An insurer runs one claims-triage model. One codebase, one weights file, one deployment pipeline. It processes New Zealand claims and Australian claims through the same logic, because that is what good architecture looks like and nobody builds two of something they can build once.
From 11 December 2026, that single model has two different disclosure obligations attached to it depending on whose personal information passed through it. The Australian path requires plain-language disclosure in the privacy policy, specific enough to contest. The New Zealand path requires nothing of the kind.
The naive response is to build to the higher standard everywhere and move on. That is often the right call, and for many organisations it will be. But it is a decision, not a default, and it needs to be made deliberately. This is an architectural observation rather than legal advice: disclosing an automated decision process in a New Zealand privacy policy where no obligation exists creates commitments that are difficult to withdraw, and a New Zealand regulator may later read a published statement as a representation. Uniform over-disclosure is a legitimate architectural choice. Accidental over-disclosure is not.
Either way, both paths need the same underlying capability, and it is a capability most AI governance roadmaps built to the light-touch strategy do not currently produce: a per-system, per-jurisdiction inventory of automated decision-making, expressed in language a customer can read.
That is an architecture problem, and it decomposes cleanly.
Determining whether a system is caught
The first artefact is a determination path. Run every candidate system through it, and record the answer with a date and a named owner, because the answer is the audit evidence.
1. Does the system use personal information?No -> out of scope for APP 1.7-1.9. Record and stop.Yes -> continue.2. Does the organisation carry on business in Australia, or holdpersonal information about Australian residents?No -> not an APP entity for this system. Record, and set a reviewtrigger on any change to Australian market activity.Yes -> continue.3. Does a computer program make the decision, or perform a stepsubstantially and directly related to making it?No -> out of scope. Record the human decision point that takes itout of scope, because that is the control.Yes -> continue.4. Could the decision reasonably be expected to significantly affectan individual's rights or interests?Uncertain -> treat as in scope pending legal review. Do not resolveambiguity downward without advice.Yes -> IN SCOPE. Disclosure required by 10 December 2026.Step 3 is the one that catches organisations out. "Substantially assists" is a wider net than "decides". A model that scores an application and hands the score to a human who approves ninety-four per cent of what it recommends is performing a step substantially and directly related to the decision, whatever the process documentation says about human review. This is an engineering test to run, not a legal conclusion to assert. The control is not the presence of a human. It is whether the human materially changes outcomes, and that is a measurable property of your own decision logs.
Extending the agent register
The second artefact reuses infrastructure this book has already built. The agent register schema introduced in Chapter 13, and extended through the identity work in Chapters 16 to 20 and again in Chapter 24, already carries ownership, capability and audit fields. Jurisdictional decision scope is a small addition to it, and putting it there rather than in a separate compliance spreadsheet is the entire point: the register is the architecture.
agent:id: "agent-claims-triage-001"display_name: "Claims Triage Agent"persona: "Claims Triage Officer" # ALEA Pillar 1owner_team: "Insurance Operations"business_owner: "Head of Claims"automated_decision_making:makes_decisions: trueassists_decisions: truedecision_types:- "initial claim eligibility assessment"- "claim value banding"affects_rights_or_interests: truehuman_review:present: trueoverride_rate_90d: 0.06 # measured, not assertedmaterial_review_test: FAILED # <10% override: assistive in# name, determinative in effectjurisdictional_scope:processes_personal_information_of:- jurisdiction: "AU"app_entity: trueapp_1_7_disclosure_required: truedisclosure_status: "DRAFTED"disclosure_owner: "Group Privacy Counsel"commencement: "2026-12-10"policy_section_ref: "privacy-policy-s7.3"- jurisdiction: "NZ"app_entity: falsestatutory_disclosure_required: falsevoluntary_disclosure_position: "ALIGN_TO_AU"rationale_ref: "ADR-2026-114" # decision recorded, not driftedcontestability:human_review_pathway: "claims-review-queue"pathway_published: trueplain_language_description_ref: "disclosure-copy-claims-001"max_response_days: 20Three fields carry most of the weight. override_rate_90d turns "we have human review" from an assertion into a measurement. material_review_test records what that measurement means. And voluntary_disclosure_position with its rationale_ref forces the New Zealand-side choice to be an architectural decision with a recorded rationale, rather than something that happens by copy-paste when the privacy policy is next updated.
Mapping the controls
The third artefact is the control mapping. It is deliberately short, because the honest version of this table is short.
| Capability | Australia (APP 1.7-1.9, from 10 Dec 2026) | New Zealand (Privacy Act 2020, today) |
|---|---|---|
| Inventory of ADM systems | Required in substance to produce the disclosure | Not required; needed anyway for IPP 1 and IPP 8 discipline |
| Categories of personal information used | Must be disclosed | Not required as an ADM-specific disclosure |
| Kinds of decisions made solely by program | Must be disclosed | Not required |
| Kinds of decisions substantially assisted | Must be disclosed | Not required |
| Plain-language description | Required, specific enough to be meaningful | Not required |
| Contestability pathway | Required in effect, since disclosure must support challenge | IPP 6 and IPP 7 access and correction rights apply generally |
| Grandfathering of legacy systems | None. Pre-existing systems fully in scope | Not applicable |
Everything in the left column has a date. Nothing in the right column does. That asymmetry is the whole of the design problem, and it is not resolved by having an opinion about which regime is better.
The institutional question, and who is asking it
One day after the Office of AI announcement, New Zealand's Science Media Centre published expert reaction asking whether New Zealand should establish something equivalent.
Professor Alistair Knott of the Centre for Data Science and AI at Victoria University of Wellington argued that New Zealand needs a government AI office and could readily get one, pointing to the centralisation of government digital delivery inside the Public Service Commission as existing groundwork to build on rather than starting from nothing. Dr Andrew Lensen, Senior Lecturer in Artificial Intelligence at the same institution, raised concerns about a proposed Southland data centre on power price, drinking water and profit repatriation grounds, and warned against a trans-Tasman competition in which cheaper power and faster consenting become the main attractions for foreign investment.
Both are university academics commenting through the Science Media Centre's expert-reaction mechanism. Neither speaks for the New Zealand Government, MBIE, the Government Chief Digital Officer, or the Public Service Commission. As at the time of writing, no New Zealand government body has stated an intention to establish an AI office of the kind announced in Canberra. What the piece establishes is that the question is being asked domestically, by named people with relevant expertise, within twenty-four hours of Australia moving. That is worth recording. It is not a forecast, and this chapter does not treat it as one.
The architectural observation, which is the only one this book is qualified to make, is this. The machinery Professor Knott points to is the same machinery Chapter 23 examined: a centralised digital-delivery function operating with an advisory rather than an authoritative mandate. Chapter 23 found a coordinating structure holding the position without the corresponding authority. The question now being raised publicly is whether that same structure should take on a new job.
That is a familiar shape. It is the question every architect eventually asks about a shared service: does this function have the mandate to do the thing everyone assumes it is doing. Whether it should is a policy matter, and outside this book's scope. That the question is now live, and that it is the same structural question Chapter 23 documented, is architecture.
Architectural Debt, at the jurisdictional layer
Throughout this series and the Cyber Guide for Boards work, Architectural Debt has meant a gap that exists not because nobody noticed, but because nobody was assigned the authority to close it.
The trans-Tasman divergence is that pattern at the level above the enterprise. The gap is visible. It is being discussed publicly by named experts. It has a date attached to one half of it. And for the individual organisation, none of that matters, because the organisation cannot close a jurisdictional gap. It can only build to both sides of it.
Which is the practical instruction. You are not going to resolve the regulatory divergence. You are going to inventory your automated decisions, determine which are caught, write the disclosures in language a customer can read, publish the contestability pathway, and record the New Zealand-side position as a decision rather than an omission. Four months.
The systems that will hurt are the old ones. The 2019 scoring model nobody has looked at since the person who built it left. The rules engine that is not on anyone's AI register because it is not AI. The vendor product where the automated assessment happens inside somebody else's boundary and your contract does not oblige them to describe it to you. Start there, because that is where the December date bites, and because none of them will appear on an inventory that was built by asking which systems use machine learning.
The open-source dimension is where a lot of this actually gets built. A jurisdiction-aware inventory of automated decisions does not need a proprietary compliance module. It needs a portable, machine-readable way to express which system makes which decision, on whose personal information, under which regime. Open standards already do this. Open Policy Agent lets you write the jurisdictional rule once as policy-as-code, rather than burying it inside a vendor's product where it cannot travel. Open provenance standards, the World Wide Web Consortium's PROV model and the OpenLineage project, record which data flowed into which decision, which is the evidence both regimes ultimately ask for. Open reference architectures let a small team build the determination path once and carry it between jurisdictions rather than rebuilding it for each. Portability, not any single product, is what lets one register answer to two regimes at once.
That same portability question runs up into defence and sovereignty. The pattern in this chapter, one system carrying different obligations depending on whose jurisdiction it touches, is the everyday condition of allied defence enterprise architecture. The United States export-control regimes, the International Traffic in Arms Regulations and the Export Administration Regulations, attach handling obligations to technical data by its content and destination, not by where its holder is domiciled, so the same artefact is freely held in one jurisdiction and tightly controlled in another. The United States Cybersecurity Maturity Model Certification programme extends that logic to suppliers: an organisation touching United States defence information meets the standard whatever its domestic law requires, because the obligation attaches to the data, not the company. Domestic compliance does not travel there either. The architecture answer is the same: build to both regimes, and record which governs each system as a deliberate decision.
Where is the automated decision in your organisation that nobody thinks of as AI, and who would have to describe it in plain language by December?
The views expressed in this article are entirely my own, informed by more than 30 years of professional experience in architecture, security, and technology leadership in New Zealand. They do not represent the views of my employer, any government agency, or the New Zealand government. My commentary on legislation and policy is analytical, drawing on publicly available sources and my professional expertise in architecture, security, and AI governance. I follow the Public Service Commissioner's Code of Conduct for the Public Sector and social media guidance.
Andreas Hamberger is a New Zealand leader in Architecture & Security and Associate Member of the Institute of Directors. Zero Trust Architecture for the Agentic Enterprise is the first book in The Hamberger Report series, providing practitioners with deployable patterns and configurations for securing AI-driven systems.
I use AI tools, including Sudowrite, Claude, Perplexity AI, DeepSeek AI, ChatGPT, Grok, Copilot, Openart and Gemini, as deliberate production tools, not ghostwriters. This is consistent with my position: AI amplifies human judgement; it does not replace it. The frameworks, arguments, and editorial decisions in this series are original work. AI accelerated the process. The thinking is mine.
References
[1] Office of the Australian Information Commissioner. "Chapter 1: APP 1, Open and transparent management of personal information." Australian Privacy Principles Guidelines. https://www.oaic.gov.au/privacy/australian-privacy-principles/australian-privacy-principles-guidelines/chapter-1-app-1-open-and-transparent-management-of-personal-information
[2] Buddle Findlay. "AI in the machine: what Australia's new automated decision-making rules mean for New Zealand organisations." July 2026. https://www.buddlefindlay.com/insights/ai-in-the-machine-what-australias-new-automated-decision-making-rules-mean-for-new-zealand-organisations/
[3] Prime Minister of Australia. "AI in Australia's interests." Media release, 15 July 2026. https://www.pm.gov.au/media/ai-australias-interests
[4] Ministry of Business, Innovation and Employment. "New Zealand's Strategy for Artificial Intelligence: Investing with Confidence." July 2025. https://www.mbie.govt.nz/business-and-employment/economic-growth/digital-policy/new-zealands-ai-strategy-investing-with-confidence
[5] Bell Gully. "Analysis of New Zealand's AI Strategy: a light-touch, existing-law approach." 2025. (No captured document URL; cited in full without a URL.)
[6] Office of the Privacy Commissioner. "Artificial Intelligence and the Information Privacy Principles." 21 September 2023. https://www.privacy.org.nz/resources-and-learning/a-z-topics/ai/
[7] Science Media Centre NZ. "Should NZ copy Australia's 'Office of AI'? Expert Reaction." 16 July 2026. https://www.sciencemediacentre.co.nz/2026/07/16/should-nz-copy-australias-office-of-ai-expert-reaction/