AI for Incident Analysis and Leading Indicators: A Human-in-the-Loop WHS Playbook

Most workplace health and safety functions in Australian banks, insurers and super funds are sitting on a large, underused dataset: the incident register. Slips and trips across corporate floors, ergonomic complaints from sustained keyboard work, security incidents at branches, and a long tail of near-misses that never became injuries. Each record is logged, classified, and then largely left alone until a regulator, an audit, or a serious event forces someone to read across the whole set by hand.

This is exactly the kind of work that AI can accelerate, and exactly the kind of work where getting the human-in-the-loop boundary wrong creates legal exposure. There are three uses that hold up. There is one use that does not, and it is the one most likely to be quietly adopted by accident.

This guide sets out a safe operating model for an Australian financial-services WHS team. It is written for a regulated enterprise environment, so every prompt and example uses placeholder tokens and de-identified data. The hard line is stated up front and repeated, because it is the part that matters most: AI must never be the thing that decides whether an event is a notifiable incident.

The duty that AI must not touch

Australian WHS law is built on the model Work Health and Safety Act 2011, which each state and territory adopts into its own legislation, with some local variation. Federal employers, including a number of large financial-services entities, sit under the Commonwealth WHS Act administered by Comcare. The structure of the notification duty is consistent across these regimes.

Under the model WHS Act, a notifiable incident is defined at section 35 as the death of a person, a serious injury or illness of a person, or a dangerous incident (Safe Work Australia). Section 36 defines what counts as a serious injury or illness, including injuries requiring immediate treatment as an in-patient in a hospital and certain specified injuries. Section 37 defines a dangerous incident as one that exposes a person to a serious risk to health or safety from an immediate or imminent exposure to specified hazards.

Section 38 imposes the duty itself: a person conducting a business or undertaking, the PCBU, must ensure the regulator is notified immediately after becoming aware that a notifiable incident has occurred, by the fastest possible means (Safe Work Australia). Section 39 adds a related obligation to preserve the incident site until an inspector arrives or directs otherwise. Comcare's guidance restates the same structure for Commonwealth-covered employers (Comcare).

Note that Safe Work Australia published amendments to the model WHS Act incident notification provisions in December 2025. Those amendments only take legal effect once each jurisdiction adopts them, so the precise wording in your jurisdiction may differ. The governance point does not change with the wording. Classifying an event against these sections is a legal judgement that carries a personal and corporate duty, and a misclassification that delays or omits a required notification is itself a breach. That judgement must be made by a competent person, not inferred by a language model from a free-text incident description.

Three uses that hold up, and the de-identification rule

The supported uses share a common shape. AI reads structured or semi-structured incident data, proposes patterns or hypotheses, and a human tests, edits and decides. The AI output is never a conclusion. It is a draft and a prompt to think.

Standing data rule. Never paste real personal, claim, health or incident data into a model that is not an approved enterprise instance. Public consumer chatbots are not approved enterprise instances. Before any incident export leaves your safety system, strip names, employee IDs, claim numbers, exact dates, and any free text that could re-identify a person. Replace them with placeholder tokens such as [EMPLOYEENAME], [CLAIMNUMBER], [INCIDENTID], [TEAM], [ROLE], [SITE] and [DATE].

Use one: de-identified trend and pattern analysis

This is the highest-value, lowest-risk use. You take a de-identified export of many incident records and ask the model to cluster them by contributing factor, surface concentrations by site or task type, and identify candidate leading indicators. A leading indicator is a signal that predicts harm before it happens, for example a rising rate of near-misses of a particular type, rather than a lagging indicator such as a lost-time injury that records harm after the fact.

The model is good at reading across hundreds of short text fields and proposing groupings a human would take hours to assemble. It is not good at deciding which groupings are real and which are artefacts of how the data was coded. That decision is yours.

Use two: ICAM-style causal support for a single incident

The Incident Cause Analysis Method, or ICAM, is a widely used investigation framework that organises contributing factors into four levels: absent or failed defences, individual or team actions, task or environmental conditions, and organisational factors (ICAM Australia). The method's central premise is that serious incidents are rarely caused by a single act, and that individual error usually sits on top of weaker conditions and failed controls.

AI can support an ICAM investigation by proposing candidate contributing factors at each of the four levels for a single de-identified incident. The investigator then tests each proposed factor against the evidence, discards the ones that do not hold, and adds the ones the model missed. The model widens the search. The competent investigator decides what is true. ICAM is a recognised method described by multiple practitioners rather than a single proprietary law, so treat the AI output as structured prompting, not as an authoritative finding.

Use three: drafting the investigation write-up, with blanks

Once the human has done the analysis, AI can draft the investigation summary into a consistent house format, leaving explicit blanks for the human's findings and, critically, leaving the notifiability decision as a blank for a named competent person to complete. This keeps the writing fast and the judgement human.

The use that does not hold up

AI must never auto-classify whether an event is a notifiable incident under sections 35 to 39. It is tempting, because the inputs look like a classification problem and language models are good at classification. The reason it fails is not technical. It is legal.

The notification duty is immediate and strict. A model that reads an incident description and outputs "not notifiable" creates a documented, automated recommendation that a tired investigator may rely on at the worst possible moment. If that recommendation is wrong, the organisation has not just missed a notification, it has built a system that reliably produces the breach. The competent-person judgement is the control. Do not automate the control away.

The safe pattern is the inverse. AI prepares the facts and structures the analysis so a competent person can make the notifiability decision faster and better. The decision field stays blank until that person fills it.

Worked example: a bank's corporate-site incident dataset

The rest of this guide runs a single de-identified, finance-sector example end to end, from project setup to prompt to illustrative output to the human decision gate.

The scenario: a WHS analyst at a major Australian bank has a de-identified export of incident and near-miss records across the bank's corporate office sites for the last twelve months. The export contains slips and trips, ergonomic and musculoskeletal complaints, security incidents at customer-facing sites, and near-misses. Every record has already been stripped of identifying detail and carries only [INCIDENTID], [SITE], [DATE] reduced to month, a category, and a short de-identified description.

Project setup: the Incident Insights Assistant

Set up a dedicated project space, in ChatGPT Projects or Claude Projects, so the model carries the right framing and source files into every conversation. The custom instructions establish the role, the four ICAM levels, the de-identification expectation, and the hard rule about notifiability.

You are the Incident Insights Assistant for an Australian financial-services WHS function.

Your role:
- Help a WHS analyst read across de-identified incident and near-miss records to surface patterns, hotspots and candidate leading indicators.
- When asked, propose candidate contributing factors for a single de-identified incident, organised by the four ICAM levels: (1) absent or failed defences, (2) individual or team actions, (3) task or environmental conditions, (4) organisational factors.
- Draft investigation summaries in the house format, leaving explicit blanks for the human investigator's findings.

Hard rules:
- You never decide whether an event is a notifiable incident under the model WHS Act sections 35 to 39. You may surface relevant facts, but the notifiability classification is left as a blank for a named competent person.
- You treat all your outputs as hypotheses and drafts, never as findings. Always end causal analysis with: "Test each proposed factor against the evidence before relying on it."
- You assume all data provided is already de-identified. You never ask for real names, employee IDs, claim numbers, exact dates or health detail. If a user pastes anything that looks identifying, stop and tell them to remove it.

Style: Australian English, clinical and concise. No em dashes. Cite the ICAM level for every contributing factor you propose.

Files to upload to the project:

• A de-identified incident export, CSV or table, with columns such as [INCIDENTID], category, [SITE], month, severity band, and a de-identified one-line description. No names, no IDs, no exact dates.
• Your WHS incident taxonomy or category list, so the model clusters using your codes rather than inventing its own.
• The relevant incident notification guidance for your jurisdiction, for example the Safe Work Australia notification requirements page or the Comcare guide, so the model understands the legal context it is forbidden to apply.

The prompt library

Four prompts cover the supported workflow. Each is ready to run inside the project. Each assumes the data is already de-identified.

Prompt 1: cluster de-identified incidents by contributing factor.

Using the attached de-identified incident export and our taxonomy, cluster the records by likely contributing factor. For each cluster:
- name the contributing factor in plain language
- count the records and list their [INCIDENT_ID] values
- note the [SITE] values and severity bands involved
- map the factor to the relevant ICAM level (defences, individual/team, task/environment, organisational)

Do not infer anything about specific individuals. Treat clusters as hypotheses. End with a short note on which clusters look strongest and which may be artefacts of how records were coded.

Prompt 2: surface leading indicators and trends.

From the attached de-identified export, identify candidate leading indicators: signals that may predict future harm rather than record past harm. Look in particular at near-miss patterns, repeat factors at the same [SITE], and any category whose monthly count is trending up.

For each candidate leading indicator:
- describe the signal
- state why it could predict future harm
- state what additional data a human would need to confirm it is real

Flag clearly that these are hypotheses for a WHS analyst to test, not conclusions.

Prompt 3: run an ICAM-structured contributing-factor pass on one incident.

Here is a single de-identified incident: [paste de-identified description, using [INCIDENT_ID], [SITE], [DATE as month], [TEAM], [ROLE] tokens only].

Propose candidate contributing factors across all four ICAM levels:
1. Absent or failed defences
2. Individual or team actions
3. Task or environmental conditions
4. Organisational factors

For each candidate, write one line and mark it as a hypothesis. Then list the three questions a human investigator should ask to test the most important candidates. Do not state a root cause. End with: "Test each proposed factor against the evidence before relying on it."

Prompt 4: draft an investigation summary with blanks for the human.

Draft an investigation summary for [INCIDENT_ID] in our house format. Use the contributing factors I have confirmed, which are: [paste confirmed factors]. 

Leave these as explicit blanks for the human to complete:
- Investigator's confirmed findings: [TO BE COMPLETED BY INVESTIGATOR]
- Corrective actions and owners: [TO BE COMPLETED]
- Notifiability decision under model WHS Act ss 35-39: [TO BE COMPLETED BY COMPETENT PERSON - DO NOT PRE-FILL]

Keep it concise and in Australian English. Do not offer an opinion on notifiability.

Illustrative output and the human decision gate

Run Prompt 2 against the bank's de-identified export. The model returns several candidate leading indicators. One stands out.

A short illustrative version of that output, de-identified throughout:

Candidate leading indicator. Near-miss records coded as slips on entrance-lobby flooring are concentrated at [SITE] and have risen across the last three months, mostly logged in the after-hours band. None resulted in injury, so they do not appear in lost-time statistics. ICAM level: this points first at task or environmental conditions, possibly an absent or failed defence around wet-weather floor management at that site. Signal: a rising near-miss rate that no lagging indicator would surface. To confirm, a human would need the cleaning and wet-weather-matting schedule for [SITE] and the after-hours foot-traffic pattern. This is a hypothesis for a WHS analyst to test, not a conclusion.

Now the human decision gate, which is the point of the whole exercise. The analyst does not act on the model's output. The analyst tests it. They pull the cleaning roster for [SITE], confirm the after-hours pattern against access-card data ranges, and find that wet-weather matting was being removed at the start of the after-hours cleaning window. That is a real, controllable condition. The analyst raises a corrective action to change the matting schedule, an intervention made before anyone was injured. That is a leading indicator doing its job, with AI surfacing the signal and a competent person making the call.

The same discipline applies to the single-incident ICAM pass. The model proposes candidate factors across the four levels. The investigator tests each one, discards the weak ones, and adds context the model could not see. When it comes to whether a given event is notifiable, the investigation summary leaves that field blank, and a named competent person completes it against sections 35 to 39 for the relevant jurisdiction. The machine never fills that field.

Putting it into governance

If you are a WHS governance lead introducing this, three controls keep it defensible. First, mandate de-identification before any export reaches a model, and confirm the model is an approved enterprise instance. Second, document in your procedure that AI is used for pattern surfacing and ICAM-style hypothesis support only, and that the notifiability decision and final findings rest with a competent person. Third, keep the human decision gate visible in the record, so an auditor can see that AI proposed and a person decided.

Used this way, AI does not replace the investigator or the duty holder. It reads the long tail of near-misses that nobody had time to read, proposes the patterns a human can then test, and gives the WHS function a way to act on leading indicators before they become lagging ones. The judgement stays where the law puts it.

References

• Safe Work Australia, Incident notification requirements under the model WHS Act* (model WHS Act 2011, sections 35 to 39), safeworkaustralia.gov.au.
• Safe Work Australia, Incident notification* topic page, safeworkaustralia.gov.au.
• Comcare, Guide to Work Health and Safety Incident Notification* (WHS Act 2011 (Cth), sections 35 to 39), comcare.gov.au.
• Safe Work Australia, Model WHS laws, safeworkaustralia.gov.au.
• ICAM Australia, What is ICAM?* (four contributing-factor levels: absent or failed defences, individual or team actions, task or environmental conditions, organisational factors), icamaustralia.com.au.

---

General information and education only. Not legal, WHS, compliance or professional advice. WHS laws are model laws adopted differently across Australian jurisdictions, and federal employers are covered by the Commonwealth WHS Act administered by Comcare. Always confirm your obligations against the legislation and regulator guidance that applies to your organisation, and have a competent person make notifiability decisions. Never paste real personal, claim, health or incident data into a model that is not an approved enterprise instance.*