Where does your data actually go? Six ways to use AI

One of the least useful questions we can ask about a new technology is simply, “Is AI safe?” AI is not one system. A public chatbot, Microsoft Copilot, a commercial AI API, a local language model, a local document-search system and an entirely Māori-controlled AI environment may all contain a large language model somewhere in the architecture, but beyond that they can be profoundly different.

If Māori data sovereignty is fundamentally concerned with authority and control, those differences matter. The simplest way to understand them is to stop looking at the AI brand and follow the information. Where does it start, where does it travel, who processes it, what is retained, and who can change the rules later?

Public cloud AI

The first architecture is the one most people encounter. A person opens a public AI service, enters a prompt and perhaps attaches a document. That information travels from their computer to infrastructure operated by another organisation. The model runs there and the answer returns.

Whether the provider subsequently uses that information for model improvement depends on the service, account, settings and current terms. That should be checked rather than assumed. For public information, this may present little difficulty. Asking an AI system to summarise a publicly available council report does not necessarily require an elaborate sovereignty assessment.

The calculation changes if the material contains whakapapa, cultural information, internal iwi strategy, sensitive locations or information provided under restricted circumstances. The important question is not whether the AI company is trustworthy in some general sense. The first question is whether sending that information outside Māori control was appropriate in the first place.

Enterprise cloud AI

Enterprise services change part of the equation. Microsoft, for example, states that prompts, responses and organisational information accessed by Microsoft 365 Copilot are not used to train its foundation language models. Existing Microsoft 365 permissions remain part of the security model. This is considerably different from the often-repeated warning that anything given to an AI automatically becomes training data.

Enterprise protection does not mean the information is local. Processing still occurs within infrastructure controlled by another organisation, and interactions may be logged and retained for enterprise audit, compliance and eDiscovery. That may be entirely acceptable for many kinds of work. The point is to understand the trade rather than replacing technical analysis with either trust or fear.

See Microsoft’s current Microsoft 365 Copilot privacy guidance for the product-specific details that should be checked at the time a service is adopted.

Cloud AI through an API

A third architecture uses a commercial AI model through an API. This can provide considerably more control than a public chatbot because an organisation can build its own interface, decide which information is submitted, remove identifying information, enforce access controls and log exactly what is happening.

The model still runs elsewhere. For some purposes this will be an excellent compromise. For others, the act of sending the information outside the organisation will itself be unacceptable. The answer depends on the information, the authority attached to it and the kaupapa.

Local documents with a cloud model

A fourth architecture is commonly called retrieval-augmented generation, or RAG. Documents are indexed and searched by a system controlled by the organisation. When somebody asks a question, the search system identifies the most relevant passages and those passages are supplied to a model so it can prepare an answer.

This can substantially reduce disclosure compared with sending entire document collections. But “local RAG” does not necessarily mean local AI. If the retrieved passages are passed to a cloud model, those selected passages still leave the local environment. The useful question is therefore not simply whether an organisation uses RAG, but where every component of that RAG system runs.

Local model and local documents

The fifth architecture changes the sovereignty calculation substantially. A model can now run directly on a desktop computer, workstation or local server. Applications such as LM Studio can operate without an internet connection after models have been downloaded, and its documentation describes local chat and document processing that can run entirely on the device. See the current LM Studio offline guidance.

Open-weight models are also lowering the hardware threshold. Smaller reasoning models can operate on well-equipped desktop machines, while larger models can be run on workstations or shared servers. OpenAI’s open-weight gpt-oss models are one example of models specifically intended to be run on infrastructure controlled by the organisation or user. See the current gpt-oss model guidance.

In this architecture, the documents can remain local. The embeddings can remain local. The search index can remain local. The prompt can remain local. Model inference can remain local and the answer can remain local. This does not resolve every sovereignty question, but it removes an important one: the organisation no longer has to send the information to a model provider simply to obtain AI capability.

Why this matters for GIS mapping

GIS makes these architecture choices very concrete. A mapping project may contain far more than the picture eventually shown on a map. It can include precise coordinates, polygons, attribute tables, field observations, photographs, survey material, historical place-name research, Māori land references, environmental reports and metadata about where every layer came from. Some of that material may be public. Some may be appropriate only for a defined group. A map that looks harmless at a small scale can sit on top of source data that is much more sensitive.

That means an AI workflow for GIS should follow the spatial data as carefully as it follows documents. If a practitioner uploads a GeoPackage, spreadsheet of coordinates, field report or GIS project to an external AI service, the relevant question is what parts of that material leave the organisation and what the service can retain or process. Where the work concerns sensitive locations, a safer architecture may keep the authoritative spatial layers inside QGIS, ArcGIS or a local spatial database while AI works only with approved text, generalised data or synthetic examples.

Local AI opens a particularly useful middle ground for mapping. A local model can help search GIS metadata, find references to an awa or ingoa wāhi across reports, explain a QGIS error, draft an expression, help structure field notes or identify candidate information for a new layer while the source documents and spatial data remain on locally controlled hardware. The AI can assist the mapping workflow without becoming the source of geographic truth. The geometry should still come from evidence, and important locations, boundaries and names should still be checked by the people responsible for the kaupapa.

Māori-controlled AI infrastructure

There is then a sixth possibility. Instead of thinking about local AI as one employee running a model on a laptop, imagine shared Māori-controlled infrastructure. Te Pā Tūwatawata is already demonstrating a related idea for storage through a Māori-owned and iwi-designed distributed storage network.

The next logical question is whether similar thinking could extend from storage into computation. Māori-controlled storage could sit alongside Māori-controlled AI servers. Different organisations could determine their own access arrangements, models could be selected according to purpose, sensitive information could remain within controlled environments, and audit, permissions, logging and retention could be determined according to the needs of the kaupapa rather than whatever happens to be built into a global consumer service.

This would not mean building a Māori equivalent of OpenAI, Google or Anthropic. It would mean controlling more of the infrastructure on which existing models operate. That is a much more achievable proposition and, potentially, a practical expression of rangatiratanga over digital infrastructure.

Draw the architecture

Before adopting any AI system, draw its architecture on one page. Do not begin with policy language. Draw the documents, the computer, the network boundary, the model, the vector database if one exists and every external service. Then put arrows wherever information moves.

For GIS, add the spatial components to that same diagram. Show where the GeoPackage, geodatabase or spatial database lives, where field data arrive, where imagery is stored, whether any map service is external, and whether coordinates or feature attributes are passed into the AI system. This immediately exposes cases where the attractive final map is not the sensitive part at all. The real issue may be the source layer beneath it.

Once that exists, ask the sovereignty questions. Who controls each component? Where does the information go? Who can access it? What gets retained? Who can change the rules? Can it be deleted? Can the system work if the internet is disconnected? Does any part of the workflow cross a jurisdictional boundary?

The discussion immediately becomes more useful. The aim should not be to find one architecture that is somehow Māori-data-sovereignty compliant for every situation. The aim should be to deliberately choose an architecture that fits the information, the authority, the consequence and the kaupapa.

A practical recommendation

Māori organisations should make a simple data-flow diagram a standard part of evaluating AI. For GIS work, make it a data-and-map-flow diagram. Include the source spatial layers, supporting documents, field information, AI components and the final map or dataset. A two-page architecture and authority statement will often reveal more than a long generic AI policy because governance people, GIS practitioners, technical staff and the people who hold authority over the information can discuss the same actual workflow.

This is the first article in a practical Māori AI series. Continue with Local AI is not a magic shield, which looks at what local processing solves and what it does not.