The real risks of AI in industry, and why local deployment reduces them

Artificial intelligence is sold on its benefits: time saved, historical records finally usable, better-prepared decisions. Those benefits are real. But a plant director does not buy a promise, they weigh a risk, and on that ground the sales pitch suddenly goes very quiet. The risks of AI in an industrial environment are real, they are specific, and most of them do not come from the technology itself: they come from the way it is deployed, and above all from where the data ends up.

This article names them one by one, with what they actually produce on the ground, without dramatising or downplaying.

The risk of data escaping

This is the first, and the most underestimated. Most consumer AI services process data by sending it to a vendor's servers. To draft an email, that has no consequence. For an industrial site, it is a transfer of sensitive material outside your walls.

What leaves is not trivial. In chemicals and petrochemicals, an inspection report contains the wall thickness readings, the corrosion loops and the damage mechanisms of a plant: in other words, the map of its weak points. In food and beverage processing, a clean-in-place sequence is as much a matter of know-how as of food safety. In pharmaceuticals, a qualified process parameter touches the most tightly regulated part of the site. Aggregated, this information describes your production assets better than a competitor ever could.

And the risk does not go away with 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 meant to protect. Where these leaks really come from, and how to frame them, is covered in AI data leaks come from your teams and your contractors.

The risk of the invisible error

A generative AI can produce a wrong answer with the same confidence as a correct one. This is called a hallucination. In an ordinary conversation, it does not matter. On a piece of technical data, it is a time bomb.

Picture an assistant that, in summarising a report, gives back a remaining wall thickness slightly different from the one measured, or attaches a finding to the wrong equipment tag. Nobody notices, because the output is clean and plausible. The wrong value enters a historical record, becomes the basis for a corrosion rate calculation, then for a reinspection date. The error is not visible at the moment it is made: it becomes visible, possibly, the day the equipment is inspected later than it should have been.

That is why the boundary between what an AI prepares and what it decides is not a precaution of principle: it is the protection against the invisible error. An AI that does not show where each piece of information comes from cannot be used to decide, because you cannot verify what you cannot trace back.

The risk of dependence

A tool rented in the cloud is never quite your own. The vendor can change its terms, raise its prices, alter its model, restrict a use case, or disappear. The day that happens, you find out what your autonomy is really worth: a workflow built around a service you do not control stops when it stops.

This risk has a name well known to managers who have lived through a forced CMMS migration: vendor lock-in. Your data, your historical records, your automations end up trapped in a format or a platform that is expensive to leave. The question to ask before you start is not only "does it work", but "what still belongs to me if the vendor walks away". It is one of the questions a serious business case has to settle.

The risk to network security

Every new connection between your information system and the outside world is one more door. A poorly integrated cloud AI tool can become a bridge between your office IT and your industrial network, precisely where the rule is to keep them apart. The separation between business IT and operational IT is not a specialist's whim: it is what stops an incident on an office workstation from reaching a line controller.

The risk is not theoretical for sites where availability and safety come first. Adding AI without asking where the data flows go, and what the tool has access to, amounts to drilling through a partition without looking at what is on the other side.

The human risk, over-reliance

This one is more discreet, and often the most costly. A tool that gives fluent answers inspires confidence, and that confidence quickly turns into the habit of no longer checking. The day the tool gets it wrong, the error slips through because nobody really controls it any more.

In maintenance and inspection, a signature commits an accountability that cannot be delegated to a machine. A tool that claims to decide on its own does not save time: it shifts onto whoever signs an accountability they no longer have the means to bear, having failed to keep a grip on the reasoning. Good practice reverses the logic: the AI prepares, proposes, flags, and the human keeps the decision and the verification.

The risk of non-compliance

The framework is tightening. The European regulation on artificial intelligence classes uses according to their level of risk and requires, for the most sensitive, documentation, human oversight and robustness. The general data protection regulation applies as soon as a piece of personal data enters the scope, an operator's name in a report for example. Deploying a tool without knowing where the data goes, or who decides, means exposing yourself to being unable to answer the day the question is asked.

These texts are cited by their subject, never by an article number or a threshold you have not verified: an invented obligation discredits you as much as a false figure.

The risk of the stillborn project

There is a risk that gets little attention because it is not spectacular: the project that never produces anything. In industry, most AI initiatives do not fail on the technology, they fail on the implementation.

The scenario is familiar. A tool is chosen on a flattering demo, without starting from a specific operational need. It then turns out that the data it was supposed to work on is scattered, poorly recorded, sometimes locked inside the spreadsheet of a technician who has retired. The field teams, who were not involved, see yet another tool imposed on them, and do not use it. A few months later the pilot is buried, and the conclusion drawn is wrong: "AI doesn't work here". It is not the AI that failed, it is the project that was launched back to front.

This risk is prevented upstream: start from a real task that costs time, check that the data exists and is usable, involve those who will use the tool, and deploy small before scaling up. That is the whole point of change management on an industrial AI project and of a first deployment run over ninety days.

The risk of the black box

One last risk, more insidious: a tool that produces conclusions without anyone being able to explain how it reaches them. In industry, a decision has to be justified. In front of an auditor, in front of management, in front of an authority, you have to be able to say why a given piece of equipment was kept in service, on what data, following what reasoning.

A model that answers without showing its sources turns every result into a gamble. If nobody can trace back from the conclusion to the original reading, the tool is not auditable, and what is not auditable has no place in a decision chain where traceability is the rule. The risk is not only being wrong: it is being unable to demonstrate that you were right. An AI that is useful in industry is one whose every statement you can verify, not an oracle you take on trust.

The risk of costs spiralling

A cloud service is billed by usage, and that bill has an unfortunate tendency to grow with adoption. What looked modest on a pilot becomes a significant budget line once the tool is deployed across the whole site: every document processed, every query, adds to the meter. The real cost of a tool cannot be read from its entry price, but from what it will cost the day it is genuinely used.

A local deployment, by contrast, concentrates the investment up front, in hardware and setup, then stabilises. Neither one is free, and pretending otherwise would be dishonest. But the cost structure is not the same, and a serious business case has to compare not two entry prices, but two trajectories over time. The risk here is not paying: it is paying without having anticipated it.

The common root, and the answer

Go back over these risks. Most of them, the leak, the dependence, the security gap, the black box, part of the non-compliance, and even the invisible error when you cannot trace the source, come down to the same point: the data and the model are outside your control.

That is what explains why the answer is not to add a layer of precaution after the fact, but to change the architecture. A tool that is bespoke, trained and deployed locally, off cloud, keeps the data on site, depends on no external service, and makes it possible to trace what it produces. It does not bring the risk to zero, no tool does, but it eliminates the ones that arise from having handed the essentials to a third party. This is exactly the logic of a responsible AI designed in from the outset: risks are not corrected, they are designed out upstream.

A plant director is not looking for the tool that impresses most in a demo, but for the one they will be able to account for in six months, in front of an auditor as much as in front of their management. That kind of tool cannot be salvaged at the end of a project: it is decided at the start, in the choice of where your data lives and who, in the end, keeps control of it.