Workplace AI Risk Assessment Guide for EHS Teams (2026)
A people-first working method for deciding where AI can support workplace health and safety work, what can go wrong, which controls are needed, and who must remain accountable.
By Alvin Liao, last reviewed · 阅读简体中文版本
Before an AI system affects a worker, task, machine, record or safety decision, document its purpose and boundaries, map the people exposed to its errors, identify physical, health, psychosocial, privacy, information, cybersecurity and governance hazards, assess the consequence and uncertainty of failure, then assign controls and a qualified human reviewer. Start with the lowest-consequence use that can be tested. Do not let AI become the sole basis for safety-critical control, compliance approval, incident findings or consequential people decisions.
Scope: what this guide covers
This guide applies to AI-enabled tools, models, agents, analytics, computer vision, algorithmic management features and robotics-related systems used by or for EHS, operations, engineering, HR, learning, maintenance or incident teams. It covers both a general-purpose assistant used in an EHS workflow and an AI component embedded in equipment or a workplace process.
Worker-facing effects
Outputs or actions that can change how people work, what they are exposed to, what they are monitored for, what training they receive, or how they challenge a decision.
System and process effects
Changes to a machine, vehicle, process, permit, inspection, reporting route, emergency workflow, data flow, work organization or safety control.
Not a legal test
This is not a jurisdiction-specific legal interpretation, certification scheme, engineering sign-off or substitute for a competent risk assessment under local requirements.
Include worker voice
Talk with affected workers and their representatives early. They often see workarounds, false alarms, workload changes and practical failure modes that a system description misses.
The UK's Health and Safety Executive (HSE) states that its health and safety framework applies to AI in the workplace and that uses affecting workplace health and safety need risk assessment and appropriate controls, including attention to cybersecurity. That statement is specific to HSE's remit; this page uses it as a source-grounded reason to assess AI before deployment, not as a universal legal rule.
Working risk taxonomy for EHS teams
Use more than an accuracy check. AI can change the hazard profile of a physical system, introduce psychosocial effects through work organization, or make it harder for a person to understand and challenge a decision. The taxonomy below is a practical assessment lens informed by NIOSH's workplace AI hazard discussions; it is not a regulatory classification.
| Risk family | Questions for the assessment | Examples of controls |
|---|---|---|
| Physical and process safety | Can an output alter a machine, vehicle, process, isolation, alarm, inspection priority or work instruction? What happens if it is wrong, late, unavailable or acted on out of context? | Keep safety functions independent where required; define fail-safe and manual fallback; validate in representative conditions; require qualified release and stop authority. |
| Occupational health and psychosocial | Could the system intensify work, reduce autonomy, create fatigue, change skills, increase stress, or shift exposure to noise, chemicals, ergonomics or other hazards? | Review work design with workers; preserve reasonable workload and breaks; monitor new exposures; provide training, support and a route to challenge or pause the workflow. |
| Human factors and decision integrity | Can automation bias, unclear explanations, missing context, hallucination, stale data or a confident tone cause a person to accept a wrong output? | Show source evidence and uncertainty; use independent checks; design a reject and escalation path; test rare and failure scenarios, not only typical examples. |
| Privacy, fairness and worker voice | What worker, health, location, image, performance or incident data is collected? Can the output disadvantage a group or prevent a person from understanding and challenging an outcome? | Minimize data; set access and retention rules; check representative performance; give notice and a human challenge route where relevant; involve privacy, HR and worker representatives. |
| Cybersecurity and resilience | Can prompts, files, sensors, integrations, vendors or model updates leak data, manipulate an output, bypass a control or make the workflow unavailable? | Threat-model inputs and integrations; control access; test malicious and malformed inputs; record versions; maintain fallback operations and incident escalation. |
| Governance, change and accountability | Who owns the use case, model, data, decision and correction? What changes trigger reassessment? Can the organization reconstruct what the system produced and what the reviewer decided? | Maintain a use-case register; assign RACI; keep versioned evidence and review records; define change control, complaints, incident review and retirement criteria. |
Step-by-step assessment
Run the steps with the people who perform the work, the person accountable for the safety outcome and the technical owner. Pause the proposal whenever the team cannot describe the system boundary, the affected people, the evidence or the fallback.
- Define the purpose and the stop conditions. Write one sentence describing the task AI supports, the intended benefit and what AI is not allowed to do. Name the decision, action or control that remains human-owned. Include the model, interface, data sources, integrations, downstream users and physical equipment in the boundary.
- Map people, tasks and decisions. Identify workers who operate, supervise, maintain, review, are monitored by, or may be affected by the output. Describe the normal workflow, the foreseeable workaround and the emergency or degraded mode. Ask whose work, privacy, autonomy, workload and ability to speak up could change.
- Describe the AI characteristics. Record the model or algorithm type, training or retrieval sources where known, input data, update path, confidence or uncertainty signals, latency, known limitations, vendor dependencies and access permissions. Distinguish the algorithm from the physical platform or process it influences.
- Identify hazards and failure modes. Walk through the taxonomy above. For each failure, ask: who could be harmed, through which task or decision, how would a person notice it, how quickly could it be corrected, and what happens if the system is unavailable? Include misuse, over-trust, malicious input, data drift, integration failure and workarounds.
- Assess consequence, exposure and uncertainty. Use the risk levels in the next section as qualitative decision labels. Consider the worst credible worker impact, how often people encounter the output, how much control they have, how uncertain the evidence is and how reversible the outcome is. Do not create a precise numeric score when the underlying evidence cannot support one.
- Select controls in the workflow. Prefer removing unnecessary AI exposure, narrowing the purpose, reducing sensitive data and keeping people away from avoidable hazards before relying on warnings or training. Add technical safeguards, access controls, source display, independent checks, manual fallback, worker consultation and escalation. Give the reviewer enough time, competence and authority to reject an output.
- Test with representative scenarios. Test normal, edge, rare, ambiguous, stale, missing-data, malicious-input and unavailable-system cases. Include the languages, shifts, environments, equipment states and worker groups that matter. Record what happened, what the reviewer saw, what they changed and whether the control worked in practice.
- Approve, record and communicate. Decide whether the use is allowed, restricted, deferred or prohibited under the organization's baseline. Record the purpose, risk level, evidence, controls, reviewer, accountable decision-maker, fallback, worker communication, open issues and review trigger. Tell affected people what the system does, what it does not do and how to challenge an outcome when relevant.
- Monitor and reassess. Look for incidents, near misses, complaints, false alarms, missed hazards, work intensification, drift, new data, model or vendor changes, and reviewer overrides. Reopen the assessment after a material change or a signal that the original assumptions no longer hold.
Risk-level table
These four levels are internal operating labels for this guide. They help teams choose review depth; they do not replace local law, a formal safety method, an engineering standard or a regulator's classification.
| Level | Typical trigger | Minimum control expectation | Decision posture |
|---|---|---|---|
| Low | AI drafts, organizes or retrieves information from approved material; an error is visible and easily corrected before it affects work. | Defined purpose; approved data; basic output and source check; named owner; no automatic action; record the use. | May proceed within the approved boundary after proportionate review. |
| Moderate | AI influences planning, prioritization, training, inspection triage or a report that people use to decide what to do; errors could create meaningful but detectable harm. | Representative testing; documented limitations; source or input traceability; qualified reviewer; worker feedback; fallback and reassessment triggers. | Proceed only with restricted use, explicit review and a recorded accountable decision. |
| High | AI materially influences a safety control, incident response, worker monitoring, work allocation, compliance interpretation or another decision where correction may be late, difficult or contested. | Formal use-case approval; domain and technical evaluation; strong data and cybersecurity controls; qualified review of each consequential output; challenge and escalation route; auditable records. | Defer, narrow or pilot under heightened governance until evidence and ownership are sufficient. |
| Critical | AI could directly actuate or override a safety-critical function, issue an emergency action, authorize a permit or compliance decision, determine a consequential people outcome, or expose workers to severe harm if it fails. | Do not use autonomously or as the sole decision basis. Require formal safety or engineering assurance, explicit accountable sign-off, independent challenge, tested fallback and a defined stop authority before any controlled use. | Baseline prohibition in this guide unless a formally governed exception is justified and approved by the accountable organization. |
Allowed, restricted and prohibited use matrix
This baseline matrix is deliberately conservative. An organization's policy, contract, local requirement or safety case may be stricter. A use can move only after the evidence, controls, worker communication and accountable approval support the new boundary.
| Status | Examples | Conditions | Human decision boundary |
|---|---|---|---|
| Allowed | Drafting a toolbox talk; summarizing an approved meeting record; extracting actions; translating a draft; retrieving passages from a controlled source library; creating a training outline. | Use approved information; minimize sensitive data; label the output as AI-assisted; check facts, sources and language before sharing; keep a named owner; do not trigger an automatic action. | A person decides what is published, assigned or used. AI is an assistant for preparation, not an approver. |
| Restricted | Inspection photo or sensor triage; standards applicability notes; risk-priority suggestions; incident narrative summaries; worker scheduling or monitoring analytics; personalized training recommendations; external-facing safety content. | Document the use case and affected people; test representative and failure scenarios; control access and retention; use source traceability; involve EHS plus technical, privacy, HR or worker representatives as relevant; record reviewer decisions. | A qualified reviewer verifies the output before it influences work. The affected person has a route to ask for correction where the workflow affects them. |
| Prohibited | Autonomous actuation or override of a safety-critical function; sole AI approval of a permit, compliance status, incident finding, disciplinary action or fitness-to-work outcome; unapproved public-tool processing of sensitive worker, medical or incident data; covert worker surveillance; unreviewed emergency instructions. | Do not use under this baseline. A different boundary requires formal governance, evidence, accountable sign-off and any applicable local review before a controlled exception is considered. | AI cannot be the sole decision-maker or silently change a safety-critical condition. Stop the workflow when the boundary is unclear. |
Human review and RACI guidance
Human review is meaningful only when the reviewer understands the work, can see the evidence and has enough time and authority to reject the output. A human clicking “approve” after an opaque, rushed or unchallengeable recommendation is not an effective control.
Check the evidence
Confirm the right system and version, the task context, source documents or sensor inputs, factual accuracy, missing information, uncertainty and whether the output says more than the evidence supports.
Check the consequence
Ask who could be affected, whether the decision is within the AI boundary, whether a safer alternative exists, and whether the reviewer has authority to pause, correct or escalate.
Keep a record
Retain the relevant output, inputs or sources, reviewer decision, changes made, exception rationale and escalation. Keep only what the approved data and retention rules allow.
Listen to workers
Invite reports of false alarms, missed hazards, workload changes, privacy concerns and unexpected workarounds. Treat a challenge as a safety signal, not a nuisance.
| Activity | Accountable (A) | Responsible (R) | Consulted (C) | Informed (I) |
|---|---|---|---|---|
| Define purpose, worker impact and stop conditions | Operational leader who owns the safety outcome | EHS or process owner with the system owner | Affected workers or representatives; engineering; privacy or HR as relevant | Managers and governance forum |
| Describe data, model, integrations and technical controls | System or product owner | Technical owner or vendor manager | EHS; IT/security; privacy; procurement | Operational owner and reviewers |
| Assess hazards, test scenarios and set risk level | Operational leader and EHS leader jointly, according to local governance | EHS assessor with the technical owner | Frontline workers; engineering; maintenance; HR or worker representatives as relevant | Governance forum and affected teams |
| Approve a restricted or high-risk workflow | Named accountable operational leader | System owner maintains the approval record | EHS; security; privacy; engineering; worker representatives as relevant | Users and affected workers |
| Review each consequential output or action | Decision owner remains accountable | Qualified EHS, engineering or operational reviewer | Technical owner when behavior is unexpected | People who need the final decision or correction |
| Monitor, handle challenges and reassess | System or operational owner named in the register | Process owner and assurance team | EHS; workers; security; privacy; vendor | Governance forum and affected teams |
RACI is an assignment aid. It does not transfer a statutory duty, professional obligation, engineering sign-off or operational decision to a software vendor or to the AI system.
Example AI risk register
The rows below are illustrative entries, not evidence that these systems are deployed or approved. Adapt the fields to the organization's existing EHS, change-control, privacy and information-security records.
| ID and use case | People and inputs | Baseline level | Status and controls | Owner and evidence |
|---|---|---|---|---|
| EHS-01 Meeting summary and action extraction | EHS coordinators; approved meeting notes; no unapproved personal or incident-sensitive data. | Low | Allowed for drafting. Human checks names, actions, dates and context before circulation; no automatic task closure. | EHS process owner; saved source note, output and reviewer correction. |
| EHS-02 Controlled standards retrieval and applicability note | EHS and engineering reviewers; licensed or approved source library; project scope and edition context. | Moderate | Restricted. Show citations and source version; qualified standards reviewer confirms scope and interpretation; AI does not decide compliance. | Standards owner; source links, review note and decision record. |
| EHS-03 Inspection image triage | Inspectors and affected workers; approved images, location and asset metadata. | Moderate | Restricted. Test lighting, occlusion and false-negative cases; reviewer verifies every issue before work is reprioritized; manual inspection remains available. | Inspection process owner; test set, reviewer log and correction route. |
| EHS-04 Incident narrative summarization | Investigators, witnesses and affected workers; incident records may contain sensitive personal information. | High | Restricted only with approved data handling, access controls, source traceability and investigator review. AI cannot determine causation, blame or reportability. | Incident investigation lead; access record, source material and signed review. |
| EHS-05 Permit or safety-control authorization | Permit issuers, operators and maintenance workers; live operational state and safety controls. | Critical | Prohibited as an autonomous or sole decision. Keep authorization with the qualified accountable person and use formal engineering and operational assurance for any proposed support function. | Permit authority; formal change and assurance record required before any exception. |
Practical evidence pack
For each restricted or higher-risk use case, keep an evidence pack that another qualified person can understand. It should contain the purpose and boundary, system and data description, affected people, hazard analysis, risk rationale, test scenarios and results, controls, fallback, reviewer and accountable approver, worker communication, version history, complaints or challenge records, incidents or near misses, and the trigger for the next review.
Keep source evidence close to the claim. For a retrieval workflow, preserve the cited source and edition. For a model output, preserve the relevant input and version where the approved data policy allows. For a physical or process control, preserve the test condition, observed behavior and release decision. The aim is traceability, not paperwork for its own sake.
These public sources provide the evidence boundary for this guide. They are linked for direct reading; no paid standard text is reproduced.
- HSE's regulatory approach to Artificial Intelligence (AI) - the UK's Health and Safety Executive describes its remit, a risk-based and proportionate approach, the need to assess and control workplace-health-and-safety risks from AI, and the need to address cybersecurity. The page concerns HSE's enforcing authority and should not be read as a universal jurisdictional rule.
- NIOSH: Practical Strategies to Manage AI Hazards in the Workplace - an official NIOSH discussion of workplace AI hazards, algorithmic hygiene, familiar occupational hazard methods, work-design and software-design controls, and evaluation approaches.
- NIOSH: Algorithms and the Future of Work - an official NIOSH discussion of invasive surveillance, algorithmic bias, loss of autonomy and privacy, inaccurate outputs and work intensification as risks to consider in workplace assessment.
- NIST AI Risk Management Framework - NIST's voluntary framework for incorporating trustworthiness considerations into the design, development, use and evaluation of AI systems. Its RMF 1.0 and related resources are not a legal mandate by themselves.
- ISO/IEC 42001:2023 - AI management systems - ISO's public overview of a management-system standard for establishing, implementing, maintaining and continually improving an AI management system. The standard is not reproduced here and implementation is not the same as certification.
Reviewed 29 Aug 2026. Official pages and standards can change. Check the current source, applicable jurisdiction, contract, site procedure and competent professional advice before making a deployment or compliance decision.
Limitations and boundaries
- This guide is an educational operating framework, not legal, regulatory, medical, occupational-hygiene, cybersecurity, engineering or employment advice.
- The labels Low, Moderate, High and Critical are this guide's qualitative decision aids. They are not universal risk categories and do not establish that a use is lawful, safe or compliant.
- AI behavior depends on its model, data, interface, instructions, integrations, environment, users and change history. A page-level description cannot establish that a particular system is safe.
- Worker consultation, human review and a register do not remove underlying hazards. Controls must be tested in the real work context and revised when assumptions fail.
- Local requirements may impose stricter controls, consultation, records, privacy safeguards, machinery assurance or professional sign-off. The accountable organization must determine what applies.
Frequently asked questions
What is a workplace AI risk assessment?
It is a documented review of how an AI system can affect workers, tasks, decisions, equipment and work organization, followed by proportionate controls, human review, ownership and monitoring.
Does every AI tool used by an EHS team need an assessment?
Every proposed use needs at least a proportionate triage. A tool that only drafts from approved, non-sensitive material may need a light review, while a tool that influences physical work, worker monitoring, compliance or incident decisions needs a deeper assessment and stronger approval.
Can EHS teams use generative AI?
Yes, for governed decision-support tasks such as drafting, summarizing or retrieving approved sources, provided sensitive data is controlled, outputs are checked and qualified people retain decision accountability.
What makes an AI use case high risk?
A use case becomes high risk when a wrong, delayed, biased or unavailable output could materially affect worker safety, health, privacy, fairness, a safety control, an incident response or a consequential employment decision, especially when people cannot detect or correct the error in time.
What should a human reviewer check?
The reviewer should check the system, context, source evidence, factual accuracy, uncertainty, worker impact, decision authority and required record before accepting an output or action. The reviewer must have the competence and authority to reject it.
When should an AI risk assessment be revisited?
Revisit it before use, after a material change to the model, vendor, data, prompt, interface, task or control, and after an incident, near miss, complaint, failed review or meaningful change in worker feedback.
Use this guide with the AI-Native EHS Starter Kit, review the EHS AI governance explainer, or scope a Corporate AI Safety Diagnostic for a use-case register and implementation boundary.