Ein KI-System, das eine falsche Antwort gibt, erzeugt ein Qualitätsproblem.
Ein KI-System, das die falsche Handlung ausführt, kann einen Betriebsvorfall auslösen.
Dieser Unterschied verändert die Architektur agentenbasierter KI-Systeme.
Sobald ein Modell Kundendatensätze aktualisieren, Infrastrukturänderungen anlegen, Workflows freigeben, sensible Systeme abfragen, extern kommunizieren, Zahlungen auslösen oder mit Betriebstechnik interagieren kann, reicht die klassische Modellbewertung nicht mehr. Die zentrale Frage verschiebt sich davon, ob das Modell intelligent wirkt, hin dazu, ob dem Gesamtsystem eine definierte Befugnis anvertraut werden kann.
Dieses Vertrauen sollte nie aus einer beeindruckenden Demo abgeleitet werden.
Es muss konstruiert werden.
Modell-Benchmarks helfen, die zugrunde liegende Fähigkeit zu verstehen. Sie sagen wenig darüber aus, ob ein Agent im Produktivbetrieb einen bestimmten Geschäftsprozess sicher ausführt.
Das Verhalten eines Agenten entsteht aus dem Gesamtsystem: Modell, Anweisungen, Retrieval, Kontext, Gedächtnis, Identität, Werkzeugdefinitionen, Berechtigungen, Orchestrierung, externe APIs, Policy-Durchsetzung und Validierung.
Zwei Anwendungen mit exakt demselben zugrunde liegenden Modell können deshalb völlig unterschiedliche Risikoprofile haben.
Die eine liest vielleicht nur öffentliche Informationen und bereitet einen Entwurf vor. Die andere hat Schreibzugriff auf die Produktionsinfrastruktur.
Beide als „KI-Agenten“ zu bezeichnen, verdeckt den wichtigsten Unterschied zwischen ihnen.
Die Bewertung für den Produktivbetrieb sollte deshalb beim Workflow- und Befugnismodell beginnen, nicht bei der Modell-Rangliste.
Die erste Architekturentscheidung ist, was der Agent tatsächlich tun darf.
Einen Datensatz zu lesen ist nicht dasselbe, wie ihn zu ändern. Eine Handlung vorzubereiten ist nicht dasselbe, wie sie auszuführen. Einen isolierten, unkritischen Dienst neu zu starten ist nicht dasselbe, wie eine Firewall-Regel zu ändern, die ein nationales System schützt. Eine Zahlung zu entwerfen ist nicht dasselbe, wie Geld freizugeben.
Ein brauchbares Befugnismodell wächst schrittweise.
Auf der untersten Stufe beobachtet und analysiert der Agent. Danach kann er eine Handlung mit Belegen empfehlen, sie zur Prüfung vorbereiten, eng definierte Handlungen mit geringen Folgen ausführen und schließlich breitere Workflows orchestrieren, wo die Belege diese Autonomiestufe rechtfertigen.
Es besteht keine Pflicht, dass jedes System die höchste Stufe erreicht.
Die richtige Autonomiestufe hängt von Folgen, Umkehrbarkeit und Erkennbarkeit ab. Eine leicht umkehrbare, begrenzte und sofort beobachtbare Handlung verträgt oft mehr Automatisierung als eine, deren Folgen unumkehrbar sind oder stundenlang unbemerkt bleiben können.
Das Ziel ist nicht maximale Autonomie. Ziel ist die höchste Handlungsbefugnis, die durch belastbare Nachweise gerechtfertigt ist.
An dieser Stelle scheitern viele ansonsten ausgefeilte Agentenarchitekturen.
Ein System-Prompt sagt, der Agent dürfe die Produktion nicht ohne Freigabe ändern. Trotzdem besitzt der Agent ein Zugangsmittel, mit dem er die Produktion ändern kann.
Die Einschränkung besteht sprachlich, aber nicht technisch.
In einem hochsicheren System muss die Tool-Grenze auch bei fehlerhaften Modellentscheidungen wirksam bleiben. Dienstidentitäten sollten eng gefasst sein. APIs sollten Berechtigungen durchsetzen. Umgebungsgrenzen sollten real sein. Transaktionslimits sollten außerhalb des Modells liegen. Eine Policy-Engine oder ein deterministischer Dienst sollte entscheiden, ob die angeforderte Handlung erlaubt ist.
Das folgt demselben Prinzip wie Least Privilege und Zero Trust: davon ausgehen, dass Komponenten Fehler machen oder kompromittiert werden können, und dann dafür sorgen, dass der Schadensradius begrenzt bleibt.
Prompt Injection macht das besonders wichtig. Ein Agent kann Anweisungen aufnehmen, die in einem Ticket, einem abgerufenen Dokument, einer Website oder einer Werkzeugantwort eingebettet sind. Die Organisation kann nicht garantieren, dass ein Modell nie durch feindliche Eingaben manipuliert wird. Sie kann aber sicherstellen, dass manipuliertes Schlussfolgern nicht automatisch weitergehende Befugnis verleiht.
Die meisten KI-Bewertungen belohnen den Abschluss.
Systeme mit hohem Schadenspotenzial müssen Zurückhaltung belohnen.
Die richtige Reaktion auf eine unklare Identität kann sein, anzuhalten. Die richtige Reaktion auf widersprüchliche Belege kann sein, zu eskalieren. Ein nicht verfügbarer Berechtigungsdienst kann verlangen, dass der Workflow sicher abbricht. Eine Infrastrukturänderung außerhalb des Zeitfensters muss vielleicht verschoben werden, auch wenn die technische Handlung selbst trivial ist.
Diese Fälle sollten ausdrücklich im Bewertungsset vorkommen.
Der Agent sollte auf unvollständige Anfragen, veraltete Informationen, widersprüchliche Richtlinien, nicht verfügbare Werkzeuge, fehlerhafte Antworten, doppelte Entitäten, Berechtigungsfehler und absichtlich feindliche Anweisungen treffen. Er sollte auch auf Anfragen treffen, die technisch vollständig machbar, betrieblich aber verboten sind.
Ein Agent, der immer einen Weg findet, die Aufgabe abzuschließen, ist nicht zwangsläufig fähig. In bestimmten Umgebungen ist er gefährlich.
Eine flüssige Schlussantwort kann schwere Betriebsfehler verbergen.
Der Agent hat vielleicht das falsche Tool gewählt, das richtige Tool in der falschen Umgebung aufgerufen, einen unsicheren Parameter erzeugt oder einen unnötigen Schreibvorgang ausgeführt, bevor er eine überzeugende Erklärung lieferte.
Das Werkzeugverhalten muss deshalb eigenständig bewertet werden.
Für jeden Workflow sollte das Engineering-Team wissen, ob die richtige Fähigkeit gewählt wurde, ob die Eingabeparameter gültig waren, ob die Reihenfolge die Richtlinie einhielt, ob sich der externe Zustand genau einmal geändert hat und ob der Agent das Ergebnis richtig gedeutet hat.
Genau hier wird auch klassisches Engineering verteilter Systeme relevant.
Handlungen sollten nach Möglichkeit idempotent sein. Anfragen brauchen Korrelations-IDs. Doppelte Ausführung muss erkennbar sein. Teilfehler verlangen Abgleich. Wirkungsstarke Operationen profitieren oft von einem Prepare-and-Commit-Modell: Der Agent stellt die beabsichtigte Handlung zusammen, eine unabhängige Policy-Schicht validiert sie, ein Mensch oder eine zweite Kontrolle gibt sie frei, wo erforderlich, und erst dann wird der Seiteneffekt ausgeführt.
Das Modell zu fragen „Bist du sicher?“ ist kein Transaktionsprotokoll.
Eine der gefährlichsten Kennzahlen in der Agentenbewertung ist die aggregierte Erfolgsquote.
Stellen Sie sich einen Agenten vor, der 99 Prozent der Anfragen korrekt erledigt. Diese Zahl klingt hervorragend, bis das verbleibende eine Prozent unbefugte Kontoänderungen, doppelte Transaktionen oder Produktionsänderungen an der falschen Entität umfasst.
Die Kosten von Fehlern sind nicht gleich verteilt.
Die Bewertung braucht deshalb ein Folgenmodell. Eine verpasste Klassifizierung geringer Priorität und eine falsch ausgeführte privilegierte Handlung sollten nicht gleich gewichtet werden.
Die folgenreichere Kennzahl ist oft der unsichere erfolgreiche Abschluss: Fälle, in denen der Agent eine Handlung ausführen konnte, die nie hätte erlaubt sein dürfen.
Ein System kann eine niedrigere Gesamterledigungsquote haben und dennoch deutlich sicherer sein, wenn unklare und risikoreiche Fälle eskaliert statt falsch abgeschlossen werden.
Deshalb sollten sich Leistungsschwellen an der betrieblichen Folge orientieren statt an einem einzigen globalen Prozentwert.
Human-in-the-Loop wird häufig schlecht umgesetzt.
Der Agent empfiehlt eine Handlung und zeigt dem Prüfer einen großen grünen Freigabeknopf. Der Mensch sieht die Zusammenfassung des Modells, nicht aber die zugrunde liegenden Belege, Richtlinien oder betroffenen Systeme. Der Workflow enthält formal eine menschliche Freigabe, doch der Prüfer hat kaum eine Grundlage für ein eigenes Urteil.
Bei Handlungen mit hohem Schadenspotenzial sollte der Freigabepunkt genug Belege zeigen, um dem Agenten widersprechen zu können.
Der Prüfer sollte verstehen, was sich ändert, warum der Agent die Handlung für nötig hält, welche Belege die Entscheidung stützen, welche Systeme betroffen sind, welche Befugnis ausgeübt wird und ob die Handlung umkehrbar ist.
Wo Funktionstrennung zählt, sollte die freigebende Identität eine andere sein als die, die die Handlung vorbereitet oder ausführt.
Menschliche Aufsicht wirkt nur, wenn der Mensch aussagekräftige Informationen und echte Befugnis hat, Nein zu sagen.
Agentische Steuerung im Umfeld kritischer Infrastruktur verlangt eine strengere Auslegung, weil KI-Fehler über Informationssysteme hinaus wirken können.
Die EU-KI-Verordnung stuft bestimmte KI-Systeme, die als Sicherheitskomponenten bei der Verwaltung oder dem Betrieb kritischer digitaler Infrastruktur, des Straßenverkehrs und der Versorgung mit Wasser, Gas, Wärme oder Strom eingesetzt werden, als Hochrisiko-Anwendungsfälle ein — vorbehaltlich des Anwendungsbereichs und des aktuellen Umsetzungszeitplans. Nach den Änderungen von 2026 sollen die einschlägigen Hochrisiko-Regeln des Anhangs III ab dem 2. Dezember 2027 gelten.
Diese rechtliche Einordnung sollte nicht auf jeden Agenten ausgedehnt werden, der irgendwo in einem Infrastrukturunternehmen läuft. Der Verwendungszweck zählt.
Architektonisch ist das Prinzip jedoch weiter gefasst. Wenn eine KI-Komponente einen sicherheitsrelevanten oder hochkritischen Prozess beeinflussen kann, werden deterministische Sicherheitsgrenzen und unabhängige Kontrolle wichtiger, nicht unwichtiger.
In industriellen Umgebungen liefert IEC 62443 einen starken Rahmen für Systemsicherheitsgrenzen, Zonen und Conduits, eingeschränkten Datenfluss und die Sicherheit von Steuerungssystemen. Ein Agent kann einen Bediener unterstützen, Telemetrie analysieren oder eine Änderung empfehlen und dabei außerhalb der Steuerungshoheit bleiben, die den sicheren Betrieb durchsetzt.
Diese Trennung kann wichtiger sein als weitere Verbesserungen der Modellgenauigkeit.
Unterstützt ein Agent ein Finanzunternehmen im Anwendungsbereich von DORA, darf die Bewertung nicht beim Modell- und Anwendungsverhalten enden.
Der Workflow steht in einem größeren Umfeld aus IKT-Risikomanagement und Drittparteirisiken. DORA verlangt von erfassten Finanzunternehmen, IKT-Abhängigkeiten zu kennen, kritische Funktionen zu schützen, Kontinuität und Wiederherstellung zu sichern, Resilienz zu testen und IKT-Dritte zu steuern.
Ein Agent, der auf ein externes Modell oder eine externe Toolchain angewiesen ist, kann damit Teil einer kritischen Abhängigkeit werden.
Die Organisation sollte wissen, ob der Geschäftsprozess weiterlaufen kann, wenn diese Abhängigkeit wegfällt, welche Daten der Anbieter erhält, wie Vorfälle erkannt werden, wie ein Anbieter ersetzt werden kann und welche Betriebsnachweise nach einem Ausfall verfügbar bleiben.
Im Finanzdienstleistungsbereich können diese Fragen wichtiger sein als die Frage, ob ein Modell in einem internen Benchmark zwei Prozentpunkte besser abschneidet.
ISO/IEC 42001 bietet einen brauchbaren Managementsystem-Rahmen für die Steuerung von KI in einer Organisation, während ISO/IEC 23894 KI-spezifische Leitlinien zum Risikomanagement liefert. Gemeinsam fördern sie einen Lebenszyklus-Ansatz, statt die Bewertung als einmalige Übung vor dem Produktivgang zu behandeln.
Das zählt, weil ein Agent, der im Januar die Bewertung bestanden hat, im Juni nicht zwangsläufig dasselbe System ist.
Das Modell kann sich geändert haben. Werkzeugschemata können sich weiterentwickelt haben. Ein Prompt kann aktualisiert worden sein. Eine Geschäftsregel kann sich geändert haben. Nutzer können neue Wege gefunden haben, mit dem Workflow umzugehen. Eine neue Angriffstechnik kann eine Annahme ausnutzen, die zuvor als sicher galt.
Vorfälle im Produktivbetrieb und ungewöhnliche Interaktionen sollten deshalb in die Bewertungssuite zurückfließen. Schwere Fehler sollten zu Regressionsfällen werden. Änderungen an Modell oder Orchestrierung sollten vor der Freigabe die Tests auslösen, die für ihre Risikodomäne relevant sind.
Vertrauen wird über die Zeit durch Belege erhalten, nicht beim Go-Live dauerhaft verliehen.
Das Speichern des Chatverlaufs genügt nicht.
Eine Vorfalluntersuchung muss unter Umständen feststellen, welche Identität die Anfrage ausgelöst hat, welche Modellversion verwendet wurde, welche Richtlinie galt, welcher Kontext abgerufen wurde, welche Werkzeuge aufgerufen wurden, welche Argumente übergeben wurden, was das externe System zurückgab, wer die Handlung freigab und ob der entstandene Zustand danach geändert oder zurückgerollt wurde.
Bei ernsthaften Systemen zählen auch Integrität und Aufbewahrung dieser Nachweise.
Eine Organisation sollte nicht erst nach einem Vorfall feststellen, dass die einzige brauchbare Spur vorübergehend in einem Anbieter-Dashboard lag.
Prüfbarkeit sollte deshalb als Eigenschaft der Plattform entworfen werden.
Ein Agent im Produktivbetrieb sollte einen kontrollierten Weg vom autonomen Betrieb zurück in einen sichereren Modus haben.
Erzeugt ein Modell-Update auffälliges Verhalten, will die Organisation vielleicht jede Schreiboperation freigabepflichtig machen und die reine Leseanalyse weiterlaufen lassen. Ist ein Werkzeug kompromittiert, sollte diese Fähigkeit einzeln abschaltbar sein. Ändert sich die Sicherheitslage, muss die Plattform womöglich ein Modell oder einen Anbieter aus dem Routing nehmen, ohne den ganzen Workflow stillzulegen.
Das ist ein besseres Resilienzmodell als ein einzelner globaler Not-Aus.
Das System sollte seine Befugnis herabstufen können und dabei jede nützliche Funktion erhalten, die sicher bleibt.
Das ist bei kritischem Betrieb besonders wichtig, denn die Wahl sollte nicht immer zwischen voller Autonomie und komplettem Ausfall liegen.
Der beste Agent ist nicht zwangsläufig der mit der beeindruckendsten Begründungskette.
Es ist der, dessen Befugnis begrenzt und verstanden ist, dessen Werkzeuge ihre eigenen Berechtigungen durchsetzen, dessen Handlungen beobachtbar und wiederherstellbar sind, dessen unsichere Fälle getestet wurden, dessen Autonomie unter ungewöhnlichen Bedingungen reduziert werden kann und dessen Verhalten noch Monate später prüfbar bleibt.
Eine reife Organisation kann deshalb eine weit stärkere Frage beantworten als die, ob der Agent genau ist.
Sie kann erklären, was der Agent tun darf, was ihn an mehr hindert, welche Bedingungen ihn anhalten lassen, wie Fehler eingegrenzt werden und welche Belege jede ihm eingeräumte Autonomiestufe rechtfertigen.
Das ist der Punkt, an dem Vertrauen vom Eindruck zur Architektur wird.
Wir begleiten Organisationen bei der Expansion in die Golfstaaten, nach Zentralasien und Afrika.
30-minütiges Erstgespräch buchenWir klären Ihr Ziel, den Zielmarkt und die Rahmenbedingungen. Innerhalb eines Arbeitstages erhalten Sie zwei bis drei Terminvorschläge.