Viele Kill Switches sind nur ein Beruhigungsversprechen Wie KI in kritischen Systemen wirklich beherrschbar wird

24.09.2026 Ein Gastbeitrag von Marco Eggerling 6 min Lesedauer

Anbieter zum Thema

Ein Energieversorger, ein KI-Agent, ein Konfigurationsfehler, der drei Wochen unentdeckt bleibt. Kein Angriff von außen, sondern eine schlecht geregelte Änderung in einem System, das niemand mehr vollständig überblickt. Solche Szenarien entstehen überall dort, wo KI schneller eingeführt wird als die Strukturen, die sie rahmen sollen.

Ein Kill Switch nützt wenig, wenn niemand weiß, wer ihn wann betätigen darf. Erst benannte Verantwortliche und geprobte Abläufe machen KI-Kontrollen im Ernstfall wirksam.

(Bild: Gemini / KI-generiert)

Gartner prognostiziert, dass bis 2028 eine fehlkonfigurierte KI die kritische Infrastruktur eines G20-Staates lahmlegen wird. Die Formulierung ist zugespitzt, aber sie beschreibt eine reale Schwachstelle. Wer in kritischen Umgebungen arbeitet, weiß: Nicht das Modell selbst richtet den Schaden an, sondern die ungeklärte Zuständigkeit im Ernstfall, der Change, der ohne ausreichende Prüfung in den Betrieb gelangt, das Governance-Dokument, das nur deshalb existiert, weil es ein Audit erforderte.

Die entscheidende Unterscheidung ist dabei keine technologische, sondern eine kontextuelle. Zwischen einem Sprachmodell, das einem Marketing-Team Textentwürfe liefert, und einem Agenten, der Prozesse in einer Energieleitwarte, einer Fertigungsanlage oder einer Zahlungsinfrastruktur beeinflusst, liegt ein fundamentaler Unterschied im Risikoregister. Spätestens dort, wo cyberphysische Systeme oder streng regulierte Abläufe betroffen sind, genügt der Hinweis auf ein laufendes Pilotprojekt nicht länger als Antwort auf die Frage nach der Beherrschbarkeit. KI muss in diesen Umgebungen denselben Anforderungen genügen wie jedes andere Hochrisiko-Asset: mit eindeutigen Verantwortlichkeiten, dokumentierten Risikoentscheidungen und belastbaren Kontrollen.

Der Kill Switch als Prüfstein

In Workshops und Audits begegnet einem eine Antwort mit bemerkenswerter Verlässlichkeit, sobald nach der Absicherung eines KI-gestützten Use Cases in der Betriebstechnologie gefragt wird: „Wir haben einen Kill Switch.“ Was folgt, ist die eigentlich aufschlussreiche Frage: Wer ist befugt, diesen in einem konkreten Szenario zu betätigen und wo ist diese Befugnis schriftlich fixiert? Welches System wird dadurch tatsächlich abgeschaltet? Wie sieht der geordnete Rückweg in den sicheren Zustand aus, und wer ist für dessen Ausführung verantwortlich? An dieser Stelle entsteht oft eine Pause. Oder es folgt der Verweis auf ein Notfallhandbuch, das in der Runde niemand aus eigener Anschauung kennt. Das ist kein Ausnahmefall. Es ist ein strukturelles Muster. Und es beschreibt exakt den Unterschied zwischen einem ernsthaften Sicherheitsmechanismus und seiner bloßen Behauptung.

Ein funktionsfähiger Kill Switch in einer kritischen Umgebung ist operational verankert: Es gibt namentlich benannte Personen mit klar definierten Entscheidungsrechten. Es gibt Runbooks, die im verantwortlichen Team bekannt sind und regelmäßig geprobt werden. Es gibt einen getesteten Rückführungspfad hin zu einem definierten sicheren Zustand mit verbindlichen Zeitvorgaben und nachvollziehbaren Abnahmekriterien. Ein Kill Switch, der keines dieser Merkmale aufweist, ist kein Sicherheitsinstrument, sondern ein Beruhigungsversprechen und damit genau jene Schwachstelle, auf die Szenarien wie das eingangs Geschilderte warten.

Governance in drei Ebenen: Wirkung, Kontrolle, Verantwortlichkeit

KI in kritischen Systemen lässt sich entlang dreier Ebenen strukturieren, die in einem sinnvollen Verhältnis zueinanderstehen müssen: Wirkung, Kontrolle und Verantwortlichkeit. Wer diesen Rahmen konsequent ausgestaltet, braucht kein weiteres Parallelkonstrukt neben dem bestehenden GRC-Gefüge, er muss lediglich bereit sein, das vorhandene ernsthaft anzuwenden.

Wirkungsebene

Jeder KI-Use Case bewegt sich auf einem Spektrum möglicher Einwirktiefe: von der bloßen Handlungsempfehlung über automatische Parameteranpassungen bis hin zum Anstoßen vordefinierter Arbeitsabläufe. Maßgeblich für die Risikobewertung ist die Frage, wie nah ein Use Case an der Aktorebene operiert; also dort, wo Entscheidungen in Systeme eingreifen, die physische oder finanzielle Aktionen ausführen, von OT-Komponenten bis zu Finanztransaktionen. Je unmittelbarer dieser Eingriff, desto enger muss der Governance-Rahmen gefasst sein. Das ist keine regulatorische Vorsichtsmaßnahme, sondern eine Konsequenz aus der Logik des Risikomanagements.

Kontrollebene

Drei Elemente müssen hier ineinandergreifen. Policy und Governance legen fest, in welchen Prozessen KI selbständig handeln darf, wo sie auf Empfehlungen beschränkt bleibt und welche Aktionen grundsätzlich ausgeschlossen sind. Technische Guardrails in Form von Plattform- oder Orchestrierungsebenen stellen sicher, dass Agenten ausschließlich auf freigegebene Systeme zugreifen, definierte Grenzen einhalten und ihr Verhalten nachvollziehbar bleibt. Operative Prozesse schließlich regeln, wie KI-gestützte Änderungen getestet, freigegeben, überwacht und im Bedarfsfall geordnet zurückgerollt werden.

Orchestrierende Plattformen können in diesem Gefüge als technischer Vertrauensanker wirken. Nicht, indem sie zusätzliche KI-Funktionalität einführen, sondern indem sie Governance in technisch durchsetzbare Regeln übersetzen. Use Cases gelangen nicht unmittelbar an operative Systeme, sondern werden über definierte Schnittstellen, Prüfpfade und Freigabemechanismen geführt. Was bisher nur in Richtlinien formuliert war, wird damit operativ erzwingbar.

Verantwortlichkeitsebene

Hier entscheidet sich, ob Governance substanziell ist oder nur eine formale Hülle. Für jeden produktiven KI-Use Case in einer kritischen Umgebung sind vier klar benannte Rollen erforderlich:

• ein Use Case Owner im Fachbereich, der Zielsetzung und Risikoakzeptanz des konkreten Einsatzes verantwortet;

• ein Risk- und Security Owner, der den Use Case im Kontext von Informationssicherheit, OT-Security und betrieblicher Resilienz bewertet;

• Legal und Compliance für die regulatorische Einordnung und Haftungsfragen;

• sowie Operations für Betrieb, Monitoring und Incident Handling.

Ohne diese personelle Verankerung bleibt ein KI-Use Case in einer sicherheitskritischen Umgebung ein Governance-freies Experiment mit Produktionsanbindung.

Integration in bestehende Kontrollrahmen

KI benötigt in kritischen Umgebungen kein eigenes Rahmenwerk. Sie lässt sich in etablierte Kontrollfamilien wie ISO 27001, NIST CSF oder IEC 62443 einbetten, sofern die Bereitschaft besteht, bestehende Prozesse konsequent anzuwenden, statt sie durch ein weiteres Schichtenmodell zu überlagern.

Im Asset Management wird KI als eigenständige Asset-Klasse geführt, mit definierter Kritikalität, namentlichem Owner und dokumentierten Systemabhängigkeiten. Im Berechtigungsmanagement braucht es klare Zuordnungen für die Änderung von KI-Policies und die Freigabe neuer Use Cases. Im Monitoring ergänzen verhaltensbasierte Kontrollen das bestehende Instrumentarium: Schwellwerte, Anomalieerkennung bei Aktionssequenzen und Limits für gleichzeitige Eingriffe in sicherheitsrelevante Parameter. In der Incident Response werden Playbooks dahingehend erweitert, dass Fehlverhalten von Agenten und Fehlkonfigurationen von Policies als vollwertige Szenarien behandelt werden, mit denselben Anforderungen an Reaktionszeit, Eskalationspfad und Nachweisführung wie bei anderen Betriebsstörungen.

Drei Kriterien für Governance-Reife

Gut aufgestellte Governance zeigt sich nicht an der Eleganz ihrer Dokumentation, sondern daran, ob sie im konkreten Fall greift – einschließlich der Bereitschaft, einem Use Case die Produktionsreife zu verweigern, wenn die Voraussetzungen nicht gegeben sind. Für kritische Umgebungen lassen sich drei Kriterien benennen, anhand derer sich dieser Reifegrad belastbar beurteilen lässt.

• Erstens: Sind strategische Entscheidungen in operative Vorgaben übersetzt? In welchen Prozessen erhält KI mehr als Vorschlagsrecht? Welche Fehlerrate oder Ausfallzeit ist in welchem Kontext akzeptabel? Welche Gremien (etwa Risk-Komitee, Change Advisory Board oder OT-Sicherheitsausschuss) bereiten diese Entscheidungen vor und tragen sie mit? Strategische Unschärfe auf Führungsebene setzt sich unmittelbar in operatives Risiko um.

• Zweitens: Sind KI-Use Cases vollständig in bestehende Change-Prozesse integriert? Nicht parallel dazu, sondern durch dieselben Strukturen mit zusätzlichen, angemessenen Prüfpunkten. Für jeden produktiven Use Case muss eine namentlich benannte Ownership-Struktur bestehen, einschließlich klarer Befugnisse zur Konfigurationsänderung und zur Unterbrechung des Betriebs im Ernstfall.

• Drittens: Wurde der Rückführungspfad tatsächlich erprobt? Nicht beschrieben. Nicht geplant. Erprobt. Mit konkreten Zeitvorgaben, definierten Abnahmekriterien und benannten Zuständigkeiten. Ein Notfallmechanismus, der nie unter realistischen Bedingungen getestet wurde, ist kein Sicherheitsinstrument. Er ist eine Annahme.

Ein KI-Use Case in einer kritischen Umgebung, der diese drei Kriterien nicht erfüllt, hat die Schwelle zur Produktionsreife noch nicht überschritten, unabhängig von seinem technischen Reifegrad.

Unsicherheit als Argument für Prinzipien, nicht für Aufschub

Wesentliche Fragen sind noch offen. Die Haftungsverteilung in mehrstufigen KI-Ketten vom Modellanbieter über Plattformbetreiber und Integratoren bis zu Betreibern und Regulatoren ist rechtlich nicht abschließend geklärt. Standardisierte Prüf- und Auditverfahren für agentische Systeme in OT-Umgebungen befinden sich in der Entwicklung. Das Zusammenspiel lokaler Plattformebenen, Cloud-Infrastrukturen und sektoraler Regulierung wirft praktische Fragen auf, die noch keine konsolidierten Antworten haben. EU AI Act und NIS2 setzen erste gesetzliche Leitplanken; ein global kohärentes Bild ist leider nicht in Sicht.

Diese Unschärfen sind real, aber sie sind kein stichhaltiges Argument dafür, KI-Governance in kritischen Systemen zu vertagen. Im Gegenteil: Gerade weil Rechtsprechung, Aufsichtspraxis und technische Normung noch im Fluss sind, gewinnen robuste, technologieunabhängige Grundsätze an Bedeutung. Wer wartet, bis alle regulatorischen Fragen beantwortet sind, wartet auf einen Zustand, der in dynamischen Technologiefeldern strukturell nicht eintritt.

Die Gartner-Prognose sollte die Sicherheits-Community daher nicht als Medienhype abtun, sondern als Verdichtung einer bekannten Schwachstelle lesen und als Aufforderung, bestehende Lücken mit dem Instrumentarium zu schließen, das bereits heute zur Verfügung steht.

Über den Autor: Marco Eggerling ist Field CISO bei UiPath.

(ID:50956756)