Who's Liable When an AI Safety Platform Misclassifies an OSHA-Recordable Injury?

Who's Liable When an AI Safety Platform Misclassifies an OSHA-Recordable Injury?

Every EHS software vendor on the market is now selling the same feature: AI that reads an incident narrative and tells you whether it's OSHA-recordable. Recordable versus first aid. DART versus non-DART. Days away, restricted, or transfer. The pitch is consistent across the category — faster classification, fewer inconsistent logs, less time spent arguing about 29 CFR 1904.7 in a conference room.

What none of these vendors advertise is what happens when the model gets it wrong.

And it will get it wrong. Not often, and not dramatically — but recordability determinations sit on judgment calls that even experienced safety managers disagree on: whether a restriction counted as "restricted duty," whether first aid crossed into medical treatment, whether a case is work-related at all under the geographic-presence and causation tests in 1904.5. An AI model trained to pattern-match incident narratives against those tests will occasionally land on the wrong side of a genuinely close call. The question every safety and compliance leader evaluating these platforms should be asking isn't "how accurate is the AI" — it's "when it's wrong, who owns that."

You might also like to read: Is Cursor AI Safe for HIPAA-Compliant Healthcare App Development?

The Regulation Doesn't Care Who Made the Call

29 CFR 1904.32 requires the employer to certify the accuracy of the OSHA 300A annual summary with a company executive's signature. Not the software vendor's signature. Not the AI's confidence score. The certifying official is attesting, under their own name, that they have "reasonably determined" the log is accurate — a standard that assumes a human reviewed the substance of the determination, not just approved a workflow that a vendor built.

If OSHA opens an inspection and finds a case classified as non-recordable that a compliance officer would classify as recordable, the citation goes to the employer. There is no provision in Part 1904 for shifting that citation to a third-party software provider, no matter how the marketing materials describe the tool's role in the decision. Your vendor's terms of service will say the same thing in different words: the platform is a decision-support tool, and the employer remains responsible for the recordkeeping determination. That allocation of risk is standard in every EHS software contract, and it means the "AI-powered" part of the pitch has almost no bearing on where liability actually sits.

This matters because the sales conversation and the compliance conversation are answering two different questions. The sales conversation is about throughput — how many incident reports a safety coordinator can process in a shift, how much faster the 300 log gets built. The compliance conversation is about whether the record that gets submitted to OSHA's Injury Tracking Application will hold up when an inspector or a plaintiff's attorney in a related wage-and-hour or workers' comp dispute pulls the file eighteen months later. Speed and defensibility are not the same feature, and most procurement conversations only evaluate the first one.

You might also like to read: How Healthcare IT Teams Are Accelerating Internal App Development Without Violating HIPAA

Where the Exposure Actually Concentrates

The unreviewed AI determination. Some platforms present the AI's classification as the default and require an affirmative click to override it, rather than requiring an affirmative click to accept it. That design choice matters enormously in an OSHA inspection or a deposition. A determination that a human accepted by doing nothing looks very different, evidentially, from one a human actively reviewed and signed off on. If your platform doesn't produce a record of what the reviewer actually saw and how long they spent on it, "we have an AI-powered system" is not a defense — it may be evidence that no one was actually looking.

The training data problem. Recordability determination models are typically trained on a mix of public OSHA enforcement history and vendor customer data. Neither source is a clean map of the current rule. Enforcement patterns shift with each administration's priorities; a model trained heavily on pre-2023 cases may under-flag categories OSHA has recently started scrutinizing more closely, such as heat-related illness classification under emerging state and federal heat standards, or musculoskeletal disorders in warehouse and logistics settings. A vendor's "AI accuracy" claim is usually benchmarked against historical data, not against how OSHA is currently enforcing the standard.

The multi-establishment consolidation gap. Under 1904.30, each establishment maintains its own log, with specific rules for how travel, temporary reassignment, and remote work affect which establishment a case belongs to. AI systems built for throughput sometimes default an ambiguous case to whichever establishment created the incident report, rather than applying the establishment test correctly. For multi-site manufacturers and logistics operators, this is a more common and more consequential error than a straightforward recordable/non-recordable miss, because it can misstate the DART and TRIR rates OSHA uses to target inspections under its Site-Specific Targeting program.

The rationale gap. A growing number of platforms now generate a written rationale alongside each AI determination — a short explanation citing the relevant subpart. This is a genuine improvement over a bare classification with no reasoning attached, and it's worth asking any vendor whether their tool produces one. But a generated rationale is not the same thing as a human safety professional's judgment, and it should be treated as a starting point for review, not as the record of record. An inspector who asks a safety manager to explain a classification decision expects an answer grounded in that manager's own knowledge of the incident — not a recitation of what the software generated.

You might also like to read: Why Your AI Coding Tools Are Creating a Compliance Blind Spot — And How to Close It Before Your Next Audit

What a Defensible Workflow Actually Requires

The fix here isn't "don't use AI in your safety platform" — the throughput gains are real, and the alternative for most multi-site operations is a safety office perpetually behind on its logs, which carries its own citation risk. The fix is treating the AI's output the way you'd treat a junior analyst's first-pass recommendation: useful, fast, and never the final signature.

A defensible setup requires the reviewer to see the AI's classification and its stated rationale, actively affirm or override it rather than let it default through, and have that review — including how long it took and what, if anything, was changed — captured in a record separate from the underlying incident data. It also means asking your vendor, before you sign, exactly what their determination model was trained on and how recently it was updated to reflect current enforcement priorities, since a stale training set is a compliance gap and vendors are rarely eager to volunteer it. Multi-establishment employers should specifically test how the platform handles ambiguous establishment assignment before rollout, because that failure mode is harder to catch after the fact than a simple recordable miss. And the human who ultimately certifies the 300A needs enough visibility into the classification history to actually stand behind that certification — not a dashboard summary, but the case-level record an inspector would ask to see.

None of this is a reason to slow-walk adopting AI-assisted safety recordkeeping. It's a reason to make sure the certifying signature on your 300A means what OSHA — and, if it comes to it, a court — will assume it means: that a person, not a model, made the call.

This article is intended as general information for safety, compliance, and HR leaders evaluating AI-assisted recordkeeping tools and does not constitute legal advice. Employers should consult qualified counsel when developing or auditing OSHA recordkeeping practices.

Comments

Post a Comment

Popular Posts

How Healthcare IT Teams Are Accelerating Internal App Development Without Violating HIPAA

Image
Healthcare IT leaders are caught between two pressures that don't naturally resolve. On one side: clinical operations, administrative departments, and business units that need internal tools faster than the traditional development cycle can deliver. Scheduling applications, patient communication workflows, compliance reporting dashboards, care coordination tools — the demand for internal software in healthcare organizations has never been higher, and the clinical and operational teams requesting it don't have much patience for long development timelines. On the other side: HIPAA. Specifically, the parts of HIPAA that apply to any software development process that touches protected health information — and in a healthcare organization, most internal apps eventually do. Those two pressures don't have to be in direct conflict. But they are in direct conflict at a lot of healthcare organizations right now, because the tools available to development teams have outpaced the...
Read more

Is Cursor AI Safe for HIPAA-Compliant Healthcare App Development?

Image
If you've landed on this article, there's a good chance someone on your team is already using Cursor — or has asked whether they can. It's a fair question, and it deserves a direct answer rather than the usual hedged non-answer that most compliance content provides. Here it is: Cursor, in its standard configuration, is not designed for HIPAA-compliant software development. That doesn't mean your team can't use AI coding tools in a healthcare environment. It means that Cursor specifically, as a general-purpose AI development tool, introduces compliance considerations that need to be worked through before it touches systems handling protected health information. This article goes through exactly what those considerations are — what Cursor does with your code, where HIPAA creates friction, and what a compliant path to AI-assisted development in healthcare actually looks like. What Cursor Actually Does With Your Code Understanding the compliance question starts ...
Read more

Why Your AI Coding Tools Are Creating a Compliance Blind Spot — And How to Close It Before Your Next Audit

Image
Your developers are moving faster than ever. AI coding assistants are everywhere now — writing boilerplate, suggesting completions, generating entire modules from a comment. Productivity is up. Backlogs are shrinking. Your team is shipping internal apps and automations at a pace that would have been impossible two years ago. And none of it shows up cleanly in your compliance documentation. That gap — between what your AI tools are producing and what your auditors will expect to trace, verify, and approve — is the compliance blind spot that most enterprise IT leaders don't see until they're sitting across from an auditor who's asking questions nobody prepared for. This isn't a hypothetical. It's happening right now in healthcare organizations, financial services firms, manufacturers, and logistics companies across North America. Teams that adopted AI coding tools for the productivity gains are discovering, sometimes at the worst possible moment, that they don't...
Read more

What Payroll Decision-Makers Must Know Before Configuring Payroll for Tipped Hourly Employees

Image
If you have recently inherited a multi-state payroll setup, you already know the feeling. You open the inbox and there is a stack of state tax notices going back months. Some accounts are locked. Some are in states you did not know the company had employees. A few are probably past due. And somewhere under all of it is a login spreadsheet with three different owners' email addresses and passwords that no longer work. This is not a small-company problem or a Controller-competence problem. It is a structural problem with how payroll compliance works in the United States — and it gets worse, not better, the more states you operate in. This article is for payroll decision-makers at service companies managing 20 or more active states, specifically the ones trying to build a process that actually holds up when people leave. Why Multi-State Payroll Tax Management Gets Out of Control State payroll tax compliance is not complicated in any individual state. It is complicated because you have...
Read more

How to Add Employee Wellness Check-Ins to Your Time Clock (Without Adding More Work for HR)

Image
Most HR leaders track two things obsessively: attendance and turnover. What almost nobody tracks is the gap between them, the early warning signs that show up weeks before a good employee quietly checks out, calls in sick more often, or puts in their notice. By the time exit interviews happen, the useful data is gone. There is a touchpoint that already exists in every frontline workplace and gets used by every employee, every single day, often twice: the time clock. Clock-in and clock-out are the only moments HR can guarantee contact with deskless, hourly, and shift-based staff who rarely open a company email or log into an HR portal. And right now, that moment is wasted on nothing more than a timestamp. This article looks at how to turn that daily punch into a two-second wellness check-in, why it works better than surveys or EAP enrollment emails, what questions actually generate useful data without feeling invasive, and how to set it up without creating a new project for an already-s...
Read more