Every company that buys chemical products — paints, cleaners, adhesives, lab reagents, coolants — must hold the current safety data sheet for each one and maintain a register of hazardous substances. In practice this means hundreds to thousands of 10–30-page PDFs in many layouts and languages. Document AI reads them, extracts the 16 standardised sections into structured data, detects revised versions and keeps the register, risk assessments and ERP master data consistent, with a human releasing every change.
Problem & value
- Today: EHS/safety officers, lab managers or the quality department receive SDS by email, supplier portals or with the goods, then retype product name, classification, H/P statements, storage class, limit values and PPE into Excel or an EHS system. Revisions are missed, outdated sheets stay in use and registers drift away from reality. In SMBs this is often one person's side task.
- Legal anchor: REACH Art. 31 and Annex II (as amended by Regulation (EU) 2020/878) fix the 16-section format; suppliers must update sheets when new hazard information appears. In Germany the employer must keep a hazardous-substance register (Gefahrstoffverzeichnis, GefStoffV § 6) and base the risk assessment on the SDS information [1][2][3].
- AI value: standardised section headings make SDS an ideal extraction target; multilingual VLMs remove the template effort that made earlier tools brittle. Benefits are fewer overdue or missing sheets, faster onboarding of new products and a register that is auditable. No reliable public benchmark of time savings exists; measure your own baseline (see KPIs).
Variants
- Manufacturing SMB / workshop: inbox + shared folder → register in Excel or EHS tool, link to operating instructions (Betriebsanweisungen).
- Laboratories (university, pharma, contract labs): thousands of small-volume reagents; link to LIMS / inventory and storage-compatibility rules.
- Chemical distributors and formulators: inbound SDS from raw-material suppliers feed own SDS authoring (and ESDS exposure scenarios); product-compliance teams.
- Construction and trades: site-specific lists per project, mobile access to current sheets.
- Public sector: schools, universities, fire brigades, municipal depots.
- Private use: not relevant beyond reading a consumer product's SDS (e.g. via a general assistant).
How it works
- intake (email / supplier portal / eSDScom XML / upload / goods receipt)
- format detection (machine-readable XML?
- parse | PDF/scan
- document AI)
- OCR + layout parsing, section segmentation (1–16), language detection
- field extraction against a schema (identifiers, H/P codes, composition with CAS/EC and ranges, physical data, limit values, ADR data, storage class, PPE, revision date)
- validation (code lists: H/P statements, CAS checksum, pictogram–signal word consistency, section completeness, version/date vs. register)
- diff against previous revision of the same product
- register update proposal
- review by EHS officer
- release
- downstream: risk assessment draft, operating instruction, storage-class check, ERP/LIMS fields
- Extraction: a VLM or parser that returns JSON per section; H/P statements, CAS numbers and pictogram codes are closed vocabularies, so rule-based validation catches most errors.
- Matching: product identification (trade name + supplier + article number) to existing register entries decides "new", "revision" or "duplicate".
- Human-in-the-loop: the responsible person approves every new or changed register entry; classification data are taken over from the supplier, never re-derived by the AI.
Data preparation
Needed data: safety data sheets as PDFs from suppliers (often sent by e-mail or downloaded from supplier portals), the list of used products and substances, storage locations, quantities and the existing hazardous-substance register (often an Excel sheet). They live in mailboxes, file shares, the ERP purchasing module and sometimes in paper folders at the workplace.
Typical gaps: outdated SDS versions, several revisions of the same product, scans without text, missing SDS for products in use, different names for the same product, and no link between a product and its place of use. Formats are standardised (16 sections under REACH Annex II), which makes extraction easier than with free documents.
Preparation steps: inventory all products in use together with the departments (PREP-003, PREP-002); collect current SDS from suppliers and request missing ones; digitise paper SDS with OCR (PREP-006); consolidate the register into a tidy table with a unique product key (PREP-011); define the fields to extract and the categories (PREP-019); and set up a file structure with product metadata (PREP-010). Extraction itself is covered by DOC-014.
Effort share is medium, roughly 30 to 40 percent, mostly for finding the current SDS and cleaning the register. See GUIDE-003.
Implementation paths
Which path for whom
- smb: Path A, because mature SDS and hazardous-substance management products exist at SMB prices and the process (register per ChemG, GefStoffV) is standard.
- enterprise: Path A, because EHS suites with SDS extraction are commodity functions; extend with B only for custom ERP integration.
- developer: Path B, because integrators combine document-extraction APIs with the customer's ERP and substance master data.
Path A — Buy (recommended for most SMBs)
- EHS / Gefahrstoff software with SDS import: Quentic (DE, EHS suite with hazardous-substance management), Sphera, Verisk 3E, Enhesa and similar suites; several offer SDS parsing or a managed SDS-data service run by the vendor. Verify per vendor whether extraction is AI-based or a human-curated service, and whether data hosting is in the EU.
- SDS management tools: SDS Manager, NextSDS and comparable SaaS offer SDS repositories, update tracking and automatic data extraction; check language coverage and export to ERP.
- Choose A when: < a few thousand products, a standard EHS suite is acceptable and no special ERP integration is needed. Always run a pilot with your own sheets, including scanned legacy ones.
Path B — Build on cloud APIs
- Parsing: Azure AI Document Intelligence (layout model, EU regions), Google Document AI (EU), Mistral OCR (EU provider), or a multimodal frontier model (Claude, Gemini, GPT) with structured outputs.
- Extraction: page images or markdown + JSON schema per section; separate small prompts for composition tables and H/P lists work better than one prompt for 20 pages.
- Integration: n8n / Power Automate / small service; write to Excel/SharePoint, EHS tool API or ERP.
- Choose B when: you need custom register fields or want to feed an existing in-house tool.
Path C — Self-host (open source)
- Parsing: Docling (IBM), PaddleOCR / PaddleOCR-VL, MinerU, olmOCR; table structure for composition tables.
- Extraction: open VLMs/LLMs (e.g. Qwen3-VL, Mistral/Mixtral-class or Llama-class models) via vLLM or Ollama with constrained JSON output; multilingual coverage matters (SDS exist in all EU languages).
- Stack: PostgreSQL for the register, n8n for workflow, optional vector search over SDS text for Q&A.
- Hardware: HW2 is enough: SDS volume is low (hundreds of documents per month). A shared server may also serve DOC-001/DOC-014. Needed when supplier formulations are treated as trade secrets.
Path D — Custom training
Rarely worthwhile. Fine-tuning a small model on corrected extractions (a few hundred sheets from your own suppliers) can help for exotic layouts or to run on CPU; start with prompting and schema validation.
State of the art (2026)
- Standardised structure helps: all 16 section headings and the H/P statement catalogue are fixed, so extraction is largely section segmentation + closed-vocabulary checks. Composition tables (ranges, multi-component mixtures), limit-value tables with several countries, and ADR transport data are the usual weak points.
- Machine-readable exchange: industry standard eSDScom (XML-based, promoted by the chemical industry) exists for supplier-to-customer exchange; adoption is uneven, so PDF extraction remains necessary. The revised CLP Regulation (EU) 2024/2865 additionally strengthens digital provision of information [4][5].
- Extended SDS (ESDS) with exposure scenarios as annexes are long, partly free-text documents; extract scenario identifiers and conditions of use, but have an expert interpret them.
- Limits: a VLM can confuse a list of "H" codes of different components, skip a table row, or invent a missing CAS number. Never let the AI derive classification (CLP) itself; take supplier data and flag inconsistencies. Scanned old sheets and non-Latin layouts need extra review.
Shared resources & combinations
- Same stack (ocr-docparse + vlm + llm-general): DOC-001 invoices, DOC-014 PDF-to-structured data and DOC-003 forms; one VLM server serves all.
- Neighbouring documents: DOC-019 quality certificates and test reports (different content, same pipeline); DOC-008 mailroom classification can route incoming SDS to this process.
- Related compliance: DOC-027 label/packaging proofing (CLP labels), SCI-015 in-silico toxicology and chemical safety assessment (inputs for substances without data).
- Shared building blocks: workflow engine, translation, validation against code lists, master-data matching (also used in procurement and ERP data quality).
Effort, cost & KPIs
- Path A: days to weeks for setup plus initial import of the existing sheet archive; subscription per user or per product count.
- Path B: 1–2 months for a pilot with register export; API cost is small for the low document volume.
- Path C: 2–3 months including ops; one GPU server shared with other document use cases.
- KPIs: share of products with current SDS (age < 5 years or latest revision), field-level accuracy on a labelled sample, time from receipt to released register entry, number of revisions detected, overdue risk assessments, share of fields corrected in review.
People & change
Involve management (responsibility for hazardous substances lies with the employer), the head of EHS or the safety officer as process owner, purchasing, and the employees who handle the substances. Add IT for integration and storage, and suppliers for current SDS. Legal/compliance checks duties under GefStoffV and CLP. A data protection officer is rarely needed, as the data is product data; involve them if names of employees appear in the register.
Works council: no, as a rule, because the system processes product documents and not employee behaviour or performance. Still inform it in good time under §90(1) no. 3 BetrVG where work processes change, and note that occupational safety topics are an area where works councils usually support improvements.
AI literacy: AI Act Art. 4 requires measures that support AI literacy (GUIDE-006). Short sessions for safety staff are enough: what the tool extracts, where extraction errors occur (units, hazard statements, concentrations) and that every record needs a human check before it enters the register. Choose a pilot with one site or department and 30 to 50 SDS, compare extracted fields against manual entry, and then roll out (GUIDE-009). Typical concerns are trust in the extracted hazard data and liability. Address them with mandatory human review of H- and P-statements, a visible link to the source page and a periodic spot check (GUIDE-008).
Risks, regulation & compliance
- EU AI Act: minimal risk — no Annex III category; AI literacy duty (Art. 4). If the output were used as a safety component of a regulated product the picture could change, which is not the case for a register.
- GDPR: SDS contain almost no personal data (company contact and emergency phone numbers); no DPIA normally needed. Check supplier portals and employee exposure records, which are personal data.
- Chemical law: REACH Art. 31/Annex II and CLP define supplier duties; GefStoffV and TRGS 400/ TRGS 401 define the employer's duties (risk assessment, register, operating instructions). AI extraction does not shift responsibility — the employer remains liable for correct data [2][3].
- Risks: wrong H-code or storage class leads to wrong protective measures; missed revision leads to outdated assessments; confident extraction of absent data. Mitigations: closed-vocabulary validation, source highlighting on the PDF, mandatory review of safety-critical fields (hazard classes, limit values, PPE), version history and audit log.
Getting started
- Inventory the current register and SDS archive; count products, languages and share of scans.
- Define the target schema (fields of your register, plus H/P codes, CAS, storage class, revision date).
- Pilot 2–3 tools (Path A) or a Docling + VLM prototype with 50 of your own sheets; measure field accuracy.
- Introduce the review step and a rule for who releases changes; add revision-date monitoring.
- Connect downstream: risk assessment templates, operating instructions, ERP/LIMS fields.
Sources
Note: compiled in 2026-10 from established primary legal texts and project documentation; live web research was unavailable in this run, so each URL should be re-checked before publication. 1. Regulation (EC) No 1907/2006 (REACH), Art. 31 and Annex II — https://eur-lex.europa.eu/eli/reg/2006/1907/oj 2. Gefahrstoffverordnung (GefStoffV), § 6 — https://www.gesetze-im-internet.de/gefstoffv_2010/__6.html 3. BAuA — Technische Regeln für Gefahrstoffe (TRGS 400) — https://www.baua.de/DE/Angebote/Rechtstexte-und-Technische-Regeln/Regelwerk/TRGS/TRGS-400.html 4. Regulation (EU) 2024/2865 (CLP revision) — https://eur-lex.europa.eu/eli/reg/2024/2865/oj 5. ECHA — Safety data sheets — https://echa.europa.eu/safety-data-sheets 6. Docling project — https://github.com/docling-project/docling 7. PaddleOCR — https://github.com/PaddlePaddle/PaddleOCR 8. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj