Die DSGVO ist beim Coding-Agent-Rollout nicht der schwierige Teil. Schwierig ist herauszufinden, welche personenbezogenen Daten in acht Jahren Repository-Geschichte in Testfixtures, Kommentare und Commit-Messages gewandert sind. Der Rest ist Verfahrensarbeit, die im Haus ohnehin läuft, nur eben jetzt mit einem neuen Eintrag im Verzeichnis. Manche Anbieter sprechen statt von Coding Agent von Coding Assistent oder Coding Assistant; der DSGVO-Kontext bleibt derselbe.
Drei saubere Trennungen und vier Architekturentscheidungen reichen, um aus dem Termin mit dem Datenschutzbeauftragten, kurz DPO, eine produktive Stunde zu machen statt einer Schleife über Folie sieben.
Vorab eine Klarstellung: Dieser Text ist kein Rechtsrat. Ich bin kein Anwalt. Was hier steht, ist ein Gesprächsrahmen für die Stunde mit dem DPO. Die rechtsverbindliche Einschätzung kommt nicht von einem Blog, sondern aus Ihrem Haus.
Kurz gefasst: Die DSGVO verbietet Coding Agents nicht. Sie verlangt eine saubere Einordnung des Datenflusses. Drei Themen werden in Rollouts oft vermischt: Datenschutzrecht, Geschäftsgeheimnisse, Mitbestimmung. Für Code ohne Personenbezug hat die Datenschutzkonferenz bereits 2024 eine hilfreiche Einordnung gegeben. Sobald Prompts, Repository-Kontext, Logs, Testdaten oder Tool-Ausgaben personenbezogene Daten enthalten, braucht es die normale DSGVO-Arbeit: Rechtsgrundlage, AVV, Verzeichnis, TOMs, gegebenenfalls DSFA und Drittlandprüfung. Entscheidend ist nicht das Label „DSGVO-konform" auf einem Tool, sondern die konkrete Architektur.
Wer den Datenschutzteil neben den anderen Schichten einer Coding-Agent-Einführung verorten will, findet im Rahmen für die Agent-Einführung im Entwicklerteam Tooling, Messung, Workflow-Muster und Rollout im Zusammenhang.
Drei Fragen, ein Tisch
Die meisten DSGVO-Gespräche zu Coding Agents leiden daran, dass drei Risikoebenen zu einer einzigen Frage gemacht werden. Das spart auf der Tagesordnung Platz aber kostet im Termin Zeit.
Die drei Fragen sind:
Erstens: Datenschutzrecht. Werden personenbezogene Daten verarbeitet? Auf welcher Rechtsgrundlage? Mit welchem Auftragsverarbeiter? Diese Frage beantwortet Ihr Datenschutzbeauftragter.
Zweitens: Geschäftsgeheimnisschutz. Darf unser Code das Haus verlassen? Haben wir das gegenüber Kunden vertraglich zugesichert? Was steht in unseren NDAs? Diese Frage beantworten Vertragswesen und Vertrieb.
Drittens: Mitbestimmung. Ist die Einführung des Tools nach § 87 Abs. 1 Nr. 6 BetrVG beteiligungspflichtig, weil es objektiv geeignet ist, Verhalten oder Leistung der Beschäftigten zu erfassen? Das BAG hat im Juli 2024 (Beschluss 1 ABR 16/23) noch einmal bestätigt, dass „objektive Eignung" reicht. Auch wenn niemand vorhat, mit dem Telemetrie-Export Leistungsbeurteilungen zu fahren. Diese Frage beantworten Personalwesen und Betriebsrat. Wie das praktisch aussieht, beschreibt der Beitrag zum Betriebsrat.
Jede dieser drei Fragen ist legitim. Keine ist für die anderen beiden zuständig. Wenn das Meeting in der Reihenfolge „Datenschutz – Vertragsrecht – Mitbestimmung" durchgeht und jede Frage von der zuständigen Stelle beantwortet wird, dauert es eine Stunde. Wenn alle drei Themen in einen einzigen Satz „aber ist das DSGVO-konform" gepresst werden, dauert es drei Termine, und am Ende ist niemand zufrieden.
Was die Datenschutzkonferenz schon beantwortet hat
Die Datenschutzkonferenz, das gemeinsame Gremium der deutschen Datenschutz-Aufsichtsbehörden, hat ein häufiges Coding-Szenario am 6. Mai 2024 in trockenster Behördensprache eingeordnet. Die Orientierungshilfe „Künstliche Intelligenz und Datenschutz" führt in Abschnitt 1.3 als Beispiel 2 auf:
„Das Entwicklungsteam eines Unternehmens nutzt einen LLM-Chatbot, um Fehler in einer Code-Sequenz zu finden, die keinen Personenbezug enthält. Es ist jedoch zu prüfen, ob eine Verarbeitung personenbezogener Daten aufgrund eines Personenbezugs im KI-Modell vorliegen kann."
Zwei Sätze, die mehr leisten als die meisten Compliance-Folien. Der erste zeigt: Nicht jede Coding-Agent-Interaktion ist automatisch ein Datenschutzvorgang. Wer eine Code-Sequenz ohne Personenbezug prüfen lässt, also das Refactoring einer Utility-Funktion, eine Debug-Session in einer isolierten Berechnungsfunktion, die Implementation eines Endpoints, die nichts über reale Personen weiß, bewegt sich zunächst außerhalb des klassischen Personenbezugs. Die Einschränkung folgt aber sofort: Kontext, Modellbezug und Toolzugriffe können das Ergebnis ändern. Der zweite Satz weist auf die Frage hin, ob im Modell selbst Personenbezug liegen kann. Für den Rollout ist das kein Punkt für Bauchgefühl, sondern für Anbieterprüfung, Vertragslage und dokumentierte Risikobewertung. Der vertragliche Trainingsausschluss, auf den die nächste Sektion eingeht, gehört dazu, ersetzt diese Prüfung aber nicht.
Soweit der angenehme Teil. Jetzt zur schlechten Nachricht: Personenbezug taucht in Repositories häufiger auf, als Entwickler im ersten Moment glauben. Vier Kategorien laufen mir in jedem Projekt-Audit über den Weg.
Testdaten mit echten Kundennamen, oft historisch gewachsen, in Fixtures, Seed-Skripten und Beispiel-Payloads. Selten absichtlich, fast immer übersehen.
Commit-Metadaten: Autor-Namen, E-Mail-Adressen, Commit-Messages mit „Anpassung für Kunde Müller, Tarif 4711". Sobald der Agent den Git-Verlauf in den Kontext zieht, ist das ein Eingabe-Personenbezug.
Kommentare und Logs: das berühmte // TODO Schmidt anrufen wegen Storno neben einer Funktion. Debug-Logs, in denen Session-IDs und Klartextnamen direkt nebeneinander stehen. Incident-Reports im Repo mit Namen von Kunden, Betreibern, Innendienst.
Code, der personenbezogene Daten verarbeitet, wenn der Agent zur Laufzeit Live-Daten zurückbekommt. Ein Prompt wie „warum stimmt die Adresse für user_id 12345 nicht" liest harmlos, wenn die Query gegen die Staging-Umgebung mit Mock-Daten läuft. Er liest anders, wenn er gegen Produktion läuft.
Nicht jeder Coding-Agent-Einsatz überschreitet diese Linie. Teams, die sie überschreiten, sollten das wissen und solche Flows architektonisch anders behandeln als die Refactoring-Hilfe für die Utility-Bibliothek.
Wenn personenbezogene Daten doch fließen
Sobald die Antwort auf „verarbeiten wir hier personenbezogene Daten" Ja oder Vielleicht lautet, gilt die DSGVO. Vier Anforderungen sind dann zu erfüllen, und alle vier sind seit 2018 derselbe Stoff wie bei jedem anderen Datenverarbeitungsvorgang im Unternehmen.
Rechtsgrundlage. Art. 6 DSGVO. Für interne Entwickler-Tools trägt im Regelfall Art. 6 Abs. 1 lit. f, das berechtigte Interesse. Einwilligung im Beschäftigungskontext ist nach Auffassung der DSK (Kurzpapier Nr. 14 zum Beschäftigtendatenschutz) in der Regel nicht tragfähig. Die Freiwilligkeit ist im Arbeitsverhältnis selten gegeben. Die Rechtsgrundlage gehört dokumentiert, nicht stillschweigend angenommen.
Auftragsverarbeitungsvertrag. Art. 28 DSGVO. Der Coding-Agent-Anbieter ist in der Regel Auftragsverarbeiter, sobald er personenbezogene Daten im Auftrag des Unternehmens verarbeitet. Ohne wirksamen AVV fehlt für diese Auftragsverarbeitung ein zentraler DSGVO-Baustein. Das ist kein Formalismus, sondern Art. 28 DSGVO. Anthropic, GitHub und andere Enterprise-Anbieter haben standardisierte DPAs einschließlich EU-Standardvertragsklauseln. Für Anthropic ist der DPA self-service über das Privacy Center abrufbar und gilt für alle Commercial-Plans, über die Claude Code ausgeliefert wird. Für GitHub Copilot Business und Enterprise sind die DSGVO-relevanten Punkte (Trainingsausschluss, Auftragsverarbeitungslogik) im GitHub Copilot Trust Center hinterlegt.
Verzeichnis der Verarbeitungstätigkeiten. Art. 30. Der Coding-Agent gehört als Verarbeitungstätigkeit aufgenommen, mit Datenkategorien, Empfängern, Speicherfristen, technischen Maßnahmen. Eine Datenschutz-Folgenabschätzung nach Art. 35 ist nicht automatisch Pflicht, wird aber von vielen Aufsichtsbehörden bei AI-Tools im Beschäftigungskontext praktisch regelmäßig erwartet. Die DSK empfiehlt sie in der Mai-2024-Orientierungshilfe ausdrücklich.
Drittlandübermittlung. Art. 44 bis 46. Hier hängen die meisten Rollouts. Wenn Inferenz in den USA läuft, liegt eine Übermittlung in ein Drittland vor. Das EU-US Data Privacy Framework deckt das aktuell, aber das Framework ist angegriffen. Die Klage Latombe gegen die Kommission ist seit dem 31. Oktober 2025 als Rechtsmittel beim Europäischen Gerichtshof anhängig (C-703/25 P), nachdem das Gericht die Klage am 3. September 2025 abgewiesen hatte. Ein Urteil liegt bislang nicht vor; das Risiko, dass das DPF kippt, hat die Praxis aber längst eingepreist. Viele Häuser im öffentlichen Sektor und in regulierten Branchen akzeptieren das DPF schon heute nicht als ausreichend. Genau hier entscheidet die Architektur über den Termin.
Vier Architekturentscheidungen für den DPO-Termin
Die DSGVO ist hier nicht das eigentliche Problem. Das eigentliche Problem sind Default-Einstellungen, die fünf Jahre alt sind und die niemand bewusst getroffen hat. Vier Entscheidungen ändern das.
Erstens: EU-Inferenz bewusst konfigurieren. Wer Prompt- und Kontextdaten nicht in Drittstaaten verarbeiten lassen will, muss die Inferenzregion aktiv prüfen. Für die direkte Anthropic-API sind nach Anthropic-Dokumentation derzeit nur us und global als Inference Geo verfügbar. Wer EU-Inferenz braucht, landet praktisch bei Provider-Integrationen: AWS Bedrock mit Claude in mehreren europäischen Regionen, je nach Modellverfügbarkeit, oder Google Vertex AI in europe-west1 (Belgien) und europe-west3 (Frankfurt). Claude Code ist genau für diese Wahl gebaut: CLAUDE_CODE_USE_BEDROCK=1 mit gesetztem AWS_REGION, oder CLAUDE_CODE_USE_VERTEX=1 mit CLOUD_ML_REGION=europe-west1. GitHub bietet seit April 2026 eine eigene Copilot Data Residency für US- und EU-Regionen an, opt-in auf Enterprise-Ebene. Bevor das im Verzeichnis als „EU-only" eingetragen wird: Enterprise-Kunden sollten prüfen, welche Copilot-Funktionen, Datenarten und Subprozessoren vom jeweiligen Data-Residency-Scope tatsächlich erfasst sind. Je nach Provider und Region stehen nicht immer dieselben Claude-Modelle zur Verfügung. Wer EU-Residenz verlangt, prüft die Modellmatrix im konkreten Deployment und akzeptiert unter Umständen eine andere Modellgeneration als im globalen Endpoint. Diese Entscheidung ist Konfiguration, keine Tool-Wahl.
Zweitens: Trainingsausschluss, vertraglich. Die Anthropic Commercial Terms (Stand 17. Juni 2025) enthalten in Abschnitt B den Satz, der den größten praktischen Einwand entkräftet: „Anthropic may not train models on Customer Content from Services." Für Copilot Business und Enterprise gilt derselbe Ausschluss. Ein Hinweis lohnt sich: Seit dem 24. April 2026 ist für die Konsumenten-Pläne von GitHub Copilot (Free, Pro, Pro+) Training auf Nutzerinteraktionen standardmäßig aktiviert, mit Opt-out. Business und Enterprise sind davon nicht betroffen. Aber jeder Entwickler, der morgens privat Pro nutzt und nachmittags in Ihrer Codebasis arbeitet, sitzt jetzt zwischen zwei Welten. Eine Nutzungsrichtlinie regelt das in zwei Sätzen.
Drittens: MCP-Server-Allowlist. Das Model Context Protocol macht aus „der Agent sieht Code" sehr schnell „der Agent ruft Tools auf und stellt Queries gegen Systeme, die niemand bewusst freigegeben hat". Red Hats Analyse vom Juli 2025 hat die MCP-Angriffsfläche systematisch dokumentiert: Prompt-Injection über Tool-Beschreibungen, Tool-Poisoning, stille Redefinitionen genehmigter Tools, Cross-Server-Shadowing, Lieferketten-Risiken in Server-Paketen. Eine zentral verwaltete Allowlist zugelassener Server ist kein Nice-to-have. Sie ist das, was bei Art. 32 als „angemessene technische Maßnahme" eintragbar ist.
Viertens: Least Privilege, auch für den Agent. Der Agent erbt die Rechte des ausführenden Entwicklers. Kein Service-Account mit Produktionszugriff für „schnelles Debugging". Keine Anmeldedaten, die der Agent durch Verzeichnislistung zufällig in den Kontext zieht. Keine Sandbox, die in Wahrheit der gleiche Container wie die Build-Umgebung ist. Diese Punkte gelten auch ohne KI. Mit Coding Agents werden sie audit-relevant.
Diese vier Entscheidungen verlangen keine neue Rechtslage und kein KI-spezialisiertes Rechtsteam. Sie verlangen bewusste Architektur, klare Zuständigkeiten und in der Regel eine Enterprise-Konfiguration.
Was wirklich auf die Tagesordnung gehört
Wer den Termin mit dem Datenschutzbeauftragten gut nutzen will, geht nicht mit „wir hätten gerne Claude Code" hinein. Sie gehen mit einer Beschreibung hinein, welche Daten fließen.
Welche Daten verarbeitet der Agent? Prompts, Code-Suggestions, Telemetrie. An welcher Stelle könnte Personenbezug auftauchen, also Testdaten, Commit-Metadaten, Debug-Logs, Live-DB-Sessions? Welche Architekturentscheidung trifft das Team: EU-Inferenz über welchen Anbieter, mit welchem AVV-Stand, mit welcher Trainingsausschluss-Klausel? Welche MCP-Server stehen auf der Allowlist, wer verwaltet sie?
Daraus ergibt sich ein Vorschlag für den Eintrag im Verzeichnis der Verarbeitungstätigkeiten. Und die Frage, ob eine DSFA durchgeführt wird. Spätestens hier ist eine Nutzungsrichtlinie hilfreich, die festlegt, welche Daten nicht in Prompts gehören (Produktionsdatensätze, besondere Kategorien nach Art. 9, Klartextdaten zu Kunden).
Der Hinweis auf den Betriebsrat gehört ans Ende. Nicht, weil er weniger wichtig ist, sondern weil er eine eigene Gesprächsspur ist. Der Datenschutzbeauftragte verhandelt nicht die Mitbestimmung. Aber er erinnert das Team in der Regel daran, dass die Spur existiert.
Die Abstimmung verhandelt dann nicht mehr „DSGVO ja oder nein", sondern „diese Architektur, diese Prozesse, diese Kontrollen, passt das zu unserem Schutzniveau?". Das ist die Konversation, in der ein Engineering Lead gewinnen kann. Wer in regulierten Branchen arbeitet und parallel BaFin- und MaRisk-Themen klären muss, findet im Beitrag zu BaFin und MaRisk die ergänzende Spur.
Was die Aufsicht bisher nicht getan hat
Eine Beobachtung, die in den DSGVO-Gesprächen meistens fehlt: Seit den ersten Coding-Agent-Pilotierungen in deutschen Unternehmen, also Cursor 2024 und breite Claude-Code- und Copilot-Einführungen 2025, ist mir bislang keine öffentliche deutsche Aufsichtsentscheidung bekannt, die namentlich Cursor, Claude Code oder GitHub Copilot als Coding-Agent-Rollout beanstandet. Der 33. Tätigkeitsbericht der BfDI für 2024 behandelt KI-Aufsicht strukturell, nicht namentlich. Die DSK hat zur Mai-2024-Orientierungshilfe bisher keine Coding-Agent-Aktualisierung nachgereicht. Italienische Garante-Verfahren betreffen ChatGPT und DeepSeek, nicht Coding-Werkzeuge.
Das ist kein Persilschein. Das Fehlen einer öffentlichen Beanstandung ist ein schwacher Datenpunkt, kein Freibrief, und Aufsichtsbehörden sortieren ihre Fragen ohnehin anders als manche Compliance-Folie unterstellt. Es spricht aber gegen die These, Coding Agents seien als Kategorie bereits aufsichtsrechtlich verbrannt. Im DPO-Gespräch ist das ein Beruhigungsmoment, mehr nicht.
Unter dem Strich
Die DSGVO verbietet Coding Agents nicht. Sie verlangt Datenflussanalyse, Architektur und Dokumentation. Die Hälfte dieser Arbeit steckt meist schon in bestehenden Verfahren: AVV-Prüfung, Verzeichnis, Berechtigungskonzept, TOMs und Betriebsratsprozess. Wer die Arbeit vorne macht, also vor dem Rollout, mit dem DPO an einem Tisch, bekommt ein produktives Werkzeug. Wer sie hinten macht, nach dem ersten Audit, unter Zeitdruck, bekommt eine Krise. Tools sind nicht DSGVO-konform; Deployments sind es.
Wenn Sie den DPO-Termin nicht alleine vorbereiten wollen: In 60 Minuten klären wir Datenflüsse, Inferenzregion, AVV-Stand, MCP-Zugriffe und die Vorlage für den DPO-Termin. Sprechen Sie mich an
Quellen
- Datenschutzkonferenz: Orientierungshilfe „Künstliche Intelligenz und Datenschutz" vom 6. Mai 2024
- Datenschutzkonferenz: TOM-Orientierungshilfe für Entwicklung und Betrieb von KI-Systemen, Juni 2025
- Datenschutzkonferenz: Kurzpapier Nr. 14 zum Beschäftigtendatenschutz
- Anthropic: Privacy Center · Data Processing Addendum
- Anthropic: Commercial Terms, Stand 17. Juni 2025
- Anthropic: Data Residency Documentation
- GitHub: Copilot Trust Center
- GitHub Blog: Copilot Data Residency in US, EU und FedRAMP, 13. April 2026
- GitHub Blog: Privacy Statement Update, 25. März 2026
- EuG, Urteil T-553/23 Latombe gegen Kommission, 3. September 2025
- EuGH, Rechtsmittel C-703/25 P Latombe gegen Kommission, eingelegt 31. Oktober 2025
- BAG, Beschluss 1 ABR 16/23 vom 16. Juli 2024 (objektive Eignung)
- Red Hat: Model Context Protocol · Security Risks and Controls
- Bitkom: Künstliche Intelligenz und Datenschutz · Praxisleitfaden, Auflage 2.0, August 2025
