Why responsible industrial AI is local, bespoke and off the cloud

Picture an ordinary scene. A contractor hands back the report from its inspection campaign: a scanned PDF, forty pages, tables of wall thickness measurements tagged with a coding scheme that is not yours. To prepare the next turnaround, someone has to dig out the wall thickness of a nozzle recorded during the previous campaign, compare it, and work out a corrosion rate. The reflex today is to paste the contents into an artificial intelligence tool. And that is exactly where everything is decided: this document describes the real condition of your pressure equipment, and it has just left your site for a server you know nothing about.

"Responsible and ethical AI" has become a slogan stuck at the bottom of a brochure, next to a logo. In industry that is not enough, and it shows very quickly. The question is not whether AI is "ethical" in the abstract, but what it does with your data, who keeps control, and who answers when it gets things wrong. This article starts there: the concrete stakes of AI in an industrial environment, and what a responsible approach changes in the very design of the tool.

The stakes begin with sensitive data

An industrial site produces data that nobody on the outside should ever see, and which is far more revealing than people assume once it is aggregated.

In chemicals and petrochemicals, the wall thickness measurements, corrosion loops and damage mechanisms across a fleet map out the real condition of the installations and, above all, their weak points: where the wall is thinning, where a shutdown is approaching. In food and beverage, the clean-in-place sequences, their temperatures and durations are as much a matter of know-how as of food safety. In pharmaceuticals, a qualified process parameter or an extract from a batch record touches on the most tightly controlled part of the plant. Add failure histories, work instructions, drawings and audit reports: aggregated, they describe your production capability better than any competitor ever could.

Most consumer AI services process your data by sending it to a provider's servers. For drafting an email, that carries no consequence. For a major-hazard Seveso site, a food processing plant or a pharmaceutical unit, it is a transfer of sensitive material beyond your walls, with all the questions that come with it: where is that data stored, who can access it, how long is it kept, and what becomes of it if the provider changes its policy. These are exactly the questions a serious AI project has to settle before it starts.

And the problem is not solved by a simple ban. Where the IT department blocks cloud tools on workstations connected to the industrial network, the teams do not stop working: a technician copies an extract of a report into a consumer tool from their phone, convinced they are saving time. This is Shadow AI, the AI that comes in through the back door, unchecked, carrying off precisely the data you wanted to keep. Banning without offering a controlled alternative does not remove the risk: it makes it invisible.

What "responsible" means, without the slogan

Responsible AI in industry comes down to three verifiable requirements.

A human keeps the decision. AI reads, extracts, classifies, retrieves and flags. It does not requalify a piece of equipment, does not pronounce a fitness-for-service, does not decide to keep an asset in service. This boundary is not a temporary caution while the technology catches up: it is the structure of the work, and it is the first thing an auditor checks. The subject is treated in detail in the line between what AI prepares and what a human decides.

Everything is traceable. An AI result is only worth something if you can trace it back to its source: which document this information came from, which measurement was read, on what date. An AI that produces a conclusion nobody can verify is not a working tool, it is a gamble. In inspection as in quality, traceability is not a comfort, it is the condition for signing off.

The data stays under control. This is where the talk meets the engineering. You cannot claim responsible AI while shipping production data to a third-party cloud. The two contradict each other.

Why bespoke and off-cloud is the concrete answer

From these requirements follows a consequence that few players own up to, because it is harder to sell than a subscription: genuinely responsible AI in industry is most often a bespoke tool, deployed off the cloud.

Off the cloud means installed on your own infrastructure, where the data is processed on site and does not leave it. The model comes to the data, not the other way round. The separation between your office IT and your industrial network is preserved, and no dependency on an outside service conditions the availability of the tool.

Bespoke, because a generic model knows neither your fleet, nor your vocabulary, nor your reference standards. A tool built for your context, trained or fine-tuned on your own documents without sharing them, learns your way of naming equipment, structuring a report, characterising a defect. It becomes useful exactly where a universal tool stays approximate.

This is not a technical refinement; it is the direct translation of the three requirements above. A local, bespoke tool is what makes it possible, in practice, to keep the data under control and the decision with a human. Ethics is not an extra bolted on afterwards: it is written into the architecture of the tool.

What a local, bespoke tool actually does

Staying local does not mean settling for a hobbled model. A large language model installed on site can read an inspection report in PDF format, extract the equipment tags, the measurements and the due dates, and file them in a usable form: this is the re-keying work that nobody wants to do and everybody puts off, leaving histories scattered across several contractors. It can find, in a fleet of several hundred items of equipment, every one that has shown the same damage mechanism, where a person would have spent half a day digging. It can propose a first draft of a report from guided fields, which a technician corrects rather than writing from scratch.

When the data is more than text, we are talking about multimodal models: they also read a photo of a defect, a drawing, a corrosion map. A hand-annotated survey, an image of a corroded nozzle, an isometric: all material that text alone ignores and that often makes the difference in the field.

These tasks have one thing in common: repetitive, time-consuming, with no intellectual added value, yet demanding in rigour. This is exactly the ground where local AI frees up time without ever deciding in a human's place: from document automation to complex cross-checks no spreadsheet allows. "Trained on your documents" means fine-tuned on your own reports and your vocabulary: the model learns that "drum 201" and "B-201" refer to the same equipment, that "CUI" means corrosion under insulation, without those documents ever leaving your infrastructure. A generic model, by contrast, is blind to your tags and reference standards, and stays approximate where yours becomes useful. How to deploy such a model in practice is set out in Local off-cloud AI: deploying an LLM or an LMM on site.

The frameworks that structure the approach

Three bodies of rules frame the subject today, and it is worth knowing them for what they impose, not for brandishing them.

The European regulation on artificial intelligence classifies uses by their level of risk and imposes, for the most sensitive uses, obligations of documentation, human oversight and robustness. The logic is close to one industry already knows: the more serious the consequence of an error, the stronger the control has to be.

The international standard for artificial intelligence management offers a governance framework: how an organisation decides on, documents and monitors its use of AI, in the same way it does for quality or safety.

The general data protection regulation applies as soon as personal data enters the scope: an operator's name in a report, for example.

The reading rule is simple: these texts are cited by their object, never by an article number or a figure you have not verified. An invented obligation discredits you as much as a false figure.

The five questions to ask before any project

A decision-maker does not need to be an AI expert to make the call. It is enough to ask five questions, and to demand clear answers.

Where is my data processed, and does it leave the site? If the answer is vague, or if it involves a third-party cloud, the confidentiality issue is already there. Can I trace each result back to its source? A tool that does not show where information comes from cannot be used to decide. Who remains responsible for the final decision? The answer must always be: a named human, never the tool. Is the model trained on my documents, and where do they stay during and after that training? And finally, what becomes of the tool if the provider changes its policy or disappears: do I keep control?

These five questions are not technical. They are enough, though, to rule out most projects built on sand, and to recognise those that rest on a sound architecture: local, bespoke, under control.

The limits, stated plainly

Local and bespoke are no magic formula, and claiming otherwise would already be a failure of the responsibility it is meant to serve.

A model installed on site requires suitable hardware, updates and monitoring over time: a model you install then forget degrades in silence. Training on your data assumes that data is of sufficient quality: a model fine-tuned on faulty histories learns the errors. And none of these choices removes the need for human oversight: responsible AI remains AI that someone controls.

These constraints are real. They do not call the approach into question; they are part of it. Responsible AI in industry is not a technology you buy, it is a way of designing and operating a tool where control of sensitive data and the place of the human are not options, but the starting point. That choice is made at the outset, in deciding where your data is allowed to live and who ultimately keeps control of it, and it cannot be retrofitted once the tool is already in place.

This way of designing shows up in very concrete subjects: in a digital twin built around a decision rather than to impress, where the tool's confidence never exceeds the quality of its data, and in using AI for workplace safety, where surfacing the signals without surveilling people translates exactly the same requirement.