Large shipyards are running computer vision systems for workplace safety: cameras placed at strategic points around the yard, a deep learning model that analyses the video stream and recognises predefined risk situations. Missing personal protective equipment, entry into restricted areas, dangerous proximity between people and moving machinery, falls and postures consistent with an injury in progress. On detection the system raises an alarm to the site manager and, in the more advanced configurations, automatically stops the machinery involved.

It is this last function that changes the nature of the problem. While the system only reports, safety rests with whoever receives the alarm; once it stops a crane, the integrity and availability of a piece of software become conditions of the physical safety of whoever is working under that crane. Discussion of these installations usually concentrates on the legal safeguards that make their use lawful — Article 4 of the Italian Workers’ Statute, the AI Act and the GDPR — and those safeguards are necessary. The information security side gets less attention, and it concerns the safety of the same people.

Reporting and stopping

A system that reports and a system that acts have different failure modes. In the first case a person sits between detection and intervention, able to check, ignore or get it wrong, and the latency is human. In the second, authority over the physical world lives in the code and in the model weights, and the latency drops to machine speed.

The law reaches the same point by another route. Automatically blocking a machine constitutes a decision based solely on automated processing with significant effects on the person under Article 22 of the GDPR, and therefore requires that article’s safeguards, starting with human intervention in handling the event. The provision asks for human intervention at exactly the point where the safety function requires machine-speed reaction. These are two real constraints pulling in opposite directions, and how they are reconciled is a design choice to be documented.

The same choice covers behaviour on failure. A safety function that fails into a safe state stops the machine and stops production; one that fails while letting work continue removes the protection without anyone noticing. The two options have very different costs, and the choice between them belongs in the design phase rather than at the first failure.

The precedent: Triton

That a system built to keep people from dying is a target has been documented since 2017. At a petrochemical plant in Saudi Arabia, investigators found malware — called Triton by Mandiant, TRISIS by Dragos and HatMan by the US ICS-CERT — that targeted Schneider Electric’s Triconex safety instrumented system, the layer that brings a plant to a safe state when parameters move out of range.

The sequence is instructive. The first signs date to June 2017, when the safety system tripped and the plant shut down; a second shutdown in August led to the investigation and to the discovery of the malware, made public in December. Attribution came much later: in March 2022 the United States unsealed an indictment against an employee of the Russian research institute TsNIIKhM, and the FBI issued a notification warning that the group continued to operate against the global energy sector.

Triton is the first publicly documented case of malware built to act on a safety instrumented system. Whoever wrote it had to know the controllers’ proprietary protocol and reprogram them. The precedent concerns a sector exposed to state-level adversaries and does not describe the situation of a shipyard. What it establishes is that the safety layer, when it is software, is among the things somebody tries to modify. It is the same reasoning applied to model containment in an earlier article: a boundary implemented in software inherits the failure modes of software.

Integrity, availability, authenticity

In an ordinary IT system, integrity, availability and authenticity are service properties. In a safety function they become conditions of physical safety, and deserve the same rigour as mechanical guarding.

  • Integrity. A modified threshold, a swapped model, a class removed from the list of what the system recognises: the installation keeps running and stops seeing a category of danger. The failure produces no visible symptom.
  • Availability. A system that is down protects nobody. The question to settle at design time is what happens in the yard during the minutes the system is unavailable, and who decides whether work continues.
  • Authenticity of the signal. Cameras, network and video stream are the system’s perception. A frozen or replayed frame shows a clear area.
  • The asymmetry of silent failure. An alarm that does not fire is indistinguishable from the absence of danger. Causing harm requires only the suppression of a true alarm, without any need to generate a false one, which is the effect Triton aimed at on the safety instrumented system.

The last point is the technical reason a safety function has to watch itself: liveness checks, alarms on absence of signal, periodic coverage tests in the field. These controls are well known in functional safety and reappear here because the problem is the same.

The Machinery Regulation and the AI Act

Regulation (EU) 2023/1230 on machinery, which applies from 20 January 2027 in place of Directive 2006/42/EC, has taken up this convergence explicitly. Software falls within the definition of a safety component and appears in the indicative list of safety components, which may now be physical or digital. In Annex III, among the essential health and safety requirements, point 1.1.9 is devoted to protection against corruption, and connects to point 1.2.1 on the safety and reliability of control systems.

The placement matters more than the wording: protection against intentional tampering sits among the essential health and safety requirements, at the same level as guards and emergency stops. The regulation also provides that machinery certified under a cybersecurity certification scheme adopted pursuant to Regulation (EU) 2019/881 is presumed to conform to points 1.1.9 and 1.2.1. The supporting technical standard is being written: the European draft prEN 50742 addresses accidental or intentional corruption of software, data and configurations where it can compromise safety, and as of mid-July 2026 it remains a draft rather than an applicable standard.

On the AI Act, the most immediate classification is under Annex III, point 4: a system used to monitor and evaluate people’s behaviour in the employment relationship is high-risk, with obligations applying from 2 December 2027 after the Digital Omnibus. A second classification route is worth considering: Article 6(1) treats as high-risk an AI system intended to be used as a safety component of a product covered by the Union harmonisation legislation listed in Annex I, where that product is subject to third-party conformity assessment. The Machinery Regulation is legislation of that kind and covers AI-based safety components. Whether a given installation falls down this route depends on how the system is placed on the market and on the conformity assessment required, and it is a check to be made case by case.

Downstream effects: hospitals

Healthcare shows what the outage of a computer system does to people who were never the target. A study by Christian Dameff and colleagues published in JAMA Network Open on 8 May 2023 measured the effect of a month-long ransomware attack against a San Diego hospital system on the two adjacent emergency departments, which had not been attacked: stroke patients treated went from 60 in the four preceding weeks to 103 in the four weeks of the attack, alongside higher traffic and more people leaving without being seen. It is a peer-reviewed measurement, and it documents the propagation of disruption rather than deaths.

On mortality the evidence is weaker and should be presented as such. An estimate on Medicare data puts in-hospital mortality for patients already admitted when an attack begins at roughly 3 in 100, rising towards 4 in 100, with additional deaths estimated at between 42 and 67 over 2016-2021. That estimate comes from a working paper that has not been peer-reviewed and is limited to Medicare patients, and it should be cited with those limits.

Limits

What is described here is a class of systems and not a specific installation with published results. Vendor-declared effectiveness does not replace verification in the field, and indicators should be defined before adoption rather than derived afterwards. The literature on how well these systems reduce injuries is largely produced by interested parties, and none of the figures cited here bears on it.

Adding a network-connected safety layer adds attack surface: one more system to patch, with its own credentials and remote access. The balance between the risk it removes and the risk it introduces has to be struck on site, and depends on how it is isolated from the rest of the yard network.

Nothing above claims that shipyards are today the target of Triton-class attacks, which occurred in a sector facing state-level adversaries. The relevance to a shipyard lies in the design question, not in the threat level.

There remains the question of surveillance, and it is not secondary: the same camera that stops the crane observes the people at work. Article 4 of Italian Law 300/1970 permits audiovisual installations for workplace safety among other purposes, but makes installation conditional on an agreement with union representatives or authorisation from the National Labour Inspectorate, and that step comes before everything else.

Before installing a system of this kind there are two separate questions to ask: whether it works when everything is in order, and what happens in the yard when it stops working. The second question includes who, from outside, can make it stop working.

Cover image: a woman welder in the Tyneside shipyards, 1943 — photo by Cecil Beaton, Imperial War Museums collection, public domain — https://commons.wikimedia.org/wiki/File:Cecil_Beaton_Photographs-_Tyneside_Shipyards,_1943_DB68.jpg