Wenn KI-Agenten handeln dürfen beginnt eine neue Risikoklasse
Die meisten Unternehmen diskutieren bei KI-Agenten noch immer über Modelle.
Welches Modell ist besser?
Welcher Agent arbeitet zuverlässiger?
Welche Plattform ist schneller?
Welche Lösung integriert sich besser in Microsoft, SAP oder Salesforce?
Das sind legitime Fragen.
Aber sie beginnen zu spät.
Denn sobald ein KI-Agent nicht mehr nur Text erzeugt, sondern auf Unternehmenssysteme zugreift, Daten verändert, E-Mails verschickt, Bestellungen vorbereitet, Tickets schließt oder Prozesse auslöst, verändert sich die Risikoklasse grundlegend.
Dann geht es nicht mehr primär darum, wie intelligent ein Modell ist.
Dann geht es darum:
Was darf dieses System tatsächlich bewirken?
Und genau an dieser Stelle beginnt derzeit eines der größten Missverständnisse rund um Agentic AI.
Ein Chatbot kann Unsinn erzählen. Ein Agent kann daraus Realität machen.
Halluzinationen kennen wir seit Jahren.
Ein Modell erfindet eine Quelle.
Es interpretiert einen Sachverhalt falsch.
Es formuliert eine Antwort überzeugender, als es die Faktenlage erlaubt.
Bei klassischen Chatbots ist das ärgerlich.
Bei KI-Agenten kann daraus jedoch eine Handlung entstehen.
Ein Agent liest beispielsweise eine Kundenanfrage falsch, interpretiert einen Vertragsbestandteil falsch und erzeugt anschließend automatisch eine Gutschrift.
Oder er erkennt vermeintlich einen offenen Vorgang und versendet eine Nachricht.
Oder er verarbeitet einen Datensatz falsch und schreibt das Ergebnis zurück in ein produktives System.
Der entscheidende Unterschied lautet deshalb:
Ein Fehler im Modell bleibt nicht mehr zwingend im Modell.
Er kann zum Zustandswechsel im Unternehmen werden.
Und genau deshalb reichen die bekannten Diskussionen über bessere Prompts, größere Modelle oder weniger Halluzinationen nicht mehr aus.
Das eigentliche Problem ist nicht die KI. Es ist ihre Reichweite.
Die Diskussion über KI-Agenten konzentriert sich häufig auf Intelligenz.
In der Praxis ist jedoch oft etwas anderes entscheidender:
Wie groß ist der Handlungsraum, den wir dem Agenten geben?
Ein Agent, der ausschließlich Daten aus einem abgeschotteten System liest, hat ein anderes Risikoprofil als ein Agent, der:
- Daten verändern kann,
- E-Mails versendet,
- Zahlungen vorbereitet,
- Verträge anlegt,
- Datensätze löscht,
- Berechtigungen verändert,
- oder weitere Agenten aufruft.
Der gefährlichste Agent ist deshalb nicht zwingend derjenige, der schlecht arbeitet.
Es kann derjenige sein, der technisch korrekt arbeitet – aber innerhalb eines viel zu großen Mandats.
Sieben Probleme tauchen derzeit immer wieder auf
Betrachtet man aktuelle Agentenprojekte, lassen sich viele Schwierigkeiten auf einige wiederkehrende Muster zurückführen.
1. Zu viel Autonomie
Der Agent soll unterstützen.
Nach einigen erfolgreichen Tests bekommt er zusätzliche Berechtigungen.
Dann noch eine.
Dann darf er nicht nur lesen, sondern auch schreiben.
Später darf er selbstständig Folgeaktionen ausführen.
Und irgendwann weiß niemand mehr genau, wo die Grenze zwischen Assistenz und autonomer Ausführung liegt.
Das Problem ist nicht Autonomie an sich.
Das Problem ist unkontrollierte Autonomie.
2. Berechtigungen werden mit Intelligenz verwechselt
Ein KI-Agent kann entscheiden, welche Aktion aus seiner Sicht sinnvoll erscheint.
Aber daraus folgt nicht, dass er diese Aktion ausführen darf.
Diese beiden Ebenen müssen getrennt werden.
Entscheidung und Berechtigung sind nicht dasselbe.
Ein Modell kann beispielsweise vorschlagen:
„Diese Bestellung sollte freigegeben werden.“
Das bedeutet noch lange nicht:
„Dieses System darf diese Bestellung jetzt freigeben.“
Diese Trennung ist elementar.
Und trotzdem wird sie in vielen Agentenarchitekturen noch nicht konsequent umgesetzt.
3. Prompt Injection wird zum echten Unternehmensrisiko
Prompt Injection wird häufig noch als Problem der Sprachmodelle betrachtet.
Das greift zu kurz.
Gefährlich wird Prompt Injection vor allem dann, wenn ein externer oder ungeprüfter Input das Verhalten eines Agenten so verändert, dass daraus eine privilegierte Aktion entsteht.
Eine manipulierte E-Mail.
Ein präpariertes Dokument.
Ein Kontaktformular.
Eine externe Webseite.
Ein Agent liest die Inhalte und interpretiert sie als Arbeitsanweisung.
An diesem Punkt muss die Architektur eine klare Grenze ziehen.
Untrusted Input darf niemals selbst Berechtigung erzeugen.
Ein Modell darf etwas interpretieren.
Ein Modell darf etwas vorschlagen.
Aber die Entscheidung, ob eine kritische Aktion zulässig ist, muss außerhalb des Modells getroffen werden.
4. Kostenexplosionen sind häufig nur ein Symptom
Wenn ein KI-Agent plötzlich Tausende Modellaufrufe erzeugt, wird das schnell als FinOps-Problem behandelt.
Natürlich spielt Kostenkontrolle eine Rolle.
Aber die eigentliche Frage lautet:
Warum durfte der Agent überhaupt unbegrenzt weiterarbeiten?
Ein produktives Agentensystem braucht technische Grenzen.
Zum Beispiel für:
- maximale Modellaufrufe,
- maximale Laufzeit,
- maximale Anzahl von Folgeaktionen,
- Datenvolumen,
- API-Aufrufe,
- Tokenverbrauch,
- Transaktionsbeträge,
- Empfänger,
- oder kumulatives Risiko.
Kostenbegrenzung ist deshalb nur ein Teil eines größeren Themas:
Runtime Control.
5. „Der Agent sagt, er sei fertig“ ist kein Nachweis
Dieser Punkt wird bei Agentenprojekten noch massiv unterschätzt.
Ein Agent kann melden:
„Die Aufgabe wurde erfolgreich abgeschlossen.“
Technisch kann sogar ein sauberer Exit-Code zurückkommen.
Aber das beweist nicht, dass die gewünschte Wirkung tatsächlich eingetreten ist.
Wenn ein Agent beispielsweise einen Datensatz ändern sollte, reicht seine eigene Erfolgsmeldung nicht.
Entscheidend ist der Zustand des Zielsystems.
Wurde die Änderung tatsächlich vorgenommen?
Mit welchem Wert?
In welchem Datensatz?
Zu welchem Zeitpunkt?
Unter welcher Identität?
Ein produktives Agentensystem braucht deshalb mehr als Logging.
Es braucht Evidence.
Oder anders formuliert:
Erfolg muss am Zielsystem nachgewiesen werden, nicht durch die Selbstauskunft des Agenten.
6. Der Pilot funktioniert. Die Produktion scheitert.
Viele KI-Agenten sehen im Proof of Concept beeindruckend aus.
Das ist nicht überraschend.
Ein Pilot arbeitet oft mit:
Datenexport → Agent → Ergebnis.
Produktionsbetrieb sieht anders aus.
Dort kommen hinzu:
Identität.
Berechtigung.
Live-Daten.
Datenschutz.
Monitoring.
Freigaben.
Fehlerzustände.
Versionierung.
Protokollierung.
Rollback.
Auditierbarkeit.
Aus einem erfolgreichen Pilotprojekt folgt deshalb noch keine Betriebsfähigkeit.
Der Fehler vieler Unternehmen besteht darin, Produktion als größere Version des Piloten zu betrachten.
Das ist sie nicht.
Produktion ist ein anderes Betriebsmodell.
7. Agent Chains verschärfen das Problem
Noch interessanter wird es bei Agent Chains.
Nehmen wir vier Agenten:
Agent A darf Daten lesen.
Agent B darf bewerten.
Agent C darf eine Bestellung vorbereiten.
Agent D darf sie versenden.
Jede einzelne Berechtigung sieht zunächst beherrschbar aus.
Die Kombination kann jedoch eine vollständige Geschäftstransaktion erzeugen.
Damit entsteht eine neue Frage:
Wer kontrolliert nicht nur den einzelnen Agenten, sondern die kumulative Wirkung der gesamten Kette?
Genau hier stoßen klassische Rollen- und Berechtigungssysteme schnell an Grenzen.
Denn Agent Chains erzeugen Risiken nicht nur durch einzelne Aktionen.
Sie erzeugen Risiken durch die Kombination vieler scheinbar harmloser Aktionen.
Dafür brauchen Unternehmen eine weitere Kontrollebene.
Die eigentliche Architekturfrage lautet deshalb anders
Wir sollten bei Agentic AI weniger fragen:
Welches Modell ist am besten?
Und häufiger:
Welche technische Architektur verhindert, dass ein Modell außerhalb seines Mandats handeln kann?
Daraus ergeben sich einige grundlegende Prinzipien.
Identity
Jeder Agent braucht eine eindeutige Identität.
Nicht irgendeinen gemeinsamen technischen Benutzer.
Nicht einen anonymen API-Key.
Sondern nachvollziehbare Identität.
Mandate
Jeder Agent braucht einen klar definierten Auftrag.
Was darf er?
Für wen?
In welchem Prozess?
Für welchen Zeitraum?
Scope
Daten, Systeme, Aktionen, Empfänger und Beträge müssen begrenzt werden.
Ein Agent braucht nicht „SAP-Zugriff“.
Er braucht exakt die Rechte, die seine Aufgabe verlangt.
Runtime Control
Kritische Aktionen müssen unmittelbar vor der Ausführung geprüft werden.
Nicht nur beim Start des Agenten.
Nicht nur einmal bei der Konfiguration.
Sondern dann, wenn aus einem Vorschlag eine reale Handlung werden soll.
Human Gate
Nicht jede Aktion muss durch Menschen bestätigt werden.
Aber kritische Aktionen brauchen klare Freigabeschwellen.
Geld.
Externe Kommunikation.
Löschen.
Berechtigungen.
Personaldaten.
Verträge.
Und vergleichbare irreversible oder geschäftskritische Vorgänge.
Evidence
Jede wichtige Aktion braucht einen nachvollziehbaren Nachweis.
Was sollte passieren?
Was wurde freigegeben?
Was wurde tatsächlich ausgeführt?
Und was ist im Zielsystem angekommen?
Damit verändert sich auch die Rolle von Governance
Governance wird häufig noch als Dokumentationsaufgabe verstanden.
Richtlinien.
Checklisten.
Freigaben.
Verantwortlichkeiten.
All das bleibt wichtig.
Aber bei autonomen Systemen reicht Governance auf Papier nicht mehr.
Eine Policy, die technisch nicht durchgesetzt wird, ist im entscheidenden Moment nur eine Empfehlung.
Deshalb werden Unternehmen zwei Ebenen brauchen:
Governance definiert, was erlaubt ist.
Runtime Control erzwingt, dass nur das Erlaubte ausgeführt wird.
Diese Trennung wird meiner Einschätzung nach zu einer der wichtigsten Architekturfragen der kommenden Jahre.
Genau hier entsteht eine neue Infrastrukturklasse
Zwischen KI-Agent und Unternehmenssystem braucht es künftig häufig eine zusätzliche Kontrollschicht.
Nicht um die KI langsamer zu machen.
Sondern um probabilistische Entscheidungen von deterministischer Ausführung zu trennen.
Der Agent kann vorschlagen.
Er kann analysieren.
Er kann planen.
Er kann sogar eine komplette Handlung vorbereiten.
Aber bevor diese Handlung ein produktives Unternehmenssystem verändert, muss eine unabhängige Instanz prüfen:
Ist der Agent identifiziert?
Besitzt er ein gültiges Mandat?
Ist die Aktion innerhalb seines Scopes?
Wird eine Risikogrenze überschritten?
Ist eine Freigabe erforderlich?
Ist die Aktion nachvollziehbar?
Erst danach darf ausgeführt werden.
Genau diesen Ansatz verfolgen wir mit AXYON.
AXYON sitzt zwischen KI-Agenten und Unternehmenssystemen und trennt Vorschlag, Prüfung und Ausführung voneinander.
Die Grundidee ist bewusst einfach:
Die KI schlägt vor. Das System entscheidet.
Das eigentliche KI-Risiko beginnt nicht beim Denken
Wir werden in den kommenden Jahren leistungsfähigere Modelle sehen.
Mehr Agenten.
Mehr autonome Prozesse.
Mehr Multi-Agent-Systeme.
Mehr Agent Chains.
Und gleichzeitig werden Unternehmen feststellen, dass sie nicht jedes Problem mit einem besseren Modell lösen können.
Denn je autonomer KI-Systeme werden, desto wichtiger wird eine zweite Kompetenz:
die Fähigkeit, ihre Wirkung technisch zu begrenzen.
Die entscheidende Frage lautet deshalb nicht mehr nur:
Sondern:
Was passiert, wenn wir ihm erlauben, die Lösung selbst auszuführen?
Genau dort beginnt der Unterschied zwischen einer beeindruckenden KI-Demo und einem belastbaren Unternehmenssystem.
Unternehmen müssen KI-Agenten nicht daran hindern, intelligent zu sein.
Sie müssen verhindern, dass Intelligenz mit Berechtigung verwechselt wird.