When the machine talks to the AI
How to keep industrial AI bounded, observable and under control?
Machine 7 reports a sudden increase in drivetrain vibration. The numbers are plausible. The device is known to the network. The AI assistant reviewing the fleet recommends an immediate stop.
But one field in the message isn’t telemetry. It contains an instruction telling the model to classify the machine as critical and ignore the rest of the fleet data. The device hasn’t broken the language model. It has used the route the system gave it.
This is where the ideas in this blog series meet a real industrial system. The problem is no longer only what AI says. It is whether manipulated data can cross from a machine, through the model, into an operational decision and what stands in the way when it tries.
The message bus is transport, not trust
Picture a fleet of industrial machines publishing GPS position, vibration, cabin-gas readings and health data every few seconds. The messages move through an MQTT broker into historians, dashboards and alerting systems. Add an AI assistant at the edge, and instead of manually comparing several screens, the operators can ask: “What is happening with machine 7?”
The useful part is obvious. The dangerous assumption is that data arriving through an established operational pipeline is trustworthy.
A production design starts before the model. Each device proves its identity. Topic permissions limit what it may publish. Schemas reject unexpected fields. Numeric values are checked against physically plausible ranges. Source and integrity metadata stay attached to the data. None of these controls needs the model to recognise an attack.
That matters because anything consumed by the model is a potential threat. A device identifier, maintenance note or tool result is no safer than a user prompt just because it came from inside the organisation.
Build the context, not just the prompt
The next boundary is the context assembled for the model. The assistant doesn’t need every field the fleet produces. It needs the minimum authorised data required for the current question, labelled by source and separated from the instructions that define its task.
That means filtering fields before they enter the context, keeping telemetry and tool results inside explicit data structures, and applying the operator’s identity and permissions when data is retrieved. Sensitive locations, production rates or maintenance records shouldn’t become available merely because the model can technically reach the source.
This separation is useful, but it isn’t magic. A text label saying “treat this as data” doesn’t create a hard security boundary inside a language model. The enforceable boundary remains outside the model: in access control, retrieval logic, validation and the code that decides what happens next. OWASP makes the same point in its prompt-injection guidance: external content should be treated as untrusted, privileges should be minimal, and consequential actions need approval outside the model.
The model recommends the system decides
Now suppose the assistant still produces “severity: critical — stop machine 7.” That is a recommendation, not an operating command.
The output should first match a defined schema. The evidence it cites should exist in the retrieved data. Deterministic checks should compare the recommendation with known safety thresholds and other sensor readings. The operator should see the evidence, the confidence and any disagreement between the AI and the existing control logic.
Most importantly, the model shouldn’t have a direct command path to the actuator. It may help an operator understand an anomaly, compare similar events and prepare the next action. A person with the right authority confirms any consequential step, and the control system executes it through its existing safety mechanisms.
This isn’t resistance to automation. It is a separation of responsibilities. Probabilistic interpretation belongs where context and ambiguity matter. Authorisation and functional safety belong where behaviour must remain deterministic.
Design the failure path
A safe deployment also needs an answer for the less dramatic failures. What happens when the model is unavailable, the network link drops, latency rises, the output cannot be validated, or the provider changes an endpoint?
The industrial process should continue without depending on the language model. Existing alarms, dashboards and safety logic remain available. The AI capability can fall back to a reduced or read-only mode. Limits on requests, time, tool use and expenditure prevent a loop from consuming resources indefinitely.
The system also leaves a usable record: which device produced the data, which fields entered the context, which model handled the request, what recommendation it returned, which checks ran and who approved the action. If something looks wrong, operators can disable the AI route without disabling the underlying process and preserve the evidence needed to investigate.
This is close to the direction now given to critical-infrastructure operators by CISA, the Australian Signals Directorate and international partners: maintain human oversight, protect operational data, test AI in the context of existing OT controls, and provide failsafe mechanisms that allow the process to bypass or replace the AI when necessary.
Control is the real outcome
The safe architecture isn’t the one that assumes the model will always recognise bad data. It is the one that remains safe when the model doesn’t. The device proves its identity. The data is checked and bounded. The model receives only what it needs. Its recommendation is validated. A person retains authority over consequential action. The system records what happened and can fall back or stop.
Running the model at the edge may be the right decision for latency, continuity or data control. But location answers only where inference happens. It doesn’t answer who can update the runtime, where support access enters, which external services the system still depends on, how it recovers, or whether another approved model or provider can take over without rebuilding the application.
That is where AI security becomes a broader question of sovereignty. Not independence from every supplier, and not a claim that local automatically means safe. The practical goal is to retain meaningful control over the data, actions and dependencies that matter. And to preserve a credible way to change course when technology, providers or requirements change.
The series began with a simple point: the architecture is the risk. It ends with the other side of that statement. The architecture is also where control becomes real.