Local AI for Māori GIS: keeping documents, models and maps under your control
Local AI has become much more useful in 2026. A normal desktop computer can now run a capable language model, search a collection of PDFs, extract structured information, help write Python or QGIS expressions and keep the working material on the machine. That makes it particularly interesting for Māori GIS, where the question is often not only whether AI can do the work, but where the information goes while it is doing it.
The most useful local workflow is not a private version of ChatGPT that somehow knows everything about Māori GIS. It is more modest and, for research, more useful. Give the system documents you are allowed to work with. Ask it to find candidate information. Keep the original wording and source reference. Have a person review the result. Check any geographic match against an appropriate source. Only then let the reviewed information become GIS data.
That distinction matters. A language model is quite capable of reading a reference to an old kāinga, deciding what modern place it probably means and supplying coordinates that look perfectly respectable. A GIS will then plot those coordinates without showing the slightest concern about whether they were invented. Local AI changes where the mistake was made. It does not make the mistake authoritative.
The practical question is therefore: what can we now run locally, what is genuinely offline, what appears promising for te reo Māori, and where should AI stop before the map begins?
Local means more than an app on your desktop
The word local has become rather elastic. An application can be installed on a Windows computer and still send every prompt to a hosted model. It can run the language model locally but use a cloud embedding service to index documents. It can keep the model local and then call an internet search tool. It can have an offline switch while retaining separately configured external APIs.
For Māori GIS work, it is better to think of local AI as an architecture rather than a product label. If the kaupapa requires local processing, the language model, document extraction, embeddings, vector database and any other processing of the working material need to remain inside the boundary you have chosen. Software updates and model downloads may require an internet connection beforehand. The actual research workflow should be capable of continuing after that connection is removed.
LM Studio is unusually clear about this. Its current documentation states that downloaded models, document chat and its local server can operate entirely offline, with document processing performed on the device. Ollama also states that prompts and responses are not visible to Ollama when models are run locally. There is now an important qualification: Ollama also offers cloud models. Those are deliberately offloaded to its cloud service and should not be confused with local inference simply because they are launched through the same application. Ollama provides a local-only setting for disabling its cloud features.
Open WebUI is another good example of why configuration matters. Its offline documentation notes that OFFLINE_MODE=true does not itself create an air gap. Embedding models must already be available locally, other settings are needed to prevent automatic Hugging Face access, and external model APIs can still be configured. A genuinely air-gapped environment is achieved by the network boundary, not by a reassuring toggle in a web interface.
The simple test remains one of the best. Download the required model and embedding files, add a public document, confirm that the workflow works, disconnect Wi-Fi or the network cable, and ask new questions about the document. If it fails, something in the chain is still depending on an external service. This is a much better test than assuming that private, local and offline all mean the same thing.
The Local AI and Māori GIS guide on this site is built around that testable definition of local processing.
Why it matters for Māori GIS
There is a strong practical reason for keeping some AI work local. GIS projects can bring together Māori land information, historical reports, unpublished research, environmental observations, oral history, whakapapa, place names and spatial data that should not simply be uploaded to whichever AI service happens to be convenient that week. Keeping the working material on a computer or within an organisation's own network can remove one significant path by which that material leaves local control.
It is important not to turn that technical fact into a claim that local AI automatically satisfies Māori data sovereignty. Te Mana Raraunga describes Māori Data Sovereignty in terms of Māori rights and interests in data and Māori governance of Māori data. Its principles include control, provenance and context, obligations between individuals and groups, collective benefit, respect, consent and kaitiakitanga. Decisions about physical and virtual storage are part of that picture, but only part of it.
A local model can still be used inappropriately. A person may have a copy of a file without having authority to process it for a new purpose. An embedding database can contain derived representations of sensitive material long after somebody has forgotten that it exists. A model may make new inferences by combining several sources. Information can remain on one laptop while the wider questions of permission, whakapapa, tikanga, access and future use remain unresolved.
Te Hiku Media's Papa Reo work provides another useful perspective. Papa Reo was developed around Indigenous control of language data and the principle that language communities should retain sovereignty over their data and benefit from the technology created from it. Te Hiku Media has also been direct in its criticism of Indigenous-language AI built from data whose provenance and authority are unclear. That issue does not disappear because a downloaded model is open weight or because inference now occurs on your own computer. Model provenance, training-data practices and who benefits from the technology remain valid questions.
I am writing here as a GIS practitioner and trainer, not as someone claiming authority over tikanga or Māori data governance. The technical recommendation is simply that local processing can provide a useful additional control. Decisions about whether particular information should be processed, who can see it and what may be derived from it remain with the people who hold the appropriate authority for the kaupapa.
The useful job is not chatting
The most interesting use of local AI for Māori GIS is not replacing a cloud chatbot with a smaller chatbot. It is searching local evidence.
Consider a folder containing several hundred pages of public Waitangi Tribunal research reports. A researcher may want every reference to pā, kāinga, awa, maunga, marae, tracks, land blocks and older place names in a particular district. Ordinary keyword searching helps when you already know the words. It is less useful when a place has several spellings, when the wording changes between documents, or when the relevant passage describes a feature without using the exact term you expected.
A local document system can index the reports and retrieve passages that appear relevant to a question. This is usually called retrieval-augmented generation, or RAG. The important point is that the AI does not absorb the entire archive and become an authority on it. The software breaks documents into pieces, creates numerical representations called embeddings, retrieves pieces that appear relevant to the question, and gives those pieces to the language model as evidence for the answer.
That architecture is useful because the source can remain more important than the model. A good extraction request might ask for the place name exactly as written, document title, page, nearby wording, feature type if stated, possible spelling variants and a review status. It should specifically forbid the model from assigning coordinates or silently modernising names.
A practical working table can look like this:
| Field | Purpose |
|---|---|
source_document | The report, file or record that contains the reference |
source_page | Page or other source locator |
name_as_written | Exact source spelling, including macrons where present |
source_context | Short relevant passage or faithful summary |
candidate_type | Possible pā, kāinga, awa, maunga, block, route or other feature |
possible_match | A later geographic match, if one is proposed |
match_source | Gazetteer, local dataset, historical map or other matching evidence |
match_status | Unreviewed, possible, confirmed, ambiguous or no match |
coordinate_source | The source of any coordinates, never the language model |
review_status | Whether a person has checked the record |
The sequence is deliberately conservative:
local documents
↓
OCR if required
↓
local document index and retrieval
↓
AI extracts candidate information
↓
human review of the original source
↓
Gazetteer, historical or locally held geographic checking
↓
reviewed coordinates from an identified source
↓
QGIS, ArcGIS or Google Earth
The AI is doing work that generative models are reasonably good at: finding, comparing and structuring language. The GIS and geographic reference sources do the work they are good at: representing identified places. The person doing the research decides whether the connection between those two things is defensible.
A name not appearing in the New Zealand Gazetteer does not mean it is false. Historical, customary and local names may sit outside a national dataset. Equally, finding a similar Gazetteer name does not prove that two references describe the same place. The job is to retain ambiguity until there is enough evidence to resolve it.
The desktop choices in 2026
There is no need to install every local AI application. Five products cover most practical desktop and organisational use cases at present.
| Software | Best use | Local document work | Local API | Main qualification |
|---|---|---|---|---|
| AnythingLLM Desktop | Beginner document research | Strong workspace and RAG approach | Can connect to local providers | Check that the LLM, embedder and tools are all local |
| LM Studio | Downloading, comparing and serving local models | Built-in local document chat/RAG | Yes, including OpenAI-compatible local APIs | It now supports more than purely local workflows, so choose local models deliberately |
| Ollama | Local model engine for scripts and other applications | Usually paired with another interface | Yes | Cloud models now exist alongside local models |
| Open WebUI | Configurable self-hosted or internal organisational workspace | Strong knowledge-base and RAG functions | Connects to Ollama and OpenAI-compatible providers | More administration and more ways to configure external services |
| GPT4All / Jan | Straightforward local desktop alternatives | Both support local document or model workflows | Available | Useful alternatives, but less directly aligned with the document-to-GIS path used in this guide |
For a person who wants to install one thing on Windows and search a collection of reports, AnythingLLM Desktop remains the easiest starting point. It provides document-oriented workspaces and can keep the model, embedding model and LanceDB vector database local. The current MāoriGIS.nz installation guide uses it as the beginner path because the participant can get to a useful document task without first learning Docker, Python and model-serving commands.
For a GIS analyst who wants to understand exactly which model is loaded, compare quantisations, run a local API and connect the model to Python or another application, LM Studio is the stronger general desktop tool. Its local server is useful because a Python script can call a local model using an API pattern similar to hosted AI services while the text never has to leave the machine.
Ollama is excellent infrastructure. It is small, scriptable and supported by a large number of applications. It makes particular sense behind QGIS/Python workflows or Open WebUI. It is not, by itself, the document-research interface I would put in front of a first-time wānanga participant. The distinction is between the engine and the workspace.
Open WebUI is the most interesting option for an internal shared service. An iwi organisation, research team or other group could run a local model engine and Open WebUI on a workstation or internal server so several authorised users have access without sending the working documents to a public AI provider. That environment needs normal server administration, authentication, backups, model management and network controls. It is a useful organisational architecture precisely because those responsibilities remain visible rather than disappearing into a public SaaS service.
The model choice has changed
The model recommendation is more interesting than it was even a few weeks ago.
The earlier MāoriGIS.nz installation material used Qwen3 8B and 14B as practical multilingual desktop models, while explicitly warning that broad multilingual support did not amount to proven te reo Māori accuracy. There was a good reason for that warning. Qwen's published Qwen3 language list covered 119 languages and did not explicitly list Māori.
Qwen3.5 changes that. Qwen's February 2026 release expanded language and dialect coverage from 119 to 201, with a stated focus on lower-resource languages, and its published list explicitly includes Māori. The smaller Qwen3.5 models are now widely available for local use. Ollama currently lists Qwen3.5 4B at about 3.4 GB, 9B at about 6.6 GB and 27B at about 17 GB in their Q4 variants, with text and image input.
That makes Qwen3.5 9B the model I would test first for an ordinary Māori GIS desktop workflow in August 2026. The word test is intentional. Being named in a supported-language list is useful evidence, but it is not a te reo Māori benchmark, not a quality assurance process and not evidence that a general model understands iwi histories, whakapapa, tikanga or local place-name usage. The improvement is that Māori is now explicitly within the model family's stated language coverage rather than being inferred from a generic multilingual claim.
A proper Māori GIS test should include macrons, mixed English and te reo Māori, iwi and hapū names, geographic names that are also ordinary words, historical spellings, OCR corruption and instructions to leave uncertain items unresolved. The model should also be deliberately tested with a request for coordinates when the source contains none. A useful system says it cannot establish the location. A dangerous one rewards the researcher with a tidy latitude and longitude.
There are several strong comparison models. Gemma 4 12B, released by Google in June 2026, is designed to run locally on laptops with 16 GB of VRAM or unified memory and supports text, vision and audio. It is a particularly interesting model where scanned pages, diagrams or images form part of the workflow. Google describes Gemma 4 as supporting more than 140 languages, but the material reviewed for this article does not provide the same explicit Māori-language assurance as Qwen3.5. It should therefore be compared on real Māori material rather than assumed to be better because it is highly capable overall.
Ministral 3 8B is another sensible edge model. Mistral describes it as designed for local deployment with text and vision capability and a large context window. Again, the evidence reviewed here does not establish te reo Māori quality. gpt-oss-20b is worth considering on a computer with more memory when reasoning, coding and structured output matter. OpenAI states that it can run with 16 GB of memory, has a 128K context window and is available under Apache 2.0, but its model documentation also says the pre-training data were mostly English. It is therefore a useful GIS and coding model, not the first model I would select specifically for Māori-language extraction.
Model size can also mislead. Mistral Small 4, for example, has only a fraction of its parameters active for each token, but the full model is still a large deployment rather than an ordinary laptop choice. The number in the model name does not tell you whether it fits comfortably beside Windows, QGIS, a vector database and a useful context window.
The practical shortlist is therefore not one universal winner. For mixed English and te reo Māori document extraction, start by testing Qwen3.5 9B. Compare it with Gemma 4 12B if the computer can run it comfortably, particularly where multimodal input matters. Use a stronger reasoning or coding model where the task is Python, SQL, PyQGIS or complex structured transformation rather than language-sensitive historical extraction.
What the computer actually needs
Local models have become small enough to be useful on ordinary hardware, but the model download size is not the same as the memory required to run it. The runtime also needs memory for context, caches, embeddings, the operating system and whatever else is open. QGIS has not developed a habit of using no memory merely because an AI model would like some.
Quantisation is one reason these models fit. A Q4 model stores model weights at lower precision than the original model, greatly reducing the file and memory footprint. This normally gives up some quality in exchange for practicality. It does not turn a 9-billion-parameter model into a 4-billion-parameter model, and two files labelled Q4 can still behave differently depending on the quantisation method and runtime.
The following is practical guidance rather than a guarantee:
| Computer | Sensible starting point | What to expect |
|---|---|---|
| 16 GB RAM, no dedicated GPU | Qwen3.5 4B Q4; try 9B if patience and memory allow | Useful document extraction and basic assistance; CPU responses can be slow |
| 32 GB RAM | Qwen3.5 9B Q4; Gemma 4 12B where the runtime fits well | Good general local research workstation without specialist hardware |
| 32 GB RAM with 8 to 12 GB VRAM | Qwen3.5 9B, smaller multimodal models | Much better interactive speed when most weights can be offloaded to the GPU |
| 64 GB RAM or around 24 GB VRAM | Qwen3.5 27B Q4, gpt-oss-20b and other larger local models | More room for stronger models, longer context and heavier GIS work alongside them |
| Apple Silicon with 16 GB+ unified memory | Qwen3.5 9B class; Gemma 4 12B at suitable settings | Unified memory can make laptop local inference practical; leave headroom for the rest of the system |
The best model is not the largest model your computer can just barely load. A slightly smaller model that responds promptly and leaves enough memory for the document index and GIS is usually more useful than a larger model that turns every question into an opportunity to make coffee.
Te reo Māori needs its own test set
There is still a shortage of public evidence that lets us rank general local models confidently for te reo Māori GIS tasks. Standard multilingual benchmarks do not tell us whether a model will preserve a historical place name from a poor scan, distinguish a person's name from an awa, or refrain from changing a source spelling because it has seen a more common modern form elsewhere.
A small, reusable Māori GIS evaluation set would be more valuable than another generic leaderboard. It could use public material and contain expected results reviewed by people competent to judge the language and geography. Each new model could then be tested against the same material before it is recommended for a wānanga or a real research collection.
At minimum, the test should ask whether the model can preserve macrons exactly, work with mixed English and te reo Māori, retain historical spellings, distinguish names of people from names of places, identify repeated variants without merging them, extract the correct page or passage, return structured data without dropping uncertain records, and say unknown when the evidence does not establish a match. It should also include deliberately ambiguous names and deliberate OCR errors.
The same applies to the embedding model used by RAG. An excellent language model cannot answer from a passage that the retrieval system failed to find. Many lightweight embedding models were built mainly for English. For important mixed-language collections, multilingual retrieval should be tested separately from final answer quality. The current MāoriGIS.nz guide suggests Qwen3-Embedding-0.6B as a practical multilingual candidate because it is small enough for a desktop, but its published support should not be treated as a Māori-specific evaluation either.
This separation is easy to miss. A poor answer may be a language-model failure, or the right passage may never have been retrieved. A defensible test records both.
OCR can lose the place before AI sees it
Many historical sources are scanned PDFs rather than real text documents. If the source says Whakatāne and OCR produces Whakatane, that is already a change. If a faded historic name becomes a different sequence of letters altogether, the AI may have no realistic chance of recovering it correctly.
Local OCR tools such as OCRmyPDF and Tesseract can make scanned PDFs searchable without sending pages to a cloud OCR service. Newer local vision models can also help inspect individual pages. None of this removes the need to compare important findings with the page image. Māori names, macrons, uncommon vocabulary and older typefaces are exactly where apparently small OCR errors can matter most.
A useful document workflow therefore retains the original PDF alongside the extracted text. The source page remains available for review. OCR text is a searchable derivative, not a replacement for the source.
This becomes even more important with historical maps. A multimodal model may be able to read labels or describe a legend, but it should not be asked to convert what it sees into authoritative coordinates. Georeferencing, coordinate transformation and topology remain deterministic GIS jobs. A model can help identify what deserves attention. It should not quietly manufacture the geography that is missing.
Put the GIS after the review
Local AI becomes more interesting for GIS practitioners when it exposes a local API. LM Studio, Ollama and several other runtimes can do this. A Python or PyQGIS script can send local text to the model, receive structured JSON and then process the reviewed result using ordinary GIS libraries.
That architecture can look like this:
QGIS / Python
↓
local API on localhost
↓
local language model
↓
structured candidate result
↓
human or rule-based validation
↓
GeoPackage / CSV / database
↓
QGIS analysis and mapping
This is a better boundary than allowing the model to act as the GIS. Ask AI to identify candidate feature types, draft metadata, classify text, suggest QGIS expressions, write a first version of SQL or prepare structured fields. Let PROJ transform coordinates, GDAL read spatial formats, GEOS test geometry and QGIS apply the analysis. Deterministic software should continue doing the jobs where the same input is expected to produce the same geographic result.
A particularly safe coding pattern is to develop against synthetic data. If the problem is how to process a sensitive layer, the model often needs the schema and representative fake values rather than the real features. The generated code can be reviewed and tested locally, then run against the real data without ever placing that data in the AI conversation.
The local API should normally listen only on localhost unless there is a deliberate reason to provide a network service. Binding a model server to every network interface changes a private desktop service into something other machines may be able to reach. An organisational deployment should make that exposure deliberate and add authentication, firewall controls and logging appropriate to the environment.
What can go wrong
Local AI removes some risks and leaves others untouched. The most serious research failures are often not dramatic. They are plausible enough to survive into the next stage of the workflow.
| Failure | Practical control |
|---|---|
| The model invents coordinates for a historical place | Prohibit generated coordinates and require an identified coordinate source |
| A Gazetteer name is automatically assumed to be the historical place | Keep the match as possible or ambiguous until evidence is reviewed |
| Macronised names are silently changed | Preserve name_as_written and compare important results with the source page |
| OCR damages an uncommon Māori name | Retain page images and review low-confidence or important text manually |
| A person and a place share a similar name | Extract entity type as a candidate and require human review |
| RAG cites a document but not the passage that supports the claim | Open the retrieved source and check the actual wording rather than trusting the citation badge |
| Sensitive documents are deleted but embeddings remain | Treat vector databases, caches and backups as derived data that also require management |
| A desktop app is local but its model or embedder is cloud-hosted | Inspect every provider and repeat the workflow with the network disconnected |
| A small model produces fluent but weak GIS code | Test against copies, verify library versions and inspect counts, CRS and outputs |
| The model converts uncertainty into a tidy answer | Require explicit unknown, ambiguous and no_match states in the output schema |
There is a useful general rule here. AI should make unresolved evidence easier to see, not make it disappear.
Three setups worth considering
For an introductory Ngā Poutama Matawhenua wānanga, I would keep the architecture deliberately boring. Use a normal Windows 11 computer with at least 16 GB RAM, install AnythingLLM Desktop, use public reports for the demonstration, select a local model that fits the machine, keep the embedding model local, and prove the setup with the network disconnected. Qwen3.5 9B is now the first model I would put through the Māori GIS test set on a 32 GB machine. On 16 GB hardware, Qwen3.5 4B provides a simpler starting point, with 9B worth trying where memory and speed remain acceptable.
For a GIS analyst, I would use LM Studio or Ollama as the local model service and call it from Python as required. This provides access to model choice without forcing the GIS workflow into a chatbot interface. Qwen3.5 9B and Gemma 4 12B are sensible first comparisons. A machine with 64 GB RAM or a larger GPU can add Qwen3.5 27B or gpt-oss-20b when stronger reasoning or coding justifies the extra resources.
For an organisation, I would separate the service from individual desktops. A properly managed internal workstation or server can run Ollama or another local inference runtime with Open WebUI as the user interface, all within the organisation's network. Models and embedding files should be downloaded and approved in advance. External providers, web tools and cloud fallbacks should be disabled where the boundary requires that. Access, backups, logs, document retention and deletion of vector indexes should be treated as ordinary information-management responsibilities rather than left to the AI administrator to invent later.
None of these architectures should start with sensitive material. Use public documents first. Confirm where files, chats, models, embeddings and indexes are stored. Test deletion. Test backups. Disconnect the network. Ask the system questions whose answers you already know. Deliberately ask it something it cannot know and see whether it admits that.
Only after that does it make sense to decide what real information is appropriate for the system.
Where this leaves Māori GIS
Local AI is now good enough to be useful without being good enough to be trusted blindly. That is probably a healthy place for it to be.
The strongest opportunity is document-heavy work. Māori GIS practitioners often face large collections of reports, plans, historical records and research where the geographic evidence is present but dispersed. Local AI can reduce the mechanical effort of finding candidate references and turning them into a structured research register. It can help write code and expressions. It can make a private document collection searchable in a new way. It can do those things without making a public AI provider the default destination for the source material.
The map should still come later. A model can find the words Te ... in a 600-page report in seconds. It cannot decide by speed alone what authority that name carries, whether the source is correct, whether two names describe the same place or whether the resulting information should be mapped at all. Those remain research and governance decisions.
That is also why local AI should be seen as capability rather than as a magical privacy appliance. The useful part is not that an iwi or hapū can now own a small chatbot. It is that increasingly capable search, language and coding tools can operate inside an environment they control, alongside their own GIS, their own source records and their own decision-making processes.
The technology has finally become small enough to bring home. The responsibility for what becomes knowledge, data and a map never left.
Further reading
The practical installation and document workflow is available in Local AI and Māori GIS, including choosing software, installing local AI, finding ingoa wāhi, checking places and turning reviewed results into GIS data.
The broader question of selecting and managing AI systems is covered in The map is still the easy part: managing AI in Māori GIS.
Technical and kaupapa sources used for this review include Te Mana Raraunga's Principles of Māori Data Sovereignty, Papa Reo, Qwen3.5, LM Studio offline operation, Ollama privacy and local-only configuration, Open WebUI offline guidance, Gemma 4 12B, gpt-oss and Ministral 3 8B.
Research checked: 30 August 2026