Die Zukunft autonomer Systeme gestalten: Sicherheit, Ethik und Verantwortlichkeit im Zeitalter der KI

Fragen Sie einen Raum voller Ingenieure, die an Wahrnehmungs-Stacks für selbstfahrende Autos arbeiten, was sie über das Trolley-Problem denken, und Sie werden meist müde Blicke ernten. Das Problem an sich ist zwar substanziell, aber es ist das falsche Modell für das eigentliche Ingenieurproblem, das vor ihnen liegt. Zu erklären, warum das so ist, dauert länger, als die meisten Abendgesellschaften an Geduld aufbringen können.

Die ehrliche Version der Sicherheitsherausforderung bei autonomen Systemen ist philosophisch weit weniger dramatisch, dafür aber mathematisch umso mühsamer: probabilistische Wahrnehmung unter Sensorrauschen, Verdeckung und Latenz, eingespeist in eine Entscheidungspipeline, die eine Belohnungsfunktion über kontinuierliche Aktionsräume optimieren muss, ohne eine saubere binäre Wahlmöglichkeit irgendwo in der Schleife. Diese technische Realität korrekt abzubilden und die Standards sowie Verantwortlichkeitsrahmen darum herum richtig aufzubauen, ist ein weitaus schwierigeres und folgenreicheres Problem als jedes Gedankenexperiment, und es verdient, auch so behandelt zu werden.

Teil 1: Warum das Trolley-Problem als technische Spezifikation versagt

Das Trolley-Problem setzt etwas voraus, das kein reales autonomes System besitzt: eine deterministische Welt, perfektes Zustandswissen, eine saubere binäre Wahl und Gewissheit über die Ergebnisse. Der Wahrnehmungs-Stack eines tatsächlichen autonomen Fahrzeugs hat nichts davon. Er hat verrauschte LiDAR-Daten, Kamerabilder, die durch Regen oder tiefstehende Sonne beeinträchtigt sind, Verdeckungen hinter einem geparkten LKW und einen probabilistischen Glaubenszustand darüber, was tatsächlich da draußen ist – keine absolute Wahrheit.

Was tatsächlich unter der Haube läuft

Reale autonome Fahrzeuge stützen sich auf formale Rahmenwerke wie Partially Observed Markov Decision Processes (POMDPs) und Reinforcement Learning, gerade weil die Welt tatsächlich nur teilweise beobachtbar ist. Das System wählt nicht zwischen zwei vorbestimmten Schicksalen. Es tastet einen kontinuierlichen Aktionsraum ab, Dutzende plausibler Kombinationen aus Lenkwinkel und Beschleunigung, und optimiert das erwartete Ergebnis anhand einer Belohnungsfunktion, die auf Kollisionsvermeidung und Sorgfaltspflichtschwellen basiert – bei echter Unsicherheit darüber, wie sich der Fußgänger, das entgegenkommende Auto oder der Radfahrer in den nächsten zwei Sekunden tatsächlich verhalten werden. Ein autonomes Fahrzeug so zu programmieren, dass es ein Dilemma im Trolley-Stil „löst“, ist keine vereinfachte Version der eigentlichen Ingenieursaufgabe. Es ist die Lösung eines völlig anderen Problems, das in der Form, wie das Gedankenexperiment es annimmt, gar nicht auftritt.

Das Moral Machine Experiment und warum Crowdsourced Ethics eine Falle ist

Das „Moral Machine“-Experiment des MIT sammelte Millionen von Crowdsourced-Antworten auf hypothetische Unfallszenarien autonomer Fahrzeuge. Die kulturellen Unterschiede, die dabei zutage traten – etwa unterschiedliche Präferenzen auf Bevölkerungsebene, ob man eher das Leben junger oder älterer Menschen verschonen sollte –, sind soziologisch durchaus interessant. Sie sind jedoch auch ein ernstes Warnsignal für jeden, der versucht, ein Ethik-Modul direkt mit diesen Daten zu trainieren.

Menschliches moralisches Denken unter Zeitdruck neigt zur Deontologie; hat man Zeit zum Überlegen, neigen dieselben Menschen zum Utilitarismus. Das ist keine stabile Präferenzfunktion, die man in einem sicherheitskritischen Steuerungssystem verankert haben möchte. Schlimmer noch: Es gibt eine gut dokumentierte Perspektivenverzerrung: Menschen, die sich vorstellen, Passagiere des autonomen Fahrzeugs zu sein, wollen, dass das Auto den Passagier um jeden Preis schützt, während dieselben Menschen, wenn sie sich als Fußgänger vorstellen, das Gegenteil fordern. Trainiert man ein Modell mit solch einer Crowdsourced-Intuition, kodiert man keine Ethik. Man kodiert eigennützige Inkonsistenz in großem Maßstab, was genau der Grund ist, warum Ethik in diesem Bereich nicht als demokratische Datenanpassungsübung angegangen werden kann. Sie benötigt eine verfassungsartige Struktur, die nicht einfach aus der allgemeinen Stimmung gemittelt wird.

Top-Down, Bottom-Up und der Hybrid, der tatsächlich eingesetzt wird

Die algorithmische Top-Down-Kodifizierung schreibt spezifische ethische Verpflichtungen direkt in eine deterministische Logik fest – zum Beispiel eine strikte deontologische Regel, Verkehrsregeln nicht zu verletzen, es sei denn, dies ist zur Vermeidung einer unmittelbaren Kollision erforderlich. Dies ist prüfbar und vorhersehbar, aber auch spröde gegenüber Szenarien, die der Regelentwickler nicht vorhergesehen hat.

Bottom-Up-Maschinelles Lernen lässt das System Verhaltensnormen aus Trainingsdaten ableiten, was mit unordentlichen Variationen der realen Welt viel besser umgeht, allerdings auf Kosten der Interpretierbarkeit. Ein Black-Box-Richtliniennetzwerk kann im Nachhinein nicht leicht erklären, warum es in einem spezifischen Grenzfall eine bestimmte Flugbahn gewählt hat, was ein echtes Problem für die Unfalluntersuchung und die regulatorische Rechenschaftspflicht darstellt.

Das Muster, das sich beim ernsthaften Einsatz tatsächlich herauskristallisiert hat, ist hybrid: Bottom-Up-gelernte Richtlinien bewältigen das kontinuierliche, komplexe Problem der Wahrnehmung und Trajektorienoptimierung innerhalb harter Top-Down-Beschränkungen, deren Verletzung der gelernten Richtlinie architektonisch untersagt ist, ungeachtet dessen, was die Belohnungsfunktion sonst nahelegen könnte. Diese Begrenzungsschicht, die manchmal als expliziter regelbasierter Sicherheitsfilter nach dem gelernten Planer implementiert ist, ähnelt funktionell der Art und Weise, wie eine fest kodierte Gelenkbegrenzung oder eine Kollisionsvermeidungssperre eine gelernte Roboter-Manipulationsrichtlinie in industriellen Umgebungen einschränkt. Das Lernen bewältigt die Nuancen; die deterministische Schicht bewältigt die nicht verhandelbaren Grenzen.

Die Bedeutung von Sicherheit ist untrennbar mit dem Produktdesign selbst verwoben und in den regulatorischen Rahmenbedingungen spürbar, die dessen Entwicklung diktieren.

Funktionale Sicherheit versus SOTIF: Zwei verschiedene Fehlerkategorien

ISO 26262 regelt die funktionale Sicherheit, die etablierte Disziplin des Risikomanagements bei Hardwarefehlern oder systematischen Softwaredefekten. Ihr Rahmenwerk für die Automotive Safety Integrity Level (ASIL) skaliert die Strenge der Design- und Verifizierungsaktivitäten auf die Schwere und Wahrscheinlichkeit der Gefahr, die ein Fehler verursachen könnte. Die meisten Elektronikingenieure in der Automobilindustrie haben aus genau diesem Grund schon lange über ASIL-Dekompositionsstrategien diskutiert.

Die wirklich unbequeme Erkenntnis, mit der sich die Industrie auseinandersetzen musste, ist, dass ein autonomes Fahrzeug abstürzen kann, obwohl jede Komponente genau wie entworfen funktioniert. Eine Kamera nimmt ein perfekt sauberes Bild auf. Das Wahrnehmungsnetzwerk klassifiziert jedoch einen Fußgänger, der ein ungewöhnliches Kostüm trägt, bei starkem Regen nicht korrekt, weil diese spezifische Kombination außerhalb dessen liegt, was die Trainingsverteilung angemessen abdeckte. Nichts ist ausgefallen. Das System war einfach unzureichend für die Komplexität dieses Moments, und das gesamte Rahmenwerk der ISO 26262, das auf Fehlfunktionsrisiken aufbaut, hat kein natives Vokabular für diesen Fehlermodus.

ISO 21448, SOTIF (Safety of the Intended Functionality), existiert speziell, um diese Lücke zu schließen, und konzentriert sich auf Gefahren, die aus Leistungsbeschränkungen und unerwarteten Betriebsbedingungen resultieren, anstatt aus Komponentenfehlern. Das Vier-Quadranten-Modell von SOTIF ist im Detail verständlich, da es Ingenieurteams eine echte Roadmap an die Hand gibt, anstatt das Problem nur zu benennen. Bereich 1 ist der bekannte sichere Zielzustand. Bereich 2 ist bekannt-gefährlich, also Risiken, die das Team bereits identifiziert hat und durch Designänderungen aktiv mindert. Bereich 3 ist unbekannt-gefährlich, die wirklich gefährliche Kategorie, da das Team diese Grenzfälle noch nicht einmal identifiziert hat. Bereich 4 ist unbekannt-sicher.

Das gesamte praktische Ziel der SOTIF-Entwicklung, der umfangreichen Simulation, der statistischen Feldvalidierung und der strukturierten Entdeckung von Grenzfällen besteht darin, Szenarien aus Bereich 3 in Bereich 2 zu migrieren, wo sie zu handhabbaren Designproblemen statt zu unsichtbaren Risiken werden. ISO 26262 und SOTIF parallel zu betreiben, anstatt eines von beiden als ausreichend zu betrachten, deckt sowohl das interne Fehlfunktionsrisiko als auch das externe Komplexitätsrisiko gleichzeitig ab. Das Auslassen eines der beiden hinterlässt eine echte Lücke in der Sicherheitsargumentation.

Kollaborative Robotik: ISO 10218 und die Zusammenführung mit TS 15066 im Jahr 2025

Der gleiche grundlegende Wandel, die Annahme aufzugeben, dass ein Mensch immer der ultimative Sicherheitsmechanismus ist, vollzog sich in der Industrierobotik. Traditionelle Industrieroboter liefen in isolierten Sicherheitskäfigen mit harten Verriegelungen: Käfig öffnen, Strom sofort abschalten. Die Einführung kollaborativer Roboter veränderte die traditionellen Arbeitsplatzkonfigurationen grundlegend und machte ein Zusammenleben von Mensch und Roboter erforderlich.

Das Update der ISO 10218-2 aus dem Jahr 2025 hat die ISO/TS 15066 offiziell in einen einzigen, vereinheitlichten Standard für kollaborative Robotik integriert. Die vier darin definierten kollaborativen Betriebsmodi sollte man aus dem Effeff beherrschen, wenn man eine Cobot-Zelle spezifiziert. Der sicherheitsgerichtete überwachte Stopp hält den Roboter beim Betreten durch einen Menschen vollständig an und nimmt den Betrieb erst wieder auf, nachdem die Zone geräumt ist. Um einen sicheren und effizienten Arbeitsablauf zu gewährleisten, steuern Bediener die Bewegung des Roboterarms aktiv und kontrollieren die Geschwindigkeit an vorgegebenen Positionen präzise. In Echtzeit optimiert das System sein Tempo basierend auf dynamischen Berechnungen der relativen Geschwindigkeit und Nähe zu Menschen, was ein sichereres Arbeitsumfeld gewährleistet. Die Begrenzung von Leistungs- und Kraftgrenzen schränkt nicht nur den mechanischen Kontakt ein, sondern erzwingt elektronisch auch sichere Kontaktkräfte, um zu verhindern, dass Kollisionen vordefinierte Sicherheitsgrenzen überschreiten.

Das Detail, das neuere Integratoren am häufigsten stolpern lässt: Der Standard besagt ausdrücklich, dass kein Roboter isoliert von Natur aus „sicher“ oder „kollaborativ“ ist. Es ist die gesamte Anwendung, der spezifische Endeffektor, die Werkstückgeometrie, die umgebende Vorrichtung, die eigentliche Aufgabe, die risikobewertet und als Gesamtsystem validiert werden muss. Ein perfekt PFL-konformer Roboterarm, der einen scharfkantigen, kundenspezifischen Greifer betreibt, ist keine kollaborative Anwendung, nur weil der Basisroboter eine kollaborative Zertifizierung trägt.

IEEE P7000: Wo sozio-technische Ethik formalisiert wird

Sicherheit ist das Hauptanliegen der ISO-Normen, die sowohl physische als auch funktionale Aspekte priorisieren. Die IEEE P7000-Reihe, die im Rahmen der IEEE Global Initiative on Ethics of Autonomous and Intelligent Systems gestartet wurde, befasst sich mit den sozio-technischen und ethischen Dimensionen, für die ISO-Rahmenwerke nie konzipiert waren, und zwar mit spezifischen, adressierbaren Standards statt mit vagen, aspirativen Prinzipien.

IEEE P7001 zielt auf Transparenz ab und verlangt, dass autonome Systeme selbsteinschätzend sind und Entscheidungspfade in einer Form offenlegen, die für Menschen im Nachhinein tatsächlich erklärbar ist – genau die Fähigkeit, die reines Black-Box-Bottom-Up-Lernen ohne zusätzliche architektonische Arbeit nur schwer liefern kann. IEEE P7003 befasst sich direkt mit algorithmischer Voreingenommenheit und bietet strukturierte Rahmenwerke zur Identifizierung und Verhinderung diskriminierender Ergebnisse in trainierten Modellen vor dem Einsatz. IEEE P7009 deckt speziell das Fail-Safe-Design ab und schreibt ein sanftes, sicheres Abbauverhalten vor, anstatt abrupter oder unvorhersehbarer Fehlermodi, wenn ein System den normalen Betrieb nicht mehr fortsetzen kann. IEEE P7010 geht weiter als die meisten technischen Standards und führt Wohlbefindenskennzahlen ein, die die tatsächlichen Auswirkungen eines KI-Systems auf das menschliche Gedeihen bewerten, anstatt bei engen wirtschaftlichen oder aufgabenbezogenen Kennzahlen stehen zu bleiben.

Teil 3: Aufbau eines Sicherheitsnachweises, der Bestand hat

Compliance-Checklisten für ISO 26262 oder SOTIF sind notwendige Grundlagen, aber sie stellen für sich genommen kein verteidigbares Argument dafür dar, dass ein spezifisches System sicher in der realen Welt eingesetzt werden kann. Dieses Argument ist das, was ein „Safety Assurance Case“ formal konstruiert: strukturierte Behauptungen, gestützt durch logische Argumentationsketten, untermauert durch konkrete verifizierbare Beweise, Simulationsprotokolle, Testergebnisse von Teststrecken, Feldtelemetrie.

UL 4600: Zielbasiert statt präskriptiv

ANSI/UL 4600 verfolgt einen bewusst anderen Ansatz als traditionelle präskriptive Standards, die exakte Implementierungsanforderungen diktieren. Er ist zielbasiert und bietet eine umfangreiche Reihe von obligatorischen, erforderlichen und empfohlenen Aufforderungen, die Ingenieurteams dazu zwingen, spezifische Risikokategorien aktiv anzugehen, anstatt nur eine feste Implementierungsbox abzuhaken.

UL 4600 erzwingt die direkte Konfrontation mit der inhärenten Sprödigkeit des maschinellen Lernens, dem echten „Long Tail“ seltener Grenzfälle und der unordentlichen Realität der Mensch-Maschine-Interaktion unter realen Betriebsbedingungen. Die Anforderung an eine streng definierte Operational Design Domain (ODD) – der explizite ökologische, geografische und zeitliche Rahmen, innerhalb dessen das System tatsächlich autorisiert ist zu operieren (z. B. „tagsüber, klares Wetter, asphaltierte Straßen unter 45 mph“) – ist die operativ folgenreichste Anforderung des Standards. Wenn das Fahrzeug auf Bedingungen außerhalb dieses Rahmens stößt, etwa einen plötzlichen Schneesturm oder eine nicht kartierte Baustelle, muss der Sicherheitsnachweis belegen, dass das System diese ODD-Verletzung zuverlässig erkennen und ein wirklich sicheres Ausweichmanöver ausführen kann, anstatt nur zu hoffen, dass der Wahrnehmungs-Stack damit zufällig gut umgeht.

SACE und AMLAS: Eine ganzheitliche, umgebungsbewusste Methodik

Die SACE-Methodik der University of York (Safety Assurance of autonomous systems in Complex Environments) arbeitet mit AMLAS (Assurance of Machine Learning for use in Autonomous Systems) zusammen, um eine wirklich ganzheitliche Sichtweise einzunehmen, die sowohl das System selbst als auch die operative Umgebung, in der es existiert, umfasst.

Die Komponente „Out of Context Operation Assurance“ von SACE befasst sich mit etwas, das das ODD-Konzept von UL 4600 impliziert, aber nicht vollständig formalisiert: Die reale Welt ist unendlich viel komplexer, als es jedes definierte Operational Domain Model vollständig erfassen kann, sodass das System zwangsläufig irgendwann seine definierten Grenzen überschreiten wird. SACE verlangt den expliziten Nachweis zweier unterschiedlicher Fähigkeiten. Erstens, dass das System genau und zeitnah erkennen kann, dass es sich der ODM-Grenze nähert oder diese bereits überschritten hat, mit sorgfältig validierten Falsch-Positiv- und Falsch-Negativ-Raten bei dieser Grenzwerterkennung selbst – denn ein Grenzwertdetektor, der ständig Fehlalarm schlägt, ist fast so unsicher wie einer, der echte Grenzüberschreitungen übersieht. Zweitens, dass das System eine echte „Minimum Risk Strategy“ bereit hat, die ausgeführt werden kann, sobald es sich außerhalb der ODM befindet – sei es die Rückgabe der Kontrolle an einen menschlichen Bediener, die Durchführung eines kontrollierten sicheren Stopps oder der Übergang in einen bewusst konservativen, degradierten Sicherheitsmodus, der sich rein auf die Selbsterhaltung statt auf die Aufgabenerfüllung konzentriert.

Warum Simulation so viel vom Beweisgewicht trägt

Keine Flotte, egal wie groß, kann physisch genug reale Kilometer zurücklegen, um jedem bedeutsamen gefährlichen Grenzfall allein durch Straßentests zu begegnen; die Kombinatorik von Wetter, Beleuchtung, Verkehrsverhalten und seltenen Objektklassen macht diesen Ansatz innerhalb jedes vernünftigen Programmzeitplans statistisch hoffnungslos. Standardisierte Simulationsrahmenwerke wie ASAM OpenDRIVE für die Straßennetzwerkbeschreibung und OpenSCENARIO für die dynamische Manöverspezifikation ermöglichen es Ingenieurteams, hochgradig parametrisierte virtuelle Umgebungen zu konstruieren, in denen Fehler gezielt injiziert, Wetter- und Lichtverhältnisse systematisch variiert und Millionen von Szenariopermutationen weitaus schneller und erschöpfender ausgeführt werden können, als es physische Tests jemals erreichen könnten. Dies generiert den Großteil der Beweisbasis, auf der SOTIF- und UL 4600-Sicherheitsargumente tatsächlich ruhen, bevor diese Software jemals physische Hardware berührt.

Teil 4: Verantwortlichkeit — Wo Technik auf das Gesetz trifft

Wenn ein autonomes System einen tödlichen Unfall verursacht, ist der unmittelbare öffentliche Instinkt oft zu fragen, was die Maschine „entschieden“ hat, als hätte sie eine moralische Wahl getroffen. Diese Rahmung ist ein Kategorienfehler, und es ist wichtig, dass Ingenieure und die um diese Technologie herum aufgebauten Rechtsrahmen ihr bewusst widerstehen.

Warum Maschinen keine moralische oder rechtliche Handlungsfähigkeit besitzen können

Ein autonomes System optimiert, ungeachtet seiner architektonischen Komplexität, eine mathematische Belohnungsfunktion. Es besitzt keine Intentionalität, keinen freien Willen und kein echtes moralisches Verständnis in irgendeinem Sinne, den das Gesetz oder die klassische Ethik anerkennt. Die Zuschreibung von Handlungsfähigkeit verschleiert, anstatt zu klären, wo die Verantwortung tatsächlich liegt. Da Maschinen keine Rechtspersönlichkeit und keine Kapazität für „mens rea“ (schuldhaftes Handeln) besitzen, kann strafrechtliche Haftung nicht am System selbst festgemacht werden.

Stattdessen wurde die Bildung einer „moralischen Knautschzone“ beobachtet, in der ein Mensch, der sich am nächsten am Fehler befindet – etwa ein Sicherheitsfahrer, der ein automatisiertes System überwacht –, rechtliche und moralische Schuld absorbiert, die in keinem Verhältnis zu seinem tatsächlichen kausalen Beitrag steht, während die systemischen technischen und organisatorischen Entscheidungen, die den Fehlerzustand tatsächlich hervorgerufen haben, einer gleichwertigen Prüfung entgehen. Diese Asymmetrie ist ein echtes Versagen der Verantwortlichkeit, keine akzeptable Konsequenz des Betriebs fortschrittlicher Technologie.

Der Uber ATG-Unfall als Fallstudie für Technik und Organisation

Der tödliche Unfall von Uber ATG im Jahr 2018 in Tempe, Arizona, wird in der öffentlichen Diskussion häufig fälschlicherweise als reales Trolley-Problem charakterisiert. Die tatsächliche technische Untersuchung erzählt eine philosophisch weit weniger interessante und praktisch weitaus lehrreichere Geschichte: ein Versagen des Wahrnehmungs-Stacks, verschärft durch ein Versagen der organisatorischen Sicherheitskultur.

Die Klassifizierung einer Frau, die mit einem Fahrrad die Straße überquerte, durch das automatisierte Fahrsystem oszillierte wiederholt zwischen „Fahrzeug“, „Fahrrad“ und „anderes“, während sich das Objekt durch die Szene bewegte. Jede Neuklassifizierung setzte die Trajektorienvorhersage des Systems für dieses Objekt zurück, und dieser Rücksetzzyklus – keine bewusste Wahl im Trolley-Stil – war es, der die angemessene Bremsreaktion verzögerte, bis es zu spät war. Dies ist ein durchaus gut verstandener Fehlermodus in Multi-Objekt-Tracking- und Klassifizierungspipelines, bei dem instabile Klassenvorhersagen die nachgelagerte Bewegungsvorhersage korrumpieren. Es ist genau die Art von Problem, die eine ausgereiftere Sensorfusionsarchitektur mit stärkeren zeitlichen Konsistenzbeschränkungen über aufeinanderfolgende Frames hinweg bei Validierungstests lange vor dem Einsatz auf öffentlichen Straßen hätte erkennen müssen.

Direkt über diesem technischen Versagen lag ein separates und wohl noch verwerflicheres organisatorisches Versagen: Uber hatte Notfallbenachrichtigungen an den menschlichen Sicherheitsfahrer unterdrückt, speziell um „Alarmmüdigkeit“ durch häufige Fehlalarme zu reduzieren, und die operativen Sicherheitsaufgaben für diese Rolle waren von vornherein nicht klar oder rigoros definiert. Keine dieser organisatorischen Entscheidungen taucht in einer technischen Ursachenanalyse des Wahrnehmungs-Stacks allein auf, und genau das ist der Punkt: Ein vollständiger Verantwortlichkeitsrahmen muss den gesamten Systemlebenszyklus untersuchen, nicht nur die Software, die im Moment des Aufpralls lief.

Definition der Rollenverantwortung über den gesamten Lebenszyklus

Sinnvolle Verantwortlichkeit muss explizit jede Phase der Entwicklung und des Betriebs des Systems nachverfolgen: die Organisationen und Prozesse, die für das Sammeln und Kuratieren von Trainingsdaten verantwortlich sind; die Ingenieure, die die neuronalen Netzwerkarchitekturen entworfen und validiert haben; die Sicherheitsingenieure, die den UL 4600-Sicherheitsnachweis zusammengestellt und unterzeichnet haben; die Führungskräfte, die unter kommerziellem Druck Einsatzzeitpläne und Risikotoleranz festgelegt haben; und die Feldbediener, die das System im Alltag unter realen Bedingungen verwalten.

Diese Rückverfolgbarkeit über den gesamten Lebenszyklus ist genau der Grund, warum Standards, die transparente, rekonstruierbare Entscheidungspfade vorschreiben – IEEE P7001 ist das klarste direkte Beispiel –, über das rein technische Interesse hinaus von Bedeutung sind. Ohne diese rekonstruierbare Aufzeichnung kann eine Untersuchung nach einem Vorfall die kausale Verantwortung nicht genau auf die Lebenszyklusphasen zurückführen, in denen die tatsächlichen Fehlerbedingungen entstanden sind. Die Verantwortlichkeit kollabiert dann auf die Person, die sich zum Zeitpunkt des Fehlers physisch am nächsten am Geschehen befand – was selten der Ort ist, an dem die tatsächliche technische Verantwortung lag.

Wo es von hier aus tatsächlich hingehen muss

Der verantwortungsbewusste Einsatz sicherheitskritischer autonomer Systeme ist kein Problem, das durch die cleverere Lösung eines philosophischen Gedankenexperiments gelöst wird. Es wird durch die unglamouröse, rigorose und wirklich schwierige Arbeit der funktionalen Sicherheitsanalyse auf Komponentenebene gemäß ISO 26262, der Abdeckung von Umwelt- und Leistungsbeschränkungen gemäß SOTIF, der Risikobewertung auf Anwendungsebene gemäß dem vereinheitlichten kollaborativen Robotik-Rahmenwerk ISO 10218, der sozio-technischen Verantwortlichkeitsstruktur gemäß IEEE P7000 und der strukturierten, evidenzbasierten Sicherheitsargumentation gemäß Rahmenwerken wie UL 4600 und SACE gelöst.

Keines dieser Rahmenwerke löst das gesamte Problem für sich allein, und genau deshalb setzen ernsthafte Ingenieurorganisationen sie in Kombination ein, anstatt einen einzelnen Standard als ausreichende Absicherung zu betrachten. Die ehrliche Erkenntnis aus dem Uber ATG-Fall und jedem nachfolgenden Vorfall, der mit dieser Strenge untersucht wurde, ist dieselbe: Die Verantwortung für das, was diese Systeme tun, überträgt sich nicht auf die Maschine, nur weil die Maschine die Entscheidungen von Moment zu Moment trifft. Sie bleibt direkt bei den Menschen, die die Wahrnehmungspipeline entworfen, die operativen Grenzen definiert, den Sicherheitsnachweis unterzeichnet und die organisatorischen Prioritäten festgelegt haben, unter denen all diese Technik tatsächlich stattfand. Diese Verantwortung von Anfang an in den Prozess zu integrieren, anstatt ihr Fehlen nach einem tödlichen Unfall zu entdecken, ist die eigentliche Arbeit, die dieses Feld noch vor sich hat.