Die Grundregel: Was ist personenbezogen?
Personenbezogene Daten gehören nicht in externe KI-Systeme – ohne rechtliche Grundlage (Einwilligung, Vertrag, berechtigtes Interesse) ist die Eingabe ein Datenschutzverstoß.
Definition DSGVO Art. 4
Personenbezogene Daten
Alle Informationen, die sich auf eine identifizierte oder identifizierbare natürliche Person beziehen – direkt oder indirekt.
Auch Kombinationen können personenbezogen sein: Alter + Stadt + Beruf kann eine Person eindeutig identifizieren.
Das Problem mit Cloud-KI
Daten verlassen das Unternehmen
Was in externe KI-Dienste eingegeben wird, landet auf Servern des Anbieters – häufig außerhalb der EU.
Viele Anbieter nutzen Prompts für Training wenn keine gesonderte Vereinbarung besteht. Das kann DSGVO-widrig sein.
Was sind personenbezogene Daten? – Beispiele
Eindeutig personenbezogen
Direkte Identifikatoren
Vor- und Nachname, E-Mail-Adresse, Telefonnummer, Privatadresse, Geburtsdatum, Personalausweisnummer, Sozialversicherungsnummer.
Indirekt personenbezogen
Indirekte Identifikatoren
IP-Adressen, Standortdaten, Kennzeichen, Kundennummern, Benutzernamen, Cookies, Gerätekennungen – alles was zur Identifizierung beitragen kann.
Besondere Kategorien
Art. 9 DSGVO – höchste Schutzklasse
Gesundheitsdaten, Gehalt, Gewerkschaftszugehörigkeit, biometrische Daten, religiöse oder politische Überzeugungen, sexuelle Orientierung.
Grauzone
Kontextabhängig
Berufsbezeichnung, Abteilung, Standort – allein oft harmlos, in Kombination mit anderen Daten können sie eine Person identifizierbar machen.
Was darf eingegeben werden?
Nicht alle KI-Nutzung ist datenschutzrechtlich problematisch – diese Eingaben sind unbedenklich:
- Anonymisierte Daten: Alle Personenbezüge entfernt oder durch Platzhalter ersetzt – keine Rückidentifizierung möglich
- Pseudonymisierte Daten: Namen durch IDs ersetzt (Kunde-001, Mitarbeiter-A) – Zuordnungstabelle intern behalten
- Allgemeine technische Konfigurationen: Firewall-Regeln, Server-Configs, Skripte ohne Personenbezug
- Öffentlich zugängliche Informationen: Was bereits veröffentlicht ist, verliert nicht durch KI seinen Schutz – aber Aggregation kann Probleme erzeugen
- Eigene Texte ohne Drittdaten: Entwürfe, interne Konzepte, technische Dokumentation ohne Kundenbezug
- Anonyme Beispielszenarien: „Ein fiktiver Mitarbeiter…" – solange keine reale Person beschrieben wird
Faustregel: Wenn der Text so formuliert ist, dass kein Mensch damit eine reale Person identifizieren könnte – ist er unbedenklich.
Was darf nicht eingegeben werden?
Personenbezogene Geschäftsdaten
Kundendaten, Mitarbeiterdaten
Kundendaten: Namen, E-Mails, Bestellhistorie, Vertragsdetails – selbst für interne Auswertungen gilt DSGVO.
Mitarbeiterdaten: Gehaltsabrechnungen, Krankmeldungen, Beurteilungen, Kontaktdaten.
Patientendaten: Diagnosen, Behandlungsverläufe, Krankenkassendaten – besondere Schutzkategorie.
Zugangsdaten und Secrets
Credentials, Schlüssel, Zertifikate
Passwörter und Hashes: Auch verschlüsselt nicht in externe Dienste eingeben.
API-Keys und Tokens: Auch wenn sie „nur" zur Demonstration gezeigt werden – sofort als kompromittiert behandeln.
Zertifikate und private Schlüssel: Können zur Übernahme von Systemen missbraucht werden.
Interne Geschäftsdaten mit Vertraulichkeitsstufe (intern, vertraulich, geheim) gehören grundsätzlich nicht in externe KI-Systeme – unabhängig vom Personenbezug.
Anonymisierung: So geht es richtig
Namen ersetzen
Platzhalter verwenden
Max Mustermann → Mitarbeiter-A
maria@firma.de → user@example.com
+49 30 12345678 → [TELEFON]
Konsistent bleiben: dieselbe Person immer denselben Platzhalter.
IP-Adressen
Durch Symbole ersetzen
203.0.113.42 → IP-A
198.51.100.7 → IP-B
Zeitstempel dürfen bleiben – die zeitliche Reihenfolge ist für die Analyse nötig, ohne Personenbezug zu erzeugen.
Kundennummern
Pseudonymisieren
Kundennummer 78234 → Kunde-001
Die Zuordnungstabelle (78234 = Kunde-001) intern aufbewahren. Nur so kann die Analyse später dem echten Kunden zugeordnet werden.
Kontext prüfen
Reidentifizierungsrisiko bewerten
Nach der Anonymisierung prüfen: Kann man aus den verbleibenden Informationen noch auf eine Person schließen? Wenn ja – weitere Details entfernen.
Lokale KI als datenschutzfreundliche Alternative
Wenn Anonymisierung nicht möglich ist oder zu aufwendig wäre – lokale Modelle nutzen.
Warum lokal?
Daten verlassen das Haus nicht
Lokale Modelle (Ollama + llama3, mistral, qwen2.5) laufen auf unternehmenseigener Hardware.
Kein Datenabfluss, kein Training mit Firmendaten, kein Drittanbieter – volle Kontrolle über die Verarbeitung.
Für viele interne Aufgaben reichen kleinere Modelle völlig aus.
Einschränkungen
Tradeoffs kennen
Qualität: Lokale Modelle sind kleiner als GPT-4 oder Claude – bei komplexen Aufgaben weniger präzise.
Hardware: Leistungsfähige Modelle benötigen GPU-Server – Investition nötig.
Wartung: Updates, Backups, Sicherheitspatches liegen beim Unternehmen – kein Managed Service.
Hybridansatz: Unkritische Aufgaben → Cloud-KI. Sensible Daten → lokales Modell. Entscheidung anhand des Schutzbedarfs treffen.
Datenschutzverträge mit KI-Anbietern
Auftragsverarbeitungsvertrag (AVV)
Pflicht bei Personenbezug
Wenn personenbezogene Daten an einen Dienstleister übermittelt werden, ist nach DSGVO Art. 28 ein AVV Pflicht.
Große KI-Anbieter bieten AVVs an:
– OpenAI: Enterprise-Vertrag mit AVV
– Microsoft Copilot: über M365-Lizenz
– Anthropic Claude: API mit Datenschutzvereinbarung
Ohne AVV: keine Verarbeitung personenbezogener Daten!
Was im AVV stehen muss
Mindestanforderungen
Zweckbindung: Daten nur für den vereinbarten Zweck verarbeiten.
Kein Training: Prompts dürfen nicht für Modelltraining genutzt werden.
Löschpflicht: Daten nach Verarbeitung löschen.
Subunternehmer: Wer sonst noch Zugriff hat, muss benannt sein.
EU-Serverstandort oder Angemessenheitsbeschluss für Drittländer.
Interne Richtlinie: Grundregeln für Mitarbeiter
Was jeder Mitarbeiter wissen muss – einfach und klar formuliert:
- Keine Kundendaten: Namen, E-Mails, Adressen, Bestellungen von Kunden nicht in ChatGPT, Claude oder ähnliche Dienste eingeben
- Keine Mitarbeiterdaten: Gehalt, Beurteilungen, Krankmeldungen, Personalakten-Inhalte gehören nicht in externe KI
- Keine Zugangsdaten: Passwörter, API-Keys, Tokens – auch nicht als Beispiel
- Anonymisierung first: Wenn KI helfen soll – zuerst alle Personenbezüge entfernen, dann eingeben
- Nur freigegebene Tools: Nur KI-Dienste nutzen, für die das Unternehmen einen AVV geschlossen hat
- Bei Unsicherheit fragen: Datenschutzbeauftragten oder IT-Sicherheit ansprechen – kein Risiko eingehen
Daumenregel: Würde ich diesen Text bedenkenlos auf einer Postkarte versenden? Wenn nein – nicht in externe KI.
Zusammenfassung
- Personenbezogene Daten (Namen, E-Mails, IPs, Gesundheitsdaten) gehören nicht in externe KI – ohne AVV und Rechtsgrundlage
- Erlaubt: anonymisierte Daten, allgemeine Konfigurationen, eigene Texte ohne Drittbezug
- Verboten: Kundendaten, Mitarbeiterdaten, Passwörter, API-Keys, vertrauliche Geschäftsdaten
- Anonymisierung: Namen durch Platzhalter, IPs durch Symbole – Zuordnungstabelle intern behalten
- Lokale Modelle (Ollama) als Alternative wenn Anonymisierung nicht möglich ist
- AVV mit dem KI-Anbieter schließen bevor personenbezogene Daten verarbeitet werden dürfen
DSGVO-Konformität verhindert keine KI-Nutzung – sie erfordert bewusstes Handeln und klare interne Regeln.