„Aber der Datenschutz!“ – Agentic Work als Information-Flow-Problem

Kaum fällt das Wort AI, kommt irgendwann:

„Aber der Datenschutz.“

Der Einwand ist nicht falsch. Wer AI-Systeme oder Coding Agents mit Unternehmensinformationen, personenbezogenen Daten oder sicherheitsrelevanten Systemen verbindet, sollte sehr genau darüber nachdenken, welche Informationen dabei verarbeitet werden. Nur ist dieser Satz zunächst noch keine Risikoanalyse.

AI
↓
"Datenschutz!"

sagt technisch ungefähr so viel aus wie:

Internet
↓
"Security!"

Beides benennt ein reales Problemfeld. Beides beantwortet aber noch keine konkrete Frage.

Interessant wird die Diskussion erst, wenn wir uns den tatsächlichen Information Flow ansehen:

Information
↓
Quelle
↓
Berechtigung
↓
Agent / Tool
↓
Context
↓
Verarbeitung
↓
Output / Artefakt / Memory

Welche Information fließt wohin? Warum wird sie dort benötigt? Wer darf sie sehen? Welche Systeme verarbeiten sie? Welche Trust Boundary überschreitet sie? Welche weiteren Artefakte entstehen daraus? Und was würde passieren, wenn diese Information an einer Stelle sichtbar wird, an der sie nicht sichtbar werden sollte?

Genau an diesem Punkt verschiebt sich die Diskussion. Agentic Work ist nicht nur ein Datenschutzproblem. Es ist ein Information-Flow- und Trust-Boundary-Problem. Datenschutz ist darin eine wichtige Dimension, aber eben nur eine.

Das knüpft unmittelbar an den vorherigen Artikel dieser Serie an. Dort ging es um Architektur als Constraint: Architektur begrenzt, welche strukturellen Lösungen ein Agent überhaupt erzeugen darf. Informationsschutz erweitert diese Idee. Architektur beantwortet, was womit verbunden werden darf. Informationsschutz ergänzt, wer was sehen darf, was wohin fließen darf und was daraus entstehen darf.

Eine Architektur begrenzt also den strukturellen Lösungsraum. Eine Trust Boundary begrenzt den zulässigen Context- und Aktionsraum.

Eine sensible Domäne ist noch kein sensibler Entwicklungs-Context

Ich arbeite seit ungefähr 15 Jahren in technischer Verantwortung und habe einen beträchtlichen Teil dieser Zeit in Bereichen wie Medizin und Public Sector verbracht. In beiden Domänen existieren Informationen, bei denen völlig unstrittig ist, dass sie besonders geschützt werden müssen. Trotzdem musste ich selbst in dieser Zeit nie mit echten hochsensiblen Produktivdaten entwickeln.

Das ist ausdrücklich eine persönliche Erfahrung und keine allgemeine Aussage darüber, wie Softwareentwicklung organisiert sein muss. Es gibt Systeme, Unternehmen und Rollen, in denen Entwickler sehr wohl mit produktionsnahen oder produktiven Daten arbeiten. Für mich zeigt diese Erfahrung trotzdem einen wichtigen Punkt:

Die Existenz hochsensibler Daten in einem System bedeutet nicht automatisch, dass diese Daten Bestandteil des normalen Entwicklungs- oder Agenten-Contexts sind.

Diese Unterscheidung verschwindet in vielen AI-Diskussionen erstaunlich schnell. Ein medizinisches System verarbeitet Gesundheitsdaten. Daraus folgt aber nicht automatisch, dass ein Entwickler oder Coding Agent echte Gesundheitsdaten sehen muss. Entwicklungs- und Produktivumgebungen können getrennt werden; Entwicklungsprozesse können mit synthetischen Testdaten, anonymisierten Daten, pseudonymisierten Daten oder eigens dafür aufgebauten Testdatenbeständen arbeiten. Zugriffsrechte können so geschnitten sein, dass ein Entwickler große Teile eines Systems verstehen und verändern kann, ohne die eigentlichen Produktivdaten jemals zu sehen.

Auch die Datenschutzkonferenz empfiehlt bei der Entwicklung von KI-Systemen, zunächst zu prüfen, ob der jeweilige Zweck mit synthetischen oder anonymisierten Daten erreicht werden kann. Pseudonymisierte Daten sind dabei nicht mit anonymen Daten gleichzusetzen: Wenn eine Person mittels zusätzlicher Informationen wieder zugeordnet werden kann, bleiben die Daten grundsätzlich personenbezogen. Tatsächlich anonymisierte Informationen fallen dagegen nicht mehr unter die DSGVO. [DSK – Technische und organisatorische Maßnahmen bei KI-Systemen]

Die technische Frage sollte deshalb nicht lauten, ob das Gesamtsystem sensible Daten enthält. Sie sollte lauten:

Welche dieser Daten benötigt dieser konkrete Entwicklungsprozess oder Agent tatsächlich?

Das klingt zunächst nach einer kleinen Verschiebung. Tatsächlich verändert sie das gesamte Problem, weil wir plötzlich nicht mehr abstrakt über eine sensible Domäne sprechen, sondern über einen konkreten Datenfluss.

Datenschutz ist nur eine Dimension des Informationsschutzes

Auch der Begriff Datenschutz selbst wird in technischen Diskussionen häufig weiter verwendet, als es sinnvoll ist.

Die DSGVO schützt personenbezogene Daten. Das sind Informationen, die sich auf eine identifizierte oder identifizierbare natürliche Person beziehen. Dazu können offensichtliche Informationen wie Namen oder E-Mail-Adressen gehören, aber je nach Kontext auch Kennungen, Online-Identifier, Kundennummern, Logs oder IP-Adressen. [DSGVO, Art. 4 – EUR-Lex]

Für bestimmte Informationen gelten nochmals besondere Anforderungen. Art. 9 DSGVO nennt unter anderem Gesundheitsdaten, genetische Daten, bestimmte biometrische Daten, politische Meinungen, religiöse oder weltanschauliche Überzeugungen, Gewerkschaftszugehörigkeit sowie Informationen über Sexualleben oder sexuelle Orientierung. [DSGVO, Art. 9 – EUR-Lex]

Daneben existiert aber eine große Klasse von Informationen, die überhaupt keinen Personenbezug besitzt und trotzdem hochgradig schützenswert sein kann: Source Code, Architektur, noch unveröffentlichte Produkte, Algorithmen, Forschungsergebnisse, interne Strategien, Verträge, Preisgestaltung oder proprietäre Verfahren. Ein Teil davon kann unter bestimmten Voraussetzungen sogar als Geschäftsgeheimnis geschützt sein. Das deutsche Geschäftsgeheimnisgesetz stellt dafür unter anderem darauf ab, dass die Information nicht allgemein bekannt oder ohne Weiteres zugänglich ist, einen wirtschaftlichen Wert besitzt und Gegenstand angemessener Geheimhaltungsmaßnahmen ist. Daraus folgt gerade nicht, dass jeder nicht öffentliche Source Code automatisch ein Geschäftsgeheimnis wäre. Es zeigt aber deutlich, dass wirtschaftlich wertvolle Informationen auch völlig ohne Personenbezug einen eigenen Schutzbedarf besitzen können. [§ 2 GeschGehG]

Und dann gibt es Informationen, bei denen die primäre Frage weder Datenschutz noch klassischer Geheimnisschutz ist: API Keys, Tokens, private Schlüssel, Cloud-Konfigurationen, interne Netzstrukturen, Security-Architekturen, Informationen über Schwachstellen oder andere Credentials. Auch hier wäre die Frage, ob personenbezogene Daten enthalten sind, offensichtlich unzureichend.

Datenschutz ist nur eine Dimension des Informationsschutzes.

Für Agentic Work ist das besonders wichtig, weil Coding Agents häufig mit Informationen arbeiten, die datenschutzrechtlich vollkommen unauffällig und gleichzeitig für ein Unternehmen extrem wertvoll sind. Ein Agent muss keinen einzigen Kundennamen sehen, um trotzdem Zugriff auf den Kern des geistigen Eigentums eines Unternehmens zu besitzen.

Zwei Achsen statt eines einzigen Labels

Für technische Diskussionen nutze ich deshalb ein einfaches Modell. Es ist keine offizielle DSGVO-Systematik und kein juristisches Klassifikationsschema, sondern eine Engineering-Abstraktion, die mir hilft, zwei unterschiedliche Fragen nicht miteinander zu vermischen.

Die erste Achse betrachtet grob den Personenbezug beziehungsweise den besonderen rechtlichen Schutz:

kein Personenbezug
↓
personenbezogene Daten
↓
besondere Kategorien personenbezogener Daten

Die zweite Achse betrachtet dagegen den möglichen Schaden einer Offenlegung:

öffentlich
↓
intern
↓
vertraulich
↓
geschäftskritisch
↓
existenzbedrohend / personengefährdend

Beide Achsen hängen nicht zwingend zusammen. Eine geschäftliche E-Mail-Adresse kann personenbezogen sein und gleichzeitig einen vergleichsweise niedrigen Schutzbedarf besitzen. Ein nicht veröffentlichter Algorithmus kann keinerlei personenbezogene Daten enthalten und trotzdem wirtschaftlich extrem kritisch sein. Natürlich kann eine Information auch auf beiden Achsen weit oben liegen.

Zwei bewusst extreme Beispiele machen diesen Unterschied besonders sichtbar.

Stellen wir uns auf der einen Seite Informationen über eine politisch verfolgte Person im Kontext eines Asylverfahrens vor. Allein Informationen über politische Meinungen gehören bereits zu den besonderen Kategorien personenbezogener Daten nach Art. 9 DSGVO. Je nach Inhalt eines Vorgangs können weitere hochsensible Informationen hinzukommen. Eine unbefugte Offenlegung wäre hier nicht nur ein abstraktes Compliance-Problem. Sie könnte reale persönliche Konsequenzen haben.

Auf der anderen Seite entwickelt ein Unternehmen ein neues technisches Verfahren. Keine Kundendaten, keine Namen, keine E-Mail-Adressen, keine Benutzerkennungen, keinerlei Personenbezug. Das Verfahren ist aber das Ergebnis jahrelanger Forschung und vielleicht der zentrale zukünftige Wettbewerbsvorteil des Unternehmens. Eine Offenlegung könnte wirtschaftlich katastrophal sein.

Nicht personenbezogen bedeutet nicht automatisch unkritisch.

Für eine technische Risikoanalyse reicht deshalb ein einzelnes Label wie personenbezogen: ja / nein nicht aus. Wir müssen zusätzlich fragen, was passieren würde, wenn diese Information die falsche Trust Boundary überschreitet. Genau dort wird aus Datenschutz eine umfassendere Information-Flow-Frage.

Der Datenfluss zählt mehr als das Marketing-Label

Diese Unterscheidung hilft auch bei einigen Aussagen, die im Umfeld von AI-Produkten sehr schnell beruhigend wirken. Eine davon lautet:

Unsere Daten werden nicht zum Training verwendet.

Das kann eine wichtige Eigenschaft eines Angebots sein. Nur beantwortet sie genau eine Frage. Sie bedeutet nicht automatisch, dass keine Verarbeitung, Übertragung, Speicherung, Logs, Retention, weiteren Dienstleister, Supportzugriffe oder Verarbeitung außerhalb einer bestimmten Region existieren.

Die DSGVO verwendet den Begriff Verarbeitung wesentlich breiter. Darunter fallen unter anderem das Erheben, Erfassen, Speichern, Auslesen, Abfragen, Verwenden, Übermitteln, Bereitstellen, Verknüpfen und Löschen personenbezogener Daten. Training ist damit nur ein möglicher Verarbeitungsschritt oder -zweck innerhalb eines viel größeren technischen Ablaufs. [DSGVO, Art. 4 – EUR-Lex]

Auch die Datenschutzkonferenz trennt beispielsweise die Nutzung von Ein- und Ausgabedaten für Training von der Speicherung einer Eingabehistorie. Ein System kann Training ausschließen und trotzdem Daten speichern. [DSK – Künstliche Intelligenz und Datenschutz]

Deshalb gilt:

No training is not the same as no processing.

Das heißt nicht, dass ein kommerzielles oder extern betriebenes AI-System automatisch problematisch wäre. Es heißt lediglich, dass die Aussage No Training keine vollständige Beschreibung des Datenflusses ist. Vertragliche Regelungen, AVV beziehungsweise DPA, Retention, Region, Subprozessoren, technische Konfiguration und tatsächlicher Information Flow müssen zusammenpassen.

Der umgekehrte Kurzschluss funktioniert genauso wenig. Selbst wenn eine konkrete Verarbeitung personenbezogener Daten datenschutzrechtlich zulässig wäre, folgt daraus nicht automatisch, dass diese Information auch in einen Prompt darf. Eine Vertraulichkeitsvereinbarung kann die Weitergabe verbieten, eine interne Security Policy kann zusätzliche Grenzen setzen, die Information kann ein Geschäftsgeheimnis sein oder vertraglichen beziehungsweise regulatorischen Beschränkungen unterliegen. Es kann auch sein, dass ein Nutzer innerhalb eines internen Systems auf eine Information zugreifen darf, sie deshalb aber noch lange nicht an einen externen Dienst weitergeben darf. Und möglicherweise existiert überhaupt kein Personenbezug, während der Transfer aus Gründen des IP-Schutzes trotzdem vollkommen inakzeptabel wäre.

Eine datenschutzrechtlich zulässige Verarbeitung ist nicht automatisch eine organisatorisch oder sicherheitstechnisch zulässige Verarbeitung.

Ich bin Softwarearchitekt, kein Jurist. Ob eine konkrete Verarbeitung zulässig ist, hängt vom jeweiligen Verarbeitungskontext ab und kann eine datenschutzrechtliche oder juristische Bewertung erfordern. Die Aufgabe der Architektur beginnt aber früher: Bevor jemand rechtlich bewerten kann, ob ein Datenfluss zulässig ist, sollte technisch überhaupt klar sein, welcher Datenfluss existiert.

Agents vergrößern die Informationsoberfläche

Bei einem klassischen Chat ist die sichtbare Interaktion zunächst relativ überschaubar: Ich schreibe einen Prompt, das System verarbeitet ihn, ich erhalte eine Antwort. Ein Coding Agent kann einen völlig anderen Aktionsradius besitzen.

Je nach System, Konfiguration und Aufgabe kann er auf Teile einer Umgebung zugreifen wie:

Repository
Documentation
Tickets
Shell
File System
Environment Variables
Database
Logs
CI/CD
Cloud APIs
Secrets
Browser
External Search

Nicht jeder Agent besitzt all diese Fähigkeiten. Gerade deshalb ist die pauschale Frage, ob ein Coding Agent sicher ist, zu ungenau. Ein Agent mit Read-only-Zugriff auf ein einziges Repository ist sicherheitstechnisch etwas völlig anderes als ein Agent, der Shell-Kommandos ausführen, Dateien verändern, externe Dienste aufrufen, Secrets lesen und Deployments anstoßen darf.

Mit jedem zusätzlichen Tool wächst nicht nur sein Aktionsraum. Auch sein Informationsraum wächst. Das BSI weist im Zusammenhang mit anwendungsintegrierten Sprachmodellen beispielsweise darauf hin, dass zusätzliche Integrationen Zugriff auf Dokumente, Webseiten, Programmierumgebungen oder andere Systeme eröffnen und damit neue Angriffswege wie Indirect Prompt Injection schaffen können. [BSI – Indirect Prompt Injections]

Mit zunehmender Agency wächst die Informations- und Angriffsoberfläche.

Damit wird ein sehr altes Security-Prinzip zu einem zentralen Prinzip von Agentic Work: Least Privilege.

Die Frage sollte nicht lauten, was ein Agent irgendwann vielleicht gebrauchen könnte, sondern was er für genau diese Aufgabe benötigt:

Task
↓
benötigte Fähigkeiten
↓
benötigte Informationen
↓
minimale Berechtigungen

Ein Agent, der Texte in einer Frontend-Anwendung verändert, benötigt normalerweise keine Produktionsdatenbank, keine Cloud-Admin-Rechte, keine Secrets und keinen Zugriff auf jedes Repository des Unternehmens. Eine Analyse einer komplexen Migration kann dagegen einen deutlich größeren Context benötigen. Das ist kein Widerspruch. Least Privilege bedeutet nicht möglichst wenig Zugriff, sondern so viel wie nötig und so wenig wie möglich.

Und daraus folgt eine der für mich wichtigsten Regeln in diesem Themenfeld:

Relevant bedeutet noch nicht zulässig.

Ein Agent kann eine Information technisch gebrauchen. Das allein ist noch keine Begründung dafür, ihm diese Information zugänglich zu machen.

Autorisierung gehört vor Retrieval

Bei RAG-Systemen wird dieser Unterschied besonders deutlich. Eine sehr einfache Vorstellung von RAG sieht ungefähr so aus:

Unternehmenswissen
↓
Retrieval
↓
LLM

Weil das Wissen nicht in das Modell selbst trainiert wird, wirkt das zunächst kontrollierbarer. Das kann es auch sein. Nur verschwinden dadurch die Berechtigungsfragen nicht.

Die DSK weist in ihrer Orientierungshilfe zu RAG ausdrücklich darauf hin, dass für Referenzdokumente und Vektordatenbanken Rechte- und Rollenkonzepte relevant bleiben. Sie beschreibt außerdem, dass die Zugriffssteuerung nicht einfach dem Sprachmodell überlassen werden kann und entsprechende Rollen bereits vor der Abfrage berücksichtigt werden sollten. [DSK – Datenschutzrechtliche Besonderheiten generativer KI-Systeme mit RAG-Methode]

Aus Engineering-Sicht ergibt sich damit eine klare Reihenfolge:

Identity
↓
Authorization
↓
Retrieval
↓
Context
↓
LLM

Nicht erst alles finden, Context erzeugen und anschließend überlegen, ob der Nutzer diese Information überhaupt sehen durfte.

RAG ist kein Privacy Shield.

Retrieval verändert den technischen Weg, über den Informationen in den Context gelangen. Es hebt aber keine bestehenden Berechtigungsgrenzen auf. Ein Agent darf eine Information nicht allein deshalb erhalten, weil sie technisch auffindbar ist.

„Der Agent sollte dort eigentlich nicht hinkommen“

Eine meiner interessantesten Erfahrungen mit Coding Agents hatte genau mit dieser Annahme zu tun.

In einem früheren Audit eines großen, über Jahre gewachsenen Systems waren bestimmte besonders geschützte Teile des Source Codes explizit für den Coding Agent ausgeschlossen. Der Agent sollte diese Bereiche nicht direkt analysieren. Später tauchten trotzdem Informationen über diesen Bereich in von ihm erzeugten Audit-Dokumenten auf.

Ob diese Informationen über indirekte Dependencies, Types, Aliases, Referenzen aus anderen Modulen, bereits erzeugte Dokumentation, Search oder einen völlig anderen Analysepfad sichtbar wurden, kann ich im Nachhinein nicht mehr sicher sagen. Genau deshalb möchte ich dafür auch keine Ursache konstruieren.

Der interessante Punkt ist ein anderer:

Ein technisch ausgeschlossener Bereich war für den Agenten offenbar trotzdem nicht vollständig unsichtbar.

Das war für mich eine sehr anschauliche Erinnerung daran, dass „der Agent sollte dort eigentlich nicht hinkommen“ keine belastbare Sicherheitsbeschreibung ist. Das Wort sollte beschreibt erwartetes Verhalten. Eine Trust Boundary beschreibt eine technisch durchgesetzte Grenze.

„Der Agent sollte dort eigentlich nicht hinkommen“ ist keine belastbare Trust Boundary.

Bei Informationen mit geringem Schutzbedarf kann eine weiche Einschränkung vollkommen ausreichend sein. Je höher der Schutzbedarf wird, desto weniger möchte ich mich darauf verlassen.

File Boundary ist nicht automatisch Information Boundary

Nehmen wir an, eine Datei ist für einen Agenten nicht lesbar:

protected-module.ts
✕ direkter Zugriff

Damit wissen wir zunächst nur, dass der Agent diese Datei nicht direkt lesen kann. Wir wissen noch nicht, dass er keinerlei Information über diesen Bereich erhalten kann.

Information bleibt in einem Softwaresystem selten sauber innerhalb einer einzigen Datei. Sie verteilt sich über Contracts, Types, Dependencies, Stacktraces, Logs, Testreports, Coverage, Static-Analysis-Findings, Architektur-Dokumentation, Tickets, PR-Beschreibungen, Agent Summaries und andere generierte Artefakte. Ein Interface kann etwas über einen geschützten Bereich verraten, ohne dessen Implementierung zu enthalten. Ein Stacktrace kann Komponentenbeziehungen sichtbar machen. Ein Testreport beschreibt Verhalten. Ein Architekturdiagramm dokumentiert Dependencies. Ein Ticket kann erklären, warum ein bestimmter interner Mechanismus existiert. Eine frühere Summary kann Informationen aus einem Context weitertragen, der später gar nicht mehr zugänglich ist.

Daraus folgt ausdrücklich nicht, dass ein Agent aus solchen Informationen automatisch den ursprünglichen Source Code rekonstruieren könnte. Das wäre eine andere und wesentlich stärkere Behauptung. Der relevante Mechanismus ist einfacher:

Geschützte Information kann eine Trust Boundary überschreiten, ohne dass die ursprüngliche Datei diese Grenze selbst überschreitet.

Eine Access Control auf einer Quelldatei ist deshalb noch keine vollständige Information-Flow-Control. Das ist keine spezielle DSGVO-Regel, sondern eine Engineering-Ableitung. Gerade Agents machen sie aber besonders relevant, weil sie Informationen aus vielen Quellen zusammenführen und anschließend neue Artefakte erzeugen können.

Wir sollten deshalb nicht nur fragen, welche Dateien ein Agent lesen darf, sondern auch, welche Informationen aus erlaubten Quellen sichtbar werden können und welche neuen Artefakte daraus entstehen. Information Flow endet nicht beim Input.

An diesem Punkt gibt es sogar eine Verbindung zu einem meiner wiederkehrenden Architekturthemen. Ein Big Ball of Mud verursacht nicht automatisch Datenschutzverletzungen. Hohe Kopplung erschwert aber nachvollziehbare Grenzen:

klare Boundaries
↓
überschaubare Informationspfade

gegen:

Big Ball of Mud
↓
implizite Beziehungen
↓
schwerer vorhersehbare Informationspfade

Saubere Architektur ist deshalb noch keine Datenschutzmaßnahme. Aber sie erleichtert Ownership, Isolation, Dependency-Kontrolle und damit auch die technische Durchsetzung von Informationsgrenzen.

Hohe Kopplung erschwert die technische Durchsetzung und Überprüfung von Trust Boundaries.

Bei hohem Schutzbedarf ist weniger oft stärker

Eine naheliegende Antwort auf besonders sensible Informationen lautet, das Modell lokal zu betreiben. Das kann ein sinnvoller Baustein sein. Wenn bestimmte Informationen eine definierte Trust Boundary nicht verlassen sollen, kann ein lokal oder On-Premise betriebenes Modell einen erheblichen Unterschied machen.

Die relevante Architektur besteht aber nicht nur aus LLM lokal, sondern aus der gesamten Kette:

LLM lokal
+
Retrieval lokal
+
Logs lokal
+
Tools lokal
+
Memory lokal
+
keine Cloud-Fallbacks
+
keine unerwünschte Telemetrie

Ein lokales Modell mit externem Retrieval besitzt keine vollständig lokale Trust Boundary. Ein lokaler Agent, dessen Tooling Informationen anschließend an externe APIs sendet, ebenfalls nicht. Und ein On-Premise-Modell mit unbekannten externen Telemetriepfaden löst das Problem auch nicht allein dadurch, dass die Inference lokal stattfindet.

Die DSK weist bei RAG ebenfalls darauf hin, dass On-Premise-Architekturen die Übermittlung personenbezogener Daten an externe Modellanbieter vermeiden können, gleichzeitig aber die Gesamtarchitektur betrachtet werden muss. [DSK – RAG-Orientierungshilfe]

Entscheidend bleibt also das vollständige Data-Flow-Modell.

Noch interessanter wird es bei wirklich hohem Schutzbedarf. Dort sollten wir eine andere Frage zuerst stellen:

Warum soll diese Information diese Trust Boundary überhaupt verlassen?

Security Engineering besteht nicht ausschließlich darin, riskante Datenflüsse immer besser abzusichern. Manche Risiken lassen sich eleganter behandeln, indem der Datenfluss überhaupt nicht entsteht. Vielleicht reicht ein synthetischer Datensatz, vielleicht ein anonymisierter oder reduzierter Ausschnitt, vielleicht ein Contract. Vielleicht kann ein lokaler Service eine sensible Operation kapseln und dem Agenten lediglich ein weniger sensibles Ergebnis bereitstellen. Vielleicht ist eine manuelle Grenze sinnvoll. Und vielleicht ist für einen bestimmten Use Case schlicht kein Agent die richtige Lösung.

Bei sehr hohem Schutzbedarf kann die richtige Architektur darin bestehen, einen Datenfluss überhaupt nicht entstehen zu lassen.

Das passt zu einem Grundgedanken, den es lange vor LLMs gab: Datenminimierung und Privacy by Design verlangen bei personenbezogenen Daten gerade nicht, möglichst viele Informationen zu sammeln und anschließend maximal aufwendig zu schützen, sondern bereits bei der Gestaltung zu begrenzen, was für einen Zweck tatsächlich erforderlich ist. [DSGVO, Art. 5 und Art. 25 – EUR-Lex]

Für Agentic Work ist das eine produktive Denkweise. Nicht die Frage, welche Informationen wir einem Agenten irgendwie geben können, sollte im Mittelpunkt stehen, sondern welche Informationen wir ihm für seine Aufgabe ersparen können.

Datenschutz wird nicht erst durch AI konkret

Vielleicht ist das der Teil der Diskussion, bei dem mich die aktuelle AI-Debatte am meisten irritiert.

Organisationen verarbeiten seit Jahrzehnten Informationen über externe Systeme: Cloud, SaaS, APIs, Kommunikationsplattformen, Supportsysteme, Analytics und externe Dienstleister. Keines dieser Systeme war jemals automatisch unproblematisch. Für sie mussten und müssen Zweck, Berechtigungen, Empfänger, Speicherort, Retention, Verträge, technische Maßnahmen und Schutzbedarf betrachtet werden.

AI verändert einzelne Risikoprofile erheblich. Generative Modelle kombinieren Informationen auf neue Weise. RAG macht große Wissensbestände semantisch auffindbar. Agents erhalten Tools und können selbst Aktionen ausführen. Prompt Injection schafft neue Angriffsmöglichkeiten. Memory und generierte Artefakte können Informationen über eine einzelne Interaktion hinaus weitertragen.

Das sind reale Unterschiede. Aber die grundlegende Frage, welche Information wohin fließt, ist nicht neu. Die DSGVO ist technologieneutral angelegt. Ihre Grundsätze hängen nicht davon ab, ob personenbezogene Daten durch ein klassisches SaaS-System, eine API oder ein Sprachmodell verarbeitet werden. [DSGVO – EUR-Lex]

Deshalb halte ich beide Extreme für wenig hilfreich. Weder ist plötzlich alles verboten, nur weil AI beteiligt ist, noch ist mit einem Enterprise-Angebot automatisch alles geklärt.

Datenschutz sollte nicht dann absolut werden, wenn das Wort AI fällt. Er sollte dort konkret werden, wo reale Datenflüsse und reale Risiken entstehen.

Das ist keine Forderung nach weniger Datenschutz. Im Gegenteil: Sie macht die Diskussion präziser. Statt aus AI → Datenschutzproblem eine pauschale Schlussfolgerung zu ziehen, können wir Fragen stellen, die sich tatsächlich beantworten lassen:

Braucht der Agent diese Information?
↓
Darf der Nutzer auf sie zugreifen?
↓
Darf der Agent sie für diese Aufgabe verarbeiten?
↓
Darf sie diese Trust Boundary verlassen?
↓
Ist der Zugriff technisch begrenzt?
↓
Welche Artefakte können daraus entstehen?
↓
Können diese Artefakte Information weitertragen?
↓
Wie wird das überprüft?

Nicht jede dieser Fragen ist ausschließlich datenschutzrechtlich. Einige gehören zu Security, andere zu Architektur, Governance, Vertragsrecht oder Compliance. Gerade deshalb hilft der reflexhafte Satz „Aber der Datenschutz“ so wenig: Er vermischt zu viele unterschiedliche Probleme unter einem einzigen Label.

Datenschutz als Constraint

Damit schließt sich der Kreis zum vorherigen Artikel.

Dort ging es darum, den strukturellen Lösungsraum eines Agents zu verkleinern. Nicht jede technisch mögliche Architektur soll zulässig sein. Nur weil ein Agent eine Presentation Layer direkt mit einer Datenbank verbinden könnte, heißt das nicht, dass wir diese Lösung akzeptieren müssen.

Architektur setzt Constraints.

Informationsschutz funktioniert ähnlich. Nur weil ein Agent technisch auf eine Information zugreifen könnte, heißt das nicht, dass diese Information Teil seines Contexts sein sollte.

Architecture Constraints
↓
Welche strukturellen Lösungen sind zulässig?

ergänzt sich um:

Information Constraints
↓
Welche Informationen und Fähigkeiten sind zulässig?

Das ist für mich ein wesentlich produktiveres Verständnis von Datenschutz im Kontext von Agentic Work. Agenten besitzen reale Datenschutzrisiken, reale Vertraulichkeitsrisiken und reale Security-Risiken. Je größer ihre Agency wird, desto größer können diese Risiken werden, weil mehr Informationen und mehr Aktionen erreichbar werden.

Aber diese Risiken sind nicht mystisch. Sie lassen sich analysieren, modellieren und durch Architektur beeinflussen. Sie lassen sich durch Berechtigungen begrenzen, überwachen und überprüfen. Und manche lassen sich vermeiden, indem ein Informationsfluss gar nicht erst zugelassen wird.

Datenschutz ist kein KO-Kriterium für Agentic Work. Er ist eine Constraint des Systems.

Das bedeutet nicht, dass Datenschutz damit gelöst wäre. Es bedeutet, dass wir ihn konkret machen können.

Und dabei bleibt eine Regel besonders wichtig:

Relevant bedeutet noch nicht zulässig.

Die entscheidende Frage ist nicht, ob ein Agent theoretisch Informationen verarbeiten kann. Die entscheidende Frage ist, welche Informationen wir ihm für genau diese Aufgabe tatsächlich zugänglich machen wollen.

Wenn wir diese Frage sauber beantworten können, ist aus „AI? Aber Datenschutz!“ bereits eine wesentlich bessere Diskussion geworden:

Welche Information soll verarbeitet werden, wer darf sie sehen, warum braucht der Agent sie, welche Trust Boundary überschreitet sie, welche Folgen hätte eine Offenlegung und wie erzwingen wir diese Grenze technisch?

Das ist keine Verharmlosung des Problems. Es ist seine Konkretisierung. Und genau darin liegt die Demystifizierung.

Requirements, Architektur und Informationsgrenzen haben damit den zulässigen Lösungsraum bereits erheblich verkleinert. Deterministisch ist er trotzdem nicht. Auch innerhalb sauber definierter Constraints können Agents mehrere fachlich und technisch valide Lösungen erzeugen.

Im nächsten Artikel geht es deshalb um die Frage, wie wir diese Varianz nicht nur ertragen, sondern bewusst nutzen:

Diverge · Decide · Converge.

Quellen und Einordnung

DSGVO – Verordnung (EU) 2016/679, EUR-Lex
Primäre Rechtsquelle für personenbezogene Daten, besondere Kategorien personenbezogener Daten, Verarbeitung, Datenminimierung, Privacy by Design, Sicherheit der Verarbeitung und weitere datenschutzrechtliche Grundsätze. Sie definiert weder das Zwei-Achsen-Modell dieses Artikels noch spezielle Trust-Boundary-Modelle für Coding Agents.
https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX%3A32016R0679

Datenschutzkonferenz – Künstliche Intelligenz und Datenschutz, 2024
Behördliche Orientierungshilfe zum Einsatz von KI und zur Trennung verschiedener Verarbeitungsschritte, unter anderem Training und Speicherung von Eingaben. Keine allgemeine Freigabe oder Verbotsregel für bestimmte AI-Produkte.
https://www.datenschutzkonferenz-online.de/media/oh/20240506_DSK_Orientierungshilfe_KI_und_Datenschutz.pdf

Datenschutzkonferenz – Technische und organisatorische Maßnahmen bei KI-Systemen, 2025
Behördliche Orientierungshilfe zu Data Protection by Design, Datenminimierung, Risikoanalyse und möglichen technischen und organisatorischen Maßnahmen über den Lebenszyklus von KI-Systemen.
https://www.datenschutzkonferenz-online.de/media/oh/DSK-OH_KI-Systeme.pdf

Datenschutzkonferenz – Datenschutzrechtliche Besonderheiten generativer KI-Systeme mit RAG-Methode, 2025
Relevant für Rechte- und Rollenkonzepte, Retrieval, Referenzdokumente, Vektordatenbanken und On-Premise-Szenarien. Der Satz „RAG ist kein Privacy Shield“ ist eine technische Verdichtung dieses Artikels und kein wörtliches Zitat der DSK.
https://www.datenschutzkonferenz-online.de/media/oh/DSK_OH_RAG.pdf

BfDI – KI in Behörden: Datenschutz von Anfang an mitdenken, 2025
Handreichung für die Bundesverwaltung zum Einsatz von LLMs und zu datenschutzrechtlichen Fragestellungen. Ihre Zielgruppe ist die Bundesverwaltung; sie ist keine allgemeine Rechtsnorm für sämtliche Unternehmen.
https://www.bfdi.bund.de/SharedDocs/Downloads/DE/DokumenteBfDI/Dokumente-allg/2025/Handreichung-KI.pdf

Geschäftsgeheimnisgesetz – § 2 GeschGehG
Definiert Geschäftsgeheimnisse und deren Voraussetzungen. Personenbezogene Daten und Geschäftsgeheimnisse sind unterschiedliche Schutzkategorien, die sich überschneiden können. Nicht jeder nicht öffentliche Source Code erfüllt automatisch die Voraussetzungen eines Geschäftsgeheimnisses.
https://www.gesetze-im-internet.de/geschgehg/__2.html

BSI – Indirect Prompt Injections
Technische Security Guidance zu Risiken anwendungsintegrierter Sprachmodelle und zusätzlichen Angriffswegen durch externe Inhalte und Tool-Integrationen. Keine datenschutzrechtliche Zulässigkeitsentscheidung.
https://www.bsi.bund.de/SharedDocs/Cybersicherheitswarnungen/DE/2023/2023-249034-1032.html

Engineering-Ableitungen dieses Artikels
Das Zwei-Achsen-Modell aus Personenbezug und möglichem Offenlegungsschaden ist keine offizielle DSGVO-Klassifikation. Gleiches gilt für Identity → Authorization → Retrieval → Context → LLM, für die Übertragung von Least Privilege auf task-spezifische Agent-Berechtigungen sowie für die Aussage „File Boundary ist nicht automatisch Information Boundary“. Diese Modelle dienen dazu, abstrakte Schutzanforderungen in technisch diskutierbare und überprüfbare Grenzen zu übersetzen.