Wenn der KI-Assistent plötzlich selbst handelt
Eine KI, die einen Textentwurf formuliert, ist etwas anderes als ein Agent, der eigenständig eine E-Mail versendet, einen Datensatz verändert oder eine Bestellung auslöst. Beide können auf ähnlichen Modellen beruhen. Der Unterschied liegt in den verbundenen Werkzeugen und den Konsequenzen einer fehlerhaften Ausgabe. Sobald ein System Aktionen ausführen darf, wird aus einer Qualitätsfrage auch eine Frage der Berechtigungen, Prozesskontrollen und Verantwortung.
Für deutsche Unternehmen ist das besonders relevant, weil KI-Agenten häufig auf vorhandene Geschäftssysteme zugreifen sollen: CRM, Ticketsystem, Dokumentenablage oder E-Mail. Die vermeintlich einfache Integration verbindet damit mehrere Risiken. Ein Modell kann Informationen falsch interpretieren. Eine externe Nachricht kann manipulative Anweisungen enthalten. Eine technisch gültige Aktion kann geschäftlich unzulässig sein. Ein Pilot sollte diese Probleme vor der Produktivsetzung behandeln, nicht erst nach einem Vorfall.
Dieser Leitfaden zeigt einen praktischen Weg: vom klar begrenzten Auftrag über Rechte und Freigaben bis zu Tests, Protokollierung und Schulung. Er ist eine Organisationshilfe, keine pauschale Aussage über die rechtliche Zulässigkeit eines bestimmten Systems.
1. Zuerst den Handlungsspielraum beschreiben
Beginnen Sie nicht mit der Frage, welches Modell am intelligentesten ist. Schreiben Sie auf, welche Aufgabe der Agent erledigen soll und welche Aktionen er dafür tatsächlich benötigt. Ein Agent zur Vorbereitung von Supportantworten muss beispielsweise Tickets lesen und Entwürfe erstellen können. Er braucht nicht automatisch das Recht, Kundendaten zu löschen oder Antworten ohne Kontrolle zu versenden.
Ein brauchbarer Steckbrief enthält:
- Geschäftszweck und verantwortliche Fachabteilung.
- Erlaubte Datenquellen und verbundene Werkzeuge.
- Zulässige Aktionen und ausdrücklich ausgeschlossene Aktionen.
- Maximale Auswirkungen einer einzelnen Aktion, etwa Betrag oder Empfängerkreis.
- Freigabepunkte, Abbruchbedingungen und zuständige Ansprechpersonen.
- Kriterien, nach denen Erfolg und Fehler bewertet werden.
Diese Beschreibung ist keine einmalige Formalität. Sie macht sichtbar, wann ein vermeintliches Funktionsupdate den Risikorahmen verändert: Aus dem Entwurf einer Kundenmail wird beispielsweise durch einen zusätzlichen Senden-Knopf ein anderer Prozess.
2. Berechtigungen nach dem Minimalprinzip vergeben
Ein Agent sollte nur die Rechte erhalten, die sein konkreter Auftrag benötigt. Das bedeutet in der Praxis: getrennte technische Identitäten, begrenzte API-Berechtigungen und möglichst keine dauerhaft hinterlegten Administrationszugänge. Wo eine Schnittstelle Lesen und Schreiben getrennt erlaubt, ist für einen Rechercheagenten ein reiner Lesezugriff sinnvoll. Wo das System feinere Rechte unterstützt, sollten sie nach Datentyp, Mandant oder Aktion eingeschränkt werden.
Besonders kritisch sind allgemeine Konten, die aus Bequemlichkeit Zugriff auf sämtliche Dateien oder Postfächer erhalten. Ein Fehler kann dann weit über den ursprünglichen Anwendungsfall hinausreichen. Prüfen Sie deshalb vor der Anbindung eines Tools, ob sich Zugriffsrechte technisch begrenzen lassen und wie Zugangsdaten widerrufen werden. Ein Widerrufsprozess gehört bereits zum Pilot.
Auch das Kontextfenster ist eine Zugriffsfrage. Nur weil ein Agent theoretisch alle Dokumente abrufen könnte, müssen nicht alle Inhalte in jede Anfrage einfließen. Datensparsame Auswahl reduziert unnötige Offenlegung und erleichtert die fachliche Prüfung. Datenschutzrechtliche Anforderungen sind zusätzlich für den konkreten Einsatz zu prüfen; ein Minimalrechtekonzept ersetzt diese Prüfung nicht.
3. Menschliche Freigaben an den Folgen ausrichten
Nicht jede Aktion benötigt dieselbe Kontrolle. Ein intern gespeicherter Entwurf lässt sich meist leichter korrigieren als eine Zahlung, eine Löschung oder eine Nachricht an viele externe Empfänger. Ordnen Sie Aktionen daher nach ihren möglichen Folgen. Definieren Sie, welche Schritte automatisch laufen dürfen, welche eine Stichprobe brauchen und welche zwingend vor Ausführung freigegeben werden sollen.
Für einen E-Mail-Agenten könnte die Regel lauten: Entwürfe erstellen ja, Versand erst nach Sichtprüfung. Für einen Beschaffungsagenten: Angebote vergleichen ja, Bestellung nur innerhalb eines festgelegten Rahmens und nach Zustimmung einer berechtigten Person. Für einen Wissensagenten: Quellen zusammenstellen ja, verbindliche Rechts- oder Personalentscheidungen nein. Diese Beispiele sind Gestaltungsvorschläge, keine allgemeingültigen gesetzlichen Schwellenwerte.
Eine Freigabe muss aussagekräftig sein. Wer nur auf einen grünen Knopf klickt, ohne Empfänger, Datenbasis und beabsichtigte Aktion zu sehen, kontrolliert wenig. Die Oberfläche sollte deshalb die konkrete Handlung, ihre wesentlichen Eingaben und mögliche Folgen verständlich anzeigen. Außerdem braucht es eine Möglichkeit, abzulehnen oder an eine zuständige Person zu eskalieren.
4. Prompt Injection als Prozessrisiko verstehen
Ein Agent verarbeitet oft Informationen, die nicht aus vertrauenswürdigen internen Anweisungen stammen: Webseiten, Anhänge, Kundenmails oder Dokumente. In solchen Inhalten können Sätze stehen, die sich als Anweisung an den Agenten ausgeben. Beispielsweise könnte ein präpariertes Dokument behaupten, der Agent müsse seine bisherigen Regeln ignorieren und vertrauliche Daten an eine externe Adresse senden. Das ist ein Beispiel für Prompt Injection.
Die wichtigste praktische Unterscheidung lautet: Inhalt aus einer Quelle ist zunächst Arbeitsmaterial, keine neue Berechtigung. Ein Agent darf nicht deshalb zusätzliche Rechte erhalten, weil ein gelesener Text dies verlangt. Grenzen müssen nach Möglichkeit außerhalb des Modells technisch durchgesetzt werden, etwa durch eingeschränkte Schnittstellen, feste Empfängerregeln und Freigaben vor riskanten Aktionen.
Schulen Sie Mitarbeitende auch darin, Warnsignale zu erkennen: unerwartete Handlungsaufforderungen in Dokumenten, plötzliche Änderungen des Arbeitsziels oder vorgeschlagene Datenübertragungen ohne Bezug zum Auftrag. Prompt Injection lässt sich nicht mit einem einzigen perfekten Prompt zuverlässig erledigen. Mehrere Schutzebenen und wiederholte Tests sind die robustere Arbeitsweise.
5. Vor dem Pilot reale Fehlersituationen testen
Ein Test mit drei sauberen Beispielen beweist wenig. Stellen Sie eine kleine, repräsentative Testsammlung zusammen: typische Fälle, unvollständige Angaben, widersprüchliche Dokumente, falsche Empfänger, nicht verfügbare Systeme und absichtlich manipulative Texte. Halten Sie fest, welches Verhalten erwartet wird. Besonders wichtig ist die Frage, ob der Agent im Zweifel stoppt, nachfragt oder eine riskante Aktion trotzdem ausführt.
Testen Sie nicht nur die Textqualität, sondern den gesamten Ablauf. Wurde tatsächlich nur auf freigegebene Daten zugegriffen? Blieb eine nicht autorisierte Aktion blockiert? Wurde eine Freigabe korrekt angefordert? Kann ein fehlgeschlagener Schritt ohne doppelte Bestellung oder doppelte Nachricht wiederholt werden? Solche Prozessfragen werden in Modell-Demos leicht übersehen.
Das freiwillige AI Risk Management Framework des US-amerikanischen NIST und sein Profil für generative KI bieten dafür eine strukturierende Perspektive: Risiken werden über Governance, Kontextverständnis, Messung und Management betrachtet. Diese Dokumente sind keine deutsche Rechtsnorm und ersetzen keine Prüfung der für den jeweiligen Einsatz geltenden Pflichten. Sie können aber helfen, Test- und Kontrollfragen systematisch zu ordnen.
6. Protokollieren, ohne unnötig Daten zu sammeln
Wenn später eine fehlerhafte Aktion untersucht werden muss, sollten Unternehmen den Ablauf nachvollziehen können. Sinnvoll sind etwa die Version des Workflows, der verwendete Werkzeugaufruf, die Entscheidung über eine Freigabe und das Ergebnis der Aktion. Protokolle sollten nicht automatisch komplette personenbezogene Dokumente oder vertrauliche Inhalte dauerhaft duplizieren. Legen Sie fest, welche Angaben zur Fehleranalyse notwendig sind, wer Zugriff erhält und wann sie gelöscht werden.
Definieren Sie zudem einen klaren Stoppmechanismus. Wer kann den Agenten deaktivieren? Wie werden Tokens und API-Schlüssel gesperrt? Wie werden bereits angestoßene Vorgänge identifiziert? Eine Notfallregel, die erst im Schadensfall geschrieben wird, kommt zu spät.
Für den Betrieb empfiehlt sich ein fester Rhythmus: auffällige Aktionen prüfen, Fehlermuster auswerten, Berechtigungen erneut bestätigen und Änderungen an Modell, Prompt, Werkzeugen oder Datenquellen vor Freigabe testen. Ein Agent ist kein einmal installiertes Werkzeug, dessen Verhalten anschließend unverändert bleibt.
7. AI Literacy muss die Bedienung des Agenten abdecken
Artikel 4 der EU-KI-Verordnung verpflichtet Anbieter und Betreiber von KI-Systemen zu Maßnahmen, die die Entwicklung von KI-Kompetenz bei Mitarbeitenden und weiteren Personen unterstützen, die in ihrem Auftrag mit den Systemen arbeiten. Zu berücksichtigen sind insbesondere Vorkenntnisse und Nutzungskontext. Die im Juli 2026 geänderte Fassung verlangt nicht, ein bestimmtes Kompetenzniveau jeder einzelnen Person zu garantieren. Die Europäische Kommission erläutert außerdem, dass weder ein bestimmtes Zertifikat noch eine spezielle Governance-Struktur allein aus Artikel 4 vorgeschrieben ist.
Für einen Agenten-Workflow bedeutet kontextbezogene Kompetenz mehr als allgemeines Prompting. Anwender sollten verstehen, welche Aufgaben der Agent übernehmen darf, welche Informationen er sieht, warum externe Inhalte keine vertrauenswürdigen Befehle sind und wann sie eine Freigabe verweigern müssen. Fachliche Verantwortliche brauchen zusätzlich Kenntnisse über Grenzfälle, Kennzahlen und Eskalation. Technische Betreiber benötigen ein anderes Vertiefungsniveau zu Schnittstellen, Rechten, Tests und Stoppmechanismen.
Ein kurzes Szenariotraining kann mehr bewirken als eine lange Liste abstrakter Verbote: Der Agent schlägt vor, einen ungeprüften Anhang an einen externen Empfänger zu senden. Welche Information muss geprüft werden? Welche Aktion ist gesperrt? Wer darf freigeben? Solche Übungen machen Regeln im Arbeitsalltag anwendbar. Die konkrete Ausgestaltung muss sich an System, Rolle und Risiko orientieren.
8. Ein umsetzbarer Plan für die ersten vier Wochen
In Woche eins beschreibt das Fachteam einen einzigen, eng begrenzten Anwendungsfall und benennt den Prozessverantwortlichen. Es erfasst Datenquellen, Aktionen und mögliche Schäden. In Woche zwei setzt die IT eingeschränkte Rechte, technische Grenzen und einen Abschaltweg um. Gemeinsam definieren die Beteiligten Freigaben und nachvollziehbare Protokolle.
In Woche drei wird mit realistischen und adversarialen Beispielen getestet. Fehler werden dokumentiert und der Ablauf angepasst. In Woche vier arbeiten wenige geschulte Personen mit dem Agenten unter enger Beobachtung. Erst nach einer Auswertung von Qualität, Aufwand, Ausnahmen und Kontrollwirksamkeit wird über eine Erweiterung entschieden.
Die Reihenfolge ist wichtiger als die Geschwindigkeit: erst Auftrag und Grenzen, dann Berechtigungen und Tests, anschließend kontrollierter Betrieb. Unternehmen müssen nicht jeden Prozess autonom machen. Oft ist ein Agent, der einen guten Entwurf liefert und rechtzeitig stoppt, die bessere Lösung als ein Agent, der möglichst viele Aktionen allein ausführt.
Fazit: Gute Agenten brauchen klare Grenzen und kompetente Menschen
Sichere KI-Agenten entstehen nicht durch eine einzelne Modellanweisung. Sie brauchen einen eng definierten Auftrag, minimale Rechte, verständliche Freigaben, realistische Tests, angemessene Protokolle und einen funktionierenden Stoppmechanismus. Dazu kommt KI-Kompetenz für alle Rollen, die den Ablauf nutzen, verantworten oder technisch betreiben.