SINTARIS
SpracheENDESLRU
Kontakt aufnehmen
← Alle Artikel

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

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

TL;DR. Wenn Ihr KI-Projekt personenbezogene Daten von Personen in der EU verarbeitet, gilt die DSGVO. In den meisten Fällen lässt sich Compliance 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 analysieren wir praktisch die Muster, die Audits bestehen, und jene, die es nicht tun. Grundlage sind SINTARIS-Erfahrungen aus RAG-Implementierungen in der EU.

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 fragt und es antwortet."

Technisch ist das zwei Tage Arbeit. Rechtlich ist das ein potenzielles Bußgeld von bis zu 4 % des weltweiten Jahresumsatzes nach DSGVO (Artikel 83). Eine theoretische Bedrohung ist das nicht: Aufsichtsbehörden (der Informationsbeauftragte IP-RS in Slowenien, BfDI in Deutschland, Garante in Italien) verhängen bereits 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, wer Verantwortlicher und wer Auftragsverarbeiter ist 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. Kommt auch nur eines davon vor, 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?", und 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. Ist sie dort nicht sichtbar, 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 Wissensbasis ohne Personenbezug
Pseudonymisierung + strenge Zugangskontrolle Teilweise Bedingt Interne Analysen
On-prem LLM Nein (bleibt lokal) Ja Regulierte Branchen
Cloud LLM + DPA + SCCs Ja (mit Schutz) Bedingt 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, mit dem gesamten PostgreSQL-CRM füttern, fertig.

Technische Umsetzung:

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

Die Architekturdetails stehen 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 bei der Compliance unsicher sind, ist ein KI-Audit der erste Schritt. Wir überprüfen die Architektur, identifizieren die Datenpfade und liefern eine priorisierte Checkliste von Maßnahmen.

Starten Sie ein neues Projekt, bauen wir beim KI-Pilot (4–8 Wochen) von Anfang an eine compliance-konforme Architektur ein. Umfang und Preis vereinbaren wir nach dem Erstgespräch (siehe Pakete).

10. Quellen

Das SINTARIS-Team führt KI-Audits, KI-Piloten und Taris-Einführungen für KMU in der EU durch. Das Erstgespräch ist kostenlos und dauert 30 Minuten.