KI und personenbezogene Daten: Was erlaubt ist und was Bußgelder kostet

2026-05-24 · Sintaris · ai, gdpr, 152-fz, dpia, rag, privacy, on-prem

KI und personenbezogene Daten: Was erlaubt ist und was Bußgelder kostet

TL;DR. Wenn Ihr KI-Projekt Daten von Personen in der EU betrifft — gilt die DSGVO. Wenn Daten von Personen in Russland — gilt das 152-FZ. Wenn beides — beide Gesetze gleichzeitig. In den meisten Fällen lässt sich das nicht durch „die richtige Cloud wählen" lösen, sondern durch die Pipeline-Architektur: wo liegt das Dokument, wo liegen die Vektoren, wo der Prompt, wohin geht die Anfrage an das LLM, wer sieht die Protokolle. Im Folgenden — eine praktische Analyse der Muster, die Audits bestehen, und jener, die es nicht tun, basierend auf SINTARIS-Erfahrungen bei RAG-Implementierungen in der EU und der GUS.

1. Das Problem: „Lass uns ChatGPT an unser CRM anschließen"

Diese Anfrage kommt in fast jedem ersten Projekt. Im Unternehmen sitzt bereits ein CRM mit Kundennamen, Telefonnummern, manchmal medizinischen oder finanziellen Details. Jemand hat eine ChatGPT-Demo gesehen, und die Aufgabe lautet: „Macht es so, dass der Vertriebler fragen kann — und es antwortet."

Technisch ist das zwei Tage Arbeit. Rechtlich ist das ein potenzielles Bußgeld von bis zu 4 % des weltweiten Umsatzes nach DSGVO (Artikel 83) und/oder bis zu 18 Millionen Rubel nach dem novellierten 152-FZ. Und das ist keine theoretische Bedrohung — der Roskomnadzor und europäische Datenschutzbehörden (BfDI in Deutschland, Garante in Italien) verhängen bereits solche Bußgelder wegen „Übermittlung personenbezogener Daten an Dritte ohne Rechtsgrundlage."

Das Ziel dieses Artikels ist zu zeigen, dass die Grenze nicht dort liegt, wo sie üblicherweise gezogen wird („OpenAI = schlecht, lokales LLM = gut"). Die Grenze liegt darin, wie Daten durch das System fließen, welche davon zu Ihrem Verarbeiter werden, welche zum Auftragsverarbeiter — und wo Sie eine festgehaltene Rechtsgrundlage haben müssen.

2. Für wen das relevant ist

Wenn Ihr Szenario keinen einzigen Kundennamen, keine E-Mail-Adresse, keine Kontonummer und keine Diagnose enthält — brauchen Sie diesen Artikel nicht. Wenn auch nur eines davon vorkommt — brauchen Sie ihn.

3. Der häufige Fehler

Das Muster, das wir Dutzende Male gesehen haben:

  1. CRM-Export als CSV.
  2. In den RAG-Index über einen Standard-n8n-Workflow laden.
  3. gpt-4o via OpenAI-API obendrauf schalten.
  4. Der Vertriebsmitarbeiter schreibt in Telegram: „Was haben wir letzten Monat mit Müller besprochen?" — der Bot antwortet.
  5. Alles funktioniert, die Demo war gut, der Auftraggeber ist zufrieden.

Warum das aus Regulierungssicht inakzeptabel ist:

4. Der technische Ansatz: Wo die Grenze zu ziehen ist

Die Kernidee, die wir in jedem Audit wiederholen: Die Grenze personenbezogener Daten in einem KI-System muss im Architekturdiagramm sichtbar sein. Wenn sie nicht sichtbar ist — gibt es sie nicht.

Das Basismodell, das wir anwenden:

[Rohdaten] → [Anonymisierungsschicht] → [RAG-Indizierung]
                                        ↓
                               [Nur anonyme Vektoren]
                                        ↓
                               [LLM-Anfrage: keine Klarnamen]

Vier Ansätze, geordnet nach Datenschutzniveau:

Ansatz Personenbezogene Daten gehen an LLM? DSGVO-konform Anwendungsfall
Vollständige Anonymisierung vor Indizierung Nein Ja Wissensbase ohne Personenbezug
Pseudonymisierung + strenge Zugangskontrolle Teilweise Konditionell Interne Analysen
On-prem LLM Nein (bleibt lokal) Ja Regulierte Branchen
Cloud LLM + DPA + SCCs Ja (mit Schutz) Konditionell Wenn On-prem nicht möglich

4.1. DSFA-Checkliste (wann sie Pflicht ist)

Nach DSGVO Artikel 35 ist eine DSFA erforderlich bei:

Für KI-Systeme heißt das: fast immer, wenn Sie CRM-Daten, medizinische Daten oder Kommunikationsprotokolle verarbeiten.

DSFA-Mindestinhalt für ein RAG-System:

  1. Beschreibung der Verarbeitung und ihrer Zwecke.
  2. Verhältnismäßigkeitsbewertung.
  3. Identifizierung und Bewertung von Risiken.
  4. Maßnahmen zur Risikobekämpfung (technische und organisatorische).
  5. Nachweis der Einholung der Stellungnahme des Datenschutzbeauftragten.

5. Architekturmuster, die Audits bestehen

Muster 1: On-prem vollständig (empfohlen für regulierte Branchen)

Vollständiger Technologie-Stack auf der eigenen Infrastruktur des Kunden: Ollama für LLM-Inferenz, pgvector für Vektorspeicherung, MinIO für Dokumentenablage. Keine Daten verlassen das interne Netz. DSGVO-Hauptproblem: praktisch gelöst, da keine Übermittlung an Dritte.

Muster 2: Hybride Architektur (nicht-sensibler Kontext an Cloud)

Nur anonymisierter oder nicht-personenbezogener Kontext wird an Cloud-LLMs gesendet. Personenbezogene Datenbankteile bleiben on-prem. Realisierbar mit einem Routing-Layer, der sensible Kontexte lokal bearbeitet.

Muster 3: Cloud + vollständige Compliance-Dokumentation

Wenn On-prem nicht möglich: DPA mit jedem Cloud-Anbieter unterzeichnen, Rechtsgrundlage für jede Datenkategorie dokumentieren, DSFA durchführen und dokumentieren, SCCs (Standardvertragsklauseln) bei Drittlandübermittlung.

6. SINTARIS-Minicase

Die Produkte Maria — Klinik-Terminbenachrichtiger und Clinic assistant zeigen diesen Ansatz in der Praxis. Aufgabe: Ein Patient soll über Telegram Termine bestätigen, verschieben und eine Rezeptkopie erhalten. Die übliche Versuchung: gpt-4o-mini nehmen, die gesamte PostgreSQL-CRM füttern — fertig.

Technische Umsetzung:

Ergebnis: LLM-Kosten — ca. 2 €/Monat (Klassifizierung sind kurze Anfragen), Anrufe beim Empfang sanken um 40–50 %, die rechtliche Dokumentation passt auf eine Seite, weil Personendaten den Perimeter physisch nicht verlassen.

Architekturdetails — im KB-Kapitel Clinic assistant § 9 „Security & data boundary“.

7. Checkliste (15 Punkte) vor dem Start eines KI-Projekts mit Personenbezug

  1. Rechtsgrundlage für jede Datenkategorie ist definiert (Art. 6 DSGVO).
  2. DSFA durchgeführt und dokumentiert, falls erforderlich.
  3. DPA unterzeichnet mit jedem externen Anbieter, der Zugriff auf Daten hat.
  4. Datensparsamkeit: nur das Minimum, das für den Verarbeitungszweck nötig ist.
  5. Speicherortinformation: physischer Serverstandort für jede Datenkategorie dokumentiert.
  6. Aufbewahrungsfristen für Logs und Vektoren sind festgelegt und technisch durchgesetzt.
  7. Daten-Klassifizierung: welche Daten sind sensibel nach Art. 9 DSGVO?
  8. Anonymisierung / Pseudonymisierung vor Weiterleitung an Cloud-LLMs.
  9. DSAR-Workflow (Auskunft, Löschung, Berichtigung) als Code.
  10. Audit-Log — unveränderlich, mit Aufbewahrungsfrist.
  11. Zugangskontrolle auf Datenbankebene (RLS, nicht nur Anwendungsebene).
  12. Verschlüsselung im Ruhezustand und bei der Übertragung.
  13. Vendor-Risikobewertung für jeden KI-Dienst im Stack.
  14. Datenpannen-Prozess — wie wird eine Panne erkannt und gemeldet?
  15. Datenschutzbeauftragter einbezogen (wenn nach DSGVO erforderlich).

8. Risiken

9. Was als Nächstes zu tun ist

Wenn Sie bereits eine KI-Lösung im Einsatz haben und unsicher sind hinsichtlich der Compliance — der erste Schritt ist ein KI-Audit (€900–4500). Wir überprüfen die Architektur, identifizieren die Datenpfade und liefern eine priorisierte Checkliste von Maßnahmen.

Wenn Sie ein neues Projekt starten — bauen wir beim KI-Pilot (€3000–12000, 4–8 Wochen) von Anfang an compliance-konforme Architektur ein.

−25% Rabatt für slowenische Unternehmen vom 1. bis 30. Juni 2026 — siehe Pakete.

10. Quellen

Sintaris führt KI-Audits, KI-Pilots und Taris-Implementierungen für KMU in der EU und der GUS durch. Discovery-Call — kostenlos, 30 Minuten.