How Accurate Is AI at Reading Safety Data Sheets?

The new coating arrived Monday. The foreman wants labels before the crew opens it. The software read the supplier's SDS in a few seconds, and the record says Warning. The PDF says Danger. One field, and it's the one that goes on the label. That's the accuracy question that matters on a jobsite: not a percentage on a vendor's slide, but whether the fields your crew will act on were checked against the sheet.

There is no single accuracy rate for AI reading of safety data sheets, and OSHA sets no accuracy standard for software under 29 CFR 1910.1200. What matters is which fields were checked against the supplier's SDS, whether omissions were counted, and whether a person confirmed the values used for labels and work instructions.

At a glance: No OSHA accuracy standard for software; the SDS duties stay (1910.1200(g)(1), (g)(8)). An accuracy figure is only as good as its method: which documents, which fields, counted how. Omissions count as errors. Check first: product identifier, Section 2, then Sections 4 and 8. A confidence score is not a review. Keep the supplier's SDS as received; the record is a summary.

What an accuracy figure leaves out

Before accepting any number, ask what was counted. A figure can describe whole documents, individual fields, or only the fields the software managed to fill. Those give different answers. A sheet with the right product name and a wrong hazard statement can be "partly correct" by field and a failure by document.

Ask four questions:

1. Which documents? Clean text PDFs, scans, long sheets with composition tables across pages, Spanish sheets. A test on short, clean files says little about a library of faxed scans.
2. Which fields? A correct product name doesn't make a correct ingredient table. A figure for one field isn't a figure for the SDS.
3. Who set the right answers? A test needs the expected answer for each field before the software runs.
4. Were blanks counted? Software that skips hard fields looks better if blanks aren't errors.

The NIST AI Risk Management Framework asks for documented methods and realistic test conditions when accuracy is reported. That's guidance for evaluating AI, not an OSHA rule, and it's a fair standard to hold a vendor to.

Omissions are errors too

A record that carries two correct hazard statements and leaves out a third looks complete. Nothing on the screen is wrong. Checking only what's displayed will never find it.

Compare in both directions: every statement on the SDS should be in the record, and every statement in the record should be on the SDS. A shipped label carries every hazard statement under 29 CFR 1910.1200(f)(1)(iii), so one missing statement is one missing warning. The same goes for pictograms, required on labels by 1910.1200(f)(1)(iv), which Appendix D to 1910.1200 allows on the SDS as a graphic or by name, so a named symbol isn't a missing one. And for the signal word, remember that Appendix C, C.2.1.1, makes Danger take precedence on the label; it doesn't settle a supplier's contradiction. The Danger and Warning guide covers that case.

Which fields to check first

Not every error costs the same. A wrong comma in the supplier's address and a wrong signal word each count as one wrong field in a percentage. Only one of them ends up on a container.

Sections 3, 8, 9 and 16 of Appendix D are where the numbers live: concentrations, exposure limits, physical properties, dates. Check the unit and any qualifier, a "less than" sign or a range, along with the value.

How HazComFast reads an SDS, and who checks it

HazComFast reads the supplier's SDS, scanned or not, English or Spanish, and keeps the PDF attached exactly as received, where employees can open it under 29 CFR 1910.1200(g)(8). A Spanish copy sits next to the English SDS the supplier owes you under 1910.1200(g)(2). Then a person checks it. Before a new product's values are saved, the screen lists each field to compare with the SDS: product name, manufacturer, signal word, hazard statements, first aid, exposure controls and PPE, revision date. Each one has to be ticked, the screen counts what's left, and saving creates a permanent record.

A product whose reading still needs confirmation is marked "Extraction to review" in the inventory, next to its name, so unfinished work is visible before anyone prints a label from it.

On the product page, each value says where it came from: read from the SDS, or changed by a person, with the reviewer's name and the date. When the hazard codes alone don't settle a category, HazComFast says so and lets the SDS decide. It never guesses a pictogram.

The reading itself is tested the way this article recommends. HazComFast keeps a reference set of test SDS built with the expected answer for each field, and its automated tests replay the reading on that set field by field, so a code change that breaks a field shows up as that field failing, not as a lower average.

What happens to a field that's wrong

Decide while the SDS is still open. A value the software misread is corrected from the sheet, and the correction carries your name. A supplier SDS that contradicts itself, or contradicts the drum's label, goes back to the supplier, whose accuracy duty sits in 29 CFR 1910.1200(g)(5): the supplier's SDS has an error explains why you fix your record and not their document.

Hold what depends on the open question, and only that. A label that needs the unresolved signal word waits. The rest of the library doesn't. And if a label was already printed from the old value, correcting the record doesn't change the label on the bottle. Reprint it under the method your program uses for workplace containers, 1910.1200(f)(6).

Related: How to read a safety data sheet · The supplier's SDS has an error · The chemical inventory template

---

Sources & verification: 29 CFR 1910.1200(e)(1)(i), (f), (f)(6), (g)(1), (g)(8), (h); Appendix C, C.2.1.1; Appendix D; NIST AI Risk Management Framework, "Valid and Reliable". General guidance, not legal advice.*