Lifecycle stage — Build
Das schwierigste Hindernis zwischen einem funktionierenden KI-Prototyp und einer eingesetzten sicherheitskritischen Maschine ist der Safety Case — das strukturierte Argument, gestützt durch Nachweise, dass das System akzeptabel sicher ist. Maschinelles Lernen bricht die Annahmen, auf denen traditionelle funktionale Sicherheitsprozesse aufgebaut sind: Es gibt keine zeilenweise Spezifikation zum Nachverfolgen, das Verhalten ist statistischer Natur, und benannte Stellen akzeptieren kein undokumentiertes Modell in einem Fahrzeug, einem Luftfahrtsystem oder einer Industrieanlage. Safety-Case- und Zertifizierungsnachweis-Engineering ist die Fähigkeit, dieses Argument und diese Nachweiskette zu erstellen — Gefährdungsanalyse, Risikobewertung, ASIL/DAL/SIL-Zerlegung, Assurance-Case-Konstruktion und Verifizierungs- und Validierungsnachverfolgung — gemäß dem Standard, der Ihre Domäne regelt. Dies ist die schärfste Trennlinie zwischen einem Physical-AI-Spezialisten und einem generalistischen KI-Berater, und es ist der wichtigste Blocker in jedem sicherheitskritischen Bereich. Zur ausdrücklichen Klarstellung der Grenze: Eine benannte Stelle weist die tatsächliche Sicherheitseinstufung zu und zertifiziert das System. Ich entwickle den Safety Case und die Nachweise, die sie bewerten — ich stelle keine Zertifizierungen aus.
ML bricht die traditionelle V&V. Funktionale Sicherheitsstandards setzen eine Spezifikation voraus, die Test für Test nachverfolgt werden kann; ein gelerntes Modell hat keine. Das Sicherungsargument muss für statistisches Verhalten neu konstruiert werden, und die meisten Teams verfügen nicht über die Methode dafür.
Benannte Stellen lehnen undokumentiertes ML ab. Ein Modell, das in der Validierung gut abschneidet, aber ohne Gefährdungsanalyse, Anforderungszerlegung und nachverfolgbare Nachweiskette ankommt, wird die Konformitätsbewertung nicht bestehen — Leistung ist notwendig, aber bei Weitem nicht ausreichend.
Die Nachweise müssen von Anfang an entwickelt werden, nicht am Ende zusammengestellt. Einen Safety Case nachträglich auf ein System aufzupfropfen, das nicht darauf ausgelegt war, Nachweise zu erzeugen, ist der teuerste Weg, um herauszufinden, was der Standard verlangte.
Gemäß dem Standard, der Ihre Domäne regelt — ISO 26262 (Automobil), DO-178C/EASA (Luft- und Raumfahrt), IEC 61508 (Industrie), ISO 13482 (Serviceroboter) — und auf eine definierte Systemfunktion abgegrenzt.
Durchführung der HARA (oder des Domänenäquivalents): Gefährdungen identifizieren, Exposition/Beherrschbarkeit/Schwere bewerten und die Risikoklassifizierungsfragen ableiten, die eine benannte Stelle stellen wird — ohne die von ihr zugewiesene Einstufung vorwegzunehmen.
Sicherheitsziele in funktionale und technische Sicherheitsanforderungen zerlegen, die über die Architektur verteilt werden, einschließlich des ML-Elements und seiner Sicherheitsmechanismen, Monitore und Rückfallebenen.
Das strukturierte Sicherungsargument (z.B. GSN) aufbauen, das Behauptungen mit Nachweisen verknüpft, sodass das Sicherheitsargument explizit und überprüfbar statt implizit und behauptet ist.
Die Verifizierungs- und Validierungsnachweise sowie die Nachverfolgbarkeitsmatrix von der Anforderung zum Test definieren und zusammenstellen, damit die technische Akte vollständig und auditbereit ist.
Automobil-OEMs und Tier-1-Zulieferer (ISO 26262), Luft- und Raumfahrt- sowie Verteidigungsunternehmen (DO-178C/EASA), Industrie- und Robotikintegratoren (IEC 61508, ISO 10218/13482) und Energiebetreiber, die ML in Funktionen einsetzen, bei denen ein Sicherheitsvorfall ein regulatorisches und haftungsrechtliches Ereignis ist — kein Bug-Ticket. Für Teams, die ein funktionierendes Modell haben und nun nachweisen müssen, dass es sicher ist.
Nein. Eine benannte Stelle oder ein akkreditierter Gutachter weist die Sicherheitseinstufung zu und zertifiziert das System. Ich entwickle den Safety Case und die Nachweiskette, die sie bewerten — die Gefährdungsanalyse, die Anforderungszerlegung, den Assurance Case und die V&V-Nachverfolgbarkeit. Das Gegenteil zu behaupten wäre unehrlich, und eine benannte Stelle würde es erkennen.
Nach dem, der Ihre Domäne regelt — ISO 26262 für Automobil, DO-178C/EASA für Luft- und Raumfahrt, IEC 61508 für industrielle funktionale Sicherheit, ISO 10218/13482 für Roboter. Der erste Schritt des Engagements legt den anwendbaren Standard und die Systemgrenze fest.
Die EU-AI-Act-Konformität betrifft die Governance- und Dokumentationspflichten der Verordnung. Die funktionale Sicherheitszertifizierung ist ein separates, älteres und tiefgreifenderes Regime zur physischen Sicherheit der Maschine. Ein sicherheitskritisches KI-System benötigt in der Regel beides; dieser Service deckt die funktionale Sicherheitshälfte ab.
Entdecken Sie weitere Services, die dieses Angebot ergänzen
30 Minuten. Ich diagnostiziere Ihre Situation und sage Ihnen ehrlich, ob dieser Service passt — und wenn nicht, welcher.