KI-Agenten in Ihren Systemen: Was ein Agent allein tun darf, was ein Mensch freigeben muss und wie Sie starten, ohne die Kontrolle zu verlieren

Ein KI-Agent ist ein Sprachmodell, das Ihre Software bitten kann, Funktionen auszuführen, also Aktionen wie eine Zahlung nachzuschlagen, ein Ticket zu aktualisieren oder eine Erstattung auszulösen. Das Modell stellt nur die Anfrage. Ihre Systeme entscheiden, ob sie ausgeführt wird, und genau dort behalten Sie die Kontrolle. Beginnen Sie mit einer eng umrissenen Aufgabe, bei der der Agent selbstständig Daten liest und Entwürfe vorbereitet. Eine namentlich benannte Person gibt alles frei, was Geld bewegt, den Datensatz eines Kunden ändert oder das Unternehmen verlässt.

Was ist ein KI-Agent, in einfachen Worten?

Ein Sprachmodell, die Art von KI hinter ChatGPT, erzeugt Text. Ein Agent ist ein Sprachmodell, das mit Funktionen in Ihren Systemen verbunden ist, sodass sein Ergebnis nicht nur eine Antwort, sondern auch eine Aktion sein kann.

Die Dokumentation von Anthropic zu seinen Claude-Modellen sagt: „Tool Use (auch Function Calling genannt) ermöglicht es Claude, Funktionen aufzurufen, die Sie definieren oder die Anthropic bereitstellt.“ Für die Funktionen, die Sie definieren, liefert das Modell „einen strukturierten Aufruf, den Ihre Anwendung ausführt“. Es schreibt die Anfrage, und Ihre Software führt sie aus oder lehnt sie ab. Alle Quellen in diesem Artikel wurden am 2. November 2026 abgerufen.

Ein Agent wiederholt das in einer Schleife. Er ruft eine Funktion auf, liest das Ergebnis und wählt den nächsten Schritt, bis die Aufgabe erledigt ist. Ein Beitrag von 2024 im Engineering-Blog von Anthropic beschreibt Agenten als „in der Regel einfach LLMs, die in einer Schleife Tools auf Grundlage von Rückmeldungen aus ihrer Umgebung verwenden.“ LLM steht für Large Language Model, ein großes Sprachmodell, und Tools sind die Funktionen, die es aufrufen kann.

Ein Agent kann also nur tun, was seine Funktionen erlauben. Die Liste der Funktionen ist seine Stellenbeschreibung, und sie ist das erste Dokument, das Sie verlangen sollten.

Warum ist es wichtig, ob der Agent Daten liest oder ändert?

Weil Lesen nichts verändert. Wenn der Agent die letzten fünf Zahlungen eines Kunden abruft und eine davon falsch erfasst, ist das Ergebnis ein falscher Entwurf, den ein Mensch bemerken kann.

Schreiben verändert etwas außerhalb des Modells: Eine Erstattung wird ausgezahlt oder eine E-Mail erreicht einen Kunden. Manche dieser Änderungen lassen sich nicht rückgängig machen.

Der Leitfaden von OpenAI zum Bau von Agenten schlägt vor, jede Funktion mit niedrigem, mittlerem oder hohem Risiko zu bewerten, „anhand von Faktoren wie Lese- oder Schreibzugriff, Umkehrbarkeit, erforderlichen Kontoberechtigungen und finanziellen Auswirkungen.“ Lesen bleibt nur so lange ein geringes Risiko, wie der Agent das Gelesene nirgendwohin senden kann. Der Abschnitt über Prompt Injection, einen Trick, bei dem Anweisungen in einer E-Mail oder einem Dokument platziert werden, zeigt, warum.

Welche Aktionen darf der Agent allein ausführen, und für welche braucht es einen Menschen?

Ordnen Sie jede Funktion einer von drei Gruppen zu:

• Agent allein: Daten lesen, Dokumente durchsuchen, Tags vergeben und Entwürfe schreiben, die in Ihren Systemen bleiben, bis jemand sie verwendet
• Agent schlägt vor, ein Mensch gibt frei: alles, was Geld bewegt, den Datensatz oder Status eines Kunden ändert oder eine Nachricht an Empfänger außerhalb des Unternehmens schickt
• Nie: Änderungen an Zugriffsrechten, Limits oder Bankverbindungen sowie Entscheidungen, die nach den Erwartungen Ihrer Aufsichtsbehörde eine namentlich benannte Person treffen soll

Bei den meisten Funktionen entscheiden vier Fragen über die Gruppe:

• Lässt sich die Aktion rückgängig machen, und von wem?
• Bewegt sie Geld oder ändert sie, was ein Kunde schuldet?
• Sieht ein Kunde, ein Partner oder eine Aufsichtsbehörde das Ergebnis?
• Schreibt ein Gesetz, eine Lizenzauflage oder Ihre eigene Richtlinie vor, dass ein Mensch entscheiden muss?

Der Leitfaden von OpenAI gibt für die mittlere Gruppe denselben Rat: „Aktionen, die sensibel oder irreversibel sind oder bei denen viel auf dem Spiel steht, sollten eine menschliche Aufsicht auslösen, bis das Vertrauen in die Zuverlässigkeit des Agenten wächst.“ Zu den Beispielen gehören „das Stornieren von Bestellungen von Nutzern, das Autorisieren hoher Erstattungen oder das Ausführen von Zahlungen.“

Die OWASP Top 10 for LLM Applications 2025, eine Risikoliste des Sicherheitsprojekts OWASP, enthalten einen Eintrag namens übermäßige Handlungsbefugnis (Excessive Agency). Er beschreibt den Schaden, den ein Agent anrichten kann, wenn er mehr Funktionen, Rechte oder Freiheit hat, als seine Aufgabe braucht. Zu den Kontrollen, die der Eintrag nennt, gehört, „von einem Menschen zu verlangen, folgenreiche Aktionen freizugeben, bevor sie ausgeführt werden.“

Wie sieht das in Support, Onboarding, Zahlungen und Reporting aus?

In jedem Bereich liest der Agent und schreibt Entwürfe, und die Entscheidungen bleiben bei einem Menschen. Ihre eigene Liste hängt von Ihren Systemen ab und davon, was Ihre Aufsichtsbehörde erwartet.

• Support: Der Agent versieht Tickets mit Tags und entwirft Antworten. Anfangs gibt ein Mensch jede Antwort frei, und Erstattungen und Gebührenerlasse brauchen immer eine Freigabe. Der Agent ändert nie die E-Mail-Adresse oder Telefonnummer eines Kunden, denn wer sie kontrolliert, kann den Login des Kunden zurücksetzen
• Onboarding: Der Agent prüft Dokumente auf fehlende Felder und fasst sie für den Analysten zusammen. Eine Änderung der Risikoeinstufung wartet auf Freigabe, und die Annahme eines Kunden bleibt bei einem Menschen
• Zahlungen: Der Agent ordnet die Zeilen des Kontoauszugs den Rechnungen zu und markiert Lücken. Eine zurückgehaltene Zahlung wird erst nach Freigabe ausgeführt, und die Bankverbindung eines Zahlungsempfängers darf der Agent nie ändern
• Reporting: Der Agent entwirft den Monatsbericht mit der Quelle jeder Zahl. Ein Mensch gibt alles frei, was an einen Kunden, den Vorstand oder eine Aufsichtsbehörde geht

Wo sollte der Freigabeschritt sitzen?

Verankern Sie die Freigabe in der Software, die die Funktion ausführt, nicht nur im Prompt, also den Anweisungen, die das Modell erhält. Ein Modell kann eine Zeile in seinem Prompt ignorieren oder sich im Gespräch davon abbringen lassen. Eine Erstattungsfunktion, die ohne den Klick einer freigebenden Person nicht läuft, lässt sich durch kein Gespräch umstimmen.

Die Empfehlungen von OWASP sehen es genauso: „Implementieren Sie die Autorisierung in nachgelagerten Systemen, statt sich darauf zu verlassen, dass ein LLM entscheidet, ob eine Aktion erlaubt ist oder nicht.“

Eine brauchbare Freigabemaske zeigt der freigebenden Person:

• Die Aktion, den Datensatz, den sie ändert, und den Betrag
• Den Datensatz vor und nach der Änderung
• Die Belege, die der Agent verwendet hat, etwa das Ticket oder die Zeile im Kontoauszug
• Eine verpflichtende Begründung, wann immer die freigebende Person ablehnt

Wenn jeder Vorschlag innerhalb von Sekunden freigegeben wird, haben die Menschen aufgehört zu prüfen. Die KI-Verordnung der EU (EU AI Act) hat dafür einen Namen: Automatisierungsbias. Ihr Artikel zur menschlichen Aufsicht verlangt, dass die Personen, die ein Hochrisiko-System beaufsichtigen, sich „einer möglichen Neigung zu einem automatischen oder übermäßigen Vertrauen in die Ausgabe“ bewusst bleiben können. Prüfen Sie jede Woche eine Stichprobe freigegebener Aktionen nach.

Welche Rechte sollte das Konto des Agenten haben?

Das Konto des Agenten sollte die Funktionen auf seiner Liste erlauben und sonst nichts. Geben Sie jedem Agenten in jedem System, auf das er zugreift, ein eigenes Konto, nie ein Administratorkonto oder den Login eines Mitarbeiters. Legen Sie diese Rechte im System selbst fest, wo das Modell sie nicht ändern kann. Passwörter und Schlüssel bleiben in Ihrer Software, für das Modell unsichtbar.

Das Beispiel von OWASP ist ein Agent, der Produkte empfiehlt und „möglicherweise nur Lesezugriff auf eine Tabelle ‚products‘ braucht“. OWASP warnt außerdem vor offenen Funktionen, etwa der Ausführung beliebiger Befehle auf einem Server, und bevorzugt eng gefasste Funktionen, die jeweils nur eine Sache tun.

Wenn der Agent für einen einzelnen Mitarbeiter arbeitet, sollte er in den Worten von OWASP „im Kontext dieses bestimmten Nutzers und mit den minimal notwendigen Rechten“ handeln. Dann kann er nicht mehr sehen oder tun als diese Person.

Was ist Prompt Injection, und warum wiegt sie bei Agenten schwerer?

Prompt Injection bedeutet, Anweisungen in Text zu platzieren, den der Agent liest, etwa in einer E-Mail, einem Ticket oder einem hochgeladenen Dokument. Das Modell befolgt sie womöglich, als kämen sie von Ihnen. Die Anweisungen können für menschliche Leser unsichtbar sein, und bei einem Agenten können daraus Aktionen werden. OWASP führt Prompt Injection in seiner Liste von 2025 an erster Stelle und schreibt: „Es ist unklar, ob es narrensichere Methoden zur Verhinderung von Prompt Injection gibt.“

Der Eintrag von OWASP zur übermäßigen Handlungsbefugnis beschreibt einen Assistenten, der ein Postfach liest, um eingehende E-Mails zusammenzufassen. Die Erweiterung, die er nutzt, kann auch E-Mails senden. Eine präparierte E-Mail bringt ihn dazu, das Postfach nach sensiblen Informationen zu durchsuchen und diese an den Angreifer weiterzuleiten.

Die Abhilfen von OWASP beginnen mit einer Funktion, die nur E-Mails lesen kann, und reinem Lesezugriff auf das Postfach. Außerdem muss ein Mensch „jede von der LLM-Erweiterung entworfene Mail manuell prüfen und auf ‚Senden‘ klicken.“ Da sich Prompt Injection nicht ausschließen lässt, planen Sie mit einem Agenten, der hereingelegt wurde, und halten Sie den Schaden, den er anrichten kann, klein.

Was sollten wir protokollieren, und wie machen wir einen Fehler rückgängig?

Protokollieren Sie jeden Funktionsaufruf. Jeder Eintrag zeigt den Agenten, die Funktion und ihre Eingaben, das Ergebnis, den Text, der zu dem Aufruf geführt hat, die Modell- und Prompt-Version sowie wer den Aufruf wann freigegeben hat. Jemand außerhalb des Entwicklungsteams sollte das Log lesen und nachvollziehen können, was mit einem bestimmten Kunden passiert ist.

OWASP weist darauf hin, dass Protokollierung und Rate-Limits übermäßige Handlungsbefugnis nicht verhindern, „aber das Ausmaß des verursachten Schadens begrenzen können“. Ein Rate-Limit begrenzt, wie viele Aktionen einer Art der Agent in einer bestimmten Zeit ausführen kann, sodass eine Serie fehlerhafter Aktionen früh stoppt.

Halten Sie vor dem Start schriftlich fest, wie jede Funktion, die Daten ändert, rückgängig gemacht wird und wer das übernimmt. Bevorzugen Sie Funktionen, die zunächst nur einen offenen Vorgang anlegen, etwa eine Erstattung, die in einer Warteschlange wartet. Ein offener Vorgang lässt sich löschen, eine gesendete Zahlung dagegen kaum zurückholen. Halten Sie einen Schalter bereit, der die Funktionen des Agenten sofort abschaltet, ohne Software-Release, und testen Sie ihn vor dem Go-live.

Schreibt das Gesetz vor, dass ein Mensch freigeben muss?

In der EU legt die KI-Verordnung (AI Act) Regeln für die menschliche Aufsicht über KI-Systeme fest, die sie als hochriskant einstuft. Diese Regeln stehen in Artikel 14, und Anhang III listet die Hochrisiko-Anwendungen auf. Zur Liste gehören die Prüfung der Kreditwürdigkeit natürlicher Personen und die Bewertung ihrer Bonität, wobei Systeme zur Aufdeckung von Finanzbetrug ausgenommen sind. Ebenso gehören die Risikobewertung und Preisbildung für natürliche Personen bei Lebens- und Krankenversicherungen dazu. Der AI Act Service Desk der Europäischen Kommission nennt den 2. Dezember 2027 als Datum, ab dem die Regeln für Hochrisiko-Systeme nach Anhang III gelten. Dieses Datum berücksichtigt die Änderungen durch den Digital Omnibus on AI. Solche Daten können sich verschieben, prüfen Sie also den aktuellen Zeitplan, bevor Sie damit planen.

Nach Artikel 14 müssen Aufsichtsmaßnahmen „den Risiken, dem Grad der Autonomie und dem Kontext der Nutzung“ des Systems „angemessen sein“. Die Personen, die es beaufsichtigen, müssen in der Lage sein, „in einer bestimmten Situation zu beschließen, das Hochrisiko-KI-System nicht zu verwenden oder die Ausgabe außer Acht zu lassen, außer Kraft zu setzen oder rückgängig zu machen“. Außerdem müssen sie es mit „einer ‚Stopptaste‘ oder einem ähnlichen Verfahren“ anhalten können.

Diese Regeln gelten nur für die Hochrisiko-Systeme, die die Verordnung aufführt, und viele Agenten in Support und Betrieb werden nicht dazugehören. Für diese Agenten sind dieselben Kontrollen trotzdem sinnvoll. Ob Ihr System unter die Regeln fällt, ist eine Frage für Ihre Anwälte. Dieser Artikel ist keine Rechtsberatung und behandelt nur EU-Regeln.

Wie starten wir, ohne die Kontrolle zu verlieren?

Fragen Sie zuerst, ob die Aufgabe überhaupt einen Agenten braucht. Der Engineering-Beitrag von Anthropic empfiehlt, „die einfachste mögliche Lösung zu finden und die Komplexität nur bei Bedarf zu erhöhen“, und fügt hinzu: „Das kann bedeuten, überhaupt keine agentischen Systeme zu bauen.“ Für viele Aufgaben genügt eine einzelne Anfrage an das Modell oder eine feste Abfolge von Schritten. Eine feste Abfolge verhält sich außerdem vorhersehbarer als ein Agent, der seine Schritte selbst wählt.

Wählen Sie einen Arbeitsablauf mit vielen Fällen pro Woche, klaren Regeln und Fehlern, die sich günstig beheben lassen, etwa das Sortieren von Support-Tickets und das Entwerfen von Antworten. Gehen Sie dann in Stufen vor:

• Messen Sie den Arbeitsablauf, wie er heute läuft: Zeit pro Fall, den Anteil der Fälle, die noch einmal bearbeitet werden müssen, und den wöchentlichen Rückstand
• Lassen Sie den Agenten im Shadow-Modus an echten Fällen laufen. Er macht Vorschläge, die Menschen arbeiten wie bisher, und Sie vergleichen beides
• Wechseln Sie in den Freigabemodus, in dem ein Mensch jede Aktion freigibt, und erfassen Sie, wie oft die freigebenden Personen etwas ändern oder ablehnen
• Lassen Sie den Agenten nur bei den Aktionsarten mit den wenigsten Korrekturen allein handeln, und prüfen Sie weiterhin jede Woche eine Stichprobe

Legen Sie vorab fest, welche Kennzahlen den Agenten in die nächste Stufe bringen und wer entscheidet. Der Leitfaden von OpenAI endet mit: „Fangen Sie klein an, validieren Sie mit echten Nutzern und bauen Sie die Fähigkeiten mit der Zeit aus.“ Der Beitrag von Anthropic empfiehlt „umfangreiche Tests in Sandbox-Umgebungen“, also in einer Kopie Ihrer Systeme, in der Fehler nichts kosten.

Was sollten wir prüfen, bevor der Agent live geht?

• Jede Funktion gehört zu einer der drei Gruppen und hat auf Ihrer Seite eine namentlich benannte verantwortliche Person
• Jemand hat in jedem System mit dem Konto des Agenten eine verbotene Aktion versucht und gesehen, dass sie scheitert
• Tickets und Dokumente mit eingeschleusten Anweisungen liefen durch den Agenten, und nichts geschah außerhalb dessen, was die Gruppen erlauben
• Für jeden Kunden zeigt das Log, was der Agent getan und wer es freigegeben hat
• Eine neue Modellversion geht erst live, nachdem dieselben Tests erneut gelaufen sind

Wem gehören der Code, die Prompts und die Logs?

Ihrem Unternehmen sollten sie gehören, und der Vertrag sollte das festhalten. Der Code ist nur ein Teil des Agenten. Die Prompts, die Liste der Funktionen, die Freigaberegeln und die Testfälle bestimmen, wie er sich verhält. Benennen Sie all das als Liefergegenstände, abgelegt in einem Speicher, den Ihr Unternehmen kontrolliert.

Die Logs enthalten Kundendaten, deshalb brauchen sie dieselben Zugriffsregeln und dieselbe Aufbewahrungsfrist wie die Datensätze, die sie beschreiben. Wenn das Modell bei einem externen Anbieter läuft, fragen Sie, ob dieser Anbieter speichert, was der Agent ihm schickt, und wie lange.

Was sollten wir eine Firma fragen, die das System bauen würde?

• Können wir jede Funktion sehen, die der Agent aufrufen wird, und zu welcher Gruppe sie jeweils gehört?
• Wo werden Freigaben durchgesetzt: in unseren Systemen, in Ihrem Code oder nur im Prompt?
• Welches Konto nutzt der Agent in jedem System, und wie haben Sie getestet, dass er nicht mehr tun kann?
• Wie testen Sie auf Prompt Injection, und was passiert, wenn ein Testangriff gelingt?
• Kann unser Compliance-Team das Log ohne Ihre Hilfe lesen?
• Wie wird jede Aktion rückgängig gemacht, und wie schnell können wir den Agenten abschalten?
• Was gehört uns am Ende: Code, Prompts, Funktionsdefinitionen, Testfälle und Logs?

Wo passt amBrain ins Bild?

amBrain setzt Agenten in seinem eigenen Produkt ein. Seine Zeile zu diesem Produkt lautet: „Unser eigenes Produkt shyash.ai läuft auf KI-Agenten, die aus einem gemeinsamen Speicher von Unternehmensfakten recherchieren, schreiben, prüfen und messen. Ein Mensch gibt alles frei, was rausgeht.“

Das einzige Kundenprojekt mit einem Sprachmodell, das amBrain öffentlich beschreibt, ist dieses: „Wir haben eine LLM-Integration innerhalb des FinTech-Perimeters eines Kunden in Produktion gebracht: die Extraktion und Normalisierung unstrukturierter Mitteilungen von Brokern und Handelsplätzen – Kapitalmaßnahmen, Instrumenten- und Margin-Änderungen – zu strukturierten Datensätzen, die das Handelssystem verarbeitet.“

Dieser Artikel ist keine Case Study und beschreibt über die obige Zeile hinaus keine Arbeit für Kunden. Diese Zeile sagt nichts über Agenten oder Freigaben, und der Artikel sagt nicht, dass amBrain Agentensysteme für Kunden baut. Die Beispiele aus Support, Onboarding, Zahlungen und Reporting sind allgemein und stammen nicht aus der Arbeit von amBrain.

Die hier genannten Unternehmen und Organisationen werden anhand ihrer veröffentlichten Seiten zitiert. Der Artikel behauptet keine Beziehung zwischen amBrain und einem von ihnen und nennt weder Preise noch Zeitpläne von amBrain.

amBrain entwickelt seit 2019 Software. Es arbeitet in drei Formaten: vollständige Umsetzung, ein dediziertes Team oder in Ihr Team eingebettete Entwickler. Zum Eigentum lautet sein Satz: „Der Kunde behält das volle Eigentum an Produkt und Code, ausgenommen unsere wiederverwendbaren Komponenten.“ Die Fragen oben gelten für jede Firma, die Sie in Betracht ziehen.