Is Your Safety Data AI-Ready? A 2026 Readiness Assessment

AI pilots often stall on the data, not the model

Several EHS and QHSE vendors describe AI features such as predictive leading indicators, computer-vision PPE detection and LLM assistants that draft incident reports; the documented scope differs by product. A feature can look convincing in a demonstration, and a pilot can still stall once it meets real records.

A common reason is the data underneath the feature rather than the algorithm. A near-miss clustering model is only as good as the near-misses you actually captured (see the near-miss reporting guide). A predictive incident-rate model trained on, say, 14 months of inconsistent, free-text records will surface noise, not risk. Before you buy — or expand — an AI module, the highest-return question is not "how good is the model?" but "is our safety data ready to feed one?"

This is a practical readiness assessment: what "AI-ready" means, the six dimensions that decide the outcome, a five-minute scorecard, and how to close the gaps without a two-year data project.

What "AI-ready" actually means

AI-ready EHS data is data an algorithm can learn from without a human re-interpreting every record. In practice, that means it is:

• Sufficient — enough history and volume for the pattern you want to detect

• Structured — consistent fields, categories, and severity scales, not buried in free text

• Trustworthy — reasonably complete, accurate, and de-duplicated

• Connected — reachable through one system or an API, not stranded across five silos

• Governable — traceable, processed on a lawful basis, and defensible under the EU AI Act and privacy law

Miss one dimension and the AI either can't be trained, or it produces outputs you can't act on — or can't legally use.

The six dimensions of AI-ready safety data

1. Coverage and volume. Models learn from examples. Vision models for PPE or exclusion-zone detection need large sets of labelled frames; a predictive leading-indicator model needs a long, consistent history of incidents, observations, and audits, not a single site's quarter. If your reporting culture only captures serious incidents, you have a survivorship problem: the near-misses and unsafe conditions that actually predict harm were never recorded.

2. Structure and taxonomy. Programmes often struggle here. If "slip," "slip/trip," "STF," and "fell on wet floor" are four different free-text values, no model — and no dashboard — can group them reliably. AI-ready data uses a controlled vocabulary: consistent incident types, injury classifications, root-cause categories, and a single severity scale applied the same way across every site.

3. Data quality. Completeness (are mandatory fields actually filled, or is, for example, 40% of "root cause" blank?), accuracy (does severity reflect reality or under-reporting pressure?), and de-duplication (the same event logged in three systems). A model trained on biased or half-empty data will confidently reproduce the bias.

4. Outcomes and labels. Supervised AI needs to know what "good" and "bad" look like. To predict incidents you need near-misses linked to the incidents that followed; to learn root causes you need investigations with a decided cause, not an open action list (see the guide to root cause analysis techniques). If your near-miss and incident data live in unconnected tables, a key AI signal, the correlation between leading and lagging indicators, is invisible.

5. Integration and accessibility. Data trapped in spreadsheets, a legacy permit tool, an HR system, and a separate audit app cannot be joined when a model needs it. AI-ready environments expose data through a unified platform or documented APIs so features can read incidents, observations, training, and asset data together.

6. Governance, privacy, and traceability. Under the EU AI Act, AI systems intended to be used to monitor and evaluate the performance and behaviour of workers, or to allocate tasks based on individual behaviour or personal traits, are classed as high-risk (Annex III, point 4(b)). Providers must meet data governance (Article 10) and record-keeping (Article 12) requirements and design for human oversight (Article 14); employers that deploy such a system must assign human oversight and inform workers and their representatives before using it (Article 26). After the AI Omnibus, Regulation (EU) 2026/1744, these high-risk rules apply from 2 December 2027. You need to know where each data point came from, which GDPR lawful basis covers its use, and whether you can explain and audit a model's output. Safety data is often personal data, so treat it accordingly.

A five-minute readiness scorecard

Score one point for each yes. The thresholds are this assessment's own rules of thumb, not published benchmarks:

1. Do we have at least 2–3 years of incident, near-miss, and observation records?

2. Are incident types, causes, and severity captured from fixed lists, not free text?

3. Are mandatory investigation fields (root cause, corrective actions) filled >90% of the time?

4. Are near-misses and incidents linked to the same location, asset, and activity taxonomy?

5. Can we pull all of it from one system or a documented API without manual exports?

6. Can we say who owns the data, which lawful basis covers its use, and how a model's output would be audited?

• 5–6: AI-ready. Pilots should produce signal, not noise.

• 3–4: Fixable in a quarter. Prioritise taxonomy and linkage before buying advanced modules.

• 0–2: Any AI output will be unreliable. Fix the foundation first — the model is not your problem.

Worked example: scoring a mid-sized manufacturer

This is an illustration with invented figures. A manufacturer with four plants has three years of incident records, but near-misses sit in a separate spreadsheet at two plants and "root cause" is blank on about a third of investigations. Against the scorecard it scores as follows.

Two points out of six lands in the 0-2 band, so the first quarter goes to the taxonomy, the mandatory fields and the near-miss funnel, not to an AI purchase. If those three are fixed, the same company would score five. The scorecard is this assessment's own rule of thumb, so a vendor's stated minimums should be set beside it.

Tests you can run on an export this week

For the wider picture, see the AI in QHSE software page, the capability map for how consistently capabilities are documented, the AI statements study for what the researched profiles say about AI features, and the guide to GDPR and EHS data.

Failure modes to look for

• Free-text everything. Rich stories, zero structure. Great for reading, useless for learning.

• Severity inflation or deflation. Cultural reporting pressure makes the target variable meaningless.

• Siloed near-misses. The best predictive signal sits in a system the incident module can't see.

• "We'll let the AI clean it." Be sceptical of any claim that a model will fix messy data. A model trained on biased records can reproduce the bias in a confident-looking dashboard.

• No baseline. Without knowing your current TRIR/LTIFR trend, you can't tell whether the AI improved anything.

How to get AI-ready without a two-year project

1. Fix the taxonomy first. Adopt (or align to) a standard set of incident, cause, and severity categories and enforce them at data entry. The other steps depend on this one.

2. Make the high-value fields mandatory — location, activity, root cause, corrective action — and validate them at capture.

3. Consolidate the reporting funnel. Move observations, near-misses, and incidents into one incident and observation system so they share a taxonomy and can be linked.

4. Backfill selectively. Don't re-key ten years of history. Re-classify the most recent 24–36 months against the new taxonomy, the 2–3 year history the scorecard above asks for.

5. Write the governance note now. Document data sources, lawful basis, retention, and how AI outputs will be reviewed by a human. You'll need it for both the EU AI Act and your own audit trail.

What to ask a vendor before you sign

• What data volume and history does this AI feature need to be reliable — and what happens below that threshold?

• Does it require a specific taxonomy, and can it map to ours?

• How does it handle missing or low-quality fields — does it flag them or silently guess?

• Can we see the training-data requirements and the model's limitations in writing?

• What governance, explainability, and audit controls ship for EU AI Act compliance?

Put the answers in writing and compare them across vendors. An answer that does not name a minimum data volume or a taxonomy requirement leaves the readiness question open.

FAQ

How much incident data do I need before AI is useful?

It depends on the feature. Vision models (PPE, exclusion zones) need large sets of labelled images but can be pre-trained by the vendor. For predictive leading-indicator models, this assessment's rule of thumb is 2–3 years of consistently categorised incidents, near-misses, and observations across enough sites to see patterns; ask the vendor for its own minimum. Below that, expect descriptive summaries rather than reliable prediction.

Can AI work if our incident descriptions are all free text?

Partially. Modern LLMs can extract structure from free text, which is useful for triage and drafting. But for prediction and trend analysis you still need consistent categories and severity — free text alone produces unstable groupings. Use AI to help build the taxonomy, then enforce it at data entry.

Is our worker safety data allowed to be used to train AI under the EU AI Act?

Often yes, but with obligations. The AI Act lists AI used to monitor and evaluate workers' performance and behaviour as high-risk (Annex III, point 4(b)), with requirements for data governance, human oversight, transparency, and record-keeping that apply from 2 December 2027. Safety records are usually personal data, so the GDPR applies too: you need a lawful basis for the training use (Article 6), consent is rarely valid in employment (EDPB Guidelines 05/2020, paragraph 21), and data minimisation applies (Article 5(1)(c)). Document data sources, purpose, and human review before you deploy.

Should we clean our data first, or let the software do it?

Fix the structure (taxonomy, mandatory fields, linkage) yourself — that's a process problem no model solves for you. Let the software help with the volume work: de-duplication, classification suggestions, and extracting fields from historical free text. Structure first, automation second.

Related reading

• AI in QHSE Software

• Incident Management Software

• Risk Assessment Software

• Data Collection Software

• Best Safety Management Software

• QHSE Software Implementation Guide

Sources

• Regulation (EU) 2024/1689 (the AI Act): Articles 10, 12, 14 and 26 and Annex III, point 4.
• Regulation (EU) 2026/1744 (Digital Omnibus on AI), which moves the application date for Annex III high-risk systems to 2 December 2027.
• Regulation (EU) 2016/679 (GDPR), Articles 5 and 6.
• EDPB, Guidelines 05/2020 on consent under Regulation 2016/679.

Updated 4 October 2026: the AI Act (Annex III point 4(b), Articles 10, 12, 14 and 26), the AI Omnibus date of 2 December 2027, GDPR Articles 5 and 6 and EDPB Guidelines 05/2020 paragraph 21 were re-checked against the primary texts; statements about what vendors ship and what vendors do were reworded, and a worked scorecard example and a short test table were added.

Corrected 23 September 2026: statistics without a primary source were removed or labelled as this assessment's own rules of thumb, and the regulations cited now link to their official texts. The EU AI Act section now gives the provisions it relies on and the 2 December 2027 application date, and the post no longer suggests that worker consent is the basis for using safety data.