Für Entwicklungsteams in der EU werfen KI-Coding-Tools eine Frage auf, die sich bequem verdrängen lässt, bis sie plötzlich dringend wird: Was passiert mit personenbezogenen Daten, wenn sie in einem Prompt landen?
Sie landen dort öfter, als man im Team annimmt. Ein Stacktrace mit der E-Mail eines Nutzers. Eine Test-Fixture, gebaut aus einem echten Kundendatensatz. Eine Datenbankzeile, die man kurz einfügt, um eine Query zu debuggen. Nichts davon fühlt sich nach „Verarbeitung personenbezogener Daten“ an. Aber nach der DSGVO ist es genau das, und das Tool am anderen Ende des Prompts ist damit Teil Ihres Datenflusses.
Das ist kein Grund, KI-Tools zu verbieten. Es ist ein Grund, sie wie jedes andere System zu behandeln, das mit personenbezogenen Daten in Berührung kommt: zu wissen, was hineingeht, zu wissen, wer es verarbeitet, und die Unterlagen zu haben, die das Ganze rechtmäßig machen. Wir helfen Entwicklungsteams, genau das aufzusetzen, ohne ein Projekt daraus zu machen, das die Arbeit lahmlegt. Worauf es ankommt:
Dieser Artikel ist eine praxisnahe Entwicklersicht, keine Rechtsberatung. Die endgültige Bewertung für Ihre Organisation liegt bei Ihrem Datenschutzbeauftragten oder Ihrer Rechtsabteilung.
Die Kernpflicht, einfach gesagt
Die DSGVO regelt personenbezogene Daten, also alles, womit sich eine Person direkt oder indirekt identifizieren lässt. Sobald ein Entwickler solche Daten in ein KI-Tool eingibt, gelten drei Dinge auf einmal.
| Pflicht | Was sie für KI-Tools bedeutet | Wo Teams ins Straucheln geraten |
|---|---|---|
| Rechtsgrundlage und Zweck | Sie brauchen einen Grund, diese Daten zu verarbeiten, und die Tool-Nutzung muss dazu passen | Debugging mit echten Kundendaten hat keine saubere Grundlage |
| Auftragsverarbeitung | Der Tool-Anbieter verarbeitet Daten in Ihrem Auftrag, Sie brauchen also einen AVV | Entwickler nutzen Tools, mit denen das Unternehmen nie einen Vertrag geschlossen hat |
| Datenminimierung | Verarbeitet werden sollte nur, was Sie tatsächlich brauchen | Ganze Datensätze eingefügt, wo ein geschwärzter Ausschnitt gereicht hätte |
Der typische Fehler entspringt keiner bösen Absicht. Es ist der Entwickler mitten im Debugging, der zum schnellsten Weg greift, in ein Tool, das nie dafür geprüft wurde.
Personenbezogene Daten standardmäßig aus Prompts heraushalten
Die sauberste Compliance-Haltung ist die, bei der personenbezogene Daten das Tool gar nicht erst erreichen. Die meiste Debugging- und Coding-Arbeit braucht keine echten Kundendaten. Sie braucht Daten, die so aussehen wie echte.
- Setzen Sie auf synthetische oder anonymisierte Fixtures. Ein Testdatensatz, der echt wirkt, aber niemanden identifiziert, ist DSGVO-rechtlich unkritisch.
- Schwärzen Sie, bevor Sie einfügen. Entfernen Sie E-Mails, Namen, IDs und Tokens aus Logs und Traces, bevor sie in einen Prompt wandern. Besser noch: bereinigen Sie sie schon auf der Logging-Ebene, damit sie gar nicht erst da sind, um kopiert zu werden.
- Maskieren Sie im Tooling, nicht im Kopf. Eine Regel, die darauf baut, dass eine müde Person ans Schwärzen denkt, wird scheitern. Pre-Commit- und Log-Scrubbing-Tooling, das es automatisch erledigt, nicht.
Das ist Datenminimierung direkt am Ort der Nutzung, und die Kontrolle mit der größten Hebelwirkung überhaupt. Daten, die nie in den Prompt gelangen, erzeugen keine Übermittlung, keine Speicherung und kein Auftragsverarbeiter-Risiko, das man dann managen müsste.
Wenn personenbezogene Daten verarbeitet werden müssen: die Unterlagen in Ordnung bringen
Manchmal verlangt die Arbeit es tatsächlich. Und dann muss das Verhältnis zum Anbieter rechtmäßig sein. Hier treffen Tool-Auswahl und Compliance aufeinander, und deshalb gehört die Vertrauensebene an den Anfang der Tool-Wahl.
- Auftragsverarbeitungsvertrag. Der Anbieter ist Ihr Auftragsverarbeiter nach Artikel 28. Sie brauchen einen AVV, der festlegt, was er mit den Daten tun darf. Kein AVV, keine personenbezogenen Daten im Tool.
- Drittlandübermittlungen. Findet die Verarbeitung außerhalb der EU statt, brauchen Sie einen gültigen Übermittlungsmechanismus, etwa Standardvertragsklauseln. Klären Sie, wo das Tool die Daten verarbeitet, bevor Sie sich darauf verlassen.
- Speicherung und Training. Lassen Sie sich schriftlich bestätigen, ob Prompts gespeichert werden und ob Ihre Daten in das Training der Modelle einfließen. „Zum Training verwendet“ verträgt sich in der Regel weder mit Ihren Pflichten noch mit den Erwartungen Ihrer Kunden.
- Unterauftragsverarbeiter. Verschaffen Sie sich Klarheit darüber, wer sonst noch in der Kette steht. Die Auftragsverarbeiter Ihres Auftragsverarbeiters bleiben Ihr Risiko.
Ein Tool, das keinen AVV anbieten kann oder Ihnen nicht sagen kann, wo es die Daten verarbeitet, ist kein Tool, in das Sie personenbezogene Daten geben dürfen, ganz gleich, wie gut es Code schreibt.
An die Richtlinie koppeln, nicht an eine einmalige Prüfung
Compliance, die darauf baut, dass jeder Entwickler jedes Mal die richtige Entscheidung trifft, versagt im ungünstigsten Moment. Sie muss in die Regeln eingebaut sein, denen die Entwickler ohnehin folgen. Ihre KI-Nutzungsrichtlinie ist der richtige Ort dafür.
- Die Datenstufe „Eingeschränkt“, also Secrets und Kunden-PII, ist exakt die DSGVO-Grenze. Die Regel „nie in einen Prompt einfügen“ erledigt damit gleich zwei Aufgaben auf einmal.
- Die Liste freigegebener Tools ist Ihre auf AVV und Übermittlung geprüfte Liste. Ein Tool ist für personenbezogene Daten erst freigegeben, wenn die Unterlagen vorliegen.
- Der Eskalationspfad sagt einem Entwickler, an wen er sich wenden kann, wenn er unsicher ist, ob etwas als personenbezogen gilt, und zwar bevor er es einfügt, nicht danach.
Compliance, die im Workflow lebt, wird befolgt. Compliance, die in einem Schulungsdeck steht, wird genau dann vergessen, wenn es darauf ankommt.
Die eigene Begründung belegen können
Bei der DSGVO geht es zum Teil um Rechenschaft: darlegen zu können, dass man sich Gedanken gemacht und Kontrollen eingerichtet hat. Für KI-Tools heißt das ein kurzer, belastbarer Nachweis: welche Tools für welche Daten freigegeben sind, welche AVVs Sie geschlossen haben, wo verarbeitet wird und welche Kontrollen eingeschränkte Daten aus Prompts heraushalten.
Das muss nicht aufwendig sein. Es muss existieren, aktuell sein und den tatsächlichen Stand widerspiegeln, damit die Antwort ein Dokument ist und kein Achselzucken, wenn eine Aufsichtsbehörde, ein Kunde oder Ihr eigener Datenschutzbeauftragter nachfragt. Es ist dieselbe Nachweis-Disziplin, die auch den EU AI Act handhabbar statt beängstigend macht.
Unsere Sicht
DSGVO-Risiken aus KI-Coding-Tools sind selten exotisch. Dahinter stecken gewöhnliche personenbezogene Daten, gewöhnliches Debugging und eine gewöhnliche Lücke zwischen dem, was Entwickler tun, und dem, was die Organisation bewertet hat. Die Lösung ist genauso gewöhnlich, und gerade deshalb wird sie so oft übergangen, bis ein Vorfall sie erzwingt.
Halten Sie personenbezogene Daten standardmäßig aus Prompts heraus, über anonymisierte Fixtures und automatisches Schwärzen, dann entsteht der Großteil des Risikos gar nicht erst. Wenn die Arbeit personenbezogene Daten wirklich braucht, sorgen Sie dafür, dass das Tool ein vertraglich gebundener Auftragsverarbeiter ist: mit AVV, bekanntem Verarbeitungsort und ohne Training auf Ihren Daten. Verankern Sie all das in der Richtlinie und den Tools, die Entwickler ohnehin nutzen, und führen Sie einen schlanken Nachweis, der Ihre Begründung belegt.
So angegangen, ist die DSGVO kein Blocker für die KI-Einführung. Sie ist die Disziplin, die Ihnen erlaubt, mit Zuversicht einzuführen, im Wissen, dass die wichtigsten Daten das Haus nie verlassen haben.
Quellen
- EU-Datenschutz-Grundverordnung, Artikel 5, 28 und 44, abgerufen am 2026-06-10
- Europäischer Datenschutzausschuss, Leitlinien zu internationalen Datenübermittlungen, abgerufen am 2026-06-10
- EU-Verordnung über Künstliche Intelligenz, zu Governance- und Dokumentationspflichten, abgerufen am 2026-06-10
Häufige Fragen
- Ist das Einfügen eines Stacktraces in ein KI-Coding-Tool eine Verarbeitung personenbezogener Daten nach der DSGVO?
- Ja. Enthält der Stacktrace etwas, womit sich eine Person identifizieren lässt — eine E-Mail-Adresse, eine Nutzer-ID, einen Namen — handelt es sich nach der DSGVO um personenbezogene Daten, sobald sie im Prompt landen. Der Tool-Anbieter wird damit zu einem Auftragsverarbeiter, der diese Daten in Ihrem Auftrag verarbeitet. Das löst AVV- und Übermittlungspflichten aus, unabhängig davon, ob der Vorgang intern als 'Debugging' und nicht als Datenverarbeitung eingestuft wird.
- Welche Unterlagen brauche ich, bevor personenbezogene Daten in ein KI-Tool eingegeben werden dürfen?
- Mindestens einen unterzeichneten Auftragsverarbeitungsvertrag (Artikel 28) mit dem Anbieter, der regelt, was er mit den Daten tun darf. Findet die Verarbeitung außerhalb der EU statt, benötigen Sie zusätzlich einen gültigen Übermittlungsmechanismus, etwa Standardvertragsklauseln. Außerdem sollten Sie schriftlich bestätigen lassen, dass Prompts nicht für das Modelltraining genutzt werden, und die Unterauftragsverarbeiter des Anbieters kennen.
- Wie lässt sich automatisch verhindern, dass Entwickler versehentlich Kundendaten in Prompts einfügen?
- Der Artikel empfiehlt zwei Kontrollen, die nicht davon abhängen, dass eine müde Person ans Schwärzen denkt: Log-Scrubbing-Tooling direkt auf der Logging-Ebene, damit personenbezogene Daten gar nicht erst vorhanden sind, und Pre-Commit-Hooks, die E-Mails, Namen, IDs und Tokens automatisch entfernen. Synthetische oder anonymisierte Fixtures ersetzen echte Kundendaten für den Großteil der Debugging-Arbeit vollständig und sind DSGVO-rechtlich unkritisch.
- Wie sollte die DSGVO-Anforderung an KI-Tools in einer unternehmensweiten KI-Nutzungsrichtlinie verankert werden?
- Der Artikel platziert sie in der Datenstufe 'Eingeschränkt' — also Secrets und Kunden-PII — die exakt der DSGVO-Grenze entspricht. Die Regel 'nie in einen Prompt einfügen' erfüllt damit gleichzeitig eine DSGVO-Kontrollfunktion. Die Liste freigegebener Tools sollte ausschließlich Anbieter enthalten, deren AVV und Übermittlungssituation geprüft wurden. Ein klar definierter Eskalationspfad stellt sicher, dass Entwickler bei Unsicherheiten vor dem Einfügen nachfragen, nicht danach.
