Treat Safety AI as a WHS Change, Not an IT Rollout

MineGuard AI

· 14 October 2026 · 7 min read

Treat Safety AI as a WHS Change, Not an IT Rollout

Mining leaders are moving AI into incident investigation, safety-system assurance, critical-control work and frontline decision support. The governance question is no longer confined to privacy, cyber security or model selection. It is also a work health and safety question: how will this technology change the work, the people doing it and the controls they rely on?

That is the practical significance of Safe Work Australia’s July 2026 guidance on AI and digital technologies. It says associated risks should be managed through the familiar WHS process: identify hazards, assess risks, control them, then monitor and review the controls in consultation with workers and other duty holders.

The guidance does not create a separate AI statute, and Safe Work Australia is not the regulator. Legal effect depends on the applicable Commonwealth, state or territory framework, including mine-specific legislation. But the leadership message is clear: putting AI into safety work should be treated as a managed operational change, not a software switch-on.

The risk sits in the changed workflow

An AI tool can perform well in a demonstration and still create risk in use.

The relevant system is not only the model. It includes the source documents and evidence, the user interface, the people reviewing outputs, the permissions to act, the time available under shift pressure, the escalation path and the way software changes are released.

Safe Work Australia notes that new technology, changes to existing technology and even provider-initiated software updates may introduce or change WHS risks. Its guidance identifies potential issues including work intensification, fatigue, reduced job control, unclear roles, weak training, poor organisational change management and over-reliance on technology without proper human interpretation or oversight.

Those risks are highly relevant to mining safety workflows. Consider four failure modes:

An incident-analysis assistant produces a fluent draft, but the investigator cannot see which evidence supports each finding.
A procedure assistant retrieves an obsolete document or misses a conflict between the procedure and the risk assessment.
A control-verification tool improves completion rates while shifting attention away from whether the control is actually effective.
A software update changes output behaviour, yet the site continues to use the tool under the old validation and training assumptions.

None of these is solved by a generic instruction to “keep a human in the loop.” The organisation must define what that human is accountable for, what evidence they must inspect, when they must stop or escalate, and whether they have the competence and time to do it.

Five tests before go-live

1. Define the safety function and the boundary

Name the specific job the AI will support. Is it collating evidence, drafting interview questions, checking document consistency, proposing a bowtie, or preparing a learning pack?

Then state what it must not do. For high-consequence work, approval, operational authority and escalation rights should be explicit. A bounded use case is easier to assess, train, test and supervise than a broad promise to “assist safety.”

2. Make the evidence base governable

AI quality cannot be separated from the material it is allowed to use. Leaders should ask:

Which documents, records and evidence sources are authoritative?
Who owns their quality, currency and access?
How are superseded versions excluded?
Can a reviewer trace an output to the exact source used?
What happens when sources conflict or evidence is missing?

This is data readiness in operational terms. It is less about accumulating data than establishing provenance, document control, permissions and rules for uncertainty.

3. Consult the people whose work will change

Under Safe Work Australia’s guidance, decisions about controls should be informed by consultation with workers. That is also good system design. Investigators, supervisors, health and safety representatives, control owners and frontline users can identify practical failure modes that a project team will miss: handover gaps, connectivity limits, time pressure, duplicated entry, ambiguous prompts and alert fatigue.

Consultation should shape the workflow before rollout and remain open after deployment. It is evidence about how the technology is changing work, not a communications exercise after the design is complete.

4. Set acceptance criteria that can fail

The Australian Government’s Voluntary AI Safety Standard is voluntary and does not create new legal duties. It is nevertheless useful operational guidance: establish accountability, assess risk across the lifecycle, manage data provenance, define measurable acceptance criteria, test before deployment and continue monitoring.

For a safety workflow, acceptance criteria might address evidence traceability, completeness, unsupported claims, document currency, user comprehension, escalation performance and the time required for competent review. Thresholds should be linked to identified harms and include a clear response when the system fails.

This aligns with the NIST AI Risk Management Framework, which calls for documented roles, scoped use, human oversight, testing before deployment and regular evaluation while systems are operating.

5. Put updates through change control

A pilot result is not a permanent assurance case. Models, prompts, connected data, user permissions and interfaces can change. So can the operational context.

Define which changes require re-testing, who approves release, what is logged, how users are informed and when the system should be restricted or withdrawn. Safe Work Australia specifically identifies review before a software change that may introduce new or different risks. Leaders should expect an evidence trail showing what changed, why, what was tested and who accepted the residual risk.

What executives should ask to see

A board or executive team does not need a catalogue of technical settings. It needs a concise assurance picture:

the approved use case and prohibited uses
accountable business, safety and technical owners
affected-worker consultation and resulting design changes
authoritative data sources and document-control rules
defined human review and decision rights
acceptance criteria, test evidence and known limitations
monitoring measures, incidents and overrides
release history and reassessment triggers
supplier, hosting, retention and subprocessor dependencies
the exit plan if the system cannot remain within tolerance

This turns “responsible AI” from a principle into an operating discipline.

It also keeps the technology in proportion. Safe Work Australia’s Key Work Health and Safety Statistics Australia 2026 reported 222 traumatic worker fatalities in 2025 and said vehicle incidents remained the leading cause. AI governance matters, but it must help organisations act more consistently on known hazards and proven controls, not distract from them.

How MineGuard supports a governed rollout

MineGuard AI’s role is not to take accountability away from site leaders or competent safety professionals. Its documented approach is to help organisations structure safety work so AI outputs remain reviewable, evidence-anchored and human-approved.

MineGuard AI Consulting supports AI governance and strategy, data readiness and retrieval knowledge bases, safety-workflow transformation, and implementation and integration. Published deliverables include governance playbooks, RACI models, assurance checklists, data and metadata specifications, future-state workflows, integration designs and deployment runbooks. The engagement model moves from discovery, through a guarded pilot with defined success measures and human verification, to staged operationalisation.

For product workflows, MineGuard’s Trust & Security materials state that AI-generated outputs are presented for human inspection, named approval is required before material reaches the field, and approval activity is logged. The same materials describe evidence traceability, access controls, retention choices and deployment options. For Incident AI, MineGuard also publishes a current subprocessor register that identifies providers, purposes, configuration-dependent regions and, for the Australian sovereign deployment, the data handled by each service.

These controls do not remove the customer’s WHS duties or the need for competent judgement. They provide building blocks for a deployment that can be examined, challenged and governed.

The useful first step is not a broad AI rollout. It is a tightly scoped assessment of one safety workflow: map the work as it is actually performed, identify the evidence and decision boundaries, consult the people affected, define measurable acceptance criteria, and prove the governance before scaling.

Book a MineGuard AI governance and workflow readiness discussion to assess where evidence-anchored AI can assist, what must remain human, and what your organisation should be able to demonstrate before go-live.

Key sources

← All Posts