Ask any plant manager whether the boiler's operating profile, consumption pattern and alarm history may leak to a competitor. The answer is always the same. Then ask what happens when the same material is attached to a cloud service query — and the answer turns uncertain. That, in a nutshell, is industrial AI: a technical question with a governance question behind it.
The discussion usually turns to which model is best. That is the wrong first question. The first question is where the model runs — because that decides where the data goes, who can see it, what the analysis costs in year three, and whether it works when the network is down.
This article covers four reasons why, in an industrial environment, the model is worth running on the plant's own server, what that concretely requires from the hardware — and, honestly, where a local model loses to a cloud model.
Why industrial AI runs into the question of where the data lives
Process data is not ordinary business data. It is a precise description of how a plant is operated: what efficiency the boiler can reach, the real consumption per unit produced, where the bottleneck in the production chain sits and how often something breaks. Competitiveness can be read from it directly — and often so can the point at which the plant is vulnerable.
When material like that is used in a cloud service query, four questions follow that ought to have answers before the first query is sent:
- Where is the data processed and where does it reside? The location of the service and its subcontractor chain are not always unambiguous, and they do not stay the same across a contract period.
- Is it used to develop the model? Terms vary by service and by contract tier, and they change.
- Who can access it? The provider's own staff, subcontractors, authorities — the answer depends on the jurisdiction.
- What happens if the service ends? Analysis history, prompts and integrations are tied to a service you do not own.
None of these is an insurmountable obstacle. But each is something that has to be investigated, documented and re-checked whenever the contract terms change. A local arrangement removes the whole set of questions at once — not because it is administratively cleverer, but because no transfer takes place.
This is why industrial AI advances more slowly than office AI. The obstacle is not technical. The obstacle is that nobody wants to be the person who decided to send the plant's operating profile out of the network.
Four reasons to keep the model on the plant's own server
1. The data does not move, so it does not need protecting in transit
When the language model is a process on the same machine as the database, the material used in the analysis never leaves the server. No API key handed to an outside party, no transfer connection to secure, no question of whether the material ends up in some model's training data. This is not a setting that can be switched off by accident — it is a consequence of where the program runs.
2. The cost is known in advance
The price of a cloud model is a function of use: the more analysis, the larger the bill. That is a poor incentive precisely where more analysis is needed. A model run on your own server costs a one-off amount, and the number of queries does not change the bill. The three-year total can be calculated before a single query has been made.
3. The analysis does not stop when the network does
An industrial plant keeps running even if the office internet connection does not. If the analysis tool requires an outbound connection, it is unavailable exactly when the situation is exceptional. A local model also works in a completely closed network where the server has no route to the internet at all.
4. Each observation is traceable to the source data
An analysis is only usable once it can be verified. When the model reads the same database that holds the measurement data, every observation can be bound to a measurement point and a time range. The claim can then be checked against raw data — and the credibility of the analysis no longer depends on how well it is written.
The fourth point is in practice the one that decides whether the tool is still in use six months later. A summary written by a language model is a starting point, not proof. If an observation cannot be traced back to a measurement point, nobody dares base decisions on it — and the tool goes unused no matter how good the text looks.
What running a local model actually requires from the server
The most common misconception is that a local language model requires a server room and a row of graphics cards. For industrial analysis the requirement is considerably more modest, because there are few queries and they are short — this is not a chat service for a thousand users but a handful of analyses per day.
In practice, the sizing in DataPortia's™ AI module looks like this:
| Area | Requirement | Worth noting |
|---|---|---|
| Memory | Minimum 8 GB RAM, recommended 16–32 GB | The model reserves memory for the duration of the run. With the AI module in use, choose the upper end of the recommendation. |
| Disk | 100 GB SSD | Covers the model, the database and the time-series history. |
| Graphics card | Not in the minimum requirements | Without a separate graphics card the answer takes longer to complete, but it does complete. |
| Operating system | Windows 10/11, Windows Server 2016+, Linux (Debian, Ubuntu) | The same server as the data acquisition and the database. |
| Data source | PostgreSQL 18 + TimescaleDB | The model reads the same time-series database the measurements are stored in. |
The model itself is run with Ollama, and the available models are open ones: Qwen, Gemma, DeepSeek and Llama. The model is selected and installed during commissioning, after which the analysis works in a closed network as well. In practice this means industrial AI fits on the machine the plant already has — not on a new investment.
- 8 GB
- of RAM is the minimum requirement. That is less than an ordinary office laptop — and it is the entire hardware addition a local model needs in a typical plant installation.
Where a local model loses to a cloud model — an honest comparison
A local model is not better than a cloud model. It is different, and the difference is worth stating plainly, because a badly set expectation is the fastest way to get a tool rejected.
| Property | Local model | Cloud model |
|---|---|---|
| Location of the data | Never leaves the plant | Transferred to the provider |
| Response speed | Slower, especially without a graphics card | Fast |
| Reasoning on long questions | Coarser; the model is smaller | More precise |
| Cost model | One-off payment, no per-query charges | Based on usage |
| Operation without internet | Works | Does not work |
| General knowledge of the world | Narrower | Broader |
The choice follows from which requirement is the stricter one. If the requirement is the fastest possible answer to any question, a local model is not the right choice. If the requirement is that process data must not leave the plant, it is the only choice.
In industrial analysis the questions are, fortunately, narrow and the material is numeric: "which points deviated last week", "how did consumption develop compared with the previous period", "which alarms repeated most". A smaller model is enough for these, because the work is done by the data — not by the model's knowledge of the world.
A practical example: a process industry monthly analysis without an internet connection
Process plant: the same monthly analysis with two different architectures
Practical example
Cloud-based analysis
- The month's measurement data was exported as a file to an analysis service
- The export required a privacy assessment and internal approval every time
- In practice the analysis was done once a month, because the process was heavy
- Cost grew with the size of the material
- The production network server had no route out — the export was done by hand
- An observation could not be opened up into the source data
Local model on the same server
- The analysis is started from the very view where the data already is
- No export, no approval round, no files in motion
- The analysis is run weekly, because it does not cost extra
- The server is disconnected from the internet — the analysis works anyway
- The answer takes longer, typically tens of seconds
- Every observation is bound to a measurement point and a time range
The decisive difference is not the quality of the analysis but its frequency. When the marginal cost and the administrative friction of one analysis both drop to zero, analysis stops being a project and becomes a habit. A review done once a month finds a deviation with an average delay of two weeks; done weekly it finds the same deviation in three days — with the same model and the same data.
The practical analysis types are the same regardless of where the model runs: anomaly detection, a forecast from measured history, a comparison of consumption and operating practices between periods, and a structured summary of the observations. On top of that, a free-form question about the material can be asked in ordinary language. In DataPortia's AI module these are a 499 € add-on on top of the base product, and there is no per-query charge.
Summary: industrial AI is an architecture choice, not a model choice
Models change every year. Where the model runs is a decision that outlasts any individual model — and it is also the only one of these decisions that is hard to reverse afterwards.
The key points:
- The first question is location, not model. It settles data control, the cost model and availability in one go.
- The hardware requirement is more modest than assumed. 8 GB RAM at minimum, 16–32 GB recommended, no separate graphics card.
- A local model is slower and coarser. In industrial analysis that is enough, because the questions are narrow and the work is done by the data.
- Traceability decides adoption. An observation that cannot be checked against a measurement point does not turn into a decision.
- Frequency beats sharpness. A mediocre analysis run weekly finds the deviation before an excellent one run monthly.
When the data acquisition, the database and the model are on the same server, analysis becomes part of daily work rather than a separate project. Try DataPortia free for 30 days: the trial includes the AI module and every other feature apart from the HA add-on, and commits you to nothing. The model runs on your server and on your data, so the assessment does not have to rest on a promise.