Datenschutz bei KI-Agenten: Welche Daten ein Agent sehen darf und wo sie verarbeitet werden

Solange KI im Unternehmen ein Chatfenster war, konntest du den Datenschutz über das Verhalten deiner Mitarbeiter regeln. Eine Richtlinie legte fest, dass Kundennamen und Personaldaten nicht ins Eingabefeld gehören, und mit dem Anbieter war geklärt, dass er die Eingaben nicht zum Training nutzt. Ein KI-Agent liest dagegen selbst. Er öffnet das Postfach, schlägt im CRM nach und durchsucht die Dokumentablage. Bei keinem dieser Schritte entscheidet ein Mensch, welche Daten an das Sprachmodell gehen. Ob der Einsatz datenschutzkonform ist, hängt deshalb vor allem davon ab, worauf das System zugreifen kann.

Das ist eigentlich die bessere Ausgangslage. Zugriff kannst du technisch festlegen, prüfen und protokollieren, Verhalten dagegen nur schulen und hoffen. Drei Einstellungen tragen den größten Teil der Arbeit. Der Agent bekommt nur so viel Kontext, wie die jeweilige Aufgabe verlangt. Das Wissen, das er sich merkt, ist nach Bereichen getrennt. Außerdem legst du selbst fest, wo die KI-Anfragen verarbeitet werden. Dazu kommt eine Regel, die vieles andere absichert: Der Agent bekommt die Zugangsdaten zu deinen Systemen gar nicht erst.

Warum Chat-Regeln bei Agenten nicht mehr greifen

Bei einem Chat verlassen Daten das Unternehmen an genau einer Stelle, dem Eingabefeld. Wer dort nichts Sensibles eintippt, hat das Problem weitgehend gelöst, und deshalb drehen sich Schulungen und Richtlinien um genau diese Stelle. Ein Agent hat viele solcher Stellen. Jede angeschlossene Integration ist eine Quelle, aus der er Inhalte in seine Arbeit holt. Jeder Arbeitsschritt geht als Anfrage an ein Sprachmodell, das auf irgendeinem Server in irgendeinem Land läuft.

Dazu kommt ein zweiter Unterschied, der weniger offensichtlich ist. Ein Sprachmodell trennt nicht zuverlässig zwischen Text, den es verarbeiten soll, und Text, dem es folgen soll. Eine E-Mail, die der Agent zusammenfasst, kann Sätze enthalten, die wie ein Auftrag formuliert sind, und das Modell führt sie unter Umständen aus. Dieser Angriff heißt indirekte Prompt Injection. Dass er in der Praxis funktioniert, hat EchoLeak gezeigt. Forscher von Aim Security fanden 2025 in Microsoft 365 Copilot eine Lücke, über die eine einzige präparierte E-Mail den Assistenten dazu bringen konnte, interne Daten an einen fremden Server zu schicken, ohne dass der Nutzer etwas anklicken musste. Microsoft schloss die Lücke vor der Veröffentlichung und fand nach eigener Aussage keine Hinweise auf Missbrauch (Fallstudie auf arXiv).

Der Angriff umging gleich mehrere Schutzschichten, darunter einen Filter gegen solche Manipulationen und eine Regel, die externe Links aus den Antworten entfernen sollte. Die Autoren der Fallstudie leiten daraus einen Satz ab, den du direkt auf deine eigenen Entscheidungen übertragen kannst: Die KI kann nur preisgeben, was sie sehen kann. Filter senken das Risiko, aber sie lassen sich überlisten. Verlässlich begrenzen lässt sich der mögliche Schaden nur über den Zugriff selbst.

Zugriff, Kontext und Gedächtnis sind drei verschiedene Fragen

Wenn von den Daten die Rede ist, die ein Agent „sieht“, sind eigentlich drei Dinge gemeint. Es lohnt sich, sie auseinanderzuhalten, weil jede Ebene eigene Folgen hat.

Der Zugriff beschreibt, was der Agent grundsätzlich erreichen kann. Dazu gehört, welche Postfächer, CRM-Datensätze und Ordner er öffnen kann und ob er dort nur lesen oder auch schreiben, senden oder löschen darf. Der Zugriff ist die äußere Grenze, und alles, was außerhalb liegt, kann weder in den Kontext noch ins Gedächtnis gelangen.

Der Kontext umfasst die Daten, die der Agent für einen konkreten Arbeitsschritt tatsächlich lädt und an das Sprachmodell schickt. Nur diese Daten gehen bei einer Anfrage an den Modellanbieter. Deshalb hängt die Frage nach dem Verarbeitungsort am Kontext.

Das Gedächtnis enthält alles, was dauerhaft gespeichert bleibt, damit der Agent beim nächsten Mal weiß, wer ein Kunde ist und was letzte Woche vereinbart wurde. Hier gelten die Fragen, die du von jeder Datenbank kennst: Wer kann darauf zugreifen, wie lange bleibt etwas liegen und wie wird es wieder gelöscht?

Die übliche Debatte über KI und Datenschutz dreht sich um Modelltraining. Das berührt nur einen Teil der zweiten Ebene. Bei Agenten fallen die meisten Entscheidungen auf der ersten und der dritten.

Kontext nur so weit, wie die Aufgabe es verlangt

Die DSGVO verlangt in Artikel 5, dass personenbezogene Daten „auf das für die Zwecke der Verarbeitung notwendige Maß beschränkt“ sind. Artikel 25 verlangt zusätzlich, dass schon die Voreinstellungen eines Systems dafür sorgen, dass nur die für den jeweiligen Zweck erforderlichen Daten verarbeitet werden. Das gilt ausdrücklich auch für ihre Menge und ihre Zugänglichkeit. Bei einem Agenten ist der Zweck die einzelne Aufgabe. Also bestimmt die Aufgabe, welche Daten in den Kontext gehören.

Ein Beispiel macht das greifbar. Ein Kunde fragt per E-Mail, wann seine Bestellung kommt. Der Agent braucht dafür die Anfrage, den Kundendatensatz und den Auftragsstatus. Die Korrespondenz der letzten drei Jahre braucht er nicht, ebenso wenig die Reklamationen anderer Kunden oder die Notizen des Vertriebs zur letzten Preisverhandlung. Er schlägt den Status nach und beantwortet die Anfrage selbst, weil das eine erlaubte Routineaktion ist. Ein System, das bei jeder Anfrage vorsorglich alles lädt, was irgendwie passen könnte, verarbeitet ständig Daten ohne Zweck und schickt sie jedes Mal an das Modell.

Der naheliegende Einwand stimmt: Mit zu wenig Kontext werden die Ergebnisse schlechter, weil dem Agenten Zusammenhänge fehlen. Er lässt sich auflösen, indem du den Umfang pro Aufgabe festlegst und nicht pro Person. Ein Vertriebsmitarbeiter darf alle Kundendaten sehen, weil er im Laufe eines Tages viele verschiedene Dinge erledigt. Ein Agent, der Lieferanfragen beantwortet, erledigt eine klar umrissene Aufgabe, und für diese Aufgabe kannst du genau sagen, welche Daten sie braucht.

Frag einen Anbieter deshalb, wie sein Agent an die Daten kommt. Ein System, das für jede Aufgabe gezielt die passenden Datensätze abruft, setzt Datenminimierung in der Architektur um. Lädt ein System pauschal ganze Postfächer oder Datenbestände in den Kontext, bleibt diese Arbeit bei dir.

Warum ein Agent nicht einfach die Rechte seines Nutzers erben sollte

Am bequemsten bindest du einen Agenten an, indem du ihm dieselben Rechte gibst wie dem Menschen, der ihn einrichtet. Richtet der Geschäftsführer ihn ein, heißt das oft Zugriff auf alles. OWASP, eine Non-Profit-Stiftung, pflegt eine der bekanntesten Listen von Sicherheitsrisiken für KI-Anwendungen. Dort steht genau dieser Fall unter dem Namen Excessive Agency, und die Liste nennt drei Ursachen: zu viele Funktionen, zu weite Berechtigungen und zu viel Autonomie.

Das Beispiel von OWASP wirkt gerade deshalb, weil es so gewöhnlich ist. Ein Assistent soll eingehende E-Mails zusammenfassen und braucht dafür nur Lesezugriff. Die verwendete Erweiterung kann aber auch E-Mails versenden. Eine präparierte E-Mail bringt das Modell dazu, das Postfach nach vertraulichen Informationen zu durchsuchen und sie an den Angreifer weiterzuleiten. Hätte die Anbindung nur Leserechte gehabt, wäre der Angriff am fehlenden Sendeweg gescheitert, ganz gleich wie geschickt die Manipulation formuliert war.

Daraus folgen zwei Regeln für jede Integration. Der Agent bekommt nur die Rechte, die seine Aufgabe braucht. Und diese Rechte setzt das angebundene System selbst durch. OWASP beschreibt das als Prinzip der vollständigen Vermittlung: Jede Anfrage an ein nachgelagertes System wird dort gegen die geltenden Regeln geprüft. Das Sprachmodell entscheidet also nicht selbst, ob eine Aktion erlaubt ist. Der Grund ist einfach. Ein Modell kann man mit gut formuliertem Text überreden, eine Berechtigung im CRM dagegen nicht.

Wissen nach Bereichen trennen

Agenten werden mit der Zeit nützlicher, weil sie sich Dinge merken. Sie lernen, welche Kunden wichtig sind, wie Angebote bei euch aufgebaut sind und was im letzten Projektmeeting beschlossen wurde. Ein gemeinsames Gedächtnis für das ganze Team verstärkt diesen Effekt, denn dann muss nicht jeder Mitarbeiter seiner eigenen KI denselben Hintergrund erklären.

Das Risiko liegt auf der Hand. Fließt alles in einen großen gemeinsamen Topf, kann ein Agent, der Marketingtexte schreibt, auch auf Gehaltsgespräche oder Abmahnungen stoßen, weil sie irgendwo im selben Speicher liegen. Artikel 25 der DSGVO verlangt, dass personenbezogene Daten durch Voreinstellung nicht einer unbestimmten Zahl von Personen zugänglich gemacht werden. Ein Gedächtnis, auf das jeder Agent für jede Aufgabe zugreifen kann, steht zu dieser Vorgabe mindestens in Spannung.

Die praktische Lösung kennst du von Ordnerrechten. Das Wissen wird nach Bereichen getrennt, also etwa Vertrieb, Marketing, Personal und Finanzen, plus allgemeine Firmeninformationen, die alle kennen dürfen. Ein Agent für Marketing kennt dann das Marketingwissen und das allgemeine Firmenwissen, aber keine Interna aus der Personalabteilung. Private Gespräche eines Mitarbeiters mit einem Agenten gehören gar nicht ins gemeinsame Gedächtnis.

Die Trennung hilft auch bei einer Pflicht, die im Alltag oft untergeht. Die Datenschutzkonferenz der deutschen Aufsichtsbehörden weist in ihrer Orientierungshilfe zu KI-Systemen, die auf eigene Wissensquellen zugreifen, darauf hin, dass es schwierig bleibt, Transparenz, Zweckbindung und Betroffenenrechte im gesamten System sicherzustellen. Verlangt ein ehemaliger Mitarbeiter Auskunft oder Löschung, musst du wissen, wo seine Daten liegen. Bei einem nach Bereichen getrennten Gedächtnis, das sich einsehen, korrigieren und exportieren lässt, kannst du diese Frage beantworten.

Zugangsdaten bekommt der Agent gar nicht erst

Diese Regel wirkt technisch, betrifft aber direkt deine Haftung. Liegt ein Passwort oder ein API-Schlüssel in der Konfiguration oder im Kontext eines Agenten, ist er für das Sprachmodell einfach ein weiterer Text. Bringt eine manipulierte E-Mail das Modell dazu, Inhalte nach außen zu geben, kann der Schlüssel dabei sein. Ein abgeflossener Schlüssel funktioniert außerhalb des Agenten weiter, und keine der Grenzen, die du für den Agenten eingerichtet hast, gilt für ihn noch.

Deshalb hält eine Vermittlungsschicht zwischen Agent und angebundenem System die Verbindung. Du oder dein Administrator meldet sich einmal bei Microsoft 365, Google Workspace oder dem CRM an, und die Plattform speichert die Freigabe. Braucht der Agent einen Datensatz, fordert er ihn bei der Vermittlungsschicht an. Die Schicht prüft, ob die Anfrage im erlaubten Rahmen liegt, führt sie aus und gibt nur das Ergebnis zurück. Den Schlüssel sieht der Agent nie. OWASP empfiehlt dazu, Aktionen im Kontext des jeweiligen Nutzers auszuführen und bei der Anmeldung über OAuth nur den kleinsten nötigen Berechtigungsumfang anzufordern.

Das hat zwei Folgen, die du im Alltag merkst. Du kannst eine Verbindung an einer Stelle trennen, und sie ist für alle Agenten sofort weg. Außerdem läuft jeder Zugriff über denselben Weg, sodass er sich lückenlos protokollieren lässt. Frag einen Anbieter, wo die Tokens für deine Integrationen liegen und ob ein Agent sie jemals zu sehen bekommt. Die Antwort sollte kurz und eindeutig sein.

Wo die Daten verarbeitet werden

Bei einem Agenten gibt es mindestens drei Verarbeitungsorte. Die Plattform speichert die Agenten, ihre Aufgaben und ihr Gedächtnis. Der Modellanbieter verarbeitet den Kontext jeder einzelnen Anfrage. Die angebundenen Systeme, etwa dein Microsoft-Tenant oder dein CRM, liegen dort, wo sie schon heute liegen. Die Plattform in der EU zu betreiben ist inzwischen einfach. Schwieriger ist der zweite Ort, weil viele der leistungsfähigsten Modelle von US-Anbietern kommen.

Rechtlich sind Übermittlungen an zertifizierte US-Unternehmen derzeit über das EU-US Data Privacy Framework möglich. Das Gericht der EU hat den zugrunde liegenden Angemessenheitsbeschluss im September 2025 bestätigt. Der Kläger Philippe Latombe hat im Oktober 2025 aber Rechtsmittel beim Europäischen Gerichtshof eingelegt. Derselbe Gerichtshof hat die beiden Vorgänger, Safe Harbor 2015 und Privacy Shield 2020, gekippt (Einordnung bei WilmerHale). Die Nutzung von US-Modellen ist also heute zulässig, steht aber auf einer Rechtsgrundlage, die schon zweimal weggefallen ist.

Für dich folgt daraus, dass der Verarbeitungsort eine Einstellung sein sollte, die du jederzeit ändern kannst, und keine Eigenschaft des Produkts, mit der du leben musst. Legt die Plattform dich auf einen einzigen Modellanbieter fest, hängt dein ganzer Agenteneinsatz an dessen Rechtslage. Kannst du den Ort wählen, stellst du im Zweifel um und arbeitest weiter. Die Einstellung sollte zentral für die ganze Organisation gelten, damit nicht jeder Mitarbeiter selbst entscheidet, welches Modell Kundendaten bekommt.

Needs löst das so, dass Plattform und Datenbank in Deutschland laufen und ein Admin für die gesamte Organisation festlegt, ob KI-Anfragen nur in der EU und im EWR verarbeitet werden oder ob zusätzlich internationale Modelle erlaubt sind. Im Modus „nur EU/EWR“ sind internationale Modelle abgeschaltet, und die Modellauswahl ist entsprechend kleiner. Mit diesem Zielkonflikt wirst du bei jedem Anbieter leben müssen, weil nicht jedes Modell in der EU gehostet angeboten wird.

Die alte Frage nach dem Training bleibt trotzdem wichtig. Lass dir im Auftragsverarbeitungsvertrag bestätigen, dass deine Inhalte nicht zum Training fremder Modelle verwendet werden, und lies die Liste der Unterauftragsverarbeiter. Dort steht, welcher Dienst in welchem Land welche Aufgabe übernimmt. Diese Liste zeigt die Verarbeitungsorte genauer als jede Werbeaussage.

Was ein Agent selbst erledigen darf

Wenn Zugriff und Rechte sauber gesetzt sind, muss nicht jede einzelne Aktion freigegeben werden. Genau darin liegt der Nutzen eines Agenten. Innerhalb des Rahmens, den ihr festgelegt habt, erledigt er Routinearbeit selbst. Er beantwortet eine Lieferanfrage, trägt eine neue Telefonnummer im CRM nach, legt die Aufgaben aus einem Meeting an und erinnert einen Lieferanten an eine überfällige Unterlage. Menschen bestimmen die Ziele, die Rechte und die Grenzen. Eine ausdrückliche Freigabe braucht es erst bei Aktionen mit echtem Risiko, etwa bei einer Zahlung oder einer verbindlichen Zusage an einen Kunden.

Für den Datenschutz zählt dabei vor allem, dass sich im Nachhinein nachvollziehen lässt, was passiert ist. Artikel 5 der DSGVO macht dich als Verantwortlichen nicht nur für die Einhaltung der Grundsätze verantwortlich. Du musst sie auch nachweisen können. Protokolliert die Plattform jede Aktion eines Agenten mit ihrem Ergebnis, kann dein Datenschutzbeauftragter prüfen, welche Daten wofür verwendet wurden. Ohne Protokoll musst du dich auf die Aussage des Anbieters verlassen. OWASP nennt Protokollierung und Mengenbegrenzungen ausdrücklich als Mittel, mit denen sich ein Fehlverhalten entdecken lässt, bevor es großen Schaden anrichtet.

Wo du anfängst

Du musst nicht das ganze Unternehmen auf einmal anschließen, und es ist sogar sinnvoll, das nicht zu tun. Beginn mit einer Aufgabe, die häufig vorkommt und deren Datenbedarf du überblickst, und geh dann so vor:

1. Schreib auf, welche Daten die Aufgabe braucht, aus welchem System sie kommen und ob der Agent dort nur lesen oder auch schreiben muss.
2. Schließ nur diese Systeme an, mit dem kleinsten Berechtigungsumfang, den die Integration erlaubt.
3. Entscheide, ob die Aufgabe personenbezogene Daten enthält, die in der EU bleiben sollen. Stell den Verarbeitungsort entsprechend ein.
4. Sprich mit deinem Datenschutzbeauftragten über den Auftragsverarbeitungsvertrag, das Verzeichnis der Verarbeitungstätigkeiten und die Frage, ob eine Datenschutz-Folgenabschätzung nötig ist.
5. Sieh dir nach einigen Wochen das Protokoll an und prüf, ob der Agent Daten angefragt hat, die er für seine Aufgabe nicht brauchte.

Die zweite Aufgabe geht dann schneller, weil die Fragen dieselben bleiben. Mit der Zeit entsteht so eine Übersicht darüber, welcher Agent welche Daten sehen darf und wo sie verarbeitet werden. Eine solche Übersicht hatten die meisten Unternehmen für die Chat-Nutzung ihrer Mitarbeiter nie.

Häufige Fragen

Darf ein KI-Agent auf mein E-Mail-Postfach zugreifen?

Ja, wenn der Zugriff zur Aufgabe passt und vertraglich sauber geregelt ist. Entscheidend ist der Umfang. Ein Agent, der Anfragen sortiert, braucht Lesezugriff, aber kein Recht, E-Mails aus deinem Namen zu senden oder zu löschen.

Beachte außerdem, dass eingehende E-Mails von Fremden stammen und manipulierten Text enthalten können. Je weniger Rechte die Anbindung hat, desto weniger kann eine solche E-Mail anrichten.

Werden meine Daten zum Training der KI verwendet?

Das regelt der Vertrag mit dem Anbieter und nicht die Technik. Seriöse Anbieter schließen das Training mit Kundendaten im Auftragsverarbeitungsvertrag aus. Lass dir das schriftlich bestätigen, auch für die Modellanbieter, die als Unterauftragsverarbeiter eingebunden sind.

Reicht es, wenn der Anbieter in Deutschland hostet?

Nicht allein. Der Hosting-Standort sagt, wo Plattform und Gedächtnis liegen. Die Anfragen an das Sprachmodell können trotzdem in einem anderen Land verarbeitet werden. Frag nach beiden Orten und prüf, ob du den Verarbeitungsort der KI-Anfragen selbst festlegen kannst.

Was passiert, wenn ein Agent eine manipulierte E-Mail liest?

Das Modell kann versuchen, die darin versteckten Anweisungen auszuführen. Ob daraus ein Schaden entsteht, hängt davon ab, was der Agent sehen und tun darf. Hat er nur Zugriff auf die Daten seiner Aufgabe, keine Zugangsdaten und keinen Weg, Inhalte unkontrolliert nach außen zu schicken, läuft der Angriff weitgehend ins Leere. Das Protokoll zeigt dir danach, was versucht wurde.