Wenn bewährte Risikoanalysen an ihre Grenzen stoßen
In der klassischen Systementwicklung herrscht ein beruhigendes Gesetz: der Determinismus[4]. Wenn wir Software schreiben, gilt das unumstößliche „Wenn-Dann-Prinzip“. Auf Input A folgt präzise und vorhersehbar Output B. Sicherheitsanalysen wie die FMEA (Fehlermöglichkeits- und Einflussanalyse) oder Risikoanalysen nach ISO 14971 sind seit Jahrzehnten genau darauf optimiert, solche klaren, logischen Fehlerketten mechanischer und elektronischer Systeme zu prüfen.
Doch diese deterministische Komfortzone löst sich gerade rasant auf. Mit KI kommt eine neue Dynamik hinzu: die Probabilistik[7]. Eine KI arbeitet nicht mit festen Logiken, sondern mit Wahrscheinlichkeiten. Sie lernt aus Daten und reagiert im praktischen Einsatz potenziell unerwartet.
Genau an dieser Sollbruchstelle greift die Gesetzgebung ein: Mit der Verabschiedung des EU AI Acts vom Europäischen Parlament im Mai 2024 soll europaweit sichergestellt werden, dass künstliche Intelligenz transparent, nachvollziehbar und risikobasiert entwickelt wird. Allerdings erscheint der EU AI Act in der Industrie momentan eher als reine Drohkulisse. Doch hinter den regulatorischen Daumenschrauben steckt eine fachliche Notwendigkeit. Die eigentliche Herausforderung ist nicht das Ausfüllen neuer Formulare, sondern ein fundamentales Umdenken: Wir müssen ein kontinuierlich lernendes System über seinen gesamten Lebenszyklus hinweg beherrschen.
Das neue Risiko-Paradoxon
Klassische Sicherheitsnormen betrachten Risiken überwiegend als Folge vorhersehbarer, physikalischer oder logischer Fehler (z. B. Bauteilausfall, Software-Bug). Der EU AI Act erweitert diese Sichtweise radikal: Nun werden Risiken relevant, die aus dem lernenden Verhalten, der Datenqualität, Modelländerungen oder aus statistischen Driftprozessen (also der schleichenden Veränderung von Daten in der realen Welt) entstehen.
Was das konkret bedeutet, zeigt ein Blick in die Praxis zweier regulierter Branchen:
Beispiel 1: Medizintechnik – KI erkennt Tumore auf MRT-Bildern
- Klassisches Risiko: Der MRT-Bildsensor ist defekt → Das Bild verrauscht → Der Arzt übersieht den Tumor → Patient ist gefährdet. (Eindeutig lösbar über Hardware-Redundanz oder klassische Signal-Fehlererkennung).
- KI-Risiko: Die Trainingsdaten der KI stammten fast ausschließlich von älteren MRT-Geräten. In der Anwendung wird das Modell mit einem hochmodernen, kontrastreichen MRT-Scanner gefüttert. Die statistische Verteilung verschiebt sich (Data Drift[2]). Die KI interpretiert die schärferen Kanten falsch und übersieht den Tumor – obwohl die Software technisch fehlerfrei läuft.
Beispiel 2: Maschinenbau – Kamera erkennt Personen im Gefahrenbereich einer Maschine
- Klassisches Risiko: Kabelbruch an der Kamera → Kein Videosignal → Maschine stoppt nicht → Person wird verletzt. (Klassisch abgesichert über Ruhestromprinzip oder ISO 13849).
- KI-Risiko: Die Trainingsdaten der KI enthielten kaum Bilder von Menschen, die reflektierende Warnwesten tragen. Eine Arbeitskraft betritt mit einer neuen Warnweste den Gefahrenbereich. Die KI erkennt die Person nicht zuverlässig, aufgrund einer Verzerrung in den Trainingsdaten → Maschine stoppt nicht → Person wird verletzt.
Wie KI die Engineering-Welt verändert
Um diesen Unterschied im Entwicklungsalltag noch greifbarer zu machen, hilft eine Gegenüberstellung der Arbeitsweisen:
Klassisches Engineering
Systemverhalten: Software ist deterministisch (Wenn-Dann).
Anforderungen: Spezifikationen ändern sich nach dem Freeze selten.
Testverfahren: Testfälle bleiben stabil und werden regressionsgetestet.
Risikoanalyse: Einmaliges/periodisches Event zum Release.
AI Engineering
Systemverhalten: Modell ist probabilistisch (Wahrscheinlichkeiten).
Anforderungen: Trainings- und Validierungsdaten ändern sich regelmäßig
Testverfahren: Testdatensätze müssen kontinuierlich erweitert werden.
Risikoanalyse: Kontinuierlicher Prozess über den gesamten Lebenszyklus.
Drei Schritte, um KI-Risiken im Engineering konkret zu beherrschen
Der EU AI Act verlangt kein neues, separates Risikomanagement, das parallel zu ISO 14971 oder FMEA existiert. Er verlangt ein integriertes Risikomanagement, das die Disziplinen Data Governance[3], Modellvalidierung, Human Oversight[6] und Post-Market Monitoring direkt in den bestehenden Engineering-Prozess einwebt. Dies ist auch mit KI-Unterstützung möglich, wir haben dazu folgendes Beispiel aus objectiF RPM in einem Blogbeitrag näher beleuchtet.
Mit diesen drei konkreten Arbeitsanweisungen gelingt der Übergang:
Schritt 1: Behandeln Sie die Trainingsdaten für die KI-Modelle wie Softwareanforderungen
Deklarieren Sie Datenqualität nicht zur reinen Aufgabe der Data Scientists. Daten sind die neuen Spezifikationen.
Die Umsetzung: Erstellen Sie funktionale und nicht-funktionale Anforderungen an Ihre Trainingsdaten genau wie an klassische Systeme.
Ihre Checkliste für jedes Datenpaket:
- [ ] Herkunft: Ist die Quelle der Daten lückenlos dokumentiert und auditierbar?
- [ ] Repräsentativität: Decken die Daten alle realen Einsatzszenarien (z. B. verschiedene MRT-Typen, Warnwesten-Varianten) ab?
- [ ] Versionierung: Ist exakt nachvollziehbar, mit welchem Datenstand welches Modell trainiert wurde?
- [ ] Bias[1]-Bewertung: Wurden die Daten gezielt auf statistische Verzerrungen geprüft?
- [ ] Freigabe: Gibt es einen formalen Quality-Gate-Prozess für Daten-Releases?
Schritt 2: Definieren Sie explizit, wann die KI NICHT entscheiden darf
Da eine KI prinzipiell immer eine statistische Antwort liefert (auch wenn sie falsch liegt), muss die Systemarchitektur Grenzen setzen. Dies ist der Kern der geforderten menschlichen Aufsicht. Je nach Risiko und Anwendung kann sie beispielsweise durch Human-in-the-Loop[5]-Mechanismen oder deterministische Sicherheitsbarrieren umgesetzt werden.
Die Umsetzung: Kapseln Sie die KI-Komponente im SysML- oder UML-Modell. Implementieren Sie deterministische Safety Guards[8].
Praxis-Regel: Legt das Entwicklungsteam beispielsweise einen validierten Konfidenzschwellenwert von 90 % fest und unterschreitet das Modell diesen Wert, kann die Systemarchitektur die KI-Entscheidung blockieren und eine manuelle Überprüfung erzwingen.
Schritt 3: Etablieren Sie einen Änderungsprozess für Modellupdates
Auch bei KI-Systemen endet das Risikomanagement nicht mit der Produktfreigabe. Modelle können nachtrainiert, aktualisiert oder mit veränderten Betriebsdaten konfrontiert werden. Jedes Nachtrainieren verändert das Systemverhalten und damit können sich auch die Risiken verändern.
Die Umsetzung: Definieren Sie bereits heute einen strikten Änderungsprozess für Modellanpassungen und das anschließende Post-Market Monitoring. Sobald ein Modell im klinischen Einsatz aktualisiert wird, muss die Traceability[9]-Kette automatisch prüfen, welche ursprünglichen Risikoanalysen und Validierungstests neu durchlaufen werden müssen.
5 Fragen, die sich Ihr Entwicklungsteam jetzt stellen sollte
Bevor Sie das nächste KI-Feature planen, prüfen Sie kurz die Audit-Fähigkeit Ihres Teams anhand dieser fünf Fragen:
- Wissen wir exakt, welche Trainingsdaten für welche spezifische Produktversion verwendet wurden?
- Können wir die korrekte Umsetzung jeder KI-spezifischen Anforderung nahtlos bis zum dazugehörigen Testfall und dessen Ergebnis nachweisen?
- Wissen wir präzise, welche neuen Risiken entstehen, wenn das Modell mit den Daten der letzten drei Monate neu trainiert wird?
- Können wir einem Auditor revisionssicher nachweisen, warum und auf Basis welcher Metriken das Modell freigegeben wurde?
- Könnten wir diese Nachweise einer unabhängigen Prüf- oder Zertifizierungsstelle kurzfristig vollständig vorlegen?
Die Tool-Landschaft als Compliance-Risiko
In vielen etablierten Unternehmen in der Medizintechnik, dem Maschinenbau oder dem Automotive-Sektor sieht der Alltag leider immer noch so aus:
- Anforderungen leben in Word-Dokumenten.
- Risikoanalysen (FMEAs) werden in Excel-Tabellen gepflegt.
- Testfälle lagern in einem speziellen Testmanagement-System.
- Die Systemarchitektur wird in Visio oder Modellierungstools gezeichnet.
- Die KI-Trainingsdaten liegen verstreut auf einem Fileserver der Data Scientists.
Für klassische, rein deterministische Software war diese fragmentierte Tool-Landschaft oft mühsam, aber durch hohen manuellen Aufwand gerade noch beherrschbar. Für KI-Systeme unter den Bedingungen des EU AI Acts wird diese Zerstückelung jedoch zum akuten Compliance- und Haftungsrisiko. Da sich KI-Komponenten fortlaufend verändern, sind permanente manuelle Synchronisationen zwischen diesen Tools notwendig.
Data Drift[2]: Das Phänomen, dass sich die Daten in der realen Welt im Laufe der Zeit verändern und nicht mehr den ursprünglichen Trainingsdaten der KI entsprechen. Dies kann dazu führen, dass die Genauigkeit der KI im Betrieb schleichend nachlässt.
Data Governance[3]: Das strategische und operative Framework zur Verwaltung von Datenqualität, -integrität und -sicherheit. Im KI-Kontext bedeutet dies die lückenlose Überwachung und Bereinigung von Trainingsdaten, um Fehler oder Verzerrungen von vornherein zu erkennen, zu vermeiden oder zu reduzieren.
Determinismus[4]: Ein Programmierprinzip, bei dem ein System auf denselben Input immer exakt denselben Output liefert. Das Verhalten ist zu 100 % vorhersagbar und logisch nachvollziehbar.
Human-in-the-Loop[5]: Eine spezifische Form der menschlichen Aufsicht. Hierbei ist der Mensch zwingend in den aktiven Entscheidungsprozess der KI eingebunden – das System darf eine Aktion erst ausführen, nachdem ein menschlicher Bediener sie explizit freigegeben hat.
Human Oversight (Menschliche Aufsicht)[6]: Die gesetzliche Vorgabe des EU AI Acts, dass Hochrisiko-KI-Systeme so konzipiert sein müssen, dass sie von Menschen effektiv überwacht, verstanden und im Notfall korrigiert oder abgeschaltet werden können.
Probabilistik[7]: KI-Modelle leiten Ergebnisse aus statistischen Zusammenhängen und Wahrscheinlichkeiten ab. Deshalb lässt sich ihr Verhalten nicht in derselben Weise vollständig durch feste Wenn-Dann-Regeln beschreiben wie bei klassischer deterministischer Software.
Safety Guards (Sicherheitsbarrieren)[8]: Deterministische Schutzmechanismen oder Plausibilitätsprüfungen, die um eine KI-Komponente herum programmiert werden. Sie fangen probabilistisches Fehlverhalten auf Systemebene ab, bevor ein realer Schaden entsteht (z. B. das automatische Blockieren einer KI-Entscheidung bei zu niedrigem Konfidenzniveau).
Traceability (Rückverfolgbarkeit)[9]: Die lückenlose Dokumentation, welches Element im Entwicklungsprozess (z. B. ein Testergebnis oder ein Risiko) aus welcher ursprünglichen Anforderung oder Datenbasis entstanden ist.
Fazit: Die Single Source of Truth als Lösung
Die Lösung liegt nicht darin, Ihren Ingenieuren noch mehr Dokumentationsaufwand aufzubürden. Sie liegt im Aufbrechen der Informations-Silos. Nur wenn Anforderungen, Systemmodelle (UML/SysML), KI-spezifische Risiken, Datenparameter und Testfälle auf einer gemeinsamen, vernetzten Datenbasis operieren, entsteht eine durchgängige Nachvollziehbarkeit, die viele Dokumentations- und Nachweispflichten des EU AI Acts unterstützt.
Genau hier setzt eine integrierte Engineering-Plattform wie objectiF RPM an. Als Single Source of Truth (SSOT) führt sie alle Fäden in einem einzigen, relationalen Repository zusammen. Ändern sich Anforderungen, Risiken oder andere miteinander verknüpfte Artefakte, lassen sich die betroffenen Beziehungen und Abhängigkeiten nachvollziehen. Dadurch ist eine gezielte Analyse der Auswirkungen möglich. So meistern Sie den Paradigmenwechsel des EU AI Acts nicht als bürokratische Last, sondern als echten evolutionären Qualitätsschritt für Ihre Systeme.
Machen Sie Ihr Risikomanagement fit für das KI-Zeitalter
Verabschieden Sie sich von starren Dokumenten und unübersichtlichen Excel-Listen. Erfahren Sie in einer exklusiven Live-Präsentation, wie objectiF RPM Sie in Ihrem Anforderungs- und Risikomanagement unterstützt. Kontaktieren Sie uns gern und lassen Sie uns einen passenden Termin vereinbaren.