ChatGPT DSGVO-konform nutzen: die fünf Schritte

Die Frage ist so gestellt nicht beantwortbar, und das liegt nicht am Anbieter: Die DSGVO bewertet keine Produkte, sondern Verarbeitungsvorgänge. Ein Werkzeug kann deshalb weder „DSGVO-konform“ noch „nicht DSGVO-konform“ sein. Konform ist immer nur das, was eine bestimmte Stelle zu einem bestimmten Zweck mit bestimmten Daten tut.

Verantwortlicher im Sinne von Art. 4 Nr. 7 DSGVO sind Sie: Sie bestimmen Zweck und Mittel, wenn Sie ein Ticket, eine Bewerbung oder einen Vertragsentwurf in ein Modell geben. Der Anbieter ist Auftragsverarbeiter, und ein Auftragsverarbeiter kann Ihnen die Verantwortung nicht abnehmen. Rechtsgrundlage, Zweckbindung, Datenminimierung und Betroffenenrechte müssen Sie deshalb selbst beantworten, unabhängig davon, wie sicher der Dienst betrieben wird.

Vier der fünf Schritte hängen an Bedingungen, die ein Anbieter jederzeit ändern kann; der fünfte hängt an Ihrem eigenen System. Die allgemeinen Kriterien für den DSGVO-konformen Einsatz von KI gelten für jeden Anbieter gleichermaßen, dieser Leitfaden führt sie für den konkreten Fall ChatGPT aus.

Zu keiner Frage kursieren so viele veraltete Antworten. Tarifstrukturen, Aufbewahrungsfristen und Trainingsklauseln ändern sich mehrfach im Jahr; was im letzten Quartal in einem Blogbeitrag stand, kann heute falsch sein. Wir nennen deshalb keine Zusagen eines Anbieters, sondern die Punkte, die Sie in der jeweils aktuellen Fassung der Bedingungen selbst nachlesen und mit Datum festhalten müssen.

Zwei Muster tauchen bei fast jeder Prüfung auf. Anbieter behandeln Zugänge für Privatpersonen und Angebote für Unternehmen oder über die Programmierschnittstelle regelmäßig unterschiedlich; jede der obigen Antworten kann je nach Zugang anders ausfallen. Und der Weg neben dem offiziellen Zugang gerät aus dem Blick: Browser-Erweiterungen, Integrationen in Textverarbeitung und Chat-Werkzeuge, schlicht die Zwischenablage. Eine Freigabe, die nur einen Zugang regelt, ist eine halbe Freigabe.

Sobald personenbezogene Daten an eine Stelle außerhalb des Europäischen Wirtschaftsraums übermittelt werden oder von dort zugänglich sind, greift Kapitel V der DSGVO: Die Übermittlung braucht dann zusätzlich zur Rechtsgrundlage nach Art. 6 eine eigene Übermittlungsgrundlage. Drei Wege kommen praktisch in Betracht.

• Angemessenheitsbeschluss (Art. 45 DSGVO): Die Kommission hat für das Zielland ein angemessenes Schutzniveau festgestellt. Für die Vereinigten Staaten besteht ein solcher Beschluss derzeit auf Grundlage des EU-US Data Privacy Framework; er wirkt nur für dafür zertifizierte Unternehmen. Prüfen Sie zum Zeitpunkt Ihrer Bewertung dreierlei: ob der Beschluss fortbesteht, ob der Anbieter in der offiziellen Liste geführt wird und ob die Zertifizierung den genutzten Dienst abdeckt.
• Standardvertragsklauseln (Art. 46 DSGVO): Sie werden dem Vertrag beigefügt. Nach der Schrems-II-Rechtsprechung genügt das allein nicht; hinzu kommt eine Bewertung der Rechtslage im Zielland und, wo nötig, zusätzliche Schutzmaßnahmen. Diese Bewertung, das Transfer Impact Assessment, müssen Sie dokumentieren.
• Ausnahmen (Art. 49 DSGVO): Einwilligung, Vertragserfüllung und die übrigen Tatbestände sind eng auszulegen und für einen laufenden Verarbeitungsvorgang keine tragfähige Grundlage.

Zwei Punkte werden häufig übersehen. Ein Angemessenheitsbeschluss ist kein Dauerzustand: Frühere Beschlüsse wurden gerichtlich für ungültig erklärt; wer sich darauf stützt, sollte den Bestand kontrollieren und einen Ersatzweg bedacht haben. Und ein europäisches Rechenzentrum bedeutet nicht, dass kein Zugriff aus einem Drittland möglich ist; Support, Betrieb und Störungsanalyse sind eigene Fragen, die im AV-Vertrag beantwortet sein müssen.

Der fünfte Schritt wirkt hier bereits mit: Enthält der übermittelte Text keine Klarnamen, Adressen und Kontonummern mehr, verschiebt das die Risikobewertung im Transfer Impact Assessment spürbar. Die Übermittlung entfällt dadurch nicht, aber das, was im Fall eines Zugriffs offenläge, ist ein anderes.

Ein Vertrag, den eine Privatperson für private Zwecke geschlossen hat, trägt keine unternehmerische Verarbeitung. Halten Sie in Ihrer Dokumentation deshalb keine Tarifnamen fest, sondern die Eigenschaften, die der Zugang erfüllen muss:

• Vertragspartner ist Ihr Unternehmen, nicht die einzelne Person. Nur dann können Sie Weisungen erteilen, Rechte durchsetzen und Zugänge entziehen.
• Für diesen Zugang wird ein AV-Vertrag angeboten. Andernfalls scheidet er für personenbezogene Daten aus, unabhängig davon, wie gut das Modell ist.
• Die Bedingungen dieses Zugangs regeln die Nutzung von Eingaben ausdrücklich. Ein Hilfeartikel oder eine Marketingaussage ist keine vertragliche Zusage.
• Es gibt eine zentrale Verwaltung. Zugänge müssen sich anlegen, einheitlich einstellen und beim Ausscheiden sperren lassen.

Privat abgeschlossene Zugänge für den Privatgebrauch erfüllen diese Punkte in der Regel nicht. Das ist der Grund, warum sie für personenbezogene Daten ausscheiden, und nicht ein pauschales Urteil über das Produkt. Zur Dokumentation gehört, wer den Vertrag wann unter welcher Fassung der Bedingungen geschlossen hat, samt gespeicherter Kopie dieser Fassung. Ohne sie können Sie später nicht belegen, worauf Sie sich verlassen haben.

Parallel dazu brauchen Sie eine schriftliche Richtlinie: welche Zugänge freigegeben sind und welche Daten in keinem Fall in einen Prompt gehören. Ohne Alternative entsteht Schatten-IT: Beschäftigte nutzen dann das private Konto auf dem eigenen Telefon, und Sie erfahren davon im Zweifel erst im Rahmen einer Meldung nach Art. 33 DSGVO.

Ziel dieses Schritts ist ein nachweisbarer Zustand: Ihre Eingaben werden nicht zur Verbesserung oder zum Training von Modellen des Anbieters verwendet. Wie er hergestellt wird, ist zweitrangig: Entweder folgt er bereits aus den Bedingungen des genutzten Zugangs, oder er muss über eine Einstellung aktiv herbeigeführt werden. Beides ist zulässig, beides muss belegt sein.

Zum Nachweis gehören vier Angaben:

• Die Fundstelle: Klausel oder Bezeichnung der Einstellung, im Wortlaut zitiert und mit Prüfdatum versehen.
• Der Geltungsbereich: Gilt der Zustand organisationsweit oder je Zugang? Neu angelegte Zugänge sind der häufigste Fehler.
• Ein Beleg: datierter Bildschirmabzug oder Auszug aus der Verwaltungsoberfläche, abgelegt bei den Datenschutzunterlagen.
• Eine Wiedervorlage: Produktänderungen können Einstellungen zurücksetzen oder neue hinzufügen. Ein fester Prüftermin verhindert, dass der Nachweis stillschweigend veraltet.

Zwei Missverständnisse sind hartnäckig. „Kein Training“ bedeutet nicht „keine Speicherung“; die Aufbewahrung zur Missbrauchserkennung ist eine getrennte Frage mit eigener Frist. Und eine Abschaltung wirkt typischerweise nur nach vorne; wer sie erst nach Monaten der Nutzung setzt, sollte den vorherigen Zeitraum gesondert bewerten.

Sobald ein Anbieter personenbezogene Daten für Sie verarbeitet, verlangt Art. 28 Abs. 3 DSGVO einen Vertrag mit festgelegten Mindestinhalten: Gegenstand, Dauer, Art und Zweck der Verarbeitung, Kategorien betroffener Personen und Daten, dazu Weisungsbindung, Vertraulichkeit, technische und organisatorische Maßnahmen, Regeln für Unterauftragsverarbeiter, Unterstützung bei Betroffenenrechten sowie Rückgabe oder Löschung am Ende. Was im Einzelnen zu prüfen ist, behandelt die Seite zum AV-Vertrag für KI-Dienste ausführlich.

Bei Sprachmodellen sind drei Punkte besonders zu beachten. An der Trainingsfrage hängt die Rollenverteilung selbst: Nutzt ein Anbieter Ihre Eingaben für eigene Zwecke, handelt er insoweit nicht mehr weisungsgebunden, sondern als eigener Verantwortlicher; die Klausel aus Schritt 2 hält die Auftragsverarbeitung überhaupt erst zusammen. Die Liste der Unterauftragsverarbeiter ist bei Modellanbietern selten kurz und selten stabil; Änderungen sind Ihnen anzuzeigen, und Sie können widersprechen. Und Weisungen sollten praktisch erteilbar sein, nicht nur auf dem Papier stehen.

Wichtig für den weiteren Verlauf: Der AV-Vertrag bleibt auch dann erforderlich, wenn Sie nur pseudonymisierte Texte übermitteln, denn pseudonymisierte Daten bleiben personenbezogene Daten. Für Persona gilt dasselbe; ein AV-Vertrag nach Art. 28 DSGVO ist ab dem Pro-Tarif Bestandteil des Vertrags.

Der Einsatz eines Sprachmodells ist kein Werkzeugkauf, sondern eine Verarbeitungstätigkeit. Sie gehört nach Art. 30 DSGVO ins Verzeichnis, mit denselben Angaben wie jede andere: Zwecke, Kategorien betroffener Personen und Daten, Empfänger, Übermittlungen in Drittländer samt Garantien, Löschfristen und eine allgemeine Beschreibung der technischen und organisatorischen Maßnahmen.

Vier Ergänzungen sind bei KI-Verarbeitungen erfahrungsgemäß nötig:

• Zweck präzise fassen. „KI-Nutzung“ ist kein Zweck. „Entwurf von Antworten auf Kundenanfragen im Support“ ist einer, und er begrenzt zugleich, was übermittelt wird.
• Die Übermittlungsgrundlage benennen und die Bewertung aus Schritt 3 als Anlage beifügen, statt sie nur zu behaupten.
• Die Schwelle für eine Datenschutz-Folgenabschätzung prüfen. Art. 35 DSGVO verlangt sie bei voraussichtlich hohem Risiko; Anhaltspunkte sind neue Technologien, umfangreiche Verarbeitung, Datenkategorien nach Art. 9 oder systematische Bewertungen von Personen. Auch ein begründetes Nein gehört dokumentiert.
• Die Pseudonymisierung als Maßnahme eintragen. Art. 32 Abs. 1 lit. a DSGVO nennt sie ausdrücklich; sie gehört in den TOM-Abschnitt, zusammen mit der Angabe, wo das Zuordnungsmapping liegt und wer darauf zugreifen kann.

Vergessen Sie die Informationspflichten nicht: Gehen Kundendaten an einen Modellanbieter, ist das nach Art. 13 Abs. 1 lit. e DSGVO eine Empfängerkategorie, über die zu informieren ist; bei einem Drittlandtransfer kommt lit. f hinzu. Beides gehört in die Datenschutzerklärung, bevor die erste Anfrage abgeht.

Die ersten vier Schritte regeln das Verhältnis zum Anbieter. Der fünfte regelt, was ihn überhaupt erreicht, und ihn kann keine Änderung fremder Bedingungen aushebeln. Die Überlegung dahinter ist schlicht: Ein Modell braucht die Struktur eines Textes, um eine brauchbare Antwort zu formulieren, aber weder einen Klarnamen noch eine Kontonummer.

Von Hand funktioniert das nicht zuverlässig. Wer unter Zeitdruck ein Ticket bereinigt, übersieht die Signatur, die Kopfzeile des weitergeleiteten Verlaufs oder die Kontonummer im Zitat. Identifizierend sind ohnehin selten die Namen allein: Kundennummer, Postleitzahl und Vorgangsdatum tragen den Personenbezug mit. Vor allem aber zerstört manuelles Ersetzen die Bezüge: Wird aus zwei Beteiligten zweimal „der Kunde“, kann das Modell die Rollen nicht mehr auseinanderhalten.

Ein automatisierter Schritt löst genau diese drei Probleme. Persona nimmt über POST /v1/pseudonymize einen Text entgegen und liefert den maskierten Text, die zeichengenauen Fundstellen, das Mapping von Pseudonym zu Klarwert und einen Sensitivitätswert für den Gesamttext. Die Pseudonyme sind innerhalb eines Textes konsistent: Dieselbe Person behält dasselbe Kennzeichen, eine zweite bekommt ein eigenes. Erkannt wird kontextbasiert und mehrsprachig statt über reguläre Ausdrücke; Grundlage ist das offen lizenzierte Modell perplexity-ai/pplx-pii-masking unter MIT-Lizenz. Abgedeckt sind neun Kategorien: Personen, E-Mail-Adressen, Telefonnummern, Adressen, persönliche Links, Datumsangaben, Kontonummern, Geheimnisse und sonstige personenbezogene Angaben.

Nach der Modellantwort setzt POST /v1/reidentify mit demselben Mapping die Klarwerte wieder ein. Beide Endpunkte sprechen JSON in UTF-8 und werden mit einem API-Schlüssel als Bearer-Token aufgerufen; die Felder stehen in der API-Referenz. Die Analyse läuft auf dedizierten Servern bei Hetzner in Falkenstein in nach ISO 27001 zertifizierten Rechenzentren, ohne dass ein externer KI-Dienst aufgerufen wird; übermittelte Texte werden nicht gespeichert, nicht als Inhalt protokolliert und nicht für Training verwendet. Mit rund 45 ms im Median fällt der Schritt im Ablauf nicht auf. Wo auch das zu viel ist, lässt sich Persona im Enterprise-Tarif als Container in der eigenen Umgebung betreiben; das Modell arbeitet auch auf CPU ausreichend schnell.

Wer den Effekt zuerst an eigenem Text sehen möchte, ohne etwas anzubinden: Das Werkzeug zum Anonymisieren von Text zeigt den Ersetzungsschritt direkt im Browser.

Der Ablauf lässt sich in vier Zuständen zeigen. Ausgangspunkt ist ein Ticket, wie es hundertfach im Postfach liegt.

Das Mapping bleibt in Ihrem System. Es sind die zusätzlichen Informationen, mit denen sich der Personenbezug wiederherstellen lässt und die nach Art. 4 Nr. 5 DSGVO gesondert aufzubewahren und zu schützen sind:

{
  "⟨PERSON_1⟩":  "Miriam Hartmann",
  "⟨DATE_1⟩":    "03.09.2026",
  "⟨ACCOUNT_1⟩": "DE44 5001 0517 0032 1654 88",
  "⟨ACCOUNT_2⟩": "88-402-115",
  "⟨PHONE_1⟩":   "0170 2288341",
  "⟨EMAIL_1⟩":   "m.hartmann@beispiel-mail.de",
  "⟨ADDRESS_1⟩": "Ahornweg 14, 30159 Hannover"
}

Vier Beobachtungen lohnen sich an diesem Durchlauf.

Die Antwort ist vollständig, obwohl das Modell nichts wusste

Der Entwurf nennt Kundennummer, Datum und Konto an der richtigen Stelle, weil die Pseudonyme im gesamten Text stabil bleiben. Das Modell hat den Vorgang bearbeitet, ohne je einen Namen, eine Adresse oder eine Kontoverbindung gesehen zu haben.

Die Anrede ist die auffälligste Stelle

Aus ⟨PERSON_1⟩ lässt sich keine Anredeform ableiten, das Modell schreibt daher eine neutrale Begrüßung. Wer „Sehr geehrte Frau …“ braucht, setzt die Anrede im eigenen System aus den Stammdaten ein, statt sie das Modell raten zu lassen.

Die Rechnungsnummer bleibt stehen

Sie ist eine Vorgangsreferenz und ohne Ihre Systeme niemandem zuzuordnen; genau deshalb kann das Modell konkret antworten. Ob eine solche Nummer in Ihrem Bestand identifizierend wirkt, ist eine Frage des Kontexts; wenn ja, definieren Sie sie als eigene Kategorie. Im Enterprise-Tarif sind eigene Kategorien und Fine-Tuning auf Ihre Dokumenttypen möglich.

Prüfen Sie die Antwort auf verbliebene Platzhalter

Die Re-Identifikation ersetzt Zeichenketten: Formt ein Modell ein Pseudonym um, findet es keine Entsprechung mehr im Mapping. Ein Test auf verbliebene spitze Klammern vor dem Versand kostet nichts und erspart Ihnen einen stehen gebliebenen Platzhalter im fertigen Anschreiben.

Pseudonymisierung ist eine technische und organisatorische Maßnahme, keine Befreiung von den Pflichten der DSGVO. Der Ausgangspunkt dafür steht im Erwägungsgrund 26:

Pseudonymisierte Daten bleiben also personenbezogene Daten. Der Unterschied zur Anonymisierung, bei der es keinen Weg zurück gibt, ist grundlegend und in der Praxis oft verwischt; die Seite zu Pseudonymisierung und Anonymisierung arbeitet ihn im Detail heraus. Für den Einsatz von ChatGPT heißt das:

Der letzte Punkt verdient eine eigene Zeile. Erkennungsverfahren arbeiten mit Wahrscheinlichkeiten, nicht mit Gewissheiten. Bei besonders sensiblen Beständen — Gesundheits- und Bewerberdaten, Personalakten, anwaltlicher Schriftverkehr — bleibt eine Kontrolle des maskierten Textes sinnvoll. Der Sensitivitätswert, den die API pro Text zurückgibt, taugt dafür als Weiche: Oberhalb einer selbst gesetzten Schwelle geht ein Text zur Sichtprüfung oder gar nicht erst an einen externen Dienst.

Zum Mitnehmen: Jede Zeile beschreibt, was am Ende nachweisbar vorliegen muss, und wo der Nachweis abgelegt gehört.

Die ersten sieben Zeilen sind Vertrags- und Dokumentationsarbeit; sie muss einmal gemacht und dann gepflegt werden. Die achte ist technische Arbeit und die einzige, die unabhängig davon wirkt, was ein Anbieter morgen in seinen Bedingungen ändert. Wer nur eine Zeile umsetzen kann, fängt mit dieser an.