DSGVO und KI 2026: Was bei OpenAI, Claude & lokalen Modellen wirklich gilt

Die häufigste Frage in Erstgesprächen mit KMU: „Wenn wir Kundendaten durch GPT schicken — landen die dann im Trainingsmaterial von OpenAI?"

Die ehrliche Antwort: Es kommt genau auf zwei Dinge an — welche Variante von ChatGPT/Claude Sie nutzen und unter welchem Vertrag. In diesem Artikel zeige ich, wie Sie in 15 Minuten verstehen, ob Ihr KI-Setup DSGVO-tauglich ist — und wo echte Risiken liegen.

1. Consumer-Chatbots vs. Business-API: Der entscheidende Unterschied

Die wichtigste Unterscheidung ist nicht der Modellname, sondern die Umgebung:

ChatGPT.com im Browser (Free / Plus / Team-ähnliche Web-Varianten)

• ▸Läuft unter Consumer-AGB.
• ▸Eingaben dürfen grundsätzlich zur Modellverbesserung genutzt werden, sofern Sie das nicht aktiv abwählen.
• ▸In der Regel gibt es keinen Auftragsverarbeitungsvertrag (DPA) — damit ist der Einsatz für echte Kundendaten aus DSGVO-Sicht kaum haltbar.

Claude im Browser (Free / Pro)

• ▸Ebenfalls Consumer-Zone.
• ▸Je nach Tarif und Einstellungen können Nutzerdaten für das Training verwendet werden.
• ▸Auch hier fehlt in der Regel ein sauberer DPA für den Unternehmenseinsatz.

OpenAI-, Anthropic- & Co.-APIs (Business / Enterprise)

• ▸Wenn Sie die API unter Business- oder Enterprise-Konditionen nutzen, gelten andere Regeln.
• ▸Typischerweise: keine Verwendung von API-Inhalten fürs Training, vertraglich zugesichert.
• ▸Zusätzlich können Sie Datenregionen, Aufbewahrungsfristen und Sicherheitsmaßnahmen vertraglich regeln.

Merksatz: ChatGPT.com / Claude im Browser = Consumer-Zone, Finger weg von Kundendaten. API mit Business-/Enterprise-Vertrag + DPA = Enterprise-Zone, DSGVO-konformer Einsatz ist möglich, wenn der Rest des Setups stimmt.

2. Auftragsverarbeitungsvertrag (DPA): Pflicht, nicht Kür

Sobald Sie personenbezogene Daten durch eine externe KI-API schicken, handelt der Anbieter als Auftragsverarbeiter. Dann greift Art. 28 DSGVO — und ein Auftragsverarbeitungsvertrag ist zwingend.

Was der DPA mindestens leisten muss:

• ▸Klarstellung, dass der Anbieter Auftragsverarbeiter ist, nicht selbst Verantwortlicher.
• ▸Beschreibung der Kategorien von Daten und Verarbeitungen.
• ▸Liste der Unterauftragsverarbeiter (Sub-Processors) und Informationspflicht bei Änderungen.
• ▸Aussage zu Speicherorten (Regionen) und internationalen Datentransfers (z. B. Standardvertragsklauseln).
• ▸Regelungen zu Löschung, Speicherdauer und technischen/organisatorischen Maßnahmen (TOMs).

Die großen KI-Anbieter haben dafür spezialisierte DPA-Dokumente, die an das Hauptvertragspaket angehängt werden. Ihre Aufgabe als Unternehmen: diese Dokumente nicht nur unterschreiben, sondern auch tatsächlich gegen Ihre Anforderungen prüfen.

Praktische Faustregel: Personenbezogene Daten + externer KI-Dienst = immer DPA-Pflicht. Ohne DPA bewegen Sie sich in einer Grauzone mit Bußgeld-Risiko.

3. Speicherort & Aufbewahrung: EU-Region und 30-Tage-Thema

Selbst wenn keine Trainingsnutzung erfolgt, bleiben zwei Fragen kritisch:

• ▸Wo werden die Daten verarbeitet?
• ▸Wie lange werden sie gespeichert?

Typisch für große KI-APIs (Stand 2026): kurzfristige Speicherung von Inputs/Outputs (oft um die 30 Tage) für Abuse-Erkennung, Fehleranalyse und Betrieb.

Erweiterte Optionen in Enterprise-Tiers:

• ▸Verkürzte oder Zero-Retention-Optionen (keine Speicherung über die eigentliche Anfrage hinaus).
• ▸Data Residency-Optionen, z. B. EU-Regionen oder sogar dedizierte Cluster.

Für viele Anwendungsfälle im Marketing oder in internen Workflows ist ein 30-Tage-Window mit EU-Region und soliden TOMs ausreichend. In streng regulierten Branchen (Gesundheit, Finanz, kritische Infrastruktur) verlangen Datenschutzbeauftragte und Aufsicht aber häufig:

• ▸Klare EU-Only-Verarbeitung in den Verträgen.
• ▸Möglichst Zero-Retention oder stark reduzierte Aufbewahrung.
• ▸Verschlüsselung, Rollen- und Berechtigungskonzepte, Logging, regelmäßige Audits — sauber dokumentiert.

Wenn ein Anbieter diese Punkte nicht glaubhaft liefern kann, ist das ein Signal, zumindest für besonders sensible Daten nach Alternativen zu suchen.

4. Lokale Modelle: Wann sich On-Prem wirklich lohnt

Wenn „EU-only" und maximale Datenhoheit unverhandelbar sind, kommen lokale oder dediziert gehostete Modelle ins Spiel.

Typische Optionen 2026 — Llama 3.x, Mistral & Co.:

• ▸Laufen auf eigenen GPU-Servern im Rechenzentrum oder bei einem IaaS-Anbieter mit garantiertem EU-Standort.
• ▸Sie behalten vollständige Kontrolle über Infrastruktur, Zugriffe und Logs.
• ▸Daten verlassen nie Ihr Netzwerk bzw. Ihren EU-Hosting-Partner.

Vorteile

• ▸Maximale Datenhoheit und kein Drittlandtransfer, solange die Hardware in der EU steht.
• ▸Feine Kontrolle über Logs, Retention und Sicherheitsmaßnahmen.

Nachteile

• ▸Höhere Initialkosten (Hardware, Setup, Betrieb).
• ▸Bedarf an internem Know-how für Betrieb, Monitoring, Updates und ggf. Feinjustierung der Modelle.

In der Praxis ist ein gut konfiguriertes Cloud-API-Setup (DPA, EU-Region, minimierte Retention) für viele KMU völlig ausreichend. Lokale Modelle lohnen sich vor allem dort, wo:

• ▸hochsensible Daten verarbeitet werden (Gesundheit, Finanz, IP-kritische Geschäftsgeheimnisse), oder
• ▸interne/branchenspezifische Vorgaben Cloud-Setups stark einschränken.

5. Die geschärfte Daumenregel für KMU

Aus der Praxis mit KMU lassen sich drei saubere Kategorien ableiten:

Kategorie 1: Personenbezogene Daten, moderates Risiko

Beispiele: CRM-Daten, Support-Tickets, interne Dokumente ohne Spezialschutz. Vorgehen:

• ▸Nutzung von Business-/Enterprise-APIs mit unterschriebenem DPA, möglichst EU-Region und klar geregelter Retention (ideal: Zero-Retention oder stark verkürzt).
• ▸Prozesse & Richtlinien definieren (wer darf was wohin schicken, welche Daten sind tabu).

Kategorie 2: Hochsensitive oder streng regulierte Daten

Beispiele: Gesundheitsdaten, Finanzdaten, Geheimhaltungs-kritische IP. Vorgehen — entweder lokale Modelle im eigenen/EU-Rechenzentrum, oder streng kontrollierte Enterprise-Cloud mit:

• ▸verbindlicher EU-Only-Verarbeitung,
• ▸Zero-Retention,
• ▸starker Verschlüsselung,
• ▸ausführlicher Dokumentation für DSB und Audits.

Kategorie 3: Keine Personenbezüge, geringes Risiko

Beispiele: Marketing-Texte, interne Wissensartikel ohne Personenbezug, Website-Copy. Vorgehen:

• ▸Consumer-Tools können ausreichend sein — sofern tatsächlich keine personenbezogenen oder vertraulichen Informationen im Prompt landen.
• ▸Trotzdem: Eine kurze interne Policy, welche Inhalte wo verarbeitet werden dürfen, ist Pflicht, um „Aus Versehen"-Verstöße zu vermeiden.

In Erstgesprächen ordnen wir jedes Projekt genau einer dieser Kategorien zu. Die Mehrheit der KMU-Projekte landet in Kategorie 1 — ein sauberes API-Setup mit DPA, EU-Region und klaren Spielregeln. Kategorie 2 (lokal oder High-End-Enterprise) wird nur dann notwendig, wenn Regulierung oder Risikoappetit es wirklich erfordert.