KANBrief 3/22
Wie lässt sich die funktionale Sicherheit und Betriebssicherheit von Systemen mit künstlicher Intelligenz überprüfen, auf die sich herkömmliche Bewertungsmethoden nicht anwenden lassen, weil die Systeme sehr komplex sind oder sich gar selbständig weiterentwickeln? Assurance Cases sind das Mittel der Wahl, wenn potentiell sicherheitskritische neue Technologien zum Einsatz kommen, zu denen noch keine ausreichenden Erfahrungen aus der Praxis vorliegen.
Trotz jahrelanger Diskussionen im Kontext von Normung und Regulierung gibt es noch keinen Konsens darüber, was ein „KI-System“ ist. Weitgehende Einigkeit scheint in der europäischen Regulierung darüber zu bestehen, dass ein KI-System eine bestimmte Art von Software ist. Wie diese jedoch von klassischer Software abzugrenzen ist, erscheint eher unklar.
Bei autonomen und teilautonomen Systemen stoßen normierte Vorgehensweisen zur Bewertung der Sicherheit immer häufiger an ihre Grenzen. Selbst ein möglichst einfach gehaltenes Sicherheitskonzept kann bei der Automatisierung von komplexen Aufgaben in komplexen Einsatzumgebungen sehr umfangreich werden. Verschiedene Maßnahmen wie das Management von Unsicherheiten bei der Umgebungserkennung1 greifen ineinander und bilden mehrere Ebenen der Absicherung („Layers of Protection Architecture“). Die Einsatzumgebungen und die zu automatisierenden Aufgaben dieser autonomen oder teil-autonomen Systeme können sehr komplex sein. Das erfordert, dass deren Absicherungsebenen auf einer Software basieren, die nach dem europäischen Regulierungsvorschlag ein KI-System ist.
Für solch komplexe Sicherheitskonzepte muss eine Sicherheitsargumentation geführt werden, die gewährleistet, dass das Gesamtkonzept wirklich dauerhaft trägt. Die in der ISO/IEC 15026 (Systems and software assurance) definierten Assurance Cases erscheinen hierfür ein geeigneter Ansatz. Diese gelten generell dann als gut geeignet, wenn noch unzureichend Erfahrung mit einer Technologie im sicherheits-kritischen Kontext vorliegt2.
Ein Assurance Case umfasst grundsätzlich eine zu belegende Behauptung zum angestrebten Sicherheitsniveau und eine zugehörige Argumentation, die auf einer Reihe unterstützender Belege und Nachweise beruht.
Wie in der Abbildung dargestellt kann die Argumentation hierarchisch strukturiert werden, indem einzelne Überlegungen (Argumentationsschritte) explizit gemacht werden. Jede Überlegung verbindet eine zu zeigende Behauptung (z. B. das Produkt ist sicher) mit Prämissen (z. B. elektrische Gefährdung ist beherrscht). Diese werden auf der nächsttieferen Ebene als neue Behauptungen aufgefasst und in weiteren Überlegungen wiederum mit Prämissen unterlegt (z. B. keine Schädigung des Netzkabels <- Isolation ist ausreichend).
Der logische Schluss von bestimmten Prämissen auf eine Behauptung gilt oft nur unter gewissen Annahmen wie beispielsweise einer bestimmten Einsatzumgebung (z. B. Anwender hat Erfahrung / elektrische Ströme sind kleiner als ...). Diese Annahmen werden bei der Entwicklung herausgearbeitet und im Assurance Case explizit dokumentiert. Jede nicht weiter verfeinerte Behauptung muss mittels Evidenzen wie Dokumentationen oder Verifikationsergebnissen belegt werden.
Ein ausgearbeiteter Assurance Case bietet eine Reihe von Vorteilen. Er führt modulartig alle notwendigen Elemente (Artefakte) für die Sicherheitsargumentation zusammen und kann über spezielle Programmbausteine (Digital Dependability Identities3) in die Software des Gesamtsystems integriert werden. Die Erfüllung wichtiger Annahmen und Behauptungen kann so während des Betriebs überwacht werden, um Schwachstellen im Assurance Case frühzeitig aufzudecken, ihn kontinuierlich zu verbessern und an Änderungen in der Einsatzumgebung anzupassen4. Insbesondere bieten Assurance Cases jedoch einen hohen Grad an Flexibilität in der Strukturierung der Argumentation. Dies erlaubt es, auf Besonderheiten der konkreten Anwendung und verwendeten Technologien einzugehen.
Um mit dieser Flexibilität produktiv umzugehen, gibt es praktische Hilfestellungen. Die AMLAS-Methode5 beschreibt beispielsweise generische Vorgehensweisen für die Strukturierung eines Sicherheitsarguments. AMLAS legt allerdings nicht fest, was „hinreichend sicher“ für ein KI-System bedeutet.
Im Projekt ExamAI wurde ein Vorschlag erarbeitet, wie Testverfahren für KI-Systeme aussehen könnten. Er beruht auf zwei unabhängigen Argumentationslinien6: Die erste zielt darauf ab zu zeigen, dass das Sicherheitsrisiko so weit reduziert wurde, wie dies in der Praxis möglich ist, indem eine möglichst effektive Kombination von Absicherungsmaßnahmen ausgewählt und unter einer Kosten-Nutzen-Abwägung bestmöglich implementiert wurde. Die zweite zielt darauf ab, quantitativ zu belegen, dass die erzielte Risikoreduktion auch ausreicht.
Im aktuellen Forschungsprojekt LOPAAS7 werden diese und weitere Ansätze aus der Forschung zusammengeführt. Die Projektpartner bringen den wissenschaftlichen Konsens zudem in Standardisierungs- und Normungsaktivitäten wie die Anwendungsregel für autonom kognitive Systeme VDE-AR-E 2842-61, den technischen Report TR 5469 von ISO und IEC zu KI und funktionaler Sicherheit oder die BSI PAS 8800 für sicherheitskritische KI im Automobil-Bereich ein.
Erstens sollte Regulierung und Normung konsistente Definitionen für die Begriffe „KI-System“ und „autonomes System“ erarbeiten. Nur so lassen sich die Lücken in Regulierung und Normung zur Sicherheit und anderen Rechtsgütern verstehen und schließen. Zweitens sollte die Forschung zu Assurance Cases, inklusive der Mitwirkung von Forschenden in der Normung und Standardisierung, gefördert und Wissen zu Assurance Cases unter Betroffenen verbreitet werden. Drittens sollten regulative Anforderungen so ausformuliert werden, dass sie eine gute Ausgangsbasis für die Erarbeitung und Anwendung von Normen zu Assurance Cases bieten. Der Fokus regulatorischer Anforderungen sollte auf den für die Sicherheit unumgänglichen Behauptungen liegen, die gewöhnlich im oberen Teil eines Assurance Cases verortet sind. Problematisch können hingegen nachgelagerte Anforderungen sein, die je nach Argumentationsführung oder Anwendungsfall nicht zwangsläufig Teil einer validen Sicherheitsargumentation sein müssen. Regulatorische Anforderungen an derartige Details könnten Umsetzungsspielräume unnötig beschränken oder unnötigen Aufwand verursachen.
1 Management von Unsicherheiten in der Umgebungserkennung (englisch)
2 Understanding what it means for assurance cases to work (englisch, pdf, nicht barrierefrei)
3 Digital Dependability Identities (englisch)
4 Assurance Cases as Foundation Stone for Auditing AI-enabled and Autonomous Systems (englisch)
5 Amlass-Methode (englisch)
6 Argumentationslinien (englisch)
7 Forschungsprojekt LOPAAS (englisch)
Rasmus Adler, Fraunhofer-Institut für Experimentelles Software Engineering IESE
rasmus.adler@iese.fraunhofer.de
Michael Kläs, Fraunhofer-Institut für Experimentelles Software Engineering IESE
michael.klaes@iese.fraunhofer.de