Section A

Mindset & Strategy

Evaluates whether leadership approaches AI as a strategic operational capability or an off-the-shelf feature.

01

When discussing requirements for a new EHS system, how is "AI" typically described?

1 pt As a single line-item in a feature list (e.g., "Add AI for smart suggestions"), with the expectation that the vendor will figure it out. 2 pts As a high-level aspiration (e.g., "Predict site risk with AI"), but without a defined scope for data architecture or R&D effort. 3 pts As a dedicated operational capability with specific use cases, documented schema requirements, internal expertise, and phased milestones.

02

What is the primary business expectation for an AI solution within your EHS program?

1 pt We expect it to work out of the box to uncover root causes and prevent incidents with minimal human input. 2 pts We expect it to automate existing administrative tasks, such as tagging incident reports or summarizing dashboard metrics. 3 pts We view it as an evolving capability that starts on a narrow, high-value problem and requires continuous engineering and calibration.

03

How is the budget for AI in EHS being allocated?

1 pt Assumed to be included within standard per-user or site software licensing fees. 2 pts Budgeted as an add-on vendor software module, but without internal budget for data cleansing, validation, or training. 3 pts Funded as a strategic investment accounting for technology licenses, data engineering, and dedicated frontline SME hours.

Section B

Data Maturity & Architecture

Examines the structure, standardization, and governance of your field incident and operational data flows.

04

How would you describe your organization's historical EHS incident data?

1 pt Fragmented across spreadsheets, paper forms, and legacy tools with inconsistent terminology. Essentially crude, unstructured data. 2 pts Stored in a central platform, but data entry varies across sites. The same classification (e.g. Lost Time) has conflicting regional meanings. 3 pts Governed by a standardized taxonomy. Captured in a unified system with enforced definitions and verified through regular data audits.

05

How are subjective EHS assessments (e.g., risk severity, likelihood) handled across your organization?

1 pt Left entirely to individual investigator discretion, causing wide variations across facilities. 2 pts Guided by a matrix and periodic training, but without routine calibration or validation mechanisms. 3 pts Standardized with explicit boundary criteria per level, monitored across sites, and calibrated to ensure inter-rater reliability.

06

If asked to provide a clean, labeled dataset for an AI proof-of-concept today, what would that require?

1 pt A massive manual salvage effort to collect and normalize disparate records, with low confidence in data accuracy. 2 pts A database export that still requires extensive manual cleaning, schema mapping, and expert verification before modeling. 3 pts An automated query generating a structured, labeled dataset (e.g. 3 years of near-misses) directly from standardized schemas.

07

How integrated is your EHS data with other enterprise systems (HR, CMMS, Operations)?

1 pt Completely siloed. EHS records have zero programmatic linkage to employee tenure, shift patterns, or equipment logs. 2 pts Manually bridged. Analysts periodically export spreadsheets and join records using VLOOKUP for ad-hoc quarterly reports. 3 pts Systematically integrated via common keys (Employee ID, Asset Tag) to link incident signals directly with operational context.

Section C

Procurement & Governance

Evaluates software procurement models, milestone definitions, and lifecycle maintenance planning.

08

How does your organization approach the procurement of enterprise EHS software?

1 pt Rigid RFP process scoring checkbox features, demanding fixed timelines and turnkey delivery from day one. 2 pts Traditional waterfall delivery, with a planned "Phase 2" contingency for future customization requests. 3 pts Strategic technical partnership structured for iterative deployment, ongoing data model refinement, and active operational pilots.

09

When is an AI implementation considered "complete"?

1 pt When vendor contract delivery sign-off occurs and the module toggle is activated. 2 pts Once user acceptance testing finishes and the tool operates without critical bugs for 90 days. 3 pts Never "complete"—it is treated as an active model requiring continuous drift monitoring, precision auditing, and retuning.

10

What is your long-term plan for model maintenance and accuracy drift?

1 pt Assumed to be covered under generic vendor SLA maintenance with no internal governance responsibility. 2 pts Technical support exists for software bugs, but no protocol exists to audit categorization drift or retrain models. 3 pts Formal governance framework includes scheduled human-in-the-loop review cycles, retraining cadence, and regulatory adaptation.

Section D

Culture & Human-in-the-Loop

Assesses frontline reporting psychological safety and the dedicated bandwidth of safety subject-matter experts.

11

What is the frontline reporting culture in your organization?

1 pt Punitive or guarded. Workers fear disciplinary fallout, resulting in concealed near-misses and corrupted baseline data. 2 pts Neutral and reactive. Reporting is requested, but frontline skepticism about management motives limits disclosure quality. 3 pts Psychologically safe and proactive. Near-misses are actively reported without blame, generating high-signal learning data.

12

What is the commitment level for EHS experts to actively train and validate AI outputs?

1 pt Viewed as administrative overhead. Safety teams are overloaded and expect the technology to run without their input. 2 pts Temporary availability during initial vendor onboarding, with no recurring time allocated for ongoing validation. 3 pts Institutionalized. Expert validation and calibration are formally recognized within EHS leadership time budgets.

The EHS AI Readiness Checklist