7 Datenschutzfehler bei KI-Agenten, die unbemerkt Ihre Unternehmensdaten preisgeben (und wie Sie sie vermeiden)

Die meisten Datenlecks bei KI-Agenten entstehen nicht dadurch, dass das Modell Ihr Unternehmen heimlich auswendig lernt. Sie kommen von Konfigurations- und Architekturfehlern, die Sie benennen und beheben können. Die großen sind: der Betrieb auf einem Consumer-Konto, dessen Voreinstellungen mit Ihren Eingaben trainieren, einem Agenten die weit gefassten Berechtigungen einer Person zu vererben, einen öffentlich zugänglichen Agenten mit internen Systemen zu verdrahten und die „tödliche Trias" intakt zu lassen (private Daten, nicht vertrauenswürdige Inhalte und ein externer Sendeweg), sodass eine einzige Prompt Injection Ihre Daten lesen und hinausschicken kann. Genau dieses letzte Muster führte dazu, dass EchoLeak (CVE-2025-32711) über Microsoft 365 Copilot sensible Daten aus einer präparierten E-Mail preisgab, ganz ohne Klick des Nutzers. Die Lösungen sind nicht exotisch, und fast alle sind Entscheidungen, die getroffen werden, bevor der Agent startet, keine Checkliste, die man Ihnen aushändigt, nachdem etwas geleckt ist.

Das ist die Liste, die wir durchgehen, bevor wir einen von uns gebauten Agenten in den Stack eines anderen Unternehmens setzen, geschrieben so, dass eine nicht-technische Inhaberin dieselben Fehler in ihrem eigenen Setup oder dem eines Dienstleisters erkennen kann. Wenn Sie lieber möchten, dass wir diese Grenze für Sie dort halten, wo sie sein sollte, sehen Sie sich an, wie wir verantwortungsvolle KI-Governance und Risikosteuerung betreiben. Alles Folgende können Sie so oder so nutzen.

Zuerst eine Unterscheidung, die fast jeder Artikel zu diesem Thema verwischt, denn sie falsch zu verstehen ist Fehler null. Es gibt zwei völlig unterschiedliche Wege, auf denen Daten über einen Agenten austreten, und sie haben völlig unterschiedliche Lösungen:

• Datenverarbeitung durch den Anbieter. Speichert der Modellanbieter Ihre Eingaben oder trainiert er damit? Das ist ein Vertrag, den Sie unterzeichnen, und ein Kontotyp, den Sie wählen. Es wird mit Konditionen und Konfiguration gelöst.
• Laufzeit-Exfiltration. Kann der Agent im Moment seiner Ausführung dazu verleitet werden, Ihre Daten an einen Ort zu senden, an den sie nicht gehören? Das wird mit Architektur gelöst, nicht mit einem Vertrag.

Die Umfragezahlen zeigen, dass Käufer das spüren, selbst wenn sie es nicht benennen können. In Clouderas Befragung von fast 1.500 leitenden IT-Verantwortlichen aus 14 Ländern planen 96 Prozent, den Einsatz von KI-Agenten im kommenden Jahr auszuweiten, doch 53 Prozent (mehr als die Hälfte) nennen Datenschutz als ihr wichtigstes Hindernis bei der Einführung. Die sieben Fehler unten sind die Stellen, an denen diese Angst zu einem echten Leck wird, und an denen die Lösung liegt.

Fehler 1: Produktionsagenten auf Consumer-Konten betreiben

Das ist der billigste Fehler, den man machen kann, und der am leichtesten zu beheben ist. Jemand verdrahtet einen Workflow mit einem persönlichen ChatGPT- oder Consumer-Gemini-Konto, weil es schon da ist, und nun werden Ihre Geschäftsdaten von Consumer-Bedingungen geregelt, die nie dafür gedacht waren.

Die Kluft zwischen Consumer- und Enterprise-Tarifen ist scharf. Auf der Enterprise-Seite ist das Muster über die Anbieter hinweg konsistent: standardmäßig kein Training mit Ihren Daten, ein kurzes Aufbewahrungsfenster zur Missbrauchsüberwachung und auf Anfrage stärkere Optionen. Die OpenAI-API bewahrt Daten 30 Tage lang zur Missbrauchsüberwachung auf und löscht sie dann, und sie trainiert standardmäßig nicht damit. Zum 14. September 2025 hat Anthropic die Aufbewahrung von API-Protokollen von 30 auf 7 Tage verkürzt, und API-Eingaben und -Ausgaben werden niemals zum Training verwendet. Googles Vertex AI (der Enterprise-Tarif) ist so konfigurierbar, dass keine Trainingsnutzung erfolgt. Auf der Consumer-Seite kippen die Voreinstellungen: Consumer-ChatGPT speichert Gespräche unbegrenzt, sofern Sie sie nicht löschen, und die Aufbewahrung bei Consumer-Gemini reicht bis zu 36 Monate und kann zur Produktverbesserung verwendet werden.

Die Lösung: Setzen Sie jeden Produktionsagenten auf eine Enterprise-API oder ein Business-Konto, niemals auf einen persönlichen Login. Die Technologie ist identisch. Die Bedingungen sind es nicht, und die Bedingungen sind der gesamte Unterschied zwischen Daten, die geregelt bleiben, und Daten, die unbemerkt zu Trainingsmaterial werden.

Fehler 2: zu weit gefasste Berechtigungen, die der Agent erbt

Das häufigste Laufzeit-Leck ist nicht raffiniert. Einem Agenten wird der Zugriff eines Mitarbeiters übergeben, oder schlimmer, ein Admin-Schlüssel, sodass er technisch alles sehen kann, was diese Person sieht. Dann wird ihm eine Frage gestellt, oder er wird zu einer verleitet, die weit über seine Aufgabe hinausreicht.

Microsofts Cloud Adoption Framework formuliert die Regel klar: „Gewähren Sie Agenten nur Zugriff auf die konkreten Datenquellen, die für ihre Funktion erforderlich sind. Geben Sie keinen breiten Zugriff auf alle Unternehmensdaten." Ein Support-Agent braucht Ihr Lohnsystem nicht. Ein Terminplanungs-Agent braucht die Kundendatenbank nicht. Wenn ein Agent im Auftrag einer Person handelt, sollte er deren Berechtigungen erben, indem ihre Identität sicher weitergereicht wird, sodass ein Helpdesk-Agent einem Mitarbeiter nur dessen eigene Personalakte zeigt, nicht die aller.

Die Lösung: Geben Sie jedem Agenten eine eigene Identität, zugeschnitten auf das geringste Privileg, und lassen Sie ihn die Berechtigungen des handelnden Nutzers erben, statt eine dauerhafte Obermenge mit sich zu führen. Der Test ist einfach. Wird der Agent morgen ausgetrickst, ist der Schaden durch den engen Satz begrenzt, der ihm gewährt wurde, nicht durch alles, was ein überberechtigtes Konto erreichen könnte.

Fehler 3: öffentlich zugängliche Agenten, die mit internen Daten verdrahtet sind

Ein Chatbot auf Ihrer Website und ein Agent, der interne Berichte verfasst, sind zwei verschiedene Sicherheitswelten, und das Leck entsteht in dem Moment, in dem jemand sie ein Backend teilen lässt. Ein öffentlicher Agent nimmt Eingaben von jedem im Internet entgegen. Wenn derselbe Agent auch interne Geschäftsdaten abfragen kann, haben Sie eine Tür vom öffentlichen Web direkt in Ihre privaten Systeme gebaut.

Microsofts Framework zieht hier die härteste Linie: „Öffentlich zugängliche Agenten dürfen nicht auf interne Geschäftsdaten zugreifen." Halten Sie Vertrauliches und Öffentliches durch eine physische oder logische Grenze getrennt (ihr Beispiel verwendet separate Verwaltungsgruppen „corp" und „online"). Der Punkt ist, dass die Grenze strukturell ist, nicht die Hoffnung, dass der Prompt hält.

Die Lösung: Ziehen Sie eine echte Grenze zwischen Agenten, die nicht vertrauenswürdige öffentliche Eingaben entgegennehmen, und Agenten, die vertrauliche Daten berühren. Wenn ein einzelner Agent wirklich beides tun muss, ist das das risikoreichste Design, das Sie wählen können, und es braucht die Trias-brechenden Kontrollen aus den nächsten Fehlern, nicht nur einen sorgfältigen System-Prompt.

Fehler 4: die tödliche Trias ignorieren

Das ist der Fehler, der die ersten drei in eine tatsächliche Exfiltration verwandelt. Simon Willison, der unabhängige Experte, der den Begriff „Prompt Injection" geprägt hat, benannte die „tödliche Trias" für KI-Agenten: drei Bedingungen, die in Kombination eine einzige eingeschleuste Anweisung Ihre Daten stehlen lassen.

Wenn alle drei vorhanden sind, versteckt ein Angreifer eine Anweisung innerhalb des nicht vertrauenswürdigen Inhalts. Das Modell „wird bereitwillig allen Anweisungen folgen, die es erreichen, egal ob sie von seinem Betreiber oder von einer anderen Quelle stammen", so Willisons Worte. Es liest Ihre privaten Daten und sendet sie hinaus, und nichts im Prompt hat ihm gesagt, der E-Mail nicht zu vertrauen.

Der unverblümte Teil, und der Grund, warum das Architektur und kein Prompt-Engineering-Problem ist: „Wir wissen immer noch nicht, wie man dies zu 100 Prozent zuverlässig verhindern kann." Dokumentierte Exploits haben Microsoft 365 Copilot, GitHubs MCP-Server und GitLab Duo getroffen. In einer Woche im Januar 2026 wurden in vier KI-Produktivitätswerkzeugen indirekte Prompt-Injection-Schwachstellen offengelegt, alle nach demselben Trias-Muster.

Die Lösung: Brechen Sie ein Bein. Verwehren Sie den externen Sendeweg, sodass gestohlene Daten nirgendwohin können, oder lassen Sie einen Agenten, der nicht vertrauenswürdige Inhalte liest, niemals im selben Kontext auch Zugriff auf private Daten haben. Sie müssen nicht den ungewinnbaren Kampf gewinnen, jede Injection abzufangen. Sie müssen sicherstellen, dass selbst eine erfolgreiche Injection keinen Weg nach draußen hat.

Fehler 5: EchoLeak als das Problem anderer behandeln

Es lohnt sich, einen realen Vorfall zu benennen, denn „die tödliche Trias" klingt abstrakt, bis Sie sie ausgeführt sehen. EchoLeak (CVE-2025-32711) war ein Zero-Click-Angriff auf Microsoft 365 Copilot. Ein Angreifer schickte eine präparierte E-Mail. Copilot, der seine normale Arbeit tat, verarbeitete diese E-Mail (nicht vertrauenswürdiger Inhalt), hatte Zugriff auf die internen Daten des Nutzers (private Daten) und hatte eine Möglichkeit, Informationen nach außen zu senden (externe Kommunikation). Die versteckte Anweisung vollzog die Preisgabe sensibler Daten, ganz ohne jegliche Nutzerinteraktion. Niemand klickte irgendetwas an.

Der Fehler hier ist die Annahme, dass ein Leck einen unachtsamen Mitarbeiter erfordert. EchoLeak erforderte keinen. Die Verteidigung, die zählte, war nicht „Schulen Sie Mitarbeiter, Phishing zu erkennen", denn es gab nichts, was ein Mensch hätte erkennen können. Die Verteidigung war architektonisch: Ein Agent, der nicht zugleich von Angreifern kontrollierte Inhalte lesen und exfiltrieren kann, lässt sich auf diese Weise nicht gegen Sie wenden.

Die Lösung: Gehen Sie davon aus, dass Zero-Click das Bedrohungsmodell ist, nicht die Ausnahme. Wenn Ihr Agent irgendetwas liest, das ein Außenstehender beeinflussen kann (E-Mail, Webinhalte, hochgeladene Dateien, Tickets), und er außerdem Daten nach außen senden kann, haben Sie ein EchoLeak-förmiges Loch, bis Sie eine dieser beiden Fähigkeiten schließen oder den Sendeweg hart abriegeln.

Fehler 6: keine Grenze für Datenresidenz oder Aufbewahrung

Manche Lecks sind keine dramatischen Exfiltrationen, sondern langsames Abdriften. Daten landen in einer Region, der Sie nie zugestimmt haben, oder liegen länger in Protokollen, als Ihre Richtlinie erlaubt, einfach weil niemand die Grenze gesetzt hat. Microsofts Framework listet dies als Kern-Governance: Identifizieren Sie den Standort jeder Datenquelle, jeder Agenten-Laufzeit und jedes Ausgabespeichers, halten Sie Daten in Regionen oder On-Premises, die Ihrer Residenz-Richtlinie entsprechen, und halten Sie sie im Ruhezustand verschlüsselt.

Die beruhigende Nachricht, die fast kein Artikel klar benennt, ist, wie viel Sie festnageln können. Das Enterprise-Muster über die Anbieter hinweg lautet: standardmäßig kein Training plus ein kurzes Aufbewahrungsfenster plus stärkere Garantien auf Anfrage. Anthropic bietet qualifizierten Unternehmen eine Zero-Data-Retention-Vereinbarung (ZDR) an, unter der Eingaben und Ausgaben nicht über das hinaus gespeichert werden, was zur Missbrauchsprüfung nötig ist. OpenAI bietet ZDR über eine ausgehandelte Vereinbarung und Datenresidenz an. Beide lassen Sie wählen, wo die Daten liegen. Das Selbsthosten eines offenen Modells (zum Beispiel mit Ollama) hält Daten vollständig lokal, ohne Aufbewahrung durch Dritte.

Die Lösung: Entscheiden und dokumentieren Sie die Grenze vor dem Start. Welche Region die Daten hält, wie lange Protokolle leben, ob Sie ZDR brauchen und ob sensibler Abruf in Ihrer eigenen VPC oder On-Premises laufen sollte. ZDR ist in der Regel nur per API verfügbar und ausgehandelt, und es deckt nicht automatisch jedes Produkt ab, sofern Sie es nicht hinzufügen, deshalb zählt das Detail.

Fehler 7: Datenschutz als Checkliste behandeln, die man übergibt

Der letzte Fehler ist strukturell. Die meisten Leitfäden, einschließlich des hervorragenden Microsoft-Frameworks, gehen davon aus, dass Sie den Agenten selbst bauen und steuern, und reichen Ihnen daher einen 3.000 Wörter starken Stapel aus Entra-Identitäten, Purview-Labels und Verwaltungsgruppen. Das ist die richtige Antwort für ein großes IT-Team. Für die meisten Unternehmen ist es eine Checkliste, die niemand die Zeit oder Spezialkenntnisse hat, vollständig umzusetzen, also wird sie nur halb ausgeliefert, und die Lücken sind genau dort, wo Daten austreten.

Der Fehler ist, die Kontrollen als Dokumentation zu behandeln statt als eine Architektur, für die jemand von Anfang bis Ende verantwortlich ist. Eine Checkliste, die „vertrauliche Daten isolieren" und „externe Integrationen auf vertrauenswürdige MCP-Server beschränken" auflistet, ist nur so gut wie die Person, die sie einbaut, jede externe Kommunikation validiert und den Notfallplan aufstellt, um einen Agenten schnell abzuschalten, wenn etwas schiefgeht.

Die Lösung: Stellen Sie sicher, dass eine Partei die Grenze tatsächlich besitzt, nicht nur das Dokument. Entweder Sie bauen die interne Fähigkeit auf, den vollständigen Stack umzusetzen und zu pflegen, oder Sie haben einen Betreiber, der diese Fehlermodi herausbaut und sie betreibt, mit einer veröffentlichten Grenze, auf die Sie zeigen können. Der falsche Mittelweg ist eine Liste von Kontrollen und niemand, der dafür verantwortlich ist, dass sie hält.

Wie die sieben Fehler und Lösungen zusammenpassen

Hier sind alle sieben an einem Ort, sortiert danach, ob die Lösung ein Vertrag ist, den Sie unterzeichnen, oder eine Architektur, die Sie bauen. Diese Aufteilung ist der schnellste Weg zu erkennen, welches Team für welche zuständig ist.

Beachten Sie, dass nur zwei der sieben durch einen Vertrag gelöst werden. Die anderen fünf sind Architektur und Verantwortung, und das ist der Teil, den ein PDF mit Best Practices nicht für Sie übernehmen kann. Es ist auch der ehrliche Grund, warum die maßgeblichen Quellen eine Lücke lassen: Sie sagen Ihnen, was zu bauen ist, nicht, wer es in Ihren spezifischen Systemen korrekt baut.

Was tatsächlich niemals austritt, wenn die Grenze richtig gebaut ist

Es ist leicht, sieben Fehler zu lesen und zu schließen, dass KI-Agenten ein Datenschutz-Minenfeld sind. Sind sie nicht, wenn die Linie bewusst gezogen wird. Zu Enterprise-Konditionen sind Ihre Eingaben keine Trainingsdaten, und die Aufbewahrung dauert Tage, nicht ewig (7 für die Anthropic-API, 30 für OpenAI, danach gelöscht). Mit ZDR werden sie nicht über die Missbrauchsprüfung hinaus gespeichert. Mit festgelegter Datenresidenz bleiben sie in Ihrer Region. Mit VPC- oder On-Premises-Abruf verlässt sensible Information Ihren Perimeter überhaupt nicht. Mit Schwärzung an der Grenze werden die Felder, die niemals reisen sollten, entfernt, bevor irgendetwas gesendet wird. Mit Least-Privilege-Zuschnitt, der die Berechtigungen des Nutzers erbt, kann der Agent immer nur erreichen, was die handelnde Person ohnehin schon erreichen konnte.

Das ist eine konkrete, verteidigbare Grenze, und sie klar benennen zu können, ist der ganze Sinn. Die Gefahr war nie das Modell, das Ihr Unternehmen heimlich aufsaugt. Es sind die sieben Konfigurations- und Architekturfehler oben, von denen jeder einzelne verhinderbar ist, bevor der erste Agent live geht.

Das ist die Arbeit, die wir in den Stacks anderer Unternehmen leisten: die Konditionen wählen, die Identitäten zuschneiden, das Öffentliche vom Vertraulichen isolieren, die Trias brechen und die Grenze besitzen, damit sie hält. Wenn Sie möchten, dass diese Fehler aus Ihren Agenten herausgebaut werden, bevor sie irgendetwas Echtes berühren, buchen Sie unten eine kostenlose Beratung, und wir kartieren Ihre Grenze gemeinsam.