Lokale LLMs und DSGVO - der ehrliche Compliance-Check 2026

Wer mit personenbezogenen Daten arbeitet, kommt um die DSGVO-Frage nicht herum. Sobald Mandantenakten, Patientenberichte, Personalunterlagen oder Kundenverträge durch ein Sprachmodell laufen, wird aus einer Technologie-Entscheidung eine datenschutzrechtliche. Cloud-APIs werfen dabei seit Jahren dieselben Fragen auf: Wo liegen die Server, wer kann mitlesen, gibt es einen Auftragsverarbeitungsvertrag, hält der einer Prüfung durch die zuständige Aufsichtsbehörde stand. Lokale LLMs verschieben diese Diskussion radikal. Dieser Text bündelt den Stand 2026, ehrlich und ohne Marketingschönfärberei. Er ersetzt keine rechtliche Beratung, hilft aber dabei, die richtigen Fragen an Datenschutzbeauftragte und Aufsicht zu stellen.

Die fünf DSGVO-Vorteile lokaler LLMs

Lokale Sprachmodelle haben gegenüber Cloud-APIs fünf strukturelle Vorteile, die in keiner einzelnen Vertragsklausel aufgehoben werden können. Diese Vorteile sind nicht graduell, sondern fundamental, weil sie aus der Architektur folgen, nicht aus einer Zusicherung des Anbieters. Wer einmal verstanden hat, warum diese fünf Punkte zählen, sieht Cloud-LLM-Verträge mit anderen Augen.

1. Kein Drittstaaten-Transfer in die USA. Das ist der wichtigste Punkt überhaupt. Sobald personenbezogene Daten in einem Cloud-LLM verarbeitet werden, das von einem US-Anbieter betrieben wird, greift Artikel 44 DSGVO. Selbst nach dem EU-US Data Privacy Framework von 2023 bleiben die strukturellen Probleme: US-Behörden haben unter dem CLOUD Act Zugriffsrechte, die mit europäischen Grundrechten kollidieren können. Die Schrems-Urteile sind nicht aufgehoben, sondern gelten weiter als Maßstab. Wer ein Modell auf eigener Hardware in Deutschland betreibt, sendet schlicht keine Daten in Drittstaaten. Damit entfällt die gesamte Diskussion um Standardvertragsklauseln, Transfer Impact Assessments und behördliche Zugriffsmöglichkeiten. Das ist ein riesiger Compliance-Vorteil, der oft unterschätzt wird, weil er unsichtbar ist: man muss nicht aktiv etwas tun, um ihn zu erhalten, sondern man muss nur die Cloud meiden.

2. Keine Auftragsverarbeitungsvereinbarung nötig. Artikel 28 DSGVO verlangt eine schriftliche Vereinbarung mit jedem Auftragsverarbeiter, der personenbezogene Daten im Auftrag des Verantwortlichen verarbeitet. Bei Cloud-APIs ist der LLM-Anbieter immer Auftragsverarbeiter. Das bedeutet Vertragsverhandlungen, Prüfung der technischen und organisatorischen Maßnahmen des Anbieters, regelmäßige Kontrolle, eine Liste der Unterauftragsverarbeiter. Bei einem lokal auf eigener Hardware betriebenen Modell gibt es keinen Auftragsverarbeiter. Es gibt nur dich als Verantwortlichen. Damit fallen Verhandlung, Dokumentation und laufende Kontrolle der AVV ersatzlos weg. Bei einem mittelständischen Unternehmen, das mit fünf bis zehn Cloud-Anbietern arbeitet, spart das einen messbaren Anteil der DSB-Kapazität.

3. Vollständige Datenhoheit. Datenhoheit ist mehr als Speicherort. Sie umfasst die Frage, wer ein Modell trainieren oder feintunen darf, wer Logs einsehen kann, wer im Fehlerfall Support-Zugriff hat, was bei einer Insolvenz des Anbieters mit deinen Daten passiert. Bei lokalen LLMs ist die Antwort auf alle diese Fragen identisch: du. Niemand sonst. Das macht die Datenflussanalyse für das Verarbeitungsverzeichnis nach Artikel 30 DSGVO trivial. Eingang: Promptdaten aus deiner Anwendung. Verarbeitung: lokal auf eigener Hardware. Ausgang: Antworttext zurück an deine Anwendung. Empfänger: keine. Das ist eine kurze, prüfsichere Beschreibung, die jeden Datenschutzbeauftragten zufrieden stellt.

4. Audit-Logs gehören dir. Jedes ernsthafte LLM-Setup loggt Anfragen, Antworten, Fehler und Performance-Daten. Bei Cloud-APIs liegen diese Logs beim Anbieter, sind in der Regel nicht oder nur eingeschränkt exportierbar, und ihre Aufbewahrung folgt der Datenschutzpolitik des Anbieters, nicht deiner. Du kannst nicht selbst entscheiden, wann sie gelöscht werden, und du kannst nicht garantieren, dass sie nicht für Modellverbesserung herangezogen werden. Bei lokalem Betrieb entscheidest du, was geloggt wird, wo es gespeichert wird, wie lange es aufbewahrt wird und wer Zugriff hat. Du kannst Logs verschlüsseln, du kannst sie regelmäßig rotieren, du kannst sie pseudonymisieren. Diese Kontrolle ist nicht nur DSGVO-relevant, sondern auch für Audits nach ISO 27001, BSI-Grundschutz oder branchenspezifische Standards entscheidend.

5. Kein API-Key-Leak-Risiko. API-Keys von Cloud-LLMs sind in den letzten Jahren zu einer der häufigsten Datenpannen geworden. Sie tauchen in versehentlich öffentlichen GitHub-Repositories auf, in Slack-Nachrichten, in Konfigurationsdateien, die in Logs landen. Wer einen Key abgreift, kann auf Kosten des Eigentümers Anfragen stellen, sensible Daten exfiltrieren oder schlicht das Budget verbrennen. Bei lokalen LLMs gibt es keinen externen Endpunkt, der mit einem geleakten Key bedient werden könnte. Der Modell-Server ist hinter der eigenen Firewall, die Authentifizierung läuft über eigene Mechanismen, und ein abgegriffener interner Token ist deutlich begrenzter im Schaden als ein OpenAI- oder Anthropic-Key, der weltweit funktioniert.

Was bleibt trotzdem kritisch?

Lokale LLMs lösen viele Probleme, aber sie lösen nicht alle. Wer nach der Migration von Cloud auf lokal denkt, der DSGVO-Teil sei erledigt, übersieht eine Reihe von Pflichten, die unverändert bestehen bleiben. Diese Pflichten sind weniger spektakulär als die Drittstaaten-Diskussion, aber sie sind in der Praxis genauso relevant.

Erstens bleiben die technischen und organisatorischen Maßnahmen aus Artikel 32 DSGVO vollständig in deiner Verantwortung. Verschlüsselung der Festplatten, Zugriffskontrolle zu den Servern, Härtung des Betriebssystems, Patch-Management, Monitoring auf Anomalien, regelmäßige Schwachstellenscans. Nichts davon entfällt, nur weil das Modell lokal läuft. Im Gegenteil: bei Cloud-APIs trägt der Anbieter zumindest einen Teil dieser Last. Bei eigenem Betrieb trägst du sie vollständig. Die TOM-Dokumentation für ein lokales LLM-System ist daher umfangreicher als für einen reinen API-Aufruf.

Zweitens ist Backup-Verschlüsselung ein häufig übersehener Punkt. Wer ein RAG-System mit Vektor-Embeddings personenbezogener Inhalte betreibt und diese Daten regelmäßig sichert, hat schnell Backups in Größenordnungen, die nicht mehr mit der Hauptanwendung mitgeschützt werden. Backups gehören in einen separaten Tresor, sind verschlüsselt zu halten, und die Schlüsselverwaltung muss vom Backup-System getrennt sein. Sonst nützt die Verschlüsselung nichts. Das gilt auch für Snapshots virtueller Maschinen, die LLM-Workloads enthalten. Ein Snapshot ist ein vollständiges Abbild und damit potenziell ein Backup mit allen darin enthaltenen personenbezogenen Daten.

Drittens ist Logging-Hygiene ein heikles Thema. Prompts können personenbezogene Daten enthalten. Wenn ein Mitarbeiter im internen Chat-System die Frage stellt: “Fasse mir die letzte Beurteilung von Maria Müller zusammen”, dann steht Marias Name in den Logs. Wer diese Logs unbegrenzt aufbewahrt, hat ein Problem. Es gibt mehrere Lösungsansätze: Pseudonymisierung beim Logging, kurze Aufbewahrungsfristen, getrennte Speicherung von Metriken und Inhalten, automatische Maskierung typischer Personendaten. Welche Lösung passt, hängt vom Anwendungsfall ab. Wichtig ist, dass die Entscheidung dokumentiert ist und im Verarbeitungsverzeichnis steht.

Viertens bleibt das Thema Halluzinationen relevant. Lokale Modelle halluzinieren genauso wie Cloud-Modelle, oft sogar stärker, weil sie kleiner sind. Eine Halluzination, die in einer Kundenkommunikation oder einer Entscheidungsvorlage landet, ist nicht nur peinlich, sondern potenziell rechtlich problematisch. Wer auf Basis einer falschen LLM-Aussage einer Kundin eine Auskunft erteilt, die ihre Rechte beeinträchtigt, kann sich nicht auf das Modell berufen. Verantwortung bleibt beim Menschen. Compliance-relevant ist daher die Pflicht zu menschlicher Prüfung vor jeder verbindlichen Außenkommunikation. Diese Pflicht muss organisatorisch verankert sein, sonst ist sie wertlos.

Fünftens ist die Frage der Haftung bei automatisierten Entscheidungen aus Artikel 22 DSGVO zu beachten. Sobald ein LLM in einen Prozess eingebunden ist, der rechtliche Wirkung gegenüber einer Person entfaltet oder sie ähnlich erheblich beeinträchtigt, gelten besondere Pflichten. Information, Widerspruchsrecht, manuelle Prüfung. Lokale Modelle ändern an dieser Pflichtenlage nichts. Wer ein LLM einsetzt, um Bewerberinnen vorzusortieren oder Kreditscoring zu unterstützen, braucht zusätzliche Sicherungen, unabhängig vom Betriebsort.

Lizenz-Lage der wichtigsten Modelle

Neben dem Datenschutzrecht ist das Urheber- und Lizenzrecht für lokale LLMs relevant. Das Modell selbst ist eine Datei, oft mehrere Gigabyte groß, die unter einer bestimmten Lizenz steht. Diese Lizenz regelt, was du mit dem Modell tun darfst: nur lokal nutzen, kommerziell nutzen, weiterverteilen, feintunen, eigene Varianten veröffentlichen.

Llama 3.2 und 3.3 stehen unter der Llama-3-Lizenz, die Meta seit 2024 nutzt. Sie erlaubt kommerzielle Nutzung mit einer wichtigen Ausnahme: Unternehmen mit über 700 Millionen monatlich aktiven Nutzern brauchen eine separate Vereinbarung. Für die meisten Mittelständler und kleinere Konzerne ist das kein praktisches Hindernis. Die Lizenz verlangt zusätzlich eine Acceptable-Use-Policy einzuhalten, die unter anderem Hochrisiko-Anwendungen wie Waffenentwicklung ausschließt. Praktisch lässt sich Llama in nahezu jedem normalen Geschäftsumfeld einsetzen.

Mistral 7B und Mixtral 8x7B stehen unter Apache-2.0. Das ist eine der freundlichsten Open-Source-Lizenzen überhaupt. Kommerzielle Nutzung ist uneingeschränkt erlaubt, Weitergabe ebenfalls, Patentschutz ist eingebaut. Wer maximale Lizenz-Flexibilität braucht, ist bei den Mistral-Modellen meistens richtig. Auch Qwen 2.5 von Alibaba nutzt seit der jüngsten Version Apache-2.0, was es für europäische Unternehmen interessant macht, die ein leistungsfähiges Modell ohne Meta-typische Nutzungsklauseln suchen.

Phi-3 von Microsoft steht unter MIT-Lizenz, was praktisch noch freier ist als Apache-2.0. Microsoft hat die Phi-Familie bewusst sehr offen gehalten, weil sie als Forschungs- und Edge-Modelle gedacht sind. Gemma von Google nutzt eine eigene Gemma-Lizenz, die kommerzielle Nutzung erlaubt, aber an die Gemma-Use-Policy bindet. Diese Policy schließt Bereiche wie Desinformation und automatisierte Überwachung aus. In normalen Unternehmensanwendungen kein Problem.

Modell	Lizenz	Kommerziell?
Llama 3.2 / 3.3	Llama-3 License	Ja, unter 700 Mio MAU
Mistral 7B	Apache-2.0	Ja, uneingeschränkt
Mixtral 8x7B	Apache-2.0	Ja, uneingeschränkt
Phi-3	MIT	Ja, uneingeschränkt
Gemma	Gemma License	Ja, mit Use-Policy
Qwen 2.5	Apache-2.0	Ja, uneingeschränkt

Bei den Trainingsdaten gibt es ungelöste Diskussionen. Mehrere Modellhersteller haben Klagen wegen der Nutzung urheberrechtlich geschützter Texte beim Training. Diese Klagen betreffen die Hersteller, nicht die Anwender, die das fertige Modell nutzen. Selbst wenn ein Gericht in einigen Jahren feststellen sollte, dass ein bestimmtes Trainingsverfahren gegen Urheberrecht verstößt, wäre die wahrscheinliche Folge eine Schadensersatzpflicht für den Hersteller, nicht eine Nutzungsuntersagung für die Anwender. Trotzdem lohnt es sich, auf die Modell-Auswahl zu achten und im Zweifel europäische oder klar dokumentierte Modelle zu bevorzugen.

Praxis-Checkliste für DSGVO-konformes LLM-Setup

Eine ehrliche Checkliste hilft, kein Detail zu vergessen. Die folgende Liste ist kein juristischer Standard, aber sie deckt die häufigsten Punkte ab, die in Audits geprüft werden. Sie eignet sich als Diskussionsgrundlage mit dem Datenschutzbeauftragten und als Roadmap für die ersten Wochen nach Inbetriebnahme eines lokalen LLM-Systems.

Erstens steht die Datenklassifizierung am Anfang. Welche Daten sollen über das Modell laufen, welche Schutzklasse haben sie, welche Aufbewahrungspflichten und welche Löschfristen. Ohne diese Klärung lässt sich kein Schutzkonzept entwickeln. Zweitens braucht es Verschlüsselung im Ruhezustand auf allen Datenträgern, die personenbezogene Daten oder daraus abgeleitete Embeddings enthalten. LUKS für Linux-Server, BitLocker für Windows-Workstations, FileVault für Macs. Bei Backups ebenso, mit getrennten Schlüsseln. Drittens ist Zugriffskontrolle ein Dauerthema. Wer darf das Modell aufrufen, wer darf in die Logs schauen, wer darf die Modell-Dateien austauschen oder feintunen. Rollenbasiertes Zugriffsmodell, Multi-Faktor-Authentifizierung für administrative Zugänge, regelmäßige Überprüfung.

Viertens gehört das Audit-Log selbst auf die Liste. Was wird geloggt, wo wird es gespeichert, wie wird es geschützt, wann wird es gelöscht. Pseudonymisierung typischer Personendaten in Prompts ist ein Muss, wenn Logs länger als wenige Tage aufbewahrt werden. Fünftens braucht jedes Backup-Konzept einen funktionierenden Wiederherstellungstest. Ein Backup, das nie restauriert wurde, ist kein Backup, sondern Wunschdenken. Viertel- oder halbjährliche Restore-Tests in einer isolierten Umgebung sind Pflicht.

• Datenklassifizierung dokumentiert und freigegeben
• Festplatten- und Backup-Verschlüsselung aktiv und auditierbar
• Rollenbasierte Zugriffskontrolle mit MFA für Admin-Zugänge
• Audit-Log-Konzept mit Pseudonymisierung und Aufbewahrungsfrist
• Restore-Test mindestens halbjährlich nachweisbar
• Incident-Response-Plan mit klaren Eskalationspfaden
• TOM-Dokumentation aktuell und im Verarbeitungsverzeichnis verlinkt
• Modelle und Abhängigkeiten patch- und versions-überwacht
• Schwachstellenscan auf der Server-Infrastruktur regelmäßig
• Schulung der Mitarbeitenden zum sinnvollen Umgang mit Prompts

Sechstens ist der Incident-Response-Plan keine Formalie. Sobald ein Sicherheitsvorfall eintritt, hast du nach Artikel 33 DSGVO 72 Stunden Zeit, um die zuständige Aufsichtsbehörde zu informieren. Diese Frist ist knapp. Wer keinen vorbereiteten Plan hat, verliert wertvolle Stunden mit Organisatorischem statt mit der Schadensbegrenzung. Der Plan muss klären: wer entscheidet, wer informiert, wer kommuniziert nach außen, welche Tools werden zur Forensik genutzt, wo liegen die Notfallkontakte. Siebtens schließlich gehört die TOM-Dokumentation regelmäßig auf den Prüfstand. Sie ist kein einmal geschriebenes Dokument, sondern lebt mit dem System mit. Jede größere Änderung an der LLM-Infrastruktur wirft die Frage auf, ob die TOM-Dokumentation noch passt.

Wann lokal, wann VPS, wann Cloud?

Die ehrliche Antwort lautet: es kommt darauf an. Aber es kommt auf nachvollziehbare Faktoren an, nicht auf Bauchgefühl. Drei Szenarien lassen sich klar unterscheiden, und jedes hat eine eigene rechtliche Logik.

Lokaler Betrieb auf eigener Hardware ist die Wahl bei höchsten Anforderungen. Anwaltskanzleien mit Mandantengeheimnis nach Paragraf 43a BRAO, Arztpraxen mit Patientendaten nach Paragraf 203 StGB, Steuerberater mit Berufsgeheimnis, Berater im sicherheitssensiblen Umfeld, Behörden mit Verschlusssachen. In all diesen Fällen ist lokal nicht nur datenschutzfreundlich, sondern oft die einzige rechtssichere Variante. Hier zählt jeder Meter Verkabelung: das Modell läuft auf einem Server, der physisch in den eigenen Räumen steht, hinter eigener Firewall, mit eigenen Mitarbeitenden als Administratoren. Diese Variante ist teurer in der Anschaffung und im Betrieb, aber sie nimmt dem Datenschutzbeauftragten einen großen Teil der Sorgen ab.

Eigener VPS oder dedizierter Server bei einem deutschen oder europäischen Hoster ist der pragmatische Mittelweg. Aus DSGVO-Sicht ist die Logik dieselbe wie bei lokalem Betrieb, nur dass die Hardware in einem Rechenzentrum eines Auftragsverarbeiters steht. Mit dem Hoster braucht es eine AVV, die TOM des Hosters müssen geprüft werden, im Idealfall liegt eine Zertifizierung wie ISO 27001 oder BSI C5 vor. Aber die Kontrolle über das Modell, die Daten und die Logs bleibt vollständig bei dir. Drittstaaten-Transfer entfällt, sofern der Hoster wirklich nur in der EU operiert und keine US-Mutter mit Zugriffsmöglichkeit hat. Das ist eine Frage, die du dem Hoster in der AVV stellen musst und die er belastbar beantworten muss. Diese Variante eignet sich für die meisten KMU, die nicht in die Hardware-Beschaffung investieren wollen, aber DSGVO-Compliance ohne Wenn und Aber brauchen.

Cloud-LLM-API ist der schnellste Einstieg, aber rechtlich der aufwendigste Weg. Wer hier compliant arbeiten will, braucht eine wasserdichte AVV mit dem Anbieter, ein Transfer Impact Assessment für US-Anbieter, Standardvertragsklauseln, idealerweise zusätzliche technische Maßnahmen wie Verschlüsselung mit eigenen Schlüsseln vor der Übertragung. Selbst dann bleibt ein Restrisiko, das die Datenschutzaufsicht im Zweifel anders bewertet als der Anbieter. Für nicht personenbezogene Daten ist die Cloud unproblematisch. Für hochvertrauliche Daten ist sie auch 2026 noch eine Wette auf die Stabilität der politischen und rechtlichen Lage zwischen EU und USA.

Praktisch heißt das: starte mit einer ehrlichen Datenklassifizierung. Daten der niedrigsten Schutzklasse können in der Cloud bleiben, wenn AVV und TIA passen. Daten mittlerer Schutzklasse gehören auf einen EU-VPS bei einem geprüften Hoster. Daten höchster Schutzklasse, insbesondere Berufsgeheimnisse und besondere Kategorien personenbezogener Daten nach Artikel 9 DSGVO, gehören auf eigene Hardware. Diese Drei-Klassen-Logik lässt sich auch dem Vorstand erklären und ist in der Praxis robust.

Häufige Fehler in der Praxis

Auch wer mit guter Absicht startet, läuft regelmäßig in dieselben Fehler. Eine Übersicht der wichtigsten, mit kurzer Erklärung warum sie passieren und wie man sie vermeidet.

Fehler eins: Die Annahme, lokal sei automatisch konform. Lokal löst die großen Cloud-Probleme, aber TOM, Logging-Hygiene, Backup und Incident-Response bleiben Pflicht. Wer das Modell installiert und denkt, der Datenschutzbeauftragte könne abhaken, hat den halben Job gemacht. Vermeidung: Checkliste durcharbeiten, TOM-Dokumentation aktualisieren, vom DSB freigeben lassen.

Fehler zwei: Logs ohne Konzept aufbewahren. Standardinstallationen vieler LLM-Server loggen Prompts und Antworten in Klartext, oft auf demselben Volume wie das Betriebssystem. Nach wenigen Wochen liegen dort Megabytes personenbezogener Inhalte ohne Verschlüsselung, ohne Pseudonymisierung, ohne Löschfrist. Vermeidung: Logging vor Inbetriebnahme konfigurieren, Aufbewahrungsfristen technisch erzwingen, Pseudonymisierung als Standard.

Fehler drei: Embeddings unterschätzen. Vektor-Embeddings sehen aus wie Zahlenreihen und werden gedanklich als anonym behandelt. Sie sind es nicht. Aus einem Embedding lassen sich Inhaltszusammenhänge rekonstruieren, und sobald das Embedding aus personenbezogenen Quellen erzeugt wurde, ist es selbst personenbezogen. Vermeidung: Vektor-Stores genauso behandeln wie die Quelldaten. Verschlüsselung, Zugriffskontrolle, Löschkonzept.

Fehler vier: AVV vergessen, wenn der VPS bei einem fremden Hoster steht. Selbst auf einem dedizierten Server ist der Hoster Auftragsverarbeiter im Sinne der DSGVO, weil er physischen Zugriff auf die Hardware hat. Ohne AVV ist die Verarbeitung formal rechtswidrig, auch wenn faktisch alles sicher konfiguriert ist. Vermeidung: AVV bei jedem externen Hoster, auch bei deutschen Anbietern, auch bei dedizierten Servern.

Fehler fünf: Modell-Updates ohne Prüfung einspielen. Neue Modellversionen erscheinen in monatlichem Rhythmus. Wer einfach das neue Llama 4 oder Mistral 9 einspielt, ohne zu prüfen, was sich an Lizenz, Acceptable-Use-Policy, Verhalten gegenüber sensiblen Daten geändert hat, riskiert Compliance-Verstöße. Vermeidung: Modell-Updates wie Software-Updates behandeln, mit Changelog-Prüfung, Lizenz-Check und Test in einer Stage-Umgebung.

Fehler sechs: Mitarbeitende ohne Schulung in das System lassen. Wer einen Prompt mit dem Klarnamen eines Kunden formuliert und detaillierten Vertragsdaten kombiniert, erzeugt einen kritischen Log-Eintrag, selbst wenn das Modell selbst die Daten nicht missbraucht. Schulung zum sinnvollen Promptbau, Pseudonymisierung im Vorfeld, Bewusstsein für die eigene Verantwortung im Umgang mit dem Modell. Vermeidung: Schulungsprogramm zur Inbetriebnahme, jährliche Auffrischung, klare Hausregeln.

Nächster Schritt

Wer nach diesem Überblick tiefer einsteigen will: Die Architekturfrage zwischen lokal und Cloud, mit Kostenrechnung und Performance-Vergleich, ist im Detail hier beleuchtet: Cloud vs. Lokal. Wer ein eigenes Wissens-System mit lokalen Modellen aufbauen will, findet die Architektur und die DSGVO-Implikationen für RAG-Systeme hier: RAG lokal. Beide Texte ergänzen die hier dargestellten Datenschutz-Aspekte um die jeweils technische Detailtiefe.

Dieser Text ersetzt keine rechtliche Beratung. Er ist ein Diskussionsrahmen für das Gespräch mit Datenschutzbeauftragten, IT-Sicherheitsverantwortlichen und Aufsichtsbehörden. Konkrete Konstellationen brauchen konkrete juristische Prüfung, idealerweise vor und nicht nach der Inbetriebnahme.