The regulator has put AI on the hazard list, and a software update you did not ask for can trigger the duty

The most useful sentence in the new material is the one that sounds least like news. Safe Work Australia says AI and digital technologies “can present new and emerging risks”, but that “the process for managing those risks remains the same as for any workplace hazard”. There is no new instrument here, no new code of practice, and nothing to comply with that did not already apply.

What has changed is that the regulator has now written down what it thinks the hazard looks like. If you run a WHS management system, that is the part worth reading, because it tells you what an inspector or an investigator will have in mind.

What counts, and it is broader than you think

The guidance is not limited to anything that looks like a robot. Digital technologies, it says, cover a wide range of hardware and software, and its own examples are computers, mobile phones, software and applications, security and safety technologies, wearable devices, and advanced robotics and automation. AI is described as an umbrella term for predictive software performing tasks that previously required human intelligence, with machine learning algorithms and generative AI given as the common workplace cases.

It then states, plainly, that these are used in most Australian workplaces. On that definition, almost every PCBU in the country is already in scope, and most have never treated it as a WHS matter.

The trigger that will surprise people

Here is the passage that does real work, and it is worth quoting closely. Introducing new digital technologies or changing existing ones may introduce or change WHS risks, and the guidance expressly includes “routine changes to IT systems, or updates ‘pushed’ or initiated by software providers”.

Read that against the duty. Under the model WHS laws a PCBU must eliminate risks so far as is reasonably practicable, or minimise them if elimination is not reasonably practicable. Safe Work Australia is saying that obligation can be engaged by a change you did not choose, did not schedule, and may not have been told about in advance.

The guidance gives the concrete version in its own examples table: a system update can “directly create safety issues (e.g. disabling sensors or alarms)”. That is not a hypothetical for anyone running plant with software-controlled interlocks. It is also the clearest argument we have seen for treating vendor release notes as safety documents rather than IT paperwork.

The four risks it names

The examples table pairs opportunities with risks, and the risks are specific enough to audit against.

Task automation. The opportunity is reduced job demands. The risk runs both ways: automating the most stimulating or fulfilling tasks can leave workers with low cognitive demands, while automating the routine ones can leave a greater proportion of tasks requiring extensive thought and focus, which the guidance calls work intensification. Automation does not simply reduce load. It changes which load is left.

Workplace monitoring. The opportunity is genuine, and the guidance uses checking that a driver takes adequate rest breaks as its example. The risks are work intensification arising from workers merely knowing they are surveilled, and scope creep, where legitimate monitoring is used for other purposes such as performance management. That second one is a governance question as much as a safety one, and it is now written into national WHS guidance.

Updates to systems. Beyond the safety-critical case above, the named risk is workloads increasing to get across updates, “particularly where updates are unnecessary, too frequent, or have little safety or long-term efficiency benefit”.

Decision making. This is the sharpest of the four. Workers may have limited authority to override decisions or outputs from digital technologies, or be unclear how to do so, which the guidance links to organisational justice risks and to potential harm to others, giving the example of patients receiving care plans created by digital technology. And it names something that will be familiar to anyone who has watched a chatbot deployed into a service team: workers may be organisationally responsible for responses from AI they cannot fully control, or where another user can influence the output.

What we would actually do with this

Our view, and it is a view built on the text above. Three things are cheap and follow directly from the guidance. Add software and AI changes to the change-management trigger in your risk register, so that a pushed update is treated like any other change to plant or process. Ask, for any monitoring system already in place, what it was introduced for and what it is now used for, because scope creep is named as a risk and is easy to demonstrate after the fact. And where AI outputs reach a worker's accountability, write down who may override them and how, because the guidance identifies the absence of that clarity as the risk.

The consultation obligation is not optional decoration either. Safe Work Australia frames the whole exercise as applying the WHS risk management process “in consultation with workers and their representatives”. For a technology rollout that is often decided by procurement and IT, that is the sentence most likely to be skipped.

One thing this guidance is not: a rule about whether AI is used, or how it is trained, or what it does with data. Those are different regimes with different regulators. This is narrowly about whether introducing it hurts the people at work, and it leaves the answer where the model laws always leave it, with the PCBU.