Local AI off the cloud: deploying an LLM or LMM on site

When people talk about artificial intelligence, the conversation is almost always about the model: which one performs best, which one understands an instruction most reliably. In an industrial setting, the decisive question lies elsewhere. It is not "which model" but "where does it run". The very same tool, depending on whether it executes in a vendor's cloud or on your own infrastructure, raises entirely different concerns around confidentiality, dependence and security. The choice of place comes before the choice of technology.

This article explains what a local, off-cloud AI actually means on an industrial site: what it can do, what it genuinely automates, and the real constraints you have to accept in order to deploy it.

What "on-premise" actually means

In a cloud service, your data travels to the model: it leaves your site, is processed on remote servers, and the answer comes back. On-premise, the logic is reversed: the model comes to the data. It is installed on a machine you control, inside your own perimeter, and nothing it processes ever leaves your walls.

This reversal has three direct consequences. Confidentiality is preserved by design, since no data passes through a third party. The separation between your office IT and your industrial network stays intact, because no outbound flow is needed for the tool to work. And availability no longer depends on a subscription or a connection: the tool keeps working even if the vendor changes its policy or disappears. These three points are not sales arguments, they are the answers to the most concrete risks of AI in industry.

LLM and LMM: reading text, and reading the rest

A large language model, or LLM, works on text. It is the one that reads a report, understands an instruction, drafts a summary. In maintenance and inspection, the raw material is precisely textual and unstructured: contractor reports, work write-ups, manuals, emails. A local LLM can pull out what matters and reshape it.

But a significant part of the industrial reality is not text. An isometric drawing, a photo of a corroded branch connection, a corrosion mapping, a hand-annotated reading: these documents carry information that a purely text-based model simply ignores. This is where the multimodal model, or LMM, comes in, able to read both text and image. On the ground, the difference is far from theoretical: it is the gap between a tool that understands only half of your documents and one that understands all of them.

Choosing between the two is not a matter of fashion. It depends on your documents. A department that only handles text reports has no need for a multimodal model; an inspection function that lives on photos and drawings certainly does.

The tasks it genuinely automates

Staying on-premise does not mean settling for a crippled tool. Here is what a local AI takes on, along with the pain it removes.

It re-keys what nobody wants to re-key. A scanned inspection report in PDF format, where the condition monitoring locations are labelled with a coding scheme that is not the one in your CMMS: it extracts the CML references, the readings and the due dates, and files them in a usable form. This is the job everyone puts off, with the result that inspection history ends up scattered across a string of successive contractors. The topic is covered in detail in OCR or AI for technical documents.

It finds things in a large body of history. Across a fleet of several hundred items of equipment, tracking down every asset that has shown the same damage mechanism, or every location where the wall thickness has dropped faster than expected, is the difference between half a day of digging and an immediate answer.

It connects scattered pieces of information. The same anomaly flagged in three different reports, by three different contractors, worded three different ways, which no one would ever have linked without having read them all on the same day.

It drafts a first version. A structured work write-up built from guided fields, which a technician corrects rather than writing from scratch. The gain is not to write in their place, it is to start from a page that is already filled in.

These tasks have one thing in common: they are repetitive, time-consuming and add no intellectual value, yet they demand rigour. That is exactly the scope where automation frees up time, including for complex cross-referencing that no spreadsheet could ever handle, without the tool ever deciding in place of the human.

"Custom-built": trained on your data, without sharing it

A generic model knows neither your fleet, nor your vocabulary, nor your reference documents. It does not know that "drum 201" and "B-201" refer to the same item of equipment, nor that "CUI" means corrosion under insulation, nor how your reports are structured. So it stays approximate exactly where precision counts.

A custom-built tool is fine-tuned on your own documents. It learns how you name equipment, how you word an observation, how you classify a defect, from your real reports. On-premise, this work is done without those documents ever leaving your infrastructure: that is the difference between training a model in your own environment, on your data, and sending them off to feed a third party's model. The first approach strengthens your control; the second gives it away.

It is this combination, local and custom-built, that turns a tool into something genuinely useful in the plant rather than vaguely impressive in a demo.

The real constraints, stated plainly

To pretend that on-premise is a solution with no trade-offs would be dishonest, and at odds with the spirit of responsible AI.

A model installed on site needs suitable hardware: running a model locally carries an infrastructure cost that has to be put on the table from the outset, and sized against real usage rather than stated ambition.

A model is not a piece of software you install and forget. It requires upkeep: updates, monitoring of its answers, correction when it drifts. A tool left to its own devices degrades quietly.

Fine-tuning on your data assumes that data is of good quality. A model trained on faulty history learns the errors, and repeats them with confidence. The local AI project often begins with a data project.

Finally, none of these choices removes the need for human oversight. On-premise protects the data and the autonomy; it does not replace judgement. A local AI is still an AI that someone keeps in check.

Local does not mean cut off from the world

One objection comes up often: does deploying on-premise mean giving up the rapid progress of the models, and ending up with a frozen tool while the cloud moves on? The fear is legitimate; the answer is no.

A model installed on site is updated, like any piece of software you keep under control. You choose when to adopt a new version, after testing it on your own cases, rather than having it forced on you overnight because a vendor changed its service. On-premise does not freeze the tool: it makes you the owner of how it evolves. That is a difference of governance, not of capability.

In the same way, local does not mean amateur. The open models deployed on site today reach, for the tasks that matter in industry (reading, extracting, finding, drafting a first version), a level that is more than sufficient. The point is not to compete with the biggest model on the market on general-purpose uses: it is to handle your own documents extremely well, without ever exposing them.

What a deployment actually looks like

A local deployment is not just about installing software. It follows a handful of steps, and each one has its traps.

It all starts with a precise task, not with the technology. You pick a use that genuinely costs time and whose data already exists: re-keying inspection reports, for example, rather than a vague ambition of "augmented intelligence". A narrow, useful scope beats a broad, hazy project.

Next comes the state of the data, the step everyone underestimates. Before training or fine-tuning a model, you need to know where the documents are, in what condition, and whether they are usable. History scattered across several contractors, references that change from one report to the next, poor-quality scans: all of these are jobs to be settled before the AI, not during it.

Then comes sizing. Running a model on-premise assumes a machine matched to real usage. You calibrate against the volume to be processed and the responsiveness expected, without over-sizing on principle or cutting corners for false economy.

Finally, the model is fine-tuned, tested and put in the hands of users, on a limited scope, with fast feedback. You correct what goes wrong, you check that the outputs remain traceable, and you only scale up once the tool has genuinely been adopted on the ground. A local deployment is no more complicated than a cloud project; it simply shifts the effort to where it creates lasting value: in your own environment, on your data.

Cloud or local: how to decide

Not everything justifies a local deployment, and it would be dogmatic to claim otherwise. The decision rule is simple: the more sensitive the data being processed, the stronger the case for on-premise.

A task that touches only public or trivial information can go through a cloud service without difficulty. As soon as inspection reports, process parameters, failure history or documents describing the real state of your installations come into play, the question changes in nature: it is no longer "is this convenient", but "am I prepared for this data to leave my site". For a major-hazard site, a food and beverage plant or a pharmaceutical unit, the answer is almost always no.

Deploying a local, off-cloud, custom-built AI is therefore not a technical preference. It is the expression of a requirement: keeping control of what makes an industrial site valuable and safe. The rest, the choice of model, the way it is fine-tuned, the computing power required, are engineering questions that arise once that course is set.

Once that course is held, AI stops being a bet on a vendor and becomes what it should always be in industry: a tool you own, on data you hand over to no one, serving tasks your teams already master. That is where usefulness and responsibility meet.