Māori Data Sovereignty Architecture: Tikanga-Aware ML Systems (2026)

Q: Why is Māori data sovereignty an architectural problem rather than a policy problem?

The default cloud architecture for ML systems was designed for a Crown-data threat model with single-region partitions, Crown-role-graded access controls, and retention-policy-driven deletion on a primary store. Māori data sovereignty needs three architectural surfaces the default does not provide: a per-partnership residency partition whose authority boundary is the Iwi or hapū rather than the Crown agency, an authority decision service that the platform consults at decision time using whakapapa-derived authority rather than agency role hierarchy, and a deletion machinery that reaches every surface (primary store, retrieval index, vector embedding store, eval datasets, prompt registry, fine-tune layer, audit log, backup chain) and produces signed evidence. Without each of these surfaces, the partnership commitment is failed by the architecture even when the policy is good. Rangatiratanga, whakapapa, whanaungatanga, kotahitanga, manaakitanga, and kaitiakitanga each map to a deliverable artefact the engineering team produces; a platform that does not produce the artefacts cannot honour the principles however well-intentioned the policy document is.

Q: How does the Iwi authority service actually work in practice when the platform team is making routine maintenance changes?

The Iwi authority service is an external identity provider that the platform integrates with using standard OIDC or SAML, configured per partnership so that the Iwi controls the IdP itself (typical pattern: the IdP is hosted on infrastructure the Iwi has nominated, run by a team the Iwi has nominated, with the Iwi data board controlling the policy that the IdP enforces). The platform never makes an access decision on Māori data without consulting the IdP; cached decisions have a short TTL (typical 5-15 minutes) so that a revocation by the IdP propagates within minutes rather than days. For routine platform maintenance, the platform team has its own role with its own scope (typical: maintenance role can read system logs, can invoke maintenance scripts, cannot read partnership data); operations that touch partnership data require either prior partnership authorisation (recurring tasks listed in the partnership agreement) or per-task authorisation through the IdP. The audit log records every decision the IdP made and every action the platform team took under each decision; the partnership cadence reviews the audit log, surfaces any patterns that the partnership wants to refine, and updates the IdP policy as the partnership evolves.

Q: What is the deletion guarantee's reach when the data has been used to fine-tune a model, and how does the architecture handle the irreversibility?

Fine-tuning is the deletion guarantee's hardest constraint because there is no architecturally credible way to "delete from model weights" — once data has been incorporated into a fine-tune layer, the data is encoded into the layer's parameters and cannot be reliably extracted or expunged. The architectural answer in 2026 is preventative plus reactive. Preventatively, fine-tuning on Māori data is treated as an exceptional operation requiring explicit partnership-level consent under an agreement that names the irreversibility; the platform default is to use Māori data only in retrieval-augmented patterns (where the data lives in the retrieval store and the model invokes against the retrieval) rather than in fine-tuning patterns (where the data is encoded into the model). Reactively, when a deletion call arrives for data that has been used to fine-tune, the response is to retire the fine-tune layer (cease serving the model that contains the data), retain the layer under restricted access for any audit obligation that survives the deletion, and replace it with a model trained without the deleted data; the deletion certificate to the Iwi documents the retirement, the residual access controls on the retired layer, the replacement model, and the residual risk (model outputs that may have been emitted before the deletion are not recallable, which the certificate names explicitly). The platform supports this by versioning every fine-tune layer with its training-data provenance and by maintaining the operational capability to retire and replace layers as a routine operation rather than as a special engineering exercise.

Q: How does this architecture map to Australian First Nations data sovereignty under the Maiam nayri Wingara principles?

The architectural pattern transplants with translation. The Maiam nayri Wingara principles (data for and about First Nations is a strategic resource; First Nations have inherent rights and interests in data; First Nations have a right to data that is relevant to their world view, priorities, and aspirations; the data should be structured to enable First Nations governance) map onto the same architectural deliverables: per-partnership cloud subscription as the residency partition, an Indigenous Data Network-aligned authority service per nation as the IdP, the same deletion machinery reaching every surface, the same provenance graph carrying the data origin forward into model outputs, the same partnership engagement cadence wired into the release calendar. The differences are jurisdictional rather than architectural. The Australian regulatory composition includes the Privacy Act 1988 (as amended by the 2024 reforms and the in-force 2025 statutory tort), the AIATSIS Code of Ethics for Aboriginal and Torres Strait Islander Research, and the recently developed AISI voluntary standard for AI safety; the partnership specifics involve the Indigenous Data Network rather than the Iwi/hapū structure, and the language and protocol of the engagement cadence reflect the specific nation's tikanga-equivalent. The architectural pattern, the deletion guarantee, the per-partnership partition, and the audit-log self-service all transplant intact; the partnership obligations and the cultural sensitivity classifier are partnership-defined per nation rather than reusable across.

Q: How does the cultural sensitivity classifier get developed in partnership, and what does the partnership review of it look like?

The classifier development is a multi-stage partnership engagement, not a one-time training project. First, the partnership defines the taxonomy of culturally significant content categories — typical categories include whakapapa references, mātauranga Māori, ceremonial language, references to wāhi tapu, te reo Māori with sacred connotations, kawa-specific protocols — with the operational definitions belonging to the Iwi/hapū rather than to a generic dictionary. Second, the partnership produces a labelled dataset under the Iwi's labelling protocol; the labels reflect the partnership's judgment about which content is culturally significant and which routing decision is appropriate; the dataset itself is held in the per-partnership partition and is treated as partnership data with the same residency and access controls as the operational data. Third, the platform team trains the classifier (with Māori subject-matter expertise on the team where possible and with the partnership reviewing the modelling decisions) and produces an eval that measures the classifier against the partnership-defined criteria; the eval typically calibrates for high recall over high precision because over-routing to human review is acceptable and under-routing is a partnership breach. Fourth, the classifier is deployed under partnership review; production failures surfaced are returned to the partnership; the classifier is retrained on a partnership-defined cadence (typically quarterly or on partnership request). The quarterly engagement review includes the classifier evolution, the failure cases observed, the partnership's direction for the next iteration, and the partnership's sign-off for the next release. The classifier is a partnership artefact under continuous development, not a tool the platform team owns.

Q: How is the per-partnership cloud subscription structured in practice across AWS, Azure, and Google Cloud?

In AWS the partition is typically an AWS account per partnership, organised inside an AWS Organisation under an OU dedicated to partnership accounts; the account has its own VPC, its own KMS keys (with the key policy referencing the Iwi authority service and the Iwi data board signatories on root rotation), its own S3 buckets, its own RDS or DynamoDB instances, its own SageMaker resources for any model training. In Azure the partition is typically an Azure subscription per partnership, organised inside a management group dedicated to partnership subscriptions; the subscription has its own resource groups, its own Key Vault (with the access policy referencing the Iwi authority service), its own storage accounts, its own compute resources. In Google Cloud the partition is a project per partnership, organised inside a folder dedicated to partnership projects; the project has its own VPC, its own Cloud KMS keys, its own GCS buckets, its own BigQuery datasets, its own Vertex AI resources. Across all three, the cross-partition access from the platform team's operations subscription is mediated by IAM roles whose assumption is gated on the Iwi authority service decision; the network controls prevent egress of partnership data to any region or service the partnership has not authorised; the observability (CloudWatch / Azure Monitor / Cloud Logging) for the partnership partition is itself in the partition rather than aggregated to a central observability subscription, which preserves the residency claim for the audit log. The additional infrastructure cost of per-partnership accounts is small (typically a few hundred dollars per month per partnership in baseline overhead) and pays back in audit defensibility, incident-response containment, and partnership engagement clarity.

Q: How does the platform handle deletion-call requests when the data has been used in eval datasets and downstream model evaluation results have been published?

The deletion machinery reaches the eval dataset (any derived eval samples are removed and the removal is noted in the eval lineage), but published evaluation results that referenced the data are not retracted because the publication was a one-time event rather than a continuing data flow. The deletion certificate to the Iwi documents this distinction explicitly: the eval samples have been removed from the active eval dataset (so future eval runs do not re-include the data), the eval lineage records the historical inclusion (because the audit obligation requires the inventory), the published evaluation reports that referenced the data remain published (because the publication has its own historical record), and the residual-risk statement names that the published reports may have leaked information about the data which is not recallable. Where the partnership agreement requires it, the platform commits to a retraction notice on any published evaluation report that referenced the deleted data, with the Iwi receiving the retraction notice for review; the platform commits to including a "data lineage may have been deleted under partnership call; current eval methodology and dataset may differ from this report" advisory on the published report. The partnership review records the deletion event, the response, the residual risk, and the agreed mitigations; the architectural lesson is to think carefully at eval-design time about which datasets are partnership-data and to design the eval methodology so that future deletion calls produce the smallest possible residual risk surface.

Q: How does the partnership engagement cadence get wired into CI as a release gate, and what happens when an engagement is overdue?

The engagement cadence is represented in the source control as a partnership-engagement record per active partnership; the record contains the last-engagement date, the next-due date (typically 90 days from last for routine quarterly cadence), the engagement minutes, the partnership-defined approval status for any pending architectural changes, and the partnership signatures on the record. The CI gate runs at every release that affects partnership data (the affected-partnership detection is itself an architectural artefact — the codebase is annotated with partnership tags and the CI computes the affected-partnership set from the diff). For each affected partnership, the CI checks: the engagement record exists, the next-due date is in the future at release time, the partnership has signed off any architectural changes since the last engagement, the audit-log self-service endpoint is healthy. If any check fails, the release is blocked; the platform team's response is to either restore the engagement (schedule the overdue engagement, hold it, update the record) or to drop the partnership-data-affecting changes from the release (typical pattern: ship the unaffected changes on schedule, hold the affected changes for the next release after the engagement is current). An engagement that becomes structurally overdue (typical threshold: 30 days past due without the engagement being scheduled) escalates to the partnership steering committee; the architecture exposes the engagement-currency dashboard to the partnership steering committee on a self-service basis so that the partnership has visibility into the platform's adherence to the cadence.

Q: What does the audit-log self-service endpoint look like for the Iwi data board, and what queries does it actually need to support?

The endpoint is a query service scoped to the partnership's data, with authentication against the Iwi authority service so that only the Iwi data board members (or their nominated delegates) can use it. The query interface is intentionally simple — a small set of canonical queries that the data board has identified as needed, plus a self-service ad-hoc query capability for the data board's analysts. The canonical queries: decisions in a date range, decisions touching a particular dataset, decisions that triggered the cultural sensitivity guardrail, decisions that resulted in escalation to human review, decisions that produced model outputs in production (with the downstream traceability into the application logs that recorded what the user did with the output), deletion events with their certificates, classifier-retraining events with the partnership review references, engagement-cadence currency, security incidents affecting the partition. The ad-hoc query capability is a structured query interface (typically a SQL-like query language against a partition-scoped audit-log warehouse) with the query results themselves logged so that the partnership and the platform team can support each other when the queries surface issues. The endpoint's SLA is partnership-defined (typical: 95th percentile query response under 30 seconds for canonical queries, ad-hoc queries under 5 minutes); the endpoint is exercised in the quarterly engagement review so that the data board confirms the endpoint is healthy and the canonical query set is the right set. The endpoint is a partnership deliverable named in the agreement; its existence and quality are reviewed alongside the architectural surfaces.

Satyam Kumar

返回博客

ai-architecture

Data Sovereignty Architecture: Respecting Māori Data Principles in Tikanga-Aware ML Systems (2026)

By Satyam KumarMay 12, 202620 min read

maori data sovereignty te mana raraunga care principles indigenous data sovereignty data residency iwi authority tikanga aware ml algorithm charter aotearoa new zealand ml governance deletion guarantee fine tune retirement cultural sensitivity classifier partnership engagement ai architecture public sector ai 2026

Data Sovereignty Architecture: Respecting Māori Data Principles in Tikanga-Aware ML Systems (2026)

Frequently Asked Questions

分享这篇文章

Twitter LinkedIn WhatsApp

Satyam Kumar

Founder & AI Architect, AppScale LLP

人工智能和云架构师。帮助团队构建可扩展到数百万的系统。

LinkedIn GitHub

Data Sovereignty Architecture: Respecting Māori Data Principles in Tikanga-Aware ML Systems (2026)

Frequently Asked Questions

分享这篇文章

Comments

Leave a comment