Wenn KI eine Behauptung aufstellt: Wer prüft sie, bevor Sie handeln?

Der Vorfall beweist nicht, dass Ihr KI-System unsicher ist. Er zeigt nicht, dass jeder KI-generierte Fehler eine menschliche Prüfung übersteht. Er belegt auch nicht, dass der Einsatz von KI jede berichtete Schwäche im weiteren Entscheidungsprozess verursacht hat.

Er veranschaulicht jedoch ein Fehlermuster, das sich in jeder Organisation prüfen lässt:

1. Ein System erzeugt oder verstärkt eine Behauptung.
2. Die Behauptung gewinnt an Autorität, während sie einen formalen Prozess durchläuft.
3. Nachgelagerte Beteiligte sehen eine fertige Antwort und nicht die Schwächen darunter.
4. Eine Handlung beginnt, bevor die Belege rekonstruiert wurden.

Die Gefahr besteht nicht allein darin, dass ein Modell einen falschen Satz erzeugt. Organisationen mussten schon immer mit fehlerhaften Informationen umgehen. Neu sind Geschwindigkeit, Reichweite und die scheinbare Sicherheit flüssig formulierter Antworten. Eine plausible Ausgabe kann vertraute Dokumente, Dashboards und Freigabewege durchlaufen, bevor jemand erkennt, dass die Belege schwächer sind als ihre Darstellung.

Fachleute bewerten Wahrscheinlichkeit und Zeitpunkt eines langfristigen Kontrollverlusts sehr unterschiedlich. Der International AI Safety Report 2026 hält fest, dass die Einschätzungen stark auseinandergehen und Wahrscheinlichkeit, Form und Zeitpunkt ungewöhnlich unklar bleiben. Der Bericht beschreibt bei heutigen Systemen erste Anzeichen einiger relevanter Fähigkeiten, jedoch nicht in einem Ausmaß, das die dort untersuchten Kontrollverlust-Szenarien ermöglichen würde.

Diese Uneinigkeit ist für Politik und langfristige Investitionen relevant. Sie ist kein guter Grund, die heutigen operativen Grenzen unklar zu lassen.

Sie müssen die Debatte über existenzielle Risiken nicht abschließend klären, bevor Sie entscheiden:

• welche Informationen ein KI-System lesen darf
• welche Quellen es außerhalb Ihrer Organisation abrufen darf
• welche Ausgaben geprüft werden müssen
• was es erstellen, verändern, veröffentlichen oder versenden darf
• welche Entscheidungen eine namentlich benannte menschliche Befugnis erfordern
• wie eine Handlung gestoppt und rückgängig gemacht werden kann

Das sind gewöhnliche Führungsentscheidungen. Dringlicher werden sie durch eine Technologie, die Recherche, Interpretation und Ausführung in eine scheinbar reibungslose Abfolge verdichten kann.

Beginnen Sie nicht mit dem Produktnamen oder der verwendeten Bezeichnung. Begriffe wie Assistent, Copilot und Agent werden zu uneinheitlich gebraucht, um daraus abzuleiten, was das System tatsächlich tut.

Nehmen Sie einen realen Arbeitsablauf und verfolgen Sie den ersten Punkt, an dem KI ihn berührt.

Fragen Sie, was das System auslöst. Reagiert es auf eine Person, überwacht es ein Postfach, liest es ein Dokument, fragt es eine Datenbank ab oder wird es aktiv, wenn sich der Zustand eines anderen Systems ändert?

Trennen Sie anschließend vier Ebenen der Befugnis:

1. Antworten: Das System erstellt Text oder Analysen, die eine Person beurteilt.
2. Zugreifen: Es kann Dateien, Datensätze, Nachrichten, Websites oder Daten verbundener Systeme abrufen.
3. Empfehlen: Es interpretiert Belege und schlägt eine Entscheidung oder nächste Handlung vor.
4. Handeln: Es kann etwas erstellen, verändern, veröffentlichen, versenden, kaufen, verschieben oder löschen.

Mit jeder Ebene verändert sich das kommerzielle und operative Risiko. Auch ein reiner Lesezugriff kann vertrauliche Informationen offenlegen oder eine schlechte Entscheidung beeinflussen. Eine Empfehlung kann mehr Autorität erhalten, als ihre Belege rechtfertigen. Eine Handlung kann Kunden, Lieferanten, Mitarbeitende oder Finanzsysteme erreichen, bevor jemand verstanden hat, was geschehen ist.

Bei einer folgenreichen Entscheidung sollten Sie die Behauptung von der Ausgabe bis zu ihren Eingaben zurückverfolgen können.

Dazu müssen Sie erkennen können:

• welche internen Datensätze verwendet wurden
• welche externen Quellen abgerufen wurden
• wann diese Quellen veröffentlicht oder aktualisiert wurden
• was das Modell abgeleitet und nicht tatsächlich gefunden hat
• wo widersprüchliche Belege ausgeschlossen oder verkürzt wurden
• welche Sicherheit oder Unsicherheit kommuniziert wurde
• welche Person die Belege und nicht nur die Zusammenfassung geprüft hat

An dieser Stelle wird Prompt Injection zu einem operativen Problem und nicht nur zu einer technischen Besonderheit. OWASP erklärt, dass indirekte Prompt Injection auftreten kann, wenn ein Modell Inhalte aus externen Quellen wie Websites oder Dateien übernimmt und darin enthaltenes Material als Anweisung behandelt. Ein Abruf kann somit sowohl Informationen als auch einen Versuch importieren, den Umgang des Systems mit diesen Informationen zu beeinflussen.

Ein Quellenlink allein reicht nicht. Die prüfende Person muss wissen, ob die Quelle die Behauptung trägt, ob das System sie korrekt verarbeitet hat und ob eine andere Anweisung das Ergebnis verändert hat.

Die Aussage „Ein Mensch war eingebunden“ sagt fast nichts über die Qualität der Kontrolle aus.

Die nützlichen Fragen lauten:

• Welche Person?
• Wozu war sie befugt?
• Welche Belege konnte sie sehen?
• Hatte sie Zeit und Fachwissen, um die Aussage zu hinterfragen?
• Konnte sie den Ablauf stoppen, ohne für die Verzögerung benachteiligt zu werden?
• Wurde ihre Freigabe genau der Version zugeordnet, die sie geprüft hatte?

Wer eine sauber formulierte Empfehlung ohne die zugrunde liegenden Belege freigeben soll, übt keine wirksame Aufsicht aus. Diese Person übernimmt Verantwortung, nachdem das System die Entscheidung bereits gerahmt hat.

Die NCSC-Leitlinie vom Mai 2026 empfiehlt, mit eng begrenzten Aufgaben mit niedrigem Risiko zu beginnen, minimale Berechtigungen zu vergeben und klar festzulegen, wer Zugriff, Überwachung, Vorfälle und die Möglichkeit zum Stoppen eines Systems verantwortet. Die Leitlinie vom August 2026 ergänzt konkrete rote Linien, abgeschottete Testumgebungen, verbindliche Freigabepunkte und den Hinweis, sich nicht allein auf Prompts zu verlassen.

Diese Kontrollen verlangen nicht, dass jede Organisation eine neue Governance-Abteilung aufbaut. Sie verlangen, dass die bestehenden Verantwortlichen für Technologie, Daten, Betrieb und kommerzielle Ergebnisse gemeinsam festlegen, wo Befugnis beginnt und endet.

Gute Kontrolle bedeutet nicht, jeden Fehler zu verhindern. Ein solches Versprechen wäre unseriös. Sie soll die Wahrscheinlichkeit senken, dass aus einer schwachen Ausgabe eine unumkehrbare Folge wird.

Legen Sie für jeden wesentlichen Arbeitsablauf fest:

1. Rekonstruktion: Können Sie nachvollziehen, welche Eingaben, Anweisungen, Werkzeuge und Modellversionen zum Ergebnis beigetragen haben?
2. Unterbrechung: Kann eine befugte Person den Ablauf stoppen, bevor die Folge die Außenwelt erreicht?
3. Umkehrung: Lässt sich eine ausgeführte Handlung sicher und innerhalb eines sinnvollen Zeitraums rückgängig machen?
4. Eskalation: Erkennt das System, wenn Belege fehlen, sich widersprechen oder außerhalb seines festgelegten Rahmens liegen?
5. Verantwortung: Ist eine namentlich benannte Person für den Arbeitsablauf verantwortlich und nicht nur für den Softwarevertrag?

Das NIST AI Risk Management Framework beschreibt eine hilfreiche operative Folge: Govern, Map, Measure und Manage. Sein Wert liegt nicht in den Begriffen. Entscheidend ist die Forderung, Rollen, Kontext, Belege, Risikoreaktion und laufende Überprüfung miteinander zu verbinden.

Die Antwort besteht nicht darin, jede harmlose KI-Nutzung durch ein Gremium freigeben zu lassen.

Ein Werkzeug, das eine interne Gesprächszusammenfassung entwirft, braucht nicht dieselben Kontrollen wie ein System, das einen Preis ändert, eine Kundenmitteilung versendet, einen Lieferanten freigibt, Bewerbende einordnet oder Geld bewegt. Beides gleich zu behandeln verschwendet Aufmerksamkeit und macht Governance zum Selbstzweck.

Richten Sie die Kontrolle an drei Punkten aus:

• Reichweite: Wer oder was kann betroffen sein?
• Umkehrbarkeit: Wie leicht lässt sich die Folge rückgängig machen?
• Beleganforderung: Wie viel Sicherheit erfordert die Entscheidung?

Für Anwendungen mit geringen Folgen können ein einfacher Hinweis und Stichproben genügen. Anwendungen mit größeren Folgen können begrenzte Zugriffe, unabhängige Quellenprüfung, versionierte Entscheidungsprotokolle, ausdrückliche Freigaben und einen getesteten Weg zur Rückabwicklung verlangen.

Es geht nicht darum, jeden Ablauf zu verlangsamen. Geschwindigkeit darf nur nicht den Moment verdecken, in dem aus einem Vorschlag eine wirksame Befugnis wird.

Wählen Sie einen KI-gestützten Arbeitsablauf, der bereits eine reale Entscheidung beeinflusst. Fragen Sie:

1. Wo genau greift KI ein und welches Ergebnis soll sie verbessern?
2. Welche internen Daten, externen Inhalte und verbundenen Systeme darf sie verwenden?
3. Was darf sie ohne weitere Prüfung erstellen, verändern, empfehlen oder versenden?
4. Wer sieht die zugrunde liegenden Belege und ist befugt, die Handlung zu stoppen?
5. Lässt sich die Entscheidung rekonstruieren und ihre Folge rückgängig machen?

Wenn die Antworten unklar bleiben, beginnen Sie nicht mit einem Richtliniendokument für jeden denkbaren Einsatz. Begrenzen Sie zuerst diesen einen Arbeitsablauf sauber.

Vielleicht arbeitet das System bereits gut und die richtige Entscheidung lautet, nichts zu verändern. Vielleicht braucht es bessere Belege, engere Zugriffsrechte oder einen zusätzlichen Freigabeschritt. Vielleicht liegt das Problem gar nicht bei der KI.

Der Test ist, ob die Belege Ihnen zu einer besseren Entscheidung verhelfen, einschließlich der Entscheidung, nichts weiter zu unternehmen.

Wenn Sie einen folgenreichen Arbeitsablauf praktisch prüfen möchten, nutzen Sie unseren Fünf-Fragen-Check zur KI-Befugnis. Er erklärt die Grenze zwischen Antworten, Zugreifen, Empfehlen und Handeln und zeigt, was eine eng begrenzte Prüfung feststellen kann, ohne dass Sie vertrauliche Daten offenlegen müssen.

• CNN, „US military had close call after using AI for false intelligence report, sources say“, 18. September 2026. Der Bericht stützt sich auf nicht namentlich genannte Quellen und wird hier als berichteter Sachverhalt behandelt, nicht als offizielle Feststellung.
• International AI Safety Report 2026. Verwendet für den Stand der Belege und die unterschiedlichen fachlichen Einschätzungen zum langfristigen Risiko eines Kontrollverlusts.
• UK National Cyber Security Centre, „Thinking carefully before adopting agentic AI“, 15. Mai 2026.
• UK National Cyber Security Centre, „Managing the cyber risk of agentic AI“, 20. August 2026.
• NIST AI Risk Management Framework.
• OWASP, LLM01:2025 Prompt Injection.