KI im Bereich QHSE: Was sie tatsächlich gut kann – und wohin Ihre Daten fließen

Jeder Anbieter von QHSE-Software hat mittlerweile eine KI-Präsentationsfolie im Programm. Nur sehr wenige von ihnen können Ihnen jedoch sagen, wohin Ihre Unfallberichte gelangen, sobald das Modell sie ausgewertet hat. Diese zweite Frage ist wichtiger als die erste, da Unfall- und Arbeitsschutzdaten keine gewöhnlichen Geschäftsdaten sind und sich die Vorschriften für den Einsatz von KI am Arbeitsplatz in diesem Sommer erneut geändert haben.

Was KI im QHSE-Bereich heute tatsächlich gut kann

Lässt man die Demos einmal beiseite, gibt es derzeit drei Aufgabenbereiche, in denen ein Sprachmodell seinen Platz in einem QHSE-System verdient. Alle drei folgen dem gleichen Muster: Es gehen große Mengen unstrukturierter Texte ein, und ein Mensch muss diese erst in eine strukturierte Form bringen, bevor daraus etwas Nützliches entstehen kann.

Eingehende Sendungen sortieren

Ein um 6 Uhr morgens aus einem Lager gemeldeter Beinaheunfall trifft in Form von drei auf einem Smartphone getippten Sätzen ein. Jemand muss entscheiden, ob es sich um einen Beinaheunfall oder einen Vorfall handelt, zu welchem Standort und welchem Prozess er gehört, unter welche Risikogruppe er fällt und wer dafür zuständig ist. Ein Modell führt diese Einstufung gut und konsistent durch – genau das ist der Teil, mit dem Menschen an zwölf Standorten und in vier Sprachen zu kämpfen haben. Der Mensch bleibt beim Genehmigungsschritt: Das Modell schlägt vor, der QHSE-Verantwortliche bestätigt.

Zusammenfassung eines Prüfberichts oder eines umfangreichen Dokuments

Eine interne Revision liefert vierzig Seiten Notizen, die höchstens drei Personen jemals lesen werden. Ein Modell wandelt diese innerhalb weniger Sekunden in eine Liste mit Feststellungen, eine Einstufung nach Schweregrad und einen Entwurf für einen Maßnahmenplan um. Der Gewinn liegt nicht in der eingesparten Schreibzeit. Er besteht vielmehr darin, dass die Zusammenfassung tatsächlich erstellt wird, anstatt bis zur nächsten Managementbewertung in einem Ordner zu verstauben.

Das lesen, was nie getippt wurde

OCR in Kombination mit einem Modell ist der stille Gewinner unter den dreien. Sicherheitsdatenblätter, Lieferantenbescheinigungen, Typenschilder von Geräten, handschriftliche Prüfprotokolle, eingescannte Genehmigungen: All das sind Texte, die Ihr System derzeit nicht durchsuchen kann. Allein schon das Extrahieren von Ablaufdaten aus Lieferantenbescheinigungen erspart eine ganze manuelle Überwachungsaufgabe – und genau diese Art von Arbeit bleibt oft unbemerkt liegen, wenn niemand Zeit dafür hat.

Was noch nicht so gut funktioniert

Unfälle vorhersagen. Anbieter vermarkten prädiktive Sicherheitsanalysen auf der Grundlage von Datensätzen, die viel zu klein und viel zu verzerrt sind, um dies zu untermauern. Ein Standort mit elf meldepflichtigen Vorfällen über einen Zeitraum von drei Jahren enthält kein prädiktives Signal, und ein Modell, das aufgefordert wird, ein solches zu finden, wird dennoch eine sichere Antwort liefern. Betrachten Sie jede Behauptung zur Vorhersagbarkeit als eine Frage nach den Trainingsdaten: Wie viele Ereignisse, über welchen Zeitraum, von wie vielen vergleichbaren Standorten?

Eine Entscheidung eigenmächtig treffen. Eine Korrekturmaßnahme abschließen, einen Prüfungsbefund als konform bewerten, eine Arbeitsgenehmigung erteilen: Das sind Entscheidungen, für die jemand die Verantwortung trägt. Jemand muss namentlich dafür verantwortlich sein, und dieser Jemand darf kein „Modell“ sein. Das ist nicht nur eine bewährte Praxis. Wenn Ihr System das Verhalten der Mitarbeiter bewertet, konzentriert sich hier auch das regulatorische Risiko, wie wir im Folgenden sehen werden.

Arbeiten ohne Kontext. Ein allgemeines Modell kennt weder Ihre Risikotaxonomie noch Ihre Standortcodes noch den Unterschied darin, wie Ihr Wartungsteam und Ihr Arbeitsschutzteam den Begriff „Vorfall“ verwenden. Ohne diese Grundlage liefert es Antworten, die zwar richtig aussehen, aber eine falsche Klassifizierung vornehmen. Die Lösung liegt in der Abfrage Ihrer eigenen strukturierten Daten, nicht in einem größeren Modell.

Warum Ihre QHSE-Daten einer strengeren rechtlichen Kategorie unterliegen

Dies ist der Teil, der in den meisten Gesprächen zur Beschaffung von KI-Lösungen übersehen wird. Gemäß der DSGVO stellen gesundheitsbezogene Daten eine besondere Kategorie personenbezogener Daten im Sinne von Artikel 9 dar, und ihre Verarbeitung ist verboten, sofern keine spezifische Ausnahme vorliegt. Im arbeitsrechtlichen Kontext kommt in der Regel die Ausnahme zur Anwendung, die Verpflichtungen im Bereich des Arbeits- und Sozialversicherungsrechts abdeckt. Diese Ausnahme ist an Bedingungen geknüpft: Sie gilt nur, wenn das Recht der Union oder eines Mitgliedstaats oder ein Tarifvertrag die Verarbeitung zulässt und angemessene Garantien vorsieht. Die rein medizinische Verarbeitung fällt wiederum unter eine andere Ausnahme und unterliegt in Frankreich als Teil des arbeitsmedizinischen Dienstes der ärztlichen Schweigepflicht. Ihr Datenschutzbeauftragter sollte bestätigen, auf welcher Rechtsgrundlage jedes Ihrer QHSE-Register tatsächlich beruht, da nicht alle auf derselben Grundlage beruhen.

Schauen Sie sich einmal an, was ein QHSE-System eigentlich umfasst. Ein Unfallbericht nennt den Namen eines Mitarbeiters, beschreibt eine Verletzung und hält oft auch die weiteren Maßnahmen fest. Eine Akte zu Berufskrankheiten enthält per Definition Gesundheitsdaten. Ein Expositionsregister verknüpft einen identifizierten Arbeitnehmer über Jahre hinweg mit einem krebserregenden oder chemischen Stoff. Eine Diensttauglichkeitsbeschränkung ist eine für eine namentlich genannte Person vermerkte Arbeitsbeschränkung, die auf einem medizinischen Gutachten basiert, über das Ihre Organisation selbst nicht verfügt. Nichts davon sind gewöhnliche Betriebsdaten, und nichts davon sollte mit derselben Nachlässigkeit behandelt werden wie ein Projekt-Tracker.

Daraus ergeben sich drei praktische Konsequenzen, die unabhängig davon gelten, ob Sie KI einsetzen oder nicht:

• Der Zugriff muss wirklich eingeschränkt werden – nach Rolle, Standort und Abteilung –, und nicht durch eine Konvention für gemeinsame Ordner, von der sich mittlerweile alle entfernt haben.
• Änderungen müssen nachvollziehbar sein. Wer eine Verletzungsbeschreibung wann geändert hat, ist eine Frage, die Ihnen früher oder später gestellt wird – sei es von einem Inspektor, einem Betriebsrat oder einem Anwalt.
• Die Frage, wo sich die Daten physisch befinden, wird zu einer echten Herausforderung und ist keine reine IT-Formalität mehr. In Frankreich dient die HDS-Zertifizierung als Referenzrahmen für das Hosting personenbezogener Gesundheitsdaten und stellt eine angemessene Messlatte dar, an der ein QHSE-Anbieter gemessen werden kann – selbst dort, wo die Verpflichtung umstritten ist.

Fügt man diesem Szenario noch ein Sprachmodell hinzu, hat man damit einen neuen Prozessor, eine neue Datenübertragung und eine neue Kopie der sensibelsten Daten, über die man verfügt, geschaffen. Damit kommen wir zu der einzigen Frage, die wirklich zählt.

Die Frage, die man jedem Anbieter stellen sollte: Wohin geht die Eingabeaufforderung?

Wenn Ihr QHSE-Tool die Möglichkeit bietet, einen Unfallbericht zusammenzufassen, verlassen bestimmte Daten Ihr System. Der Text dieses Berichts, einschließlich des Namens und der Verletzung, wird an den Ort weitergeleitet, an dem das Modell ausgeführt wird. Stellen Sie drei Fragen: Welcher Anbieter, in welchem Land und unter welchen vertraglichen Bedingungen hinsichtlich Datenspeicherung und Schulung?

Es gibt eigentlich nur drei Architekturen auf dem Markt, und der Unterschied zwischen ihnen liegt nicht in der Leistung. Es geht um die Sichtbarkeit.

Der Grund, warum Geografie keine Paranoia ist, ist der US-amerikanische CLOUD Act, der es US-Behörden ermöglicht, mit einem Durchsuchungsbefehl oder einer Vorladung einen der US-Gerichtsbarkeit unterliegenden Anbieter zu zwingen, Daten vorzulegen, die sich in seinem Besitz, seiner Verwahrung oder unter seiner Kontrolle befinden – einschließlich Daten, die auf Servern außerhalb der Vereinigten Staaten gespeichert sind. Beachten Sie, dass das Kriterium die US-Gerichtsbarkeit und nicht der Sitz des Unternehmens in den USA ist, was weiter gefasst ist, als die meisten Menschen annehmen, und dass dies auch Daten umfasst, die sich im Besitz von Tochtergesellschaften befinden. Das Gesetz sieht zwar vor, dass ein Anbieter einen Antrag auf Aufhebung stellen kann, wenn die Offenlegung im Widerspruch zu ausländischem Recht stünde, doch handelt es sich dabei um ein Verfahren, auf das Sie keinen Einfluss haben. Dies ist eher ein Risiko im Zusammenhang mit der gerichtlichen Zuständigkeit als eine Sicherheitslücke, und eine vom Anbieter verwaltete Verschlüsselung im Ruhezustand behebt dieses Problem nicht, da der Anbieter die Schlüssel besitzt.

Noch eine Anforderung, die fast niemand erfüllt, die aber bei Wirtschaftsprüfern immer mehr Anklang findet: ein Protokoll über jeden KI-Aufruf. Welches Dokument, welches Modell, welcher Nutzer, wann. Damit lässt sich der Anspruch „Wir setzen KI verantwortungsbewusst ein“ tatsächlich nachweisen.

Das KI-Gesetz in seiner Fassung vom Oktober 2026

Die rechtlichen Rahmenbedingungen haben sich in diesem Sommer geändert, sodass viele der veröffentlichten Leitfäden mittlerweile veraltet sind. Hier finden Sie den aktuellen Stand in leicht verständlicher Form.

Das EU-KI-Gesetz stuft bestimmte Systeme, die im Bereich der Beschäftigung und des Personalmanagements eingesetzt werden, gemäß Anhang III Nummer 4 als risikoreich ein, darunter auch Systeme zur Überwachung und Bewertung der Leistung und des Verhaltens von Arbeitnehmern. Das „Digital Omnibus“-Paket zur KI, das am 16. Juni 2026 vom Parlament und am 29. Juni 2026 vom Rat verabschiedet wurde und seit Juli in Kraft ist, hat die Verpflichtungen für eigenständige Hochrisikosysteme gemäß Anhang III auf den 2. Dezember 2027 verschoben. Für KI, die in Produkte eingebettet ist, die bereits unter die EU-Sicherheitsvorschriften fallen, gilt eine Frist bis August 2028. Die Transparenzpflichten gemäß Artikel 50, einschließlich der Information der Nutzer darüber, dass sie mit einem KI-System interagieren, gelten ab dem 2. August 2026, wobei für die maschinenlesbare Kennzeichnung generierter Inhalte auf bereits auf dem Markt befindlichen Systemen eine Übergangsfrist bis zum 2. Dezember 2026 gewährt wird. Die verbotenen Praktiken sind seit Februar 2025 in Kraft. Beachten Sie, was das Omnibus-Gesetz nicht getan hat: Es hat weder die Kategorie „Beschäftigung“ eingegrenzt noch die Klassifizierungskriterien geändert. Es wurden lediglich die Termine verschoben.

Es gibt zwei Interpretationen davon, und die zweite ist die nützliche.

Erstens: Die meisten QHSE-Anwendungen von KI sind nicht mit hohen Risiken verbunden. Die Zusammenfassung eines Auditberichts, das Extrahieren eines Datums aus einem Zertifikat, die Einstufung eines eingehenden Vorfalls nach Risikokategorie – nichts davon dient der Bewertung eines Mitarbeiters. Sie schaffen kein risikoreiches System, wenn Sie Ihre Dokumentendatenbank um OCR erweitern.

Zweitens: Sobald Ihr System Mitarbeiter hinsichtlich ihres Sicherheitsverhaltens bewertet, Teams anhand der Unfallhäufigkeit in Bezug auf karrierebezogene Aspekte einstuft oder Einzelpersonen als Risikoprofile kennzeichnet, fallen Sie höchstwahrscheinlich unter Anhang III. Artikel 6 Absatz 3 sieht zwar eine Ausnahmeregelung für Systeme vor, die lediglich eine eng gefasste verfahrenstechnische Aufgabe erfüllen oder den Ausgang einer Entscheidung nicht wesentlich beeinflussen, doch um sich darauf berufen zu können, sind eine dokumentierte Bewertung und Registrierung erforderlich – es handelt sich also um eine Schlussfolgerung, die Sie schriftlich festhalten müssen, und nicht um eine Annahme, von der Sie einfach ausgehen können. Die Verschiebung auf Dezember 2027 ist eine Frist, um dies richtig zu machen, und keine Erlaubnis, es zu überspringen. Organisationen, die für jede KI-Funktion eine Modellkarte, einen menschlichen Genehmigungsschritt und ein Entscheidungsprotokoll führen, werden die Frist 2027 als reine Formalität betrachten. Organisationen, die dies nicht tun, werden ein Quartal damit verbringen, nachzuvollziehen, was ihr Anbieter getan hat.

Sieben Fragen, die Sie Ihrem Anbieter stellen sollten

Drucken Sie das aus und nehmen Sie es zu Ihrer nächsten Demo mit. Anhand der Antworten lässt sich sehr schnell erkennen, ob es sich um ein seriöses Programm oder nur um eine KI-Präsentation handelt.

1. Welches Modell verarbeitet meine Eingaben, und wo wird es gehostet?

   Sie möchten den Namen eines Anbieters und ein Land wissen, nicht „ein führendes LLM“ oder „die Cloud“.

2. Werden meine Inhalte zum Trainieren von Modellen verwendet?

   Verlangen Sie dies im Vertrag, nicht in den FAQ. Die Richtlinien in der Produktdokumentation können sich ohne Vorankündigung ändern.

3. Kann ich je nach Anwendungsfall einen anderen Modus wählen?

   Die Übersetzung einer Anleitung und die Zusammenfassung eines Unfallberichts sollten nicht auf derselben Architektur basieren müssen.

4. Gibt es ein Protokoll über jeden KI-Anruf?

   Dokument, Modell, Benutzer, Zeitstempel. Das sind Ihre Nachweise für das nächste Audit.

5. Wo findet die manuelle Freigabe statt?

   Wenn ein Modell eine Aktion eigenständig abschließen oder einen Befund eigenständig bereinigen kann, handelt es sich dabei um ein Designproblem und nicht um eine Funktion.

6. Gibt es eine Funktion, mit der einzelne Mitarbeiter bewertet werden können?

   Falls ja, fragen Sie direkt nach, wie sich der Anbieter auf die ab Dezember 2027 geltenden Verpflichtungen gemäß Anhang III vorbereitet.

7. Wer unterliegt in dieser Kette dem CLOUD Act?

   Einschließlich Unterauftragsverarbeiter. Die Antwort unterscheidet sich oft von derjenigen, die sich auf die Hauptplattform bezieht.

Wie TimeTonic dabei vorgeht

TimeTonic bietet die drei oben genannten Architekturen an und ermöglicht Ihnen die Auswahl je nach Anwendungsfall: KI in der öffentlichen Cloud für gewöhnliche Inhalte, souveräne KI in Frankreich sowie einen dedizierten KI-Server, wo immer Ihre Branche oder Ihre Kunden dies erfordern. Ihre Daten fließen niemals in die Modelle Dritter ein, das Hosting ist HDS-zertifiziert und jeder KI-Aufruf wird protokolliert. Die Berechtigungen werden nach Rolle, Standort und Abteilung vergeben – ein Aspekt, der für die Unfallprotokollierung entscheidend ist, lange bevor überhaupt ein Modell zum Einsatz kommt. Eine ausführliche Beschreibung der drei Modi finden Sie in unserem vollständigen Leitfaden zum TimeTonic-KI-Angebot.

Häufig gestellte Fragen