LLM-Integration DSGVO-konform: OpenAI, Azure oder selbst gehostet?

Die Technik ist selten das Problem. Eine Zusammenfassung, eine Klassifizierung eingehender E-Mails, ein Assistent, der Mitarbeitenden die Suche in internen Dokumenten abnimmt – das ist heute in wenigen Tagen technisch integriert. Was Projekte stoppt, ist eine andere Frage: Dürfen wir das mit unseren Daten überhaupt?

Die gute Nachricht: In den allermeisten Fällen lautet die Antwort „ja, wenn man es richtig aufsetzt". Welcher der drei Wege der richtige ist, hängt davon ab, welche Daten in das Modell fließen und wie viel Datenhoheit Sie brauchen. Genau das klären wir hier.

Worum es bei „DSGVO und LLM" wirklich geht

Ein Large Language Model wird datenschutzrelevant in dem Moment, in dem personenbezogene Daten in den Prompt wandern – ein Kundenname, eine E-Mail, ein Lebenslauf, eine Support-Anfrage. Sobald das passiert, gelten dieselben Spielregeln wie bei jedem anderen Dienstleister, der Daten für Sie verarbeitet. Drei Punkte sind entscheidend:

• Auftragsverarbeitung: Der LLM-Anbieter verarbeitet Daten in Ihrem Auftrag. Dafür braucht es einen Auftragsverarbeitungsvertrag (AVV / DPA) nach Art. 28 DSGVO.
• Ort der Verarbeitung: Bleiben die Daten in der EU? Oder gehen sie in ein Drittland wie die USA? Dann braucht die Übermittlung eine eigene Rechtsgrundlage.
• Weiterverwendung: Werden Ihre Eingaben zum Training der Modelle genutzt? Bei den API-Angeboten der seriösen Anbieter lautet die Antwort standardmäßig „nein" – bei den kostenlosen Chat-Oberflächen sieht das oft anders aus.

An diesen drei Punkten entscheidet sich, welcher Integrationsweg zu Ihrem Anwendungsfall passt.

Weg 1: OpenAI-API direkt

Der schnellste und qualitativ stärkste Einstieg. Sie sprechen die API von OpenAI an, bekommen Top-Modelle ohne eigene Infrastruktur und sind in Stunden produktiv. Datenschutzrechtlich sind zwei Dinge zu beachten.

Erstens: Über die API (nicht über das kostenlose ChatGPT-Webinterface!) werden Ihre Eingaben standardmäßig nicht zum Training verwendet, und OpenAI bietet einen AVV an. Standardmäßig werden API-Ein- und -Ausgaben allerdings bis zu 30 Tage zur Missbrauchserkennung gespeichert; Unternehmen mit erhöhtem Schutzbedarf können für geeignete Endpunkte eine eingeschränkte Missbrauchsüberwachung oder Zero Data Retention (ZDR) beantragen. Zweitens: Die Verarbeitung findet in den USA statt – also eine Drittlandübermittlung, die eine Rechtsgrundlage braucht. Diese liefert in der Regel das EU-US Data Privacy Framework bzw. ergänzend Standardvertragsklauseln.

In der Praxis heißt sauber aufgesetzt: AVV abschließen, Datenübermittlung dokumentieren – und vor allem so wenig personenbezogene Daten wie möglich überhaupt erst in den Prompt geben (dazu gleich mehr). Für viele Anwendungsfälle ohne hochsensible Daten ist dieser Weg vertretbar und mit Abstand der wirtschaftlichste.

Weg 2: Azure OpenAI (EU-Region)

Hier laufen dieselben OpenAI-Modelle, aber innerhalb der Microsoft-Azure-Cloud. Entscheidend für die Datenresidenz ist dabei der Deployment-Typ, nicht nur die Region der Ressource: Eine Global-Standard-Bereitstellung darf Anfragen weltweit verarbeiten, während eine EU-Data-Zone- oder regionale Bereitstellung die Verarbeitung innerhalb der EU hält. Wer in der EU bleiben muss, wählt also bewusst einen Data-Zone- oder Regional-Typ. Damit entschärft sich die Drittlandfrage erheblich. Microsoft tritt als Auftragsverarbeiter mit etabliertem, von vielen Unternehmen bereits geprüftem Vertragswerk (Data Protection Addendum) auf und nutzt Ihre Daten nicht ohne Weisung zum Training. Auch hier kann für die Missbrauchserkennung ein kleiner Teil der Daten bis zu 30 Tage gespeichert werden; eine Ausnahme ist auf Antrag möglich.

Das macht Azure OpenAI zum pragmatischen Mittelweg: nahezu die gleiche Modellqualität wie bei OpenAI direkt, aber mit der Datenresidenz und dem Vertragsrahmen, die Compliance-Abteilungen im deutschen Mittelstand sehen wollen. Der Preis dafür: etwas mehr Einrichtungsaufwand und die Bindung an das Azure-Ökosystem.

Weg 3: Selbst gehostetes Open-Source-Modell

Offene Modelle wie Llama, Mistral oder Qwen lassen sich auf eigener oder europäisch gehosteter Hardware betreiben. Der entscheidende Vorteil: Die Daten verlassen Ihre Infrastruktur nie. Keine Drittlandübermittlung, kein externer Auftragsverarbeiter für die Inferenz, volle Datenhoheit. Für besonders sensible Bereiche – Gesundheitsdaten, Personaldaten, geschützte Geschäftsgeheimnisse – ist das oft das einzige, was durch die interne Prüfung kommt.

Der ehrliche Gegenwert: Sie betreiben jetzt Infrastruktur. GPU-Kosten, Updates, Skalierung, Monitoring – das ist echter Betriebsaufwand. Und die Qualität der frei verfügbaren Modelle ist zwar beeindruckend, liegt je nach Aufgabe aber unter den größten kommerziellen Modellen. Für klar umrissene Aufgaben (Klassifizierung, Extraktion, Zusammenfassung) reicht sie meist locker; für offene, anspruchsvolle Reasoning-Aufgaben ist der Abstand spürbarer.

Die drei Wege im direkten Vergleich

Der wichtigste Hebel: Daten minimieren, bevor sie das Modell sehen

Egal welchen Weg Sie wählen – der größte Effekt entsteht vor dem Modellaufruf. Ein LLM braucht für die meisten Aufgaben gar nicht den echten Namen oder die echte Kundennummer. Bewährte Muster:

• Pseudonymisierung: Personenbezug vor dem Prompt durch Platzhalter ersetzen und das Ergebnis danach zurückübersetzen. Das Modell sieht „Kunde A", nie den echten Namen.
• Datensparsamkeit: Nur die Felder mitschicken, die für die Aufgabe nötig sind – nicht den ganzen Datensatz „zur Sicherheit".
• Transparenz & Protokollierung: Im Verarbeitungsverzeichnis festhalten, welche Daten zu welchem Zweck an welchen Dienst gehen.

Sauberes Data-Engineering an dieser Stelle verkleinert die rechtliche Angriffsfläche oft so weit, dass selbst Weg 1 unkritisch wird – und es ist die Arbeit, die in vielen schnell zusammengeklickten KI-Prototypen schlicht fehlt.

Welcher Weg passt zu Ihnen?

Eine grobe Entscheidungshilfe aus der Projektpraxis:

1. Verarbeiten Sie keine oder nur unkritische personenbezogene Daten und wollen schnell Wirkung sehen? → OpenAI-API, mit AVV und Datenminimierung.
2. Sind Sie Mittelständler mit klarer Compliance-Erwartung, wollen aber Spitzenmodelle nutzen? → Azure OpenAI in einer EU-Region.
3. Verarbeiten Sie hochsensible Daten oder verlangen Vorgaben volle Datenhoheit? → Selbst gehostetes Modell, mit dem nötigen Betriebskonzept.

In der Realität ist es oft kein Entweder-oder: Ein unkritischer Assistent läuft über die API, während die Verarbeitung sensibler Dokumente lokal bleibt. Die richtige Architektur trennt diese Fälle sauber – statt alles über einen Kamm zu scheren.

Fazit

DSGVO-konforme KI ist kein Widerspruch und kein Hexenwerk – es ist eine Frage der bewussten Entscheidung an drei Stellen: wo verarbeitet wird, mit wem ein Vertrag besteht und welche Daten überhaupt das Modell erreichen. Wer das von Anfang an mitdenkt, baut KI-Funktionen, die nicht beim ersten Datenschutz-Review wieder kassiert werden. Wie eine solche Integration technisch sauber aufgesetzt wird, zeigt der Ratgeber Laravel + LLM; was sie im Gesamtbudget bedeutet, der Artikel Was kostet individuelle Software.

Häufige Fragen

Zurück zum Ratgeber