KI-Agenten begrenzen: Zuständigkeit klar festlegen

1. Wenn Hilfsbereitschaft zum Risiko wird

Stellen Sie sich den Chatbot einer Bank vor. Er ist dafür da, Kontostände zu erklären, bei Überweisungen zu helfen und Fragen zu Gebühren zu beantworten. Ein Kunde tippt: „Sollte ich jetzt in Kryptowährung investieren?“ Der Bot rät konkret: „In Ihrer Situation würde ich einsteigen — Bitcoin ist derzeit die solideste Wahl und passt gut zu Ihrem Profil.“ Der Kunde ist zufrieden. Fachlich ist gerade etwas passiert, das den Betreiber teuer zu stehen kommen kann: Aus einer allgemeinen Information wurde eine persönliche Empfehlung für ein bestimmtes Anlageprodukt — und genau daran entscheidet sich, ob eine erlaubnispflichtige Anlageberatung vorliegt (Abschnitt 4).

Der Bot ist dabei nicht defekt. Er tut genau das, wofür er trainiert wurde: hilfreich sein — eines von drei Leitzielen moderner Sprachassistenten, neben ehrlich und harmlos [1]. Hilfsbereitschaft ist damit nicht selbstbegrenzend und fällt auch nicht automatisch mit „harmlos“ zusammen; beide Eigenschaften müssen im Training aktiv gegeneinander abgewogen werden [2]. Ein Modell bringt also einen starken Antrieb mit, zu antworten — aber keinen eingebauten Begriff davon, wofür es zuständig ist.

Wie tief dieser Antrieb sitzt, zeigt ein verwandter Effekt: die Sycophancy — die dokumentierte Neigung von Modellen, der Sichtweise des Nutzers zuzustimmen, statt ihr zu widersprechen [3]. Das ist nicht dasselbe wie ein Themenaustritt; es belegt aber, dass die Ausrichtung auf Gefälligkeit stark genug ist, um andere Ziele zu überlagern — und macht plausibel, warum die Zurückweisung einer Frage der unwahrscheinlichere Weg ist. Hilfsbereitschaft ist ein antrainierter Reflex, kein Urteilsvermögen über Zuständigkeit. Das Modell hat kein Gespür dafür, wo die Aufgabe der Bank endet und die regulierte Anlageberatung beginnt — und niemand hat ihm diese Grenze beigebracht.

2. Warum gut gemeinte Grenzen brechen

Der erste Reflex vieler Teams ist naheliegend: „Dann schreiben wir dem Bot eben in die Grundanweisung, dass er nur über Bankthemen spricht.“ Diese Anweisung — der System-Prompt, also die feste Instruktion, die dem Modell vor jedem Gespräch mitgegeben wird — ist notwendig, aber als alleinige Grenze schwach.

Der Grund liegt in der Funktionsweise der Modelle. Sie behandeln den System-Prompt von Haus aus nicht zuverlässig als übergeordnet, sondern oft mit derselben Priorität wie den Text eines nicht vertrauenswürdigen Nutzers. Das lässt sich nachtrainieren, und Anbieter tun das auch — ein eigens entwickeltes Verfahren steigerte in den untersuchten Angriffstests die Robustheit um bis zu 63 Prozent, kein allgemeiner Wirksamkeitswert [4]. Doch eine Restlücke bleibt: Eine aktuelle Untersuchung über mehrere führende Modelle kommt zu dem Ergebnis, dass die übliche Trennung in System- und Nutzeranweisung keine verlässliche Instruktionshierarchie schafft [5] — und das Kontrollversagen tritt schon bei einfachen Konflikten auf, nicht erst bei ausgefeilten Tricks.

Erschwerend kommt der Nicht-Determinismus hinzu, also die Eigenschaft, dass dasselbe Modell auf dieselbe Frage unterschiedliche Antworten geben kann. Ein Teil davon lässt sich durch die Konfiguration dämpfen — etwa durch eine niedrige „Temperatur“, die die Zufallsstreuung verringert —, ganz beseitigen lässt er sich damit nicht. Die verbleibende Ursache liegt im Betrieb: Anfragen werden beim Anbieter zu Stapeln zusammengefasst, und je nach Auslastung landet dieselbe Frage in einem anders zusammengesetzten Stapel. Schon das verändert das Rechenergebnis geringfügig — genug, damit an einer Weggabelung eine andere Antwort herauskommt [6]. Wer sich darauf verlässt, dass ein Bot eine Frage „letztes Mal ja auch korrekt abgelehnt hat“, verwechselt eine Tendenz mit einer Garantie. Praktisch folgt daraus: Reproduzierbarkeit ist eine Eigenschaft des Betriebs, nach der man den Anbieter fragen kann (Abschnitt 6).

Hinzu kommt die Modell-Drift, die Veränderung des Verhaltens über die Zeit. Ein vieldiskutierter Befund dokumentierte, wie die Trefferquote eines Modells bei einer festen Aufgabe binnen Monaten von 84 auf 51 Prozent fiel [7]. Die Deutung war umstritten — teils lag es an Mess- und Formatfragen —, der praktische Punkt bleibt aber und ist über die Modellpflege selbst belegt: Anbieter kündigen Modellversionen planmäßig ab und ersetzen sie [8], [9]. Modell-Pinning fixiert die zugrunde liegende Version, während Aliasnamen auf neuere Snapshots verweisen können; doch auch eine gepinnte Version verhält sich nicht garantiert identisch und kann eingestellt werden. Deshalb braucht jeder Versionswechsel einen erneuten Test.

An dieser Stelle der naheliegende Einwand: „Mein Bot lehnt solche Fragen doch längst ab — ich habe es ausprobiert.“ Das stimmt oft. Aktuelle Modelle sind umfangreich darauf nachtrainiert, heikle Themen von sich aus zurückzuweisen. Nur ist das keine Grenze, sondern eine Neigung, und die drei eben genannten Punkte erklären, warum: Sie ist nicht deterministisch, sie ist nirgends zugesichert, und sie ändert sich mit jedem Versionswechsel. Bei einem eingekauften Standard-Chatbot ist zudem meist gar nicht bekannt, welches Modell in welcher Version darunter arbeitet. Eine Ablehnungsneigung, die man weder messen noch festschreiben kann, ist kein Kontrollmechanismus — sie ist ein günstiger Umstand.

Zur Abgrenzung: All das ist kein Sicherheitsthema im klassischen Sinn. Angriffe durch böswillige Akteure sind ein eigenes, wichtiges Feld — wer es systematisch angehen will, findet in der einschlägigen Risikoliste für LLM-Anwendungen den Einstieg [10]. Hier geht es um etwas anderes: Das Scope-Problem entsteht im Normalbetrieb, durch die alltägliche Frage eines gutwilligen Kunden. Es braucht keinen Angreifer, damit ein Agent seine Zuständigkeit verlässt.

3. Wie Grenzverletzungen in der Praxis aussehen

Dokumentierte Vorfälle zeigen, was passiert, wenn einem Agenten die Grenze fehlt. Sie sind allerdings nicht alle vom selben Typ — und diese Unterscheidung ist wichtiger, als sie zunächst wirkt. Drei Muster lassen sich trennen, und sie stehen für die drei Schadensklassen Marke, Recht und Datenschutz.

Muster 1 — Rollen- und Tonaustritt (Schadensklasse Marke). Ein US-Autohändler stellte einen Chatbot auf Sprachmodell-Basis auf seine Website; Nutzer brachten ihn dazu, über beliebige Themen zu plaudern und einem scherzhaft einen Neuwagen für einen Dollar zu „verkaufen“ [11]. Ein britischer Paketdienst erlebte, wie sein Support-Bot zu fluchen begann und das eigene Unternehmen als „schlechtesten Lieferdienst der Welt“ bezeichnete; die Screenshots gingen viral, das Unternehmen schaltete die Funktion ab [12]. Beide Fälle entstanden, weil Nutzer den Bot bewusst austesteten — ein Verhalten, mit dem man im offenen Kundenkanal rechnen muss. Der Schaden ist hier keiner vor Gericht, sondern an der Marke.

Muster 2 — Falschauskunft mit Rechtsfolge (Schadensklasse Recht und Haftung). Der Chatbot einer Fluggesellschaft erfand gegenüber einem trauernden Kunden eine Erstattungsregel, die es nicht gab. Als der Kunde klagte, wies ein kanadisches Schlichtungstribunal (British Columbia) die Ausrede, der Bot sei selbst verantwortlich, ausdrücklich zurück: Der Bot sei „nur ein Teil der Website“ [13], [14]. Die Entscheidung ist in Deutschland nicht bindend; das Haftungsprinzip dahinter — ein Unternehmen steht für die Erklärungen seiner eigenen Systeme ein — gilt aber auch hierzulande. Ähnlich erfand der Support-Bot eines Softwareanbieters eine nicht existierende Firmenrichtlinie; mehrere Kunden kündigten daraufhin öffentlich ihr Abonnement [15]. Und der Chatbot einer Stadtverwaltung gab Unternehmern teils rechtswidrige Auskünfte — etwa, dass Arbeitgeber das Trinkgeld ihrer Mitarbeiter einbehalten dürften [16].

Wichtig ist die ehrliche Einordnung: Diese drei Fälle sind genau genommen keine Themenaustritte. Der Bot blieb im zugewiesenen Feld und gab dort eine falsche Auskunft — das bekannte Phänomen der Halluzination, hier innerhalb der Zuständigkeit. Es verlangt eine eigene Gegenmaßnahme: Ein Themenfilter hätte den Fall der Fluggesellschaft nicht verhindert, denn die Frage war zulässig und nur die Antwort erfunden. Was hier greift, ist die Grundlagenbindung — Aussagen zu Regeln, Preisen und Fristen nur aus einer hinterlegten, freigegebenen Quelle, sonst Eskalation. Sie gehört deshalb als eigene Kontrolle in das Maßnahmenpaket in Abschnitt 5. Gemeinsam ist beiden Fehlerarten das Organisatorische: dieselbe fehlende Festlegung, dieselbe fehlende Eskalationsregel, dieselbe fehlende laufende Prüfung.

Muster 3 — Datenpreisgabe (Schadensklasse Datenschutz). Das dritte Muster hinterlässt seltener virale Screenshots und ist doch das heikelste: Ein Agent gibt personenbezogene Daten heraus, die hinter einer Berechtigungsprüfung liegen sollten — Kontostände, Vertragsdaten, Angaben zu anderen Personen. Öffentlich dokumentiert wird das seltener, weil solche Vorfälle nicht komisch sind; im Betrieb ist es der Fehler mit den unmittelbarsten rechtlichen Folgen.

Bleibt der Fall, um den es diesem Whitepaper geht: der Themenaustritt durch eine harmlose Alltagsfrage. Für ihn gibt es keinen vergleichbar prominenten öffentlichen Fall, und das hat einen einfachen Grund: Wenn ein Bankbot einem einzelnen Kunden einen unpassenden Rat gibt, entsteht kein virales Bild, sondern ein stiller Vorgang zwischen zwei Parteien. Was hier vorgeführt wird, ist deshalb ein Szenario, kein Vorfallbericht — ein konstruierter Archetyp, dessen einzelne Schritte aber belegt sind: die Ursache in Abschnitt 2, die rechtliche Einordnung in Abschnitt 4. Die drei realen Muster stützen ihn von den Rändern her: Sie belegen, dass Agenten im offenen Kundenkanal aus der Rolle fallen, dass der Betreiber für ihre Aussagen einsteht und wie unmittelbar die datenschutzrechtlichen Folgen sind. Eines eint alle Vorfälle: Keiner erforderte einen technischen Angriff.

4. Der Banking-Fall im Detail: warum der Krypto-Rat teuer wird

Zurück zum Bot. Er hat nicht nur Chancen und Risiken erklärt, sondern konkret geraten, in Bitcoin einzusteigen, und das als für die Situation des Kunden passend dargestellt. Genau diese Konkretheit ist der Unterschied: Maßgeblich für die rechtliche Einordnung ist nicht die Frage des Kunden, sondern die Antwort des Bots.

Anlageberatung ist in Deutschland und der EU eine erlaubnis- und aufsichtspflichtige Dienstleistung. Als solche gilt die persönliche Empfehlung zu einem bestimmten Finanzinstrument, die sich auf die Umstände des Anlegers stützt oder als für ihn geeignet dargestellt wird [17], [18]. Der Grat ist schmal: „Kryptowährungen schwanken stark“ ist noch keine persönliche Empfehlung. Unser Bot nennt dagegen einen konkreten Kryptowert und stellt ihn als zum Profil passend dar. Ob damit Anlageberatung nach WpHG/MiFID II vorliegt, hängt zusätzlich davon ab, ob der Kryptowert als Finanzinstrument erfasst ist. Ist das der Fall, gelten insbesondere die Pflicht, im bestmöglichen Kundeninteresse zu handeln, sowie die Geeignetheitsprüfung [19], [20]; für die Tätigkeit gelten die einschlägigen Erlaubnisregime [21], [22].

Der entscheidende Punkt für jeden, der auf Automatisierung setzt: Die Aufsicht stellt ausdrücklich klar, dass es „für die Erlaubnispflicht … keine Rolle“ spiele, ob sich der Dienstleister automatisierter Prozesse bediene [23], [24]. Dass der Rat von einem Bot kommt, entlastet also nicht. Für Kryptowerte, die nicht bereits unter das Wertpapierrecht fallen, erfasst MiCAR die personalisierte Empfehlung als „Beratung zu Kryptowerten“ und verlangt eine Geeignetheitsprüfung; grundsätzlich ist dafür eine Zulassung erforderlich, Kreditinstitute können die Dienstleistung unter den Voraussetzungen des Notifikationsverfahrens erbringen [25].

Daraus folgt mehr, als auf den ersten Blick sichtbar ist. Wo eine Empfehlung reguliert ist, entfallen ihre Pflichten nicht dadurch, dass eine Maschine sie ausspricht: Geeignetheit und Kundeninformationen müssen geprüft, Erklärungs- und Aufzeichnungspflichten erfüllt werden [19], [20], [25]. Wer diese Pflichten an ein Sprachmodell delegiert, ohne prüfen zu können, ob es sie einhält, kann sie nicht erfüllen. Was dieses Whitepaper empfiehlt — festlegen, durchsetzen, nachweisbar prüfen —, ist für regulierte Fälle also nicht nur klug, sondern die Voraussetzung dafür, den eigenen Pflichten überhaupt nachzukommen.

Nun die zweite Frage desselben Kunden, ebenso beiläufig: „Wie viel hat eigentlich mein Mann auf seinem Konto?“ Auch hier will der Bot nur helfen. Gibt er die Auskunft, ohne dass geprüft ist, ob der Fragende berechtigt ist, legt er personenbezogene Daten unbefugt offen — mangels Rechtsgrundlage ein Verstoß gegen die Vertraulichkeit der Verarbeitung und je nach Risikobewertung eine nach Art. 33 der Datenschutz-Grundverordnung meldepflichtige Verletzung des Schutzes personenbezogener Daten, bei hohem Risiko zusätzlich mit Benachrichtigung der Betroffenen [26]. Das ist die dritte Schadensklasse, und sie unterstreicht einen Kernpunkt für den nächsten Abschnitt: Solche Daten dürfen gar nicht erst ohne Berechtigungsprüfung abrufbar sein. Ein Filter, der eine Kontonummer nachträglich schwärzt, ist keine Zugriffskontrolle.

Ein Wort zur KI-Verordnung: Der EU AI Act behandelt einen beratenden Chatbot als KI-System [27] und verlangt, dass Nutzer erkennbar erfahren, dass sie mit einer KI sprechen [28]; diese Transparenzpflicht gilt ab dem 2. August 2026, die Kommission hat dazu im Juli 2026 Leitlinien veröffentlicht [29]. Bereits seit dem 2. Februar 2025 gilt außerdem eine Pflicht, die viele übersehen: Wer KI-Systeme einsetzt, muss für ausreichende KI-Kompetenz der damit befassten Mitarbeiter sorgen [27]. In die strenge Hochrisiko-Klasse fällt dagegen nicht jeder Bankbot — sie greift nur für bestimmte Einsatzfelder aus Anhang III [27].

Die Summe ist unbequem: Eine fehlende Zuständigkeitsgrenze ist hier kein Produktmangel, sondern ein Aufsichts-, Haftungs- und Datenschutzrisiko. Und das Muster ist nicht auf Banken beschränkt. Fast jedes Unternehmen hat seine eigenen „Kryptofragen“ — Gewährleistungszusagen, Gesundheits-, Personal- oder Steuerauskünfte, die ebenso in eine fremde Zuständigkeit führen.

Ein Beispiel ohne Finanzaufsicht. Ein Maschinenbauer betreibt einen Support-Bot für Produktfragen. Ein Kunde fragt: „Hält die Dichtung auch 180 Grad im Dauerbetrieb aus?“ Der Bot bestätigt bereitwillig und formuliert damit womöglich eine Beschaffenheitsvereinbarung, an der sich die Gewährleistung entscheidet [30]. Kein WpHG, keine BaFin, aber strukturell derselbe Fall: Eine hilfreiche Antwort tritt aus der Zuständigkeit „Produktauskunft“ in die Zuständigkeit „rechtsverbindliche Zusage“. Für Hersteller kommt ein Datum hinzu, das viele noch nicht auf dem Schirm haben: Die neue EU-Produkthaftungsrichtlinie erfasst Software — und damit auch KI — ausdrücklich als Produkt und gilt für alles, was nach dem 9. Dezember 2026 in Verkehr gebracht wird [31].

Damit lässt sich das Muster übertragen. Ersetzen Sie „Anlageberatung“ durch die für Sie einschlägige Sorgfalts- oder Erlaubnispflicht, und das Bild bleibt gleich:

5. Was wirklich hilft: erst die Vorfrage, dann drei Ebenen

Bevor man einen Agenten einzäunt, lohnt eine Vorfrage: Braucht dieser Anwendungsfall überhaupt einen frei formulierenden KI-Agenten? Für eng umrissene, heikle Themen ist oft eine schlichtere Bauweise sicherer — eine feste Erkennung des Anliegens mit hinterlegten, geprüften Antworten kann eine Falschberatung baulich gar nicht erst erzeugen. Und für manche Fragen ist die richtige Entscheidung, dafür bewusst keinen Bot einzusetzen.

Wo ein generativer Agent sinnvoll ist, braucht er zwei Festlegungen, die dieses Whitepaper bewusst trennt. Scope ist die Grenze: Wofür ist der Agent zuständig — und wofür ausdrücklich nicht? Policy ist das Regelwerk, das diese Grenze im Betrieb durchhält: erlaubte Themen und verbotene Zonen, Ton- und Markenregeln, welche Daten nur nach Berechtigungsprüfung herausgehen, welche Aktionen erlaubt sind, wie eskaliert wird, auf welche Modellversion der Agent festgelegt ist und wer die Verantwortung trägt. Beides gehört zusammen — eine Grenze ohne Regelwerk ist eine Absichtserklärung, ein Regelwerk ohne Grenze hat keinen Bezugspunkt.

Die Umsetzung läuft über drei Ebenen: festlegen, durchsetzen, überprüfen. Diese Abfolge ist bewusst nicht neu erfunden — sie ist die Grundfigur der etablierten Rahmenwerke für KI-Governance, der Managementsystem-Norm ISO/IEC 42001 [32] und des Risikorahmens des US-amerikanischen Normeninstituts NIST [33]. Wer bereits nach einem der beiden arbeitet, findet die drei Ebenen dort wieder; dieses Whitepaper übersetzt sie auf den Fall des zuständigkeitsgebundenen Agenten.

Wie tief die Ebenen ausfallen, richtet sich nach dem Risiko. Drei Fragen genügen zur Einstufung: Ist der Agent extern erreichbar oder nur intern? Kann er auf personenbezogene Daten zugreifen? Berührt sein Themenfeld eine Erlaubnis- oder besondere Sorgfaltspflicht — Geld, Gesundheit, Recht — oder führt er selbst Handlungen aus? Kein Ja bedeutet Stufe Niedrig, ein Ja mindestens Stufe Mittel, zwei oder drei bedeuten Stufe Hoch.

Ebene 1: Scope und Policy definieren (organisatorisch)

Die erste Frage ist keine IT-Frage: Wofür ist dieser Agent da — und wofür ausdrücklich nicht? Diese Festlegung gehört auf die Führungsebene, weil sie Geschäfts-, Rechts- und Markenentscheidungen bündelt. Dazu gehören vier Bausteine: die zugelassenen Themen und die ausdrücklich verbotenen Zonen (im Beispiel: keine Anlage-, Steuer- oder Rechtsberatung); der erlaubte Ton und die Markenregeln; der Umgang mit personenbezogenen Daten samt der Frage, was nur nach Berechtigungsprüfung herausgeht; und das Eskalationsverhalten.

Die richtige Antwort auf die Krypto-Frage ist kein besserer Rat, sondern ein sauberer Übergang: „Dazu darf ich keine Empfehlung geben. Ich verbinde Sie mit einem Berater.“ Diese eine Zeile ist das eigentliche Produkt der ganzen Arbeit — und sie hat eine gern übersehene Voraussetzung: Es muss jemanden geben, zu dem verbunden wird. Jede zusätzlich gezogene Grenze verlagert Last vom Bot auf Menschen. Zur Eskalation gehören deshalb ein benanntes Ziel (Warteschlange, Rückrufformular, Ticket), eine Regelung für Zeiten ohne Besetzung — sonntagabends darf die Übergabe keine Sackgasse sein — und eine grobe Mengenschätzung der Anfragen neben dem Kernthema.

Ebene 2: Technisch durchsetzen (System-Prompt, Guardrails, Berechtigungen, Modell-Pinning)

Die Definition muss anschließend technisch erzwungen werden — nicht allein durch den System-Prompt, sondern durch eine zusätzliche Schicht aus Guardrails: Leitplanken, die zur Laufzeit jede Ein- und Ausgabe gegen die Regeln prüfen.

Wichtig ist dabei eine Unterscheidung. Programmierbare Regelwerke legen erlaubte Themen und Absichten in deklarativen Leitplanken fest [34]; ihr Abgleich läuft allerdings teils über Ähnlichkeitsmaße und ist damit nicht vollständig deterministisch. Weitgehend reproduzierbar sind dagegen feste Musterabgleiche und die Erkennung definierter personenbezogener Datenmuster [35] — die ganze Bandbreite natürlicher Sprache erfassen sie aber nicht. Daneben gibt es LLM-gestützte Wächter, etwa ein Prüfmodell, das Ein- und Ausgaben gegen eine anpassbare Themen-Systematik abgleicht [36]; sie sind flexibler, teilen aber die probabilistische Natur des Hauptmodells und taugen als Ergänzung, nicht als harte Grenze. Ein guter Aufbau kombiniert beides und schließt im Zweifel. Das hat einen Preis: Ein zu scharfer Wächter lehnt auch berechtigte Fragen ab — die richtige Schwelle ist eine Abwägung, kein Maximum. Zu bedenken ist zudem, dass auch ein vorgeschaltetes Prüfmodell dieselben personenbezogenen Daten verarbeitet und denselben Anforderungen unterliegt, bei externen Diensten unter Umständen als weiterer Auftragsverarbeiter [26].

Für die in Abschnitt 3 beschriebene Halluzination innerhalb der Zuständigkeit kommt eine eigene Kontrolle hinzu: die Grundlagenbindung. Aussagen zu Regeln, Preisen, Fristen und Zusagen dürfen nur aus einer hinterlegten, freigegebenen Quelle stammen; findet der Agent keine, antwortet er nicht, sondern eskaliert. Das ist die Kontrolle, die den Fall der Fluggesellschaft verhindert hätte.

Zwei Grenzen dieser Textkontrollen sind für Entscheider zentral. Erstens: Eine Guardrail, die Ein- und Ausgaben filtert, ist keine Zugriffskontrolle. Dass ein Wächter eine Kontonummer schwärzt, hilft nur, wenn die Daten überhaupt hätten fließen dürfen; der sichere Weg ist, personenbezogene Daten serverseitig nur nach bestandener Berechtigungsprüfung abrufbar zu machen — die Kontrolle sitzt hinter dem Agenten, nicht im Textfilter davor. Zweitens: Sobald ein Agent nicht nur antwortet, sondern handelt — Überweisungen anstößt, Verträge ändert —, reicht keine Guardrail auf Sprache. Dann müssen seine Rechte serverseitig erzwungen werden: eine Positiv-Liste erlaubter Aktionen, harte Betrags- und Mengengrenzen je Vorgang und eine menschliche Freigabe darüber hinaus.

Dazu kommt das Modell-Pinning: Die Anwendung wird auf eine geprüfte Modellversion festgelegt, und ein Wechsel erfolgt erst, nachdem die neue Version gegen dieselben Zuständigkeitsregeln getestet wurde [8], [9]. So verhindert man, dass ein stilles Update eine funktionierende Grenze aushebelt.

Ebene 3: Laufend überprüfen (Evals und Monitoring)

Weil Modelle nicht-deterministisch sind und driften, lässt sich Zuständigkeitstreue nicht einmalig abnehmen. Das Mittel dazu sind Evals — systematische, wiederholbare Tests, die prüfen, ob der Agent sich wie vorgesehen verhält. Wie lückenhaft ohne sie geprüft wird, machte der Vergleichsrahmen HELM sichtbar: Modelle waren zuvor im Schnitt nur auf rund 17,9 Prozent der Kernszenarien vergleichbar getestet worden [37].

Wo menschliche Prüfung zu aufwendig ist, kann ein starkes Sprachmodell die Antworten eines anderen bewerten, mit hoher Übereinstimmung zu menschlichen Urteilen [38]. Wenn man dem Urteil eines LLM nicht trauen soll — warum dann ein LLM als Prüfer? Der Unterschied liegt im Aufbau: Ein Eval prüft offline, gegen eine feste Bewertungsvorlage und über viele Fälle; nicht das Modell reguliert sich selbst. Verlässlich ist auch das nicht von allein — ein prüfendes Modell hat bekannte Verzerrungen und muss gegen menschliche Urteile kalibriert werden [38], [39].

Ein Scope-Eval besteht aus zwei Testarten: Fragen außerhalb der Zuständigkeit, die der Agent zuverlässig ablehnen und korrekt eskalieren muss; und Fragen innerhalb, die er gerade nicht abweisen darf, damit der Wächter nicht überblockt. Beide Richtungen zusammen ergeben vier mögliche Ausgänge, von denen nur zwei gewollt sind.

So sieht ein Anfangsbestand für den Banking-Bot aus:

Zur Schwelle: Bei regulierten Themen ist die realistische Zielgröße eine ausnahmslose Ablehnung der Fälle außerhalb der Zuständigkeit; innerhalb ist eine kleine Fehlablehnungsquote hinnehmbar, aber zu messen. Welcher Wert vertretbar ist, entscheidet die Risikostufe — festgelegt wird er einmal und dann nicht mehr stillschweigend verschoben. Open-Source-Frameworks lassen solche Tests als festen Regressionstest bei jeder Änderung an Modell oder Anweisung mitlaufen [40].

Ein Eval prüft allerdings nur, was man ihm vorlegt, und immer vor der Freigabe — nicht, was reale Nutzer morgen fragen. Deshalb gehört zu Ebene 3 das Monitoring im laufenden Betrieb: Ablehnungen und Eskalationen protokollieren, echte Dialoge stichprobenartig prüfen und aus jedem gemeldeten Fehltritt einen neuen Testfall machen. Weil dabei echte Dialoge gespeichert werden, ist das Monitoring selbst datenschutzrelevant; die Protokolle gehören pseudonymisiert und mit klarer Löschfrist geführt. Betrifft der Agent Mitarbeiter, kommt die Mitbestimmung hinzu: Eine Protokollierung, die Rückschlüsse auf ihr Verhalten zulässt, ist eine technische Überwachungseinrichtung — der Betriebsrat gehört früh eingebunden. Vier Kennzahlen genügen: Anteil korrekt abgelehnter Fragen außerhalb der Zuständigkeit, Fehlablehnungsquote bei berechtigten Fragen, Eskalationsquote und Zeit bis zur Behebung eines Vorfalls.

Eines skaliert nicht nach unten mit: Die schriftliche Scope- und Policy-Definition aus Ebene 1 braucht jeder Agent, auch der interne. Sie adressiert vor allem das Marken- und das Eskalationsrisiko; das Haftungs- und das Datenschutzrisiko sinken erst, wenn Ebene 2 die Definition technisch durchsetzt.

Belastbare Wirksamkeitszahlen für einen konkreten Aufbau gibt es nicht, und dieses Whitepaper nennt bewusst keine. Beschreibbar ist dennoch, wie die Rechnung aussieht. Auf der Aufwandsseite stehen überschaubare, aber reale Posten: die Scope-Definition als einmaliger Workshop von rund eineinhalb Arbeitstagen (Planungsannahme, siehe Hinweis am Ende), danach ein Bruchteil einer Stelle für Pflege und Monitoring, Rechenzeit für ein zweites Prüfmodell — und die Fehlablehnungen: Jede berechtigte Frage, die der Wächter abweist, kostet Servicequalität. Dieser Posten fällt laufend und messbar an und gehört deshalb in dieselbe Rechnung. Auf der anderen Seite steht das seltene Ereignis: ein Aufsichtsverfahren, ein Bußgeld nach der Datenschutz-Grundverordnung — deren Rahmen bis zu 20 Millionen Euro oder 4 Prozent des weltweiten Jahresumsatzes reicht [26] —, eine Haftung wie im Air-Canada-Fall oder öffentliche Kündigungen wie im Cursor-Fall. Wie wahrscheinlich das im Einzelfall ist, lässt sich seriös nicht beziffern. Die Rechnung bleibt trotzdem asymmetrisch: kleiner, laufender Aufwand gegen einen seltenen Schaden, dessen Höhe man vorher kennt — und die Zeit, bis ein Fehltritt auffällt, wird kürzer.

6. Umsetzung in der Praxis: Schritt für Schritt

Für die Einführung empfiehlt sich ein Vorgehen, das Führung und Technik verzahnt und sich am Risiko orientiert. Die ersten beiden Schritte schaffen die Grundlage, auf der alles Weitere aufsetzt.

Zuständigkeit schriftlich festlegen

(Führung/Fachbereich; ca. ein Workshop-Tag). Zugelassene Themen, ausdrücklich verbotene Zonen, Tonregeln und den Umgang mit personenbezogenen Daten definieren.

Eskalation definieren

(Fachbereich; ca. ein halber Tag). Für jede Verbotszone das Verhalten festlegen — ablehnen, an einen Menschen übergeben, dokumentieren —, die Ablehnungssätze vorformulieren und das Übergabeziel samt Randzeiten benennen.

Technisch durchsetzen

(IT oder Dienstleister; Tage bis Wochen). Regeln im System-Prompt verankern und eine unabhängige Guardrail-Schicht ergänzen, die im Zweifel schließt; Aussagen zu Regeln, Preisen und Fristen an hinterlegte Quellen binden; wo der Agent handelt, Aktions- und Betragsgrenzen serverseitig erzwingen und Datenzugriffe an eine Berechtigungsprüfung binden.

Modell pinnen und ein Test-Tor einziehen

(IT; einmalig plus bei jedem Wechsel). Die Anwendung auf eine geprüfte Version festlegen; ein Wechsel erst nach bestandenem Zuständigkeitstest.

Ein Scope-Eval-Set aufbauen

(IT und Fachbereich; anfangs Tage, dann laufend). Reale und erwartbare Fragen außerhalb wie innerhalb der Zuständigkeit sammeln (Tabelle 2 als Startpunkt) und den Test zum festen Bestandteil von Freigabe und Betrieb machen.

Rollen und Kadenz klären

(Führung). Einen Verantwortlichen für die Scope-Policy benennen; die Prüfung bei jedem Modell- oder Prompt-Wechsel und mindestens vierteljährlich ansetzen; einen Prozess für Vorfälle definieren. Wichtiger noch ist eine Regel für die schleichende Ausweitung: Der Wunsch „der Bot soll künftig auch noch …“ kommt verlässlich, und nach der dritten Erweiterung stimmt die ursprüngliche Definition nicht mehr, ohne dass jemand das entschieden hätte. Jede Erweiterung durchläuft deshalb dieselbe Prüfung wie die Erstdefinition und ergänzt das Eval-Set, bevor sie live geht.

Pflichten aus Recht und Datenschutz abbilden

(Fachbereich und Datenschutz). Kennzeichnung als KI sicherstellen, die KI-Kompetenz der befassten Mitarbeiter nachweisbar herstellen, die Berechtigungsprüfung vor jedem Datenzugriff verankern und bei regulierten Themen die Fachabteilung früh einbinden.

Wenn Sie einkaufen statt bauen

Wer die technische Umsetzung nicht selbst leisten kann, hat drei Wege: den Chatbot-Anbieter vertraglich in die Pflicht nehmen, einen Dienstleister beauftragen oder intern umsetzen. Der erste Weg ist der heikelste, denn „in die Pflicht nehmen“ heißt nicht, die Haftung abzugeben: Für die Aussagen des Bots steht weiter der Betreiber ein. Vertraglich absichern lässt sich aber das Nötige:

• ein Recht auf Modell-Pinning und eine Vorankündigungsfrist für Versionswechsel;
• definierte Bestehensschwellen für das Scope-Eval, gemessen an Ihrem eigenen Testset;
• serverseitige Berechtigungsprüfung vor jedem Zugriff auf personenbezogene Daten sowie Aktions- und Betragsgrenzen, wo der Agent handelt;
• das Eskalationsverhalten samt Übergabeziel;
• Auskunft darüber, wie reproduzierbar der Betrieb ist — dedizierte Kapazität statt geteilter Auslastung verringert die in Abschnitt 2 beschriebene Schwankung;
• ein Auftragsverarbeitungsvertrag nach der Datenschutz-Grundverordnung, der auch ein vorgeschaltetes Prüfmodell erfasst.

Prüfen Sie diese Punkte vor dem Kauf, denn viele Standard-Chatbots geben die nötigen Eingriffe gar nicht her. Lautet die Antwort „nein“ — der wahrscheinlichste Fall für einen kleinen Betrieb mit einem Produkt von der Stange —, dann ist der Ausweg nicht, es trotzdem zu tun, sondern den Anwendungsfall zu verengen: engeres Themenfeld, festere Antwortpfade, ein sichtbarer Hinweis auf die Grenzen des Bots und für die heiklen Themen bewusst kein Bot. Das ist dieselbe Vorfrage wie zu Beginn von Abschnitt 5, nur von der Beschaffungsseite gestellt. Entscheidend ist nicht die Größe des Apparats, sondern dass organisatorische und technische Seite verzahnt sind; genau dort scheitern Scope-Projekte.

7. Fazit

Die Zuständigkeit eines KI-Agenten ist keine reine Technikfrage. Ein Sprachmodell bringt einen mächtigen Reflex zur Hilfsbereitschaft mit, aber kein Urteil darüber, wo seine Aufgabe endet. Dieses Urteil muss das Unternehmen liefern — als Scope, der die Grenze zieht, und als Policy, die sie zum Regelwerk macht. Wo die Grenze verläuft, entscheidet die Führung; halten muss sie die Technik. Beides ist nötig: Eine Definition ohne serverseitige Durchsetzung bleibt eine Absichtserklärung, eine Durchsetzung ohne Definition weiß nicht, was sie durchsetzen soll.

Die erste Entscheidung ist dabei oft die wichtigste — und sie lautet manchmal, für ein heikles Thema gar keinen frei formulierenden Agenten einzusetzen. Wo er sinnvoll ist, wird der Unterschied am Banking-Beispiel greifbar. Der ungebremste Bot empfiehlt bereitwillig ein Krypto-Investment und plaudert nebenbei fremde Kontostände aus. Der gut geführte Bot antwortet auf dieselben Fragen: „Dazu darf ich keine Empfehlung geben — ich verbinde Sie mit einem Berater.“ Beide Antworten stammen vom selben Modell. Der Unterschied ist die Zuständigkeitsgrenze, die jemand bewusst gezogen und dann abgesichert hat. So wird aus der Hilfsbereitschaft, die eben noch das Risiko war, ein verlässlicher Vorteil.

Quellen

Hinweis. Dieses Whitepaper ist ein konzeptioneller Beitrag auf Basis öffentlich zugänglicher Studien, Herstellerdokumentationen und Rechtsquellen (Stand: Juli 2026). Es dient der Orientierung für Entscheider und ersetzt keine Rechts-, Steuer- oder Aufsichtsberatung im Einzelfall; die konkrete regulatorische Einordnung eines Anwendungsfalls sollte fachlich geprüft werden. Der Banking-Fall ist ein konstruiertes Szenario, kein Vorfallbericht; die zugrunde liegenden Mechanismen und die rechtliche Einordnung sind einzeln belegt. Die genannten Werkzeuge und Frameworks sind als Kategorie-Beispiele zu verstehen, nicht als Produktempfehlung.

Interessenhinweis. Der Autor bietet Beratungsleistungen zu dem hier beschriebenen Gegenstand an, unter anderem den in Abschnitt 6 skizzierten Scope-Workshop. Die genannte Aufwandsangabe von rund eineinhalb Arbeitstagen beruht auf eigenen Projekterfahrungen und ist eine Planungsannahme, kein Marktwert. Alle zitierten Quellen wurden auf Existenz und Inhalt geprüft.