Safetronic 2026: Vorschau
Absicherung von Multi-Agenten-Tools mit bewährten Sicherheitsmustern aus der Automobilindustrie

Die übliche Sicherheitsmaßnahme für KI-generierte Arbeitsergebnisse besteht darin, dass ein Mensch sie liest. Ich glaube, dass diese Maßnahme zunehmend an ihre Grenzen stößt.

Sie versagt zunächst an der schieren Menge. Agentenbasierte Tools erzeugen Anforderungen, Code und Analysen bereits schneller, als die dafür zuständigen Teams sie prüfen können, und mit jedem Anstieg des Durchsatzes wächst diese Lücke. Unter diesem Druck werden selbst flüssig formulierte und gut formatierte Ausgaben häufig nur noch überflogen. Wer sie lediglich absegnet, verursacht Kosten, ohne zur Fehlererkennung beizutragen. Dennoch wird diese Maßnahme im Sicherheitsnachweis als wirksam berücksichtigt, obwohl sie faktisch nichts erkennt. Sie versagt zudem dort, wo es besonders darauf ankommt. Eine erfundene Klauselnummer oder eine nicht vorhandene Anforderungs-ID liest sich genauso wie eine echte. Um sie zu erkennen, muss jeder Verweis mit seiner Quelle abgeglichen werden. Für eine Maschine ist das ein mechanischer Vorgang. Für einen Menschen am Ende eines langen Prüfungstages ist es fehleranfällig.

Es geht also um ein anderes Ziel: den Menschen aus dem unmittelbaren Prüfprozess herauszunehmen. Technisch konzipierte Maßnahmen schaffen die erforderliche Verlässlichkeit; Menschen werden gezielt bei Eskalationen hinzugezogen, nicht für eine pauschale Überprüfung.

Das Tool wie ein Sicherheitsprodukt behandeln

Die zentrale Entscheidung dieses Konzepts mag zunächst überzogen erscheinen: Wir behandeln das GenAI-Tool so, als wäre es ein Sicherheitsprodukt.

ISO/IEC TS 22440-1, die in Vorbereitung befindliche Spezifikation zu funktionaler Sicherheit und KI-Systemen (derzeit ein Ausschussentwurf), würde ein GenAI-Entwicklungstool üblicherweise als AUL-B1 einstufen und nach dem in Anhang C beschriebenen Verfahren für Tools behandeln. Wir gehen bewusst noch einen Schritt weiter und entwickeln das Tool so, dass es die Anforderungen des Entwurfs an KI innerhalb eines sicherheitsrelevanten Steuerungssystems erfüllt, also AUL-A1. Das umfasst einen vollständigen KI-Sicherheitslebenszyklus, eine KI-Fehleranalyse, eine überwachte und redundante Architektur sowie spezielle Tests. Die Begründung ist einfach. Sobald nicht mehr jede Ausgabe überprüft wird, und genau darin liegt der Sinn des Tools, kann ein Tool-Fehler dieselben Folgen wie ein Produktfehler haben. Die erforderliche Strenge muss dem entsprechen.

Die gute Nachricht ist: Wir mussten keine neuen Sicherheitsmechanismen erfinden. Diversitäre Redundanz mit Zwei-von-drei-Abstimmung, das Monitor-/Aktuator-Prinzip hinter mehrschichtigen Überwachungskonzepten wie E-Gas, Plausibilitätsgrenzen und ein sicherer Fallback sind etablierte Muster, die von Prüfern bereits akzeptiert werden. In unserem Ansatz werden sie in einem einheitlichen Rahmenwerk für GenAI-Tools zusammengeführt. Die Architektur ist unten dargestellt.

Drei Kanäle, eine Bewertungsinstanz und ein Veto, das nicht überstimmt werden kann

So funktionieren die Multi-Agenten-Tools, die wir auf Grundlage dieses Konzepts implementieren, der Abbildung folgend vom Eingang bis zum Ausgang.

Die Vorverarbeitung prüft, ob eine Anfrage innerhalb des operativen Entwurfsbereichs des Tools liegt, und trennt Anweisungen von Inhalten. So bleibt ein in ein abgerufenes Dokument eingeschleuster Befehl reiner Text. Anschließend durchläuft die Anfrage drei Kanäle parallel. Jeder Kanal bildet die Funktionalität als vollständige Multi-Agenten-Implementierung ab, mit Agenten, deren Rollen und Befugnisse klar definiert sind, mit wiederverwendbaren Fähigkeiten, mit Zugriff auf einen kontrollierten und versionsgebundenen Korpus sowie mit Aufrufen deterministischer Prüfer wie Compiler, statischer Analysewerkzeuge und Anforderungsdatenbanken. Der Agentengraph ist festgelegt, seine Schleifen sind begrenzt. Damit bleibt die Orchestrierung gewöhnliche, testbare Software. Zwischen den Kanälen unterscheidet sich das jeweils zugrunde liegende Modell: Es stammt aus einer anderen Modellfamilie und von einem anderen Anbieter.

Eine Bewertungsinstanz aus einer weiteren Modellfamilie vergleicht die drei Kandidaten und trifft eine Zwei-von-drei-Entscheidung. Zwei Überwacher flankieren diesen Prozess. Der KI-Monitor prüft, ob die Ausgabe mit den Eingaben und der geforderten Funktionalität übereinstimmt. Er kann sie akzeptieren, ablehnen oder eskalieren, nimmt jedoch niemals selbst Korrekturen vor. Die Nicht-KI-Monitore prüfen alle Sachverhalte, die sich eindeutig beantworten lassen: Existiert die zitierte Klausel in der festgelegten Ausgabe der Norm? Lässt sich die Anforderungs-ID auflösen? Lässt sich der Code kompilieren? Schlägt jeder generierte Test bei einer gezielt eingebrachten Mutation fehl? Nur die Begrenzungslogik kann eine Ausgabe freigeben, und ein Nicht-KI-Veto kann nicht überstimmt werden. Ist eine automatische Bearbeitung nicht möglich, erhält ein Mensch einen eindeutig gekennzeichneten Punkt zur Entscheidung, mit der Quelle und den voneinander abweichenden Ausgaben direkt nebeneinander. Der Mensch verschwindet also nicht. Seine Aufgabe verändert sich. Er liest nicht mehr alles, sondern entscheidet gezielt über das, was die Maschine nicht entscheiden kann.

Wenn ich aus dieser Arbeit eine zentrale Lehre ziehen müsste, wäre es diese: Diversität muss durch unterschiedliche Modellfamilien entstehen, nicht durch unterschiedliche Eingabeaufforderungen. Zwei Eingabeaufforderungen auf demselben Basismodell sind nicht unabhängig voneinander. Und eine Bewertungsinstanz aus derselben Modellfamilie wie der Generator teilt dessen blinde Flecken. Lässt man korrelierte Modelle abstimmen, erhält man eine hohe Übereinstimmung trotz einer falschen Antwort.

Noch eine Anmerkung zur Abbildung: Sie zeigt ein umfassendes Referenzmodell. Unabhängig davon, ob ein Tool Sicherheitsanforderungen ableitet, Code und Tests generiert oder Inhalte für FMEA und FMEDA vorschlägt, bleibt das Grundgerüst gleich. Was sich ändert, ist die Auswahl der Monitore. Jedes Tool implementiert diejenigen Monitore, die sich aus seiner eigenen Fehleranalyse ergeben. Für jeden nicht vorgesehenen Monitor muss eine Begründung dokumentiert werden. Der sichere Zustand ist für alle identisch. Keine ungeprüfte Ausgabe gelangt in ein sicherheitsrelevantes Arbeitsergebnis.

Hinweis: Übersetzung des englischen Originals (Safetronic 2026: Preview – Securing Multi-Agent Tools with Proven Automotive Safety Patterns – Magazine of the Fraunhofer Institute for Cognitive Systems IKS)