Sicherheitsdatenblätter automatisch erstellen und aktualisieren

Das echte Ausmaß des Problems

Sicherheitsdatenblätter (SDB) sind keine optionalen Unternehmensdokumente. Art. 31 REACH-Verordnung schreibt sie für alle gefährlichen Stoffe und Gemische vor, die in der EU in Verkehr gebracht werden. Wer ein nicht-konformes oder veraltetes SDB liefert, haftet — und zwar nicht nur abstrakt:

• Bußgelder nach Chemikalienrecht (ChemG) reichen bis zu 50.000 Euro je Verstoß
• Produkthaftungsansprüche bei Arbeitsunfällen, bei denen ein fehlerhaftes SDB als Ursache gilt
• Marktausschluss: Industriekunden mit eigenem Gefahrstoffmanagement akzeptieren veraltete SDB schlicht nicht mehr

Das Problem ist nicht, dass Chemieunternehmen das wissen. Das Problem ist, dass die manuelle Pflege bei wachsenden Produktportfolios strukturell überfordert. Ein typisches mittelständisches Chemieproduzenten-Portfolio umfasst 50–500 Produkte, jedes mit 5–30 Inhaltsstoffen. ECHA aktualisiert die Einstufungstabellen für Stoffe mehrmals pro Jahr. Die CLP-Verordnung und ihre Anhänge werden regelmäßig angepasst. Dazu kommen länderspezifische Anforderungen für den Export: Was für den deutschen Markt gilt, entspricht nicht unbedingt den US-amerikanischen OSHA-HazCom-Anforderungen oder den britischen Post-Brexit-Regeln.

Eine einzige SDB-Überarbeitung — manuell, nach aktuellem Standard — dauert erfahrungsgemäß 4–8 Stunden für einen ausgebildeten Chemikanten oder Regulatory-Affairs-Spezialisten. Bei 200 Produkten und zwei vollständigen Überarbeitungsrunden pro Jahr: 1.600–3.200 Stunden. Das sind 0,8 bis 1,6 Vollzeitstellen — allein für das Verwalten eines Dokuments, das eigentlich nur Pflicht erfüllt.

Mit vs. ohne KI — ein ehrlicher Vergleich

¹ Zeitangaben gelten, wenn die Substanzdatenbank vollständig gepflegt ist und Produktrezepturen im System hinterlegt sind. Die Einrichtungsphase — Datenbankbefüllung, Vorlagenkonfiguration — ist der eigentliche Aufwand.

Die Zeitersparnis ist erst dann realisierbar, wenn die Grundlage stimmt: gepflegte Substanzdaten. Das ist der Teil, den viele Unternehmen unterschätzen.

Einschätzung auf einen Blick

Zeitersparnis — sehr hoch (5/5) Die Zeitersparnis ist massiv und täglich spürbar — vor allem bei der Reaktionszeit auf regulatorische Änderungen. Was heute 4–8 Stunden je Produkt kostet, dauert mit einem gut eingerichteten System 30–60 Minuten. Bei 100+ Produkten und mehrmals jährlich anfallenden Einstufungsänderungen ist das eine der größten Zeithebel im gesamten Chemie-Betrieb.

Kosteneinsparung — hoch (4/5) Die direkte Kosteneinsparung durch eingesparte Personalstunden ist erheblich. Dazu kommt die Vermeidung von Bußgeldern und Marktrisiken — die schwerer zu beziffern sind, aber real. Leicht unter dem Maximum, weil die Einrichtungskosten (Substanzdatenbank-Befüllung, Systemlizenz) den Einstieg mit echtem Aufwand verbinden.

Schnelle Umsetzung — mittel (3/5) 8–14 Wochen sind realistisch — nicht so schnell wie ein reines SaaS-Tool ohne Datenintegrationsaufwand, aber auch nicht so lang wie GxP-Validierungsprojekte. Der Engpass ist fast immer die Substanzdatenbank: Wie vollständig sind die Daten? Wie aktuell sind die Rezepturen im System? Dieser Aufwand ist nicht optional.

ROI-Sicherheit — sehr hoch (5/5) Der ROI dieses Anwendungsfalls ist unter allen Chemie-Anwendungsfällen am sichersten: Zeitersparnis ist direkt messbar (Stunden je SDB), regulatorisches Risiko ist quantifizierbar (Bußgeldrahmen bekannt), und der Bedarf an SDB-Pflege entfällt nicht — er bleibt strukturell bestehen. Anders als Innovationsvorhaben ist das ein Pflichtprozess, der optimiert wird.

Skalierbarkeit — sehr hoch (5/5) Das ist das wichtigste Argument für den Einsatz von SDB-Software: Wenn das Portfolio von 100 auf 300 Produkte wächst, skaliert das System mit — ohne proportional steigende Personalkosten. Das gibt dem Produktmanagement die Freiheit, neue Produkte einzuführen, ohne jedes Mal die SDB-Kapazitätsfrage zu stellen.

Richtwerte — abhängig von Produktportfolio-Größe, Exportmärkten und Grad der Substanzdatenbankpflege.

Was das System konkret macht

SDB-Authoring-Software ist keine generative KI im eigentlichen Sinne — und das ist gut so für regulatorische Anwendungen. Das Kernprinzip ist regelbasiert:

1. Substanzdatenbank: Das System hält eine gepflegte Datenbank aller verwendeten Stoffe mit aktuellen GHS/CLP-Einstufungen, H-Sätzen, P-Sätzen und REACH-Informationen. Spezialisierte Anbieter wie Chemwatch pflegen diese Datenbank kontinuierlich und spielen regulatorische Änderungen automatisch ein.

2. Rezepturverknüpfung: Für jedes Produkt ist die Rezeptur (Inhaltsstoffe + Konzentrationsbereiche) im System hinterlegt. Wenn sich die Einstufung eines Inhaltsstoffs ändert, identifiziert das System automatisch alle betroffenen Produkte.

3. GHS-Einstufungsberechnung: Aus den Einzelstoff-Einstufungen berechnet das System automatisch die Gemisch-Einstufung nach CLP-Algorithmus — inklusive Konzentrationsgrenzen und Einstufungshierarchien.

4. Phrasenkatalog-Ausgabe: Aus der Einstufung generiert das System die passenden H-Sätze, P-Sätze und EUH-Sätze sowie die Gefahrenpiktogramme — in allen benötigten Sprachen aus einer zertifizierten Phrasendatenbank.

5. SDB-Generierung: Das fertige Dokument wird im 16-Abschnitt-Format nach REACH Annex II ausgegeben — bereit zur Freigabe und Verteilung.

Generative KI in Form von LLMs spielt eine Ergänzungsrolle: Manche Systeme nutzen sie für Abschnitte, die Freitext erfordern (z.B. Abschnitt 8: Expositionsgrenzwerte und persönliche Schutzausrüstung), und für die Qualitätsprüfung der generierten Texte auf Vollständigkeit und Konsistenz. Das ist eine sinnvolle Ergänzung — der rechtssichere Kern bleibt aber regelbasiert.

Was das System nicht kann

Es prüft nicht, ob deine Rezeptur tatsächlich das ist, was du im System eingetragen hast. Wenn Produktionsänderungen nicht in der Rezepturdatenbank nachgezogen werden, erstellt das System ein konformes SDB — für das falsche Produkt. Die Datenpflege bleibt menschliche Aufgabe.

Rechtliche Besonderheiten: REACH, CLP und die Pflicht zur Aktualität

Die REACH-Verordnung (EG Nr. 1907/2006) und die CLP-Verordnung (EG Nr. 1272/2008) bilden den europäischen Rechtsrahmen. Für Unternehmen, die Chemikalien in der EU in Verkehr bringen, ergeben sich direkte Konsequenzen:

• Aktualisierungspflicht: SDB müssen unverzüglich aktualisiert werden, wenn neue Informationen vorliegen, die Risikobewertung oder Schutzmaßnahmen beeinflussen. “Unverzüglich” ist nicht definiert, wird aber regulatorisch als “ohne schuldhaftes Zögern” interpretiert.
• SVHC-Kandidatenliste: Wenn eine Substanz neu auf die ECHA-Kandidatenliste (Substances of Very High Concern) kommt und im Gemisch in Konzentrationen über 0,1 % enthalten ist, muss das SDB aktiv an alle bekannten Abnehmer übermittelt werden.
• Exportmärkte: Wer nach Großbritannien exportiert, benötigt UK-REACH-konforme SDB (nach Brexit eigene Anforderungen). Wer in die USA exportiert, braucht OSHA-HazCom-2012-konforme SDS. Wer nach Australien exportiert, braucht WHS-Regulation-konforme Dokumente. SDB-Software mit internationaler Abdeckung handled diese Variationen automatisch.

Ein fehlerhaftes SDB ist kein Kavaliersdelikt. Nach § 26 ChemG (Chemikaliengesetz) können Ordnungswidrigkeiten mit bis zu 50.000 Euro geahndet werden. Hinzu kommt die produkthaftungsrechtliche Dimension: Wenn ein Abnehmer durch unvollständige Schutzhinweise einen Arbeitsunfall erleidet und das SDB als fehlerhaft erkannt wird, kann das zivile Haftungsfragen aufwerfen.

Konkrete Werkzeuge — was wann passt

Chemwatch — Marktführend für globale Portfolios. Stärken: Zugriff auf über 120 Millionen Substanzdatensätze, GoSDS-Funktion für konforme SDB in 50+ Sprachen, automatische regulatorische Updates. Geeignet für: Unternehmen mit internationalem Produktportfolio und Exportmärkten außerhalb der EU. Einschränkung: Globales Hosting (kein EU-exklusives Datacenter), Preis erst nach Anfrage. Einstiegspaket (Backpack) für kleinere Portfolios.

GeSi³ — Deutsches System mit Datenhaltung in Deutschland. Stärken: Europäischer Phrasenkatalog eSDSphrac, GHS/CLP-Einstufungsberechnung inkl. Gefahrgutklassifizierung (ADR), integriertes Gefahrstoffverzeichnis. Geeignet für: Unternehmen, die primär europäische Märkte bedienen und deutschen Datenhosting-Standard brauchen. SDB-Ausgabe in bis zu 35 Sprachen.

Sphera — Geeignet für Großunternehmen, die SDB-Management in eine umfassendere EHS-Plattform integrieren wollen. Sphera deckt SDB-Erstellung, Gefahrstoffmanagement, EHS-Compliance und Supply-Chain-ESG in einem System ab. Nur wirtschaftlich für Unternehmen ab ca. 500–1.000 Mitarbeitenden mit komplexem EHS-Bedarf. Kosten sechsstellig.

3E / Verisk 3E Protect — Fokus auf internationale Exportkomplexität. Vorkonfiguriert für US-amerikanische (OSHA HazCom 2012), europäische (REACH/CLP) und weitere Rechtsordnungen. Besonders geeignet für Unternehmen, die regelmäßig in mehr als 5 Länder exportieren.

Zusammenfassung: Wann welcher Ansatz

• Primär europäischer Markt, deutsche Datensouveränität gewünscht → GeSi³
• Internationales Portfolio, viele Exportmärkte → Chemwatch oder 3E
• Großes Unternehmen, SDB als Teil eines EHS-Systems → Sphera
• Kleines Portfolio (unter 30 Produkte) ohne Exportbedarf → Überleg, ob manuelle Pflege mit einem strukturierten Excel-Template und direktem ECHA-Datenbankzugriff nicht ausreicht

Datenschutz und Datenhaltung

Sicherheitsdatenblätter enthalten grundsätzlich keine personenbezogenen Daten im DSGVO-Sinne — sie beschreiben Produkte, nicht Personen. Trotzdem sind zwei Datenschutzpunkte relevant:

Rezeptur- und Formulierungsgeheimnisse: Produktrezepturen sind in aller Regel Geschäftsgeheimnisse. Wenn diese in einem externen SDB-System hinterlegt werden, hängt die Datensicherheit vom Anbieter ab. GeSi³ mit deutschem Hosting bietet hier den höchsten Schutzstandard. Bei Chemwatch (globales Hosting) und international agierenden Anbietern: AVV prüfen, Hosting-Region klären.

Kundendaten im Verteilungssystem: Wenn SDB-Software automatisch aktualisierte Dokumente an Kunden und Lieferanten verteilt, werden dort E-Mail-Adressen und Unternehmensangaben verarbeitet. Das ist ein klassischer Fall von Auftragsverarbeitung nach Art. 28 DSGVO — AVV mit dem SDB-Softwareanbieter erforderlich.

Für Unternehmen, die aus regulierten Branchen (Pharma, Medizintechnik) kommen und ihre Rezepturen als hochvertraulich einstufen: On-Premise-Installation oder Private-Cloud-Hosting bei Anbietern wie GeSi³ ist die sicherste Variante.

Was es kostet — realistisch gerechnet

Einmalige Einrichtungskosten

• Substanzdatenbank-Befüllung (Inhaltsstoffe erfassen, Konzentrationsbereiche eintragen): 40–200 Stunden interner Aufwand je nach Portfoliogröße
• Systemkonfiguration, Vorlageneinrichtung, Exportformate: 20–40 Stunden intern oder externer Dienstleister (2.000–5.000 Euro)
• Mitarbeiterschulung: 1–2 Tage je Regulatory-Affairs-Person

Laufende Systemkosten (jährlich)

• GeSi³: Preise auf Anfrage, KMU-Einstieg erfahrungsgemäß ab ca. 3.000–8.000 Euro/Jahr
• Chemwatch (Backpack für KMU): Einstieg ab ca. 2.000–5.000 USD/Jahr; Vollversion deutlich mehr
• Sphera: Nur als Teil der EHS-Plattform, nicht separat kalkulierbar

Konservatives ROI-Szenario (100-Produkte-Portfolio)

• Jährliche Überarbeitungsrunden: 2× (typisch 1 große und mehrere kleine Änderungen)
• Manuelle Zeit je Überarbeitung: 3 Stunden × 100 Produkte × 2 Runden = 600 Stunden
• Mit System: 0,5 Stunden × 100 Produkte × 2 Runden = 100 Stunden
• Ersparnis: 500 Stunden × 40–60 Euro/Stunde = 20.000–30.000 Euro/Jahr
• Amortisationszeit: unter 12 Monate bei typischen Systemkosten

Dazu kommt die nicht-quantifizierbare aber reale Risikoeinsparung: Jedes vermiedene fehlerhafte SDB ist ein vermiedenes Bußgeldrisiko und ein vermiedener Kundenkonflikt.

Wie du den ROI tatsächlich misst Zähle vor der Einführung den Aufwand je SDB (Zeit für Neuerstellung + Zeit für Aktualisierungen) und die Anzahl der Produkte, die in einem Jahr aktualisiert werden mussten. Danach denselben Wert. Die Differenz ist messbar — und für interne Berichte belastbar.

Typische Einstiegsfehler

1. Die Substanzdatenbank nach der Einführung nicht aktuell halten. Das ist der stille Killer dieses Anwendungsfalls. Das System kann nur so gut sein wie die Eingangsdaten. Wenn Produktrezepturen sich ändern — neuer Rohstofflieferant, Substitution eines Inhaltsstoffs — und das nicht in die Datenbank eingetragen wird, erstellt das System weiterhin SDB für die alte Rezeptur. Und das systemgenerierte SDB sieht korrekt aus, ist aber falsch. Lösung: Einen festen Prozess etablieren, bei dem Produktänderungen automatisch ein SDB-Update-Review triggern.

2. Den Unterschied zwischen Substanzdatenbank-Update (automatisch) und Rezeptur-Update (manuell) nicht kommunizieren. Viele Einführungen scheitern an einem Missverständnis: “Das System hält sich selbst aktuell.” Das stimmt für die Einstufungsdaten der Einzelstoffe — wenn der SDB-Anbieter seine Substanzdatenbank pflegt. Es stimmt nicht für die eigenen Produktrezepturen. Die Verantwortung dafür, dass das System weiß, was im Produkt drin ist, liegt beim Unternehmen.

3. Mit zu vielen Produkten auf einmal starten. Der Reflex: Alle 300 Produkte auf einmal einpflegen. In der Praxis führt das zu einem halbfertigen System, in dem 200 Produkte schlecht dokumentiert sind und 100 gut. Besser: Mit den 20–30 umsatzstärksten oder regulatorisch kritischsten Produkten anfangen. Prozess validieren, dann skalieren.

4. Auslandsspezifika vergessen. Wer Produkte nach Großbritannien exportiert, braucht nach Brexit UK-REACH-konforme SDB — nicht einfach die EU-Versionen. Wer in die USA exportiert, braucht OSHA-konforme SDS mit anderen Gliederungsanforderungen. Ein System, das nur EU-Formate produziert, löst das internationale Compliance-Problem nicht vollständig. Vor der Systemauswahl: Exportmärkte auflisten und mit Anbietern klären, welche Rechtsordnungen abgedeckt sind.

Was mit der Einführung wirklich passiert — und was nicht

SDB-Authoring-Software ist technisch gesehen keine KI in dem Sinne, wie ein generativer Assistent KI ist. Das ist ein Vorteil: Die Einführung ist näher an einer ERP-Einführung als an einer KI-Einführung — strukturierter, planbarer, mit klaren Abnahmekriterien.

Die typischen Reibungspunkte sind organisatorischer Natur:

Datenpflege ist Teamarbeit. Regulatory Affairs pflegt die SDB. Aber wer meldet, dass sich eine Rezeptur geändert hat? Das ist Produktionschemie oder Einkauf — nicht Regulatory. Diese Schnittstelle muss definiert sein, bevor das System in Betrieb geht. Ohne sie funktioniert das System technisch, aber die Datenqualität degradiert still.

Wer hat Freigabeverantwortung? In regulierten Betrieben muss jedes SDB von einer fachkundigen Person freigegeben werden, bevor es an Kunden geht. Das ändert sich mit dem System nicht — es ändert sich nur, wie viel Zeit diese Person braucht. Diese Rolle muss klar definiert sein.

Kundenkommunikation bei Updates. Wenn ein SDB sich ändert, müssen Abnehmer informiert werden. Manche Systeme übernehmen das automatisch über ein Kundenportal. Wer das nicht hat, muss einen Prozess für die manuelle Verteilung haben — sonst entsteht der häufige Fall, dass das interne SDB aktuell ist, aber der Kunde noch mit der alten Version arbeitet.

Realistischer Zeitplan mit Risikohinweisen

Häufige Einwände — und was dahintersteckt

„Unsere Rezepturen sind Betriebsgeheimnisse — die geben wir nicht in ein Cloud-System.” Berechtigte Sorge. Die Antwort: Nicht jede SDB-Software ist Cloud-only. GeSi³ bietet On-Premise-Installation mit deutschem Hosting. Für Unternehmen mit strikten Anforderungen an Rezeptursicherheit ist das der richtige Einstiegspunkt. Bei Cloud-Lösungen gilt: AVV, Hosting-Region, Verschlüsselung und Zugriffsprotokoll klären — die meisten seriösen Anbieter können das liefern.

„Ein Fehler im System kann zu einem falschen SDB führen — das ist gefährlicher als manuell.” Das stimmt theoretisch. In der Praxis ist die Fehlerrate bei manuell erstellten SDB erheblich — Flüchtigkeitsfehler, verpasste H-Satz-Updates, falsch berechnete Einstufungen bei Gemischen. Ein korrekt konfiguriertes regelbasiertes System macht diese Fehler nicht. Der Punkt ist berechtigt für den Fall, dass die Substanzdatenbank veraltet ist — deshalb ist deren Pflege so zentral.

„Das lohnt sich erst bei großem Portfolio.” Für sehr kleine Portfolios (unter 20–30 Produkte, wenige Änderungen pro Jahr, kein Export) ist das grundsätzlich richtig. Ab 50+ Produkten oder wenn Export in mehrere Rechtsordnungen relevant ist, kippt die Rechnung eindeutig zugunsten des Systems.

Woran du merkst, dass das zu dir passt

• Dein Portfolio hat mehr als 50 Produkte und regulatorische Änderungen treffen regelmäßig mehrere gleichzeitig
• Du exportierst in mehrere Länder und brauchst SDB in verschiedenen Sprachen und nach verschiedenen Rechtsordnungen
• Regulatory Affairs verbringt regelmäßig mehrere Tage mit SDB-Überarbeitungen nach ECHA-Updates oder CLP-Anpassungen
• Du hattest in den letzten zwei Jahren mindestens einmal eine Kundenbeanstandung wegen veraltetem oder fehlerhaftem SDB

Wann es sich (noch) nicht lohnt — drei harte Ausschlusskriterien:

1. Unter ca. 30 Produkten, kein Export, stabile Rezepturen. Bei sehr kleinen, stabilen Portfolios ohne Export übersteigt der Einrichtungsaufwand den Nutzen. Eine strukturierte Excel-Vorlage mit direktem ECHA-C&L-Datenbankzugriff ist dann die proportionale Lösung.

2. Substanzdatenbank existiert nicht oder ist völlig unstrukturiert. Ein SDB-System braucht als Eingabe: CAS-Nummern, Konzentrationen, Lieferantendaten. Wer das nicht hat, macht zuerst ein Datenpflegeprojekt — das SDB-System kommt danach.

3. Keine Person, die die Substanzdatenbank dauerhaft aktuell hält. Das System produziert falsche SDB, wenn die Grunddaten falsch sind. Ohne eine verantwortliche Person, die Rezepturänderungen und neue Rohstoffe einpflegt, ist die scheinbare Automatisierung irreführend.

Das kannst du heute noch tun

Mach eine schnelle Bestandsaufnahme: Zähle deine Produkte mit aktiven SDB, prüfe, wann das letzte SDB-Update für die fünf umsatzstärksten Produkte war, und vergleiche das Datum mit der letzten ECHA-Aktualisierung für deren Hauptinhaltsstoffe. Auf echa.europa.eu/de/substance-information kannst du jede Substanz nach CAS-Nummer suchen und sehen, ob es Änderungen in der Einstufung gab.

Wenn du merkst, dass mehrere SDB veraltet sein könnten, ist das ein konkreter Business-Case für das Gespräch mit der Geschäftsführung — realer als jede abstrakte Effizienzrechnung.

Für eine erste SDB-Prüfung ohne Systemeinführung kannst du diesen Prompt nutzen. Er lässt einen KI-Assistenten eine strukturierte Checkliste erstellen — keine rechtlich bindende Prüfung, aber ein schneller erster Scan auf offensichtliche Lücken:

Quellen & Methodik

• REACH-Verordnung: EG Nr. 1907/2006 des Europäischen Parlaments, Art. 31 (SDB-Pflicht) und Annex II (SDB-Inhalt und -Format), konsolidierte Fassung 2024.
• CLP-Verordnung: EG Nr. 1272/2008 über die Einstufung, Kennzeichnung und Verpackung von Stoffen und Gemischen, konsolidierte Fassung 2024.
• Bußgeldrahmen: Chemikaliengesetz (ChemG), § 26 Bußgeldvorschriften. Maximaler Rahmen 50.000 Euro je Verstoß nach § 26 Abs. 1 ChemG (Stand 2024).
• SVHC-Kandidatenliste und Informationspflicht: REACH Art. 33 — Informationspflicht bei SVHC-Stoffen über 0,1 % in Gemischen.
• UK REACH: UK-Chemikalienregulierung nach Brexit (REACH Retained in UK Law, HSE-Administration). Separate SDB-Anforderungen seit 31.12.2020.
• Zeitangaben SDB-Erstellung: Erfahrungswerte aus Regulatory-Affairs-Praxis; keine unabhängige Vergleichsstudie vorhanden. Zahlen von Anbietern (Chemwatch, GeSi) für die automatisierten Systeme.
• GeSi³ Phrasenkatalog: Europäischer Phrasenkatalog eSDSphrac (Stand April 2026, gesi.de).