Does local AI keep the workflow local?

Usually only the model. "Local AI" typically means inference runs on hardware you control — it does not establish where the rest of the task's data goes. Before repeating any "data stays on site" statement about a growing operation, trace one complete task end to end: what it reads, where prompts and results are processed, what is kept afterwards, and what happens on failure.

Trace one task end to end

Take a concrete job — say a nightly growing-room summary or a batch deviation review (illustrative examples, not real installations). List where the request starts, which system retrieves the room and batch data, where prompts and results are processed, and which artefacts and logs are kept afterwards. Then list every service each tool contacts.

Data residency is about where data is physically stored and processed — a property of a specific storage or processing location, not of a whole workflow Data controls — Microsoft Learn. A local inference step can sit in the middle of a workflow whose records, alerting or monitoring are hosted elsewhere.

Check what the local tool itself does

Vendor documentation makes the distinction concrete. Ollama's FAQ states: "Ollama runs locally. We don't see your prompts or data when you run locally" — while with cloud-hosted models the vendor processes prompts and responses to provide the service Ollama FAQ. The same tool ships with cloud features (cloud models, web search) enabled by default and documents how to disable them; updates download automatically and models are pulled from the internet Ollama FAQ. The vendor's own homepage separates "nothing you run locally ever leaves your machine" from cloud models "only hosted in US, Europe and Singapore" Ollama.

So installing a local AI tool proves neither a local workflow nor a disconnected one: even the vendor lists local and hosted inference as different modes of the same product.

Where a hosted fallback processes data

If the workflow falls back to a hosted model on failure or overload, the processing location depends on the deployment type: a customer-specified geography, or Global and DataZone types, which may process prompts and responses in any geography where the model is deployed or within the specified data zone Data, privacy, and security for Models sold by Azure — Microsoft Learn. The same provider documents that prompts and completions are not stored in the model or used to train it, while stored data has its own location rules. Those are different answers to different questions — a documented fallback can still not be "local".

Keep the questions separate

For a growing operation this is also a commercial decision: room history and process records are part of how the operation is run. Decide category by category — climate telemetry, batch records, operator notes, alarm history — which may leave the site, while the arrangement is being designed. Note that data residency (where data is stored and processed) and data sovereignty (which laws apply where data sits) are different claims Data controls — Microsoft Learn.

Inference location, storage and retention, access control, licensing, update management and offline completeness each need their own evidence; none follows from the word "local".

Where MIND stands

Hosting is a project-scoped choice for MIND AIoT: "Your servers can be hosted by Manna or deployed locally on your premises" MIND AIoT platform, with implementation, licensing, hosting and support agreed for the project. We don't present that as an offline, residency, security or SLA guarantee — the same trace is how a MIND arrangement's hosting, retention and fallback get written down.

If you are about to repeat a data-location claim, run the trace first. To have the data path traced and agreed for your installation, discuss your project.

Prepared with AI assistance for Manna Insect Oy.