Welche Herausforderungen birgt das für die Gewährleistung der Sicherheit?

Systeme, die in der Industrie zum Einsatz kommen sollen, müssen nachweislich sicher gestaltet sein (siehe Kapitel 5). Da eine gänzliche Vermeidung jedweder Gefährdung nicht realisierbar ist, gilt es, das Restrisiko unter die noch akzeptierte Schwelle zu drücken. Je höher das mit dem System verbundene Risiko, desto höher sind auch die Sicherheitsanforderungen an das System. Im Industriebereich gilt beim Einsatz risikomindernder Maßnahmen zur sicheren Systemgestaltung nach wie vor das TOP-Prinzip. Zuerst muss die gefahrbringende Maschine inhärent sicher gestaltet sein. Erst danach dürfen organisatorische Maßnahmen greifen, gefolgt von Maßnahmen zum Selbstschutz durch den Menschen. Damit steht der Mensch nicht als Rückfallebene zur Verfügung, um ein etwaiges sicherheitskritisches Systemversagen aufzufangen.

„In der Sicherheitstechnik der Industrieautomatisierung wird der Mensch nicht als risikomindernder Faktor berücksichtigt.“

[Zitat aus dem Expertenkreis für funktionale Sicherheit]

In diesem Faktor unterscheidet sich die Sicherheitsbetrachtung in der Industrie von der Sicherheitsbetrachtung im Automobilbereich, bei der im Rahmen der Risikoanalyse zusätzlich zu den Eintrittswahrscheinlichkeiten und Auswirkungen eines Systemversagens noch die mutmaßliche Kontrollierbarkeit durch den Fahrer berücksichtigt wird. Durch die Annahme seines zeitnahen und angemessenen Reagierens können die Sicherheitsanforderungen an ein System und damit die Aufwände des Sicherheitsnachweises erheblich reduziert werden. In der Industrie hingegen ist eine derartige Teildelegation der Verantwortung an den Menschen für seine eigene Sicherheit selten.

Primat ist folglich die inhärent sichere Gestaltung eines Systems. Voraussetzung für den Einsatz eines Systems ist, dass der Hersteller die Erfüllung der Sicherheitsanforderungen nachweisen kann. Formal erfolgt dieser Nachweis zumeist über die Konformitätserklärung zur Norm und in selteneren Fällen über Freigaben durch offizielle Prüfstellen⁹⁸. In beiden Fällen ist eine Sicherheitsprüfung erforderlich, die einem vorgegebenen Prozess folgt, aber gleichzeitig hinreichend Spielraum zur Ausgestaltung der Prüfung für den jeweiligen Anwendungsfall lässt. Die Kenntnis des Kernprinzips des erforderlichen Prüfprozesses ist elementar, um die Herausforderung nachvollziehen zu können, die mit der Einführung von KI-Systemen für die Sicherheit und insbesondere den Nachweis dieser Sicherheit verbunden sind. Die nachfolgenden Ausführungen beschränken sich auf eine vereinfachte Darstellung dieses Kernprinzips, ohne die Vielschichtigkeit dieses Prozesses im Detail nachzuzeichnen.

98 Anmerkung der Autoren: Der elaborierte Prozess und das Instrumentarium zur Gewährleistung der Sicherheitsanforderungen kann im Rahmen des Berichts nicht näher ausgeführt werden. Die vorliegende Darstellung reduziert die Ausführungen der Experten auf die Kernprinzipien, die beim Einsatz KI-basierter Systeme nicht aufrecht zu erhalten wären.

Das Herzstück der Sicherheitsprüfung ist die Spezifikation, in der die technischen und funktionalen Aspekte des Systems festgehalten sind. Hier werden die Anwendungsfälle des Systems beschrieben und festgehalten, bei welchen Eingaben welche Ausgaben des Systems erfolgen sollen. Die Gesamtheit dieser Funktionen wird anschließend in einzelne Funktionen untergliedert, von denen jede einer spezifischen Überprüfung unterzogen wird. Anschließend erfolgt die schrittweise Zusammenführung zu Funktionsgruppen, die dann auf ihr anforderungsgemäßes Zusammenwirken überprüft werden. Dieses schrittweise Prüfen der Anforderungserfüllung bezeichnet man als Verifikation. Die Verifikation besagt, dass das System der gegebenen Spezifikation folgt und die Prüfergebnisse mit den theoretischen Anforderungen übereinstimmen. Auf die Verifikation folgt im letzten Schritt die Validierung, bei der geprüft wird, ob das finale System in seiner Anwendung die gewünschten Nutzungsziele erreicht.

Elementare Voraussetzung dieses etablierten Sicherheitsnachweises ist demnach die Spezifikation des Systems einschließlich der daraus ableitbaren Zergliederung des Systems in einzeln prüfbare Funktionen. Bei Systemen, bei denen dieser Prüfprozess durchführbar ist, kann der Sicherheitsnachweis erbracht werden. Dazu können unter bestimmten Voraussetzungen (genannt wurden ein begrenztes, nicht variables Einsatzumfeld sowie ein hoher Entwicklungsaufwand) auch Systeme gehören, die im Rahmen der vorliegenden Befragung zumindest von einigen Befragten als KI-Systeme eingeordnet wurden (konkret genannt wurden hier Bayessche Netze). Bei komplexen KI-Systemen wie neuronalen Netzen mit dem im vorherigen Kapitel (3.2.3) beschriebenen Eigenschaftsprofil funktioniert das konventionelle Vorgehen des Sicherheitsnachweises jedoch nicht mehr. Grund dafür ist die datengetriebene Systementwicklung, die zur Beherrschung komplexer Anwendungsfälle genau deswegen eingesetzt wird, weil die explizite Spezifikation zu aufwändig und voraussichtlich fehlerbehaftet wäre, während das datengetriebene Vorgehen eine bessere Erfüllung der Nutzungsziele erreicht als konventionelle Systeme.

„Man setzt neuronale Netze ein, da sie in der Lage sind, zu abstrahieren, von konkreten Problemen zu verallgemeinern, und so muss ich es gar nicht mehr definieren. Wenn ich bspw. von der Personenerkennung im Industriekontext ausgehe, beschreibe ich nicht mehr, was eine Person ist und wie sie aussieht. Das macht es auch schwierig zu überprüfen, wenn ich es nicht genau spezifizieren kann."

[Zitat aus dem Expertenkreis für funktionale Sicherheit]

Diese Spezifikation fehlt jedoch im folgenden Schritt als Grundlage des traditionellen Sicherheitsnachweises. Der Use-Case bzw. die Nutzungsziele sind bekannt (bspw.:

„Personenerkennung“), aber der Einsatzbereich ist nicht konkret definierbar. Die Szenarien können nicht erschöpfend beschrieben werden, wenn man zugrunde legt, dass jeder unberücksichtigte Parameter bzw. jede unberücksichtigte Ausprägung eines Parameters ein neues Szenario bilden können (siehe Kap. 3.2.3). Somit können nicht alle Eingänge in das System benannt und durch darauf zugeschnittene Tests abgeprüft werden. Die bisherigen Testmethoden, die sich im Bereich der Sicherheit

etabliert haben, reichen folglich nicht mehr aus, da sie darauf basieren, eine spezifizierte Eingabe mit einer spezifizierten Ausgabe zu vergleichen.

„Also das ist der Kern der ganzen Diskussion, dass sich die Methodik, an das Testen heranzugehen, sich durch den KI-Einsatz grundlegend ändert. Da, wo wir konkrete, automatisierte Tests definieren konnten, im Sinne von: „Bitte stimuliere mir gewisse Inputs meines Systems mit folgenden verschiedenen Vektoren“. Und diese Vektoren sind auch ausreichend, da ich sie auf eine Spezifikation, eine Anforderung rückführen kann. Genau das funktioniert jetzt nicht mehr. Das ist der Kern der ganzen Problematik. Das liegt aber nicht nur an der KI, sondern auch am komplexen Use-Case des Systems.“

[Zitat aus dem Expertenkreis für funktionale Sicherheit]

Damit ist die Verifikation, die eine Erfüllung der an das System gestellten Anforderungen nachzuweist, nicht mehr durchführbar. Damit fehlt aber das grundlegende Verständnis über die Funktionsweise des Systems, das die Basis des Sicherheitsnachweises bildet. Eine Validierung der KI-Systeme wäre zwar weiterhin möglich, jedoch gilt gemäß dem traditionellen Vorgehen zur Sicherheitsprüfung ein alleiniger Nachweis auf Basis empirischer Feldtests in der Anwendung unter Verzicht auf vorhergehende Verifikation nach den Maßstäben der funktionalen Sicherheit als

„zu instabil."

„Es gibt kein Entwickeln ohne Verifizieren in der Sicherheitstechnik. Das ist etwas, was die funktionale Sicherheit so nicht mehr vorsieht.“

[Zitat aus dem Expertenkreis für funktionale Sicherheit]

Das Kernproblem bei KI-Systemen besteht demnach im Unvermögen, das bei konventionellen Systemen bewährte Vorgehen des Sicherheitsnachweises auf KI-Systeme übertragen zu können und damit das zur Sicherheitsargumentation erforderliche Systemverständnis herzustellen. Nähme man an, es gäbe ein nicht erklärbares KI-System, das stets dasselbe Verhalten zeige wie ein konventionelles System, so ließe sich trotzdem ausschließlich das konventionelle System als sicher verargumentieren.

„Man muss ja Sicherheit irgendwie argumentieren. Und dieses Argumentieren läuft normalerweise direkt oder indirekt über das Systemverständnis.“

[Zitat aus dem Expertenkreis für funktionale Sicherheit]

Unabhängig von der Bedeutung der Sicherheitsargumentation über das Systemverständnis, das elementar für die etablierte Sicherheitsprüfung ist, gibt es auch inhaltliche Gründe, die Inbetriebnahme eines Systems nicht allein von empirischen Tests bzw. Feldtests abhängig zu machen. Schließlich ist nicht vorhersehbar, wie sich das System in all den Situationen verhält, die aufgrund der Komplexität des Anwendungsfalls nicht vorhersehbar waren oder nicht geprüft werden konnten. Daher wird an Ansätzen gearbeitet, die das Wissen um die sichere Bewältigung der Situationen des Anwendungsfalls, das dem datengetriebene

Vorgehen fehlt, entweder im Lernprozess zu gewährleisten oder bei der Überprüfung des KI-Systems nachträglich wiederherzustellen. Zu diesen Ansätzen gehören eine indirekte Spezifikation des Systems über die Beschaffenheit des Lerndatensatzes, Analysen zur Beschreibung und Überprüfung der Systemfunktionalität sowie die mehr oder minder weitgreifende Aufhebung der einst strikten Trennung zwischen Entwicklung und der Inbetriebnahme eines Systems.

Bei dateninferierten KI-Systemen dienen die Daten einerseits dem Anlernen des Systems und andererseits seiner Validierung. Die aus der Validierung ableitbaren Metriken (z. B. Erkennungswahrscheinlichkeit in Prozent) beziehen sich jedoch zwangsläufig auf einen verfügbaren und gelabelten Datensatz und sind nur zu dem Maße auf den Anwendungsfall übertragbar, in dem der Validierungsdatensatz selbigen widerspiegelt. Daher werden hohe Anforderungen an eine vollumfängliche Abbildung des Anwendungsfalls, der erwartbaren Situationen und deren Verteilung im Datensatz gestellt (vgl. UL 4600 „Standard for Safety for the Evaluation of Autonomous Products“

im Automobilbereich). In diesem Kontext hört man oft, dass der Datensatz einschließlich des Labellings die Spezifikation ersetze. Diese Aussage impliziert jedoch zumindest aus Safety-Perspektive keine Gleichwertigkeit zwischen der eigentlich erwünschten expliziten Systemspezifikation, die ein grundlegendes Verständnis der Systemfunktionalität ermöglicht, und einer datenbasierten Spezifikation, bei der die Beschaffenheit der Daten über Performanz und Sicherheit entscheiden. Vielleicht ließe sich auch sagen, die Systematisierung der Daten sei nur ein erneuter Anlauf, etwas zu spezifizieren, das eigentlich zu aufwändig zur Spezifikation ist.

„Die Sicherheit des Systems hängt dann von den Daten ab, die eingesetzt werden.

Das ist ein spezieller Fall, den man normalerweise in einem Safety-Kontext vermeidet.“

[Zitat aus dem Expertenkreis für funktionale Sicherheit]

Das Systemverständnis gilt nicht nur aus Voraussetzung für die Sicherheit, sondern auch bei nicht sicherheitskritischen Anwendungen als Voraussetzung dafür, die Akzeptanz der Nutzer oder die Fairness KI-basierter Entscheidungen sicherstellen zu können. Dieses Verständnis ist, wie in Kapitel 3.2.3 beschrieben, bei komplexen dateninferierten KI-Methoden wie neuronalen Netzen nicht inhärent gegeben. Daher wird an Methoden gearbeitet, diese Black-Box im Anschluss an den Lernvorgang zu durchleuchten, um verstehen zu können, wie sich die Ausgaben des Systems erklären zu lassen. Dazu gehören beispielsweise Ansätze, die nachträglich kenntlich machen, welche Teile eines neuronalen Netzes welche Aspekte eines Bildes als Grundlage seiner Erkennung und Klassifikation nutzt. Andere Ansätze bemühen sich um eine Analyse der Struktur neuronaler Netze, um von der Klassifikation rückwärts aufzuzeigen, wie diese zustande kam. Um diese Bestrebungen entstand unter dem Schlagwort „Explainable AI“ ein breites Forschungsfeld mit bedeutsamen Beiträgen zur verbesserten Nachvollziehbarkeit komplexer KI. Ob diese als ausreichend erachtet wird, hängt vom Anwendungskontext ab. Grundsätzlich gilt, dass bei kritischen

Anwendungsfällen ein höheres Maß an Systemverständnis erforderlich ist als bei unkritischen. Für einen Einsatz in sicherheitskritischen Anwendungen gilt der Grad des durch diese Methoden nachträglich erzielbaren Verständnisses von der Funktionsweise des KI-Systems jedoch als nicht ausreichend.

„Ich kenne keinen Ansatz, der hinreichend genau ist.“

[Zitat aus dem KI-Expertenkreis]

Vorab wurde ausgeführt, dass die Herausforderung beim Einsatz von KI-Systemen nicht darin besteht, dass sie mehr Fehler machen als konventionelle Systeme, sondern darin, dass das zur Sicherheitsargumentation erforderliche Systemverständnis nicht hergestellt werden kann. Die Aussage bezieht sich auf die Problematik des Sicherheitsnachweises und ist in diesem Kontext gültig. Es bedeutet jedoch nicht, dass KI-Systeme per se fehlerfreier funktionieren als konventionelle Systeme. Würde man einen pauschalen Vergleich ziehen wollen, würde man sagen, dass KI-Systeme komplexe Aufgaben wie beispielsweise die Erkennung von Menschen besser lösen als konventionelle Systeme. Konventionelle Systeme werden in ihrer Anwendung jedoch auf das zugeschnitten, was verlässlich umsetzbar und prüfbar ist. Die herausfordernde Aufgabe der Erkennung von Menschen wird daher reduziert auf eine vergleichsweise schlichte, aber mit konventionellen Methoden umsetzbare und prüfbare Unterscheidung zwischen „Hindernis“ und „kein Hindernis“ – mit der Folge, dass auch jedes unbelebte Hindernis einen Stillstand des Systems hervorruft.

„Die meisten sagen, man kriegt die Fehlertoleranz klassischer Safety-Systeme nicht hin. Das liegt auch an der Problemstellung. Der Algorithmus ist natürlich auch fehlerbehaftet, aber Dinge mit Bildverarbeitung zu lösen sind ja komplexere Probleme als das, was man in Sicherheitssystemen sonst implementiert.“

[Zitat aus dem Expertenkreis für funktionale Sicherheit]

Gegenwärtig werden systematische Methoden entwickelt, um der aufgrund der höheren Aufgabenkomplexität geringeren Fehlertoleranz (vgl. Kapitel 3.2.3) zu begegnen. Dazu gehört die gezielte Veränderung der Lerndaten, bspw. durch das Löschen von Pixeln oder durch Erzeugung von Rauschen bei der Bilderkennung, um festzustellen, inwieweit diese Abweichungen bei den Eingaben zu Fehlklassifikationen führen. Beispielsweise können in simulationsbasierten Ansätzen systematisch einzelne Parameter variiert werden, um zu sehen, ob das gewünschte Ergebnis dadurch verändert wird. Bei kleinen neuronalen Netzen können damit auch Robustheitsmetriken erzeugt werden. Je weniger das System durch diese Störungen bzw. Variationen beeinträchtigt wird, desto robuster ist es und desto geringer das Risiko einer Fehlklassifikation bei unvorhergesehenen Situationen oder auch gezielten, böswilligen Manipulationen in der späteren Anwendung. Ein derartiger empirischer Nachweis der Robustheit ist für den Einsatz eines KI-Systems in sicherheitskritischen industriellen Anwendungen jedoch nicht ausreichend für den Sicherheitsnachweis.

„Methoden zur Erhöhung der Robustheit und Analyseansätze [zur Schaffung von Transparenz] gehen in die richtige Richtung, aber sie reichen noch nicht aus, um funktionale Sicherheit nachzuweisen.“

[Zitat aus dem Expertenkreis für funktionale Sicherheit]

Schließlich ist nicht vorhersehbar, wie sich das System in unerwarteten und damit nicht abgeprüften Situationen in der späteren Anwendung verhält. Aus diesem Grund wird eine Fortführung des Lernens über die Inbetriebnahme angestrebt, um das KI-System auf Basis der im Einsatz gesammelten Erfahrungen verbessern zu können. Ein derartiger Ansatz eines im Betrieb veränderbaren Systems löst die strikte Trennung zwischen Implementierung und Inbetriebnahme auf und stellt damit nicht nur eine mögliche Antwort auf die Problematik einer nicht vollständigen Beschreibbarkeit aller denkbaren Situationen des Use-Cases dar, sondern auch eine zusätzliche Herausforderung für den Sicherheitsnachweis in Abhängigkeit von der Kontrollierbarkeit dieser Veränderung (siehe Kapitel 5).

„Je mehr Adaptionen ich zur Laufzeit habe, desto mehr muss ich das Safety-Engineering in die Laufzeit verlagern.“

[Zitat aus dem Expertenkreis für funktionale Sicherheit]

Grundsätzlich lässt sich dabei zwischen einer offline vorgenommenen Aktualisierung der im Betrieb erfassten Daten und systemseitigen Adaptionen, die während der Laufzeit ohne vorhergehende Kontrolle erfolgen, unterscheiden. Die offline vorgenommene Aktualisierung bietet die Möglichkeit, den Lernprozess im Rahmen der mit einem KI-System gegebenen Möglichkeiten zu kontrollieren. Der Ansatz wird bereits im Automobilbereich bei Entwicklungen autonomer Fahrfunktionen verfolgt, bei der während der Fahrt Daten erfasst werden, auf deren Basis gezielt Verbesserungen vorgenommen werden können. Darüber hinaus lässt sich das angemessene Funktionieren des Systems bezogen auf Einsatzstunden oder Fahrleistung konkret beziffern. In industriellen Anwendungen erscheint ein vergleichbares Vorgehen weniger erfolgversprechend, da die Anwendungsfälle heterogener sind und es deutlich kleinere Stückzahlen gibt, so dass eine Vergleichbarkeit der Daten und damit der Lernerfahrungen nicht gewährleistet ist.

Grundsätzlich erscheint jedoch der Ansatz, eine Offline-Aktualisierung auf Basis der im Betrieb gesammelten Daten vorzunehmen, der vom Menschen initiiert und kontrolliert wird, gleichermaßen notwendig wie auch – zumindest im Vergleich zu nicht kontrolliert weiterlernenden Systemen – zukünftig umsetzbar, sofern sich ein (derzeit noch nicht ausdetaillierter) Prozess zur Sicherheitsprüfung etabliert (vgl. Absatz 1.2.5).

„Dies ist auch der einzige Weg, der irgendwann gangbar wäre"

[Zitat aus dem Expertenkreis für funktionale Sicherheit]

Während geringfügige Adaptionen in einem oder zumindest wenigen Parametern in engen Grenzen möglich sind, gelten nennenswerte Erweiterungen während der

Laufzeit ohne menschliche Kontrolle in sicherheitskritischen Anwendungen jetzt und zukünftig aus Sicht der Experten als undenkbar. Als Grund dafür wird angeführt, dass weder die Selektion noch die Qualität der Lerndaten steuerbar ist, wenn das System sich diese selbst wählt, und damit nicht die Möglichkeit gegeben ist – zumindest nicht ohne zusätzliche rigide Kontrollmaßnahmen – sicheres Verhalten in der Anwendung zu garantieren.