Industrial AI can help a factory predict a fault, compare production plans or detect an unusual process condition. A digital twin can test a proposed change against a representation of the line. A collaborative robot can share a workspace with people when the application has been engineered for that interaction. None of these labels establishes safety, accuracy or financial value by itself.
Reviewed for this edition through 31 July 2026, the guide uses Health and Safety Executive material that applies to Great Britain; Northern Ireland has its own health and safety regulator. Product rules also differ between Great Britain and Northern Ireland, and the applicable route depends on where machinery is supplied or put into service. Confirm the site, product, role and current law before deployment.
Define one decision and one accountable owner
Begin with a decision that already exists. Examples include whether to inspect a spindle, adjust a non-safety-critical set point, reorder a component or alter the sequence of a changeover. Write down who takes that decision now, what evidence they use, how quickly they must act and what happens when evidence is missing.
Do not start with “build a smart factory.” Give the proposed system a bounded purpose:
- rank assets for manual inspection;
- forecast a consumable within an agreed range;
- simulate a layout before physical modification;
- identify images that require a quality engineer’s review;
- propose a maintenance window without issuing the work permit; or
- stop a cobot through an independently validated safety function.
The UK government’s 2026 advanced-manufacturing AI adoption plan recommends a scan-pilot-scale path. Treat that as a delivery pattern, not evidence that a use case will work in a particular plant. Establish a baseline for scrap, unplanned downtime, inspection effort, missed defects and safety events before comparing a pilot.
Our predictive-maintenance guide-uk) covers the narrower asset-health workflow. Keep its probability estimates separate from a safety decision or an instruction to work.
Make the digital twin a testable model
The government’s official digital-twin definition requires a digital representation, two-way communication with the real world and a timeframe appropriate to the decision and assumptions. A dashboard, static CAD model or historical simulation may be useful, but should not be marketed as a live twin if it lacks those properties.
Maintain a twin register containing:
- represented equipment, process and version;
- sensor sources, units, sampling intervals and quality rules;
- latency from physical event to model state;
- assumptions and parameters that operators may change;
- calibration data and last validation date;
- known operating envelopes and excluded states;
- consumers of each output;
- write-back capability and approval path; and
- a safe mode when feeds, clocks or identifiers fail.
Validate behaviour against held-out operating periods, planned disturbances and rare but credible states. A model can fit normal production while failing during warm-up, cleaning, product change, degraded sensing or an abnormal shutdown. Compare predicted and observed quantities in the units that matter to the decision. Report uncertainty instead of hiding it behind a realistic visualisation.
Control configuration as tightly as model code. A change to a programmable logic controller tag, sensor location, unit conversion, maintenance regime or bill of materials can invalidate a result even when the model file is unchanged. Link every twin release to the physical configuration it represents and prevent operators from applying a simulation to another line merely because the equipment names look similar.
Define the clock for each decision. A five-minute delay may be acceptable for energy planning but unsafe for motion control and useless for a fast quality response. Display last reliable observation, processing delay and stale-state behaviour. During commissioning, deliberately disconnect feeds, swap identifiers and inject impossible values. The twin should expose uncertainty, reject corrupted input and return the plant to an approved operating method rather than silently carrying the last state forward.
Retain a comparison record after each authorised change. If observed performance moves outside the agreed residual range, investigate data, equipment and assumptions before recalibration. Automatic recalibration can conceal mechanical deterioration or a sensor fault.
| Layer | Evidence before use | Failure response |
|---|---|---|
| Physical asset | Maintained equipment and verified sensor placement | Use established operating procedure |
| Data pipeline | Units, clocks, lineage and missing-data tests | Quarantine affected interval |
| Model | Versioned validation inside a stated envelope | Withdraw or constrain output |
| Operator interface | Comprehension and workload test | Revert to approved manual view |
| Write-back | Independent limits and authorised change | Block command and investigate |
Keep safety functions independent
The PUWER overview explains that work equipment must be suitable, maintained and protected against dangerous parts. An AI forecast is not a substitute for guarding, interlocks, emergency stops, isolation, lock-out procedures, inspection or competent maintenance.
HSE’s review of machinery standards and emerging technology identifies questions raised by autonomous mobile robots, AI and collaborative applications. It is research, not a declaration that existing duties have disappeared. Likewise, the government’s machinery-safety call-for-evidence outcome described intended future changes as of February 2026. Check enacted rules and current guidance rather than designing against a proposal.
Map hazards through the complete lifecycle: installation, teaching, production, recovery, cleaning, maintenance, tool change, foreseeable misuse and decommissioning. Safety-related control must have an appropriate architecture and validation independent of the predictive model. If a model recommends faster motion, a hard safety limit must still prevent an unsafe command.
Engineer the collaborative application, not the robot label
A cobot is not automatically safe because the product can operate in a collaborative mode. The end effector, workpiece, fixtures, speed, force, reachable space, operator task and surrounding machinery determine the application risk.
In June 2026 HSE announced work on its first joint industry guidance for collaborative robotics. At this guide’s cutoff, that announcement said the first stage would launch during summer; do not cite it as completed application guidance unless the final material has actually been published.
Test at least:
- approach and separation monitoring across realistic paths;
- power-and-force limits with the actual tool and component;
- trapping and crushing points created by benches or stock;
- sensor occlusion, reflective clothing and poor lighting;
- restart after a protective stop or network interruption;
- unauthorised entry and maintenance mode;
- dropped, sharp, hot or unstable workpieces; and
- manual recovery when the robot stops in an awkward position.
Our SME robotics guide provides a broader automation-selection framework. A competent machinery-safety assessment still has to address the specific cell.
Secure the operational-technology boundary
Connecting twins, cloud analytics, vendor support and robots can join office IT to systems where availability and physical safety matter. The NCSC’s secure-connectivity principles for operational technology call for documented, risk-informed connections, limited exposure, third-party control and defence in depth.
Create a definitive architecture and data-flow record. Segment production networks, use strongly authenticated and time-limited remote access, deny unnecessary outbound traffic, monitor privileged sessions and keep recoverable configurations offline. Test how production continues when the analytics service, identity provider, historian or vendor connection is unavailable.
Supplier contracts should identify components and subprocessors, update support, vulnerability handling, access logging, export formats, model-change notice and exit assistance. The NCSC’s device-security principles for manufacturers include secure updates, trusted software, constrained interfaces, logging and recovery. Require evidence for the actual product rather than a generic security certificate.
Protect workers without converting telemetry into surveillance
Sensor and robot data may reveal pace, location, breaks, errors or individual work patterns. A safety or maintenance purpose does not automatically justify performance scoring. Consult workers and representatives early, minimise individual identifiers and document who can access which views.
The ICO’s worker-monitoring guidance requires monitoring to be necessary, proportionate and transparent. Complete a data protection impact assessment where the processing is likely to create high risk. Separate safety investigations from routine management analytics, set short retention periods and provide a route to challenge inaccurate inferences.
Automation also changes work. Train operators to recognise model limits, isolate equipment and recover safely. Measure workload, alarm burden and workarounds; a nominally efficient system can shift hidden effort onto technicians.
Evaluate operational value honestly
Run the pilot in shadow mode before permitting advice or write-back. Compare it with the current rule, schedule or inspector at the same event grain. Count false alerts, missed events, lead time, human review, production interruption and maintenance introduced by the new stack.
Pre-register success criteria. For predictive maintenance, measure precision at an actionable horizon and avoided emergency work without treating every early replacement as a saving. For quality inspection, review false negatives by defect type and product family. For a twin, compare predicted and observed outcomes after controlled changes. For a cobot, measure stable cycle performance only after safety and ergonomic acceptance.
Do not extrapolate a short, supervised trial across lines, shifts or products. Include licence, integration, sensors, connectivity, validation, cybersecurity, training and vendor dependence in the cost.
Use 90 days to earn a wider deployment
Days 1–30: appoint the operational, safety, security and data owners. Record the baseline, decision boundary, hazards, architecture, worker-data purpose and supplier dependencies. Choose one line and a reversible use case.
Days 31–60: validate data and model behaviour in shadow mode. Exercise abnormal states, loss of connectivity, sensor drift and recovery. Complete machinery, clinical-equivalent safety, cyber and privacy reviews applicable to the plant. Train each affected role.
Days 61–90: run a controlled shift comparison with documented overrides. Review safety observations, missed defects, false alerts, downtime, workload and full operating cost. An independent approver decides whether to stop, extend the experiment or expand to one additional bounded context.
Define industrial pause gates
Pause automated advice or write-back when:
- a protective function, interlock or emergency response behaves unexpectedly;
- the model operates outside its validated equipment, material or speed envelope;
- sensor identity, units, timestamps or calibration cannot be trusted;
- false negatives exceed the pre-agreed safety or quality tolerance;
- remote access or an OT credential is compromised;
- operators develop an unapproved workaround to meet production pressure;
- a supplier changes the model, firmware or subprocessor without review;
- worker telemetry is reused for an undeclared purpose; or
- recovery cannot restore a known safe state.
Industrial AI should make a bounded decision easier to inspect and improve. It should never make the factory’s safety case, data lineage or human accountability harder to see.


