How GeoAI works · Part 3

Nothing leaves the building

Municipal geodata points at people’s homes. Why GeoAI runs entirely on the municipality’s own hardware, what that costs, and why a smaller model made the design better.

Soheil SetayeshiPrincipal Software Engineer

If you work with municipal geodata, you know why. Your database isn’t just trees and lampposts. It holds property values, energy use per address, building dossiers, permits, and registers that point straight at people’s homes. Much of it is personal data, and all of it is the municipality’s responsibility. “We send it to a model in another country and get an answer back” is not a sentence a municipality can sign.

So we made a decision early, before anything else: GeoAI runs entirely on the municipality’s own hardware. Not mostly. Entirely.

What “on-premise” means here

Every part of the system runs inside your own environment:

It starts at a single GPU workstation. No cluster, no cloud account, no third party in the path between a question and your data.

The honest part: small models are harder

There is a trade-off, and it would be dishonest not to name it. The models that fit on one workstation are much smaller than the giant ones behind cloud chat services. They are less fluent, and they make more mistakes of judgement.

That constraint shaped the whole design. If the model can’t be trusted with everything, it shouldn’t do everything. So GeoAI splits the work:

• The model judges meaning: what the question asks, which dataset fits, whether a register provides what’s needed.
• Code handles facts: which columns exist, which values occur, where a dataset has data, how a place maps to its official boundary, and the SQL itself.

We deliberately develop against the smaller model. A bigger model hides mistakes; a smaller one shows you where the design is weak. If a question works on the small model, it works on the big one.

A bigger model hides design mistakes. A smaller one shows you exactly where they are.

Nobody changes your model overnight

There’s a benefit to local models that has nothing to do with privacy: nothing changes unless you change it.

A cloud model can be updated by its provider on a Tuesday, and your answers shift on Wednesday without a single line of your code changing. For a system whose answers end up in council letters, that’s not acceptable. With local models, the model is a file you chose, and it stays that file.

We learned to take this seriously. Once, an automatic update of the model server itself quietly made every request much slower on one of our machines. Nothing in our code had changed. Since then everything is pinned: model, model server, settings. An update is a decision, tested like any other change.

What still touches the internet

In the spirit of the previous post: here is the complete list of what reaches outside, today.

• Web fonts. The chat, the Stage and the reference pages load their typefaces from a public font service. Without it they fall back to system fonts.
• The basemap. The Stage, our animated demo view, draws its map over the public Dutch national basemap. Without it the answers still draw, just without a background map.
• Map libraries, as a fallback. The Stage ships its own copies of its map libraries and only fetches them from a public CDN if those copies are missing.

None of these carry your questions or your data; they are public files your browser downloads. For an installation that has to run fully offline, all of them can be hosted locally.

One installation, your territory

Nothing about a municipality is written into the code. The territory an installation covers is a configured list of official municipality codes. That list drives which places are recognised, how national datasets are clipped to your area, and where the map starts. A new municipality needs its data loaded and its codes set, not a new version of the software.