Lokale KI datenschutzkonform betreiben: DSGVO-Checkliste für On-Premise-LLM-Deployments

Ein lokales LLM auf eigener Hardware bedeutet noch keine DSGVO-Konformität – es senkt aber den Aufwand erheblich, weil kein Drittland-Transfer stattfindet und du als Betreiber volle Kontrolle über alle Daten behältst. Ob Ollama mit Open-WebUI, LibreChat oder vLLM: Sobald Mitarbeiter- oder Kundendaten in den Modell-Kontext gelangen, greifen Art. 5, 25, 30, 32 und 35 DSGVO – inklusive Löschpflichten, Zugriffsdokumentation und je nach Einsatzzweck einer Datenschutz-Folgenabschätzung. Diese Anleitung gibt keine Paragraphenpredigt, sondern eine direkt umsetzbare Checkliste für KMU-Admins und Selfhoster.

Voraussetzungen

1. Server oder Workstation mit mindestens 16 GB RAM für 7B-Modelle (CPU-only), 8 GB+ VRAM für GPU-Betrieb
2. Linux-Host (Ubuntu 22.04/24.04 oder Debian 12 empfohlen) oder Windows 11 Pro mit WSL2 und Docker Desktop
3. Docker Engine und Docker Compose (Version 2.x oder höher)
4. Ausreichend Festplattenplatz: 7B-Modell (GGUF Q4_K_M) ca. 4–5 GB, 13B ca. 8–9 GB, 70B ca. 40 GB
5. TLS-Zertifikat für HTTPS-Zugriff (Let's Encrypt oder interne CA)
6. openssl auf dem Host für Schlüsselgenerierung
7. Dokumentiertes Datenschutzkonzept oder Verarbeitungsverzeichnis-Vorlage
8. Zugang zu einem Datenschutzbeauftragten (DSB) für DSFA-Begleitung bei Hochrisiko-Einsatz
9. Backup-Lösung mit Verschlüsselung (z. B. Restic mit age-Verschlüsselung)

Wann brauche ich überhaupt einen AVV?

Der Auftragsverarbeitungsvertrag nach Art. 28 DSGVO ist immer dann erforderlich, wenn ein externer Dritter personenbezogene Daten im Auftrag der verantwortlichen Organisation verarbeitet. Bei einem vollständig internen Deployment – eigener Server, eigenes Netz, kein externer Zugriff – bist du alleiniger Verantwortlicher und kein AVV ist nötig.

Die Grenze ist jedoch schärfer gezogen als viele annehmen. Folgende Szenarien machen den AVV zur Pflicht:

1. Cloud-Hosting-Provider betreibt die Serverinfrastruktur (Hetzner, Netcup, AWS, Azure)
2. Managed-GPU-Dienst übernimmt die Inference-Last
3. SaaS-Monitoring-Tool speichert Traces oder Logs mit Prompts und Responses (z. B. Langfuse Cloud, Datadog)
4. Ollama Cloud-Modelle ab v0.12+: Diese laufen auf Datacenter-Hardware von Ollama und erfordern einen separaten Datenschutzprozess

Fehlt der AVV bei nachweisbarer Auftragsverarbeitung, drohen Bußgelder bis zu 20 Millionen Euro oder 4 Prozent des Jahresumsatzes. Selbst gehostetes Langfuse (MIT-Lizenz, eigene PostgreSQL-Instanz) hingegen erfordert keinen AVV, weil keine Daten das eigene Netz verlassen.

Ollama absichern: History-Logging und Cloud-Modelle

Ollama speichert laut offizieller Privacy Policy keine Prompts und überträgt nichts an externe Server – solange du ausschließlich lokale Modelle verwendest. Es gibt jedoch einen Punkt, der in Produktivumgebungen oft übersehen wird: Die CLI speichert eine Prompt-History als Klartext in ~/.ollama/history. Jeder Prozess, der unter demselben Benutzer läuft, kann diese Datei lesen.

Die Lösung ist eine einzige Umgebungsvariable:

# Temporär vor dem Start (Bash/Zsh)
export OLLAMA_KEEP_HISTORY=false
ollama serve

# Dauerhaft via systemd-Override
# Datei: /etc/systemd/system/ollama.service.d/override.conf
[Service]
Environment="OLLAMA_KEEP_HISTORY=false"

# Bestehende History löschen
rm -f ~/.ollama/history

# Systemd neu laden und Dienst starten
sudo systemctl daemon-reload
sudo systemctl restart ollama

Wichtig ab Ollama v0.12+: Es gibt jetzt Cloud-Modelle, die auf Ollama-Datacenter-Hardware laufen. In Unternehmensumgebungen sollte der Login mit einem Ollama-Account unterbunden oder klar geregelt werden, damit Mitarbeiter nicht versehentlich Cloud-Modelle auswählen und Daten die eigene Infrastruktur verlassen.

Verfügbare lokale Modelle lädst du ohne Netzwerkkommunikation zu externen Inference-Diensten:

# Modelle lokal herunterladen
ollama pull llama3.2:3b
ollama pull mistral:7b-instruct-q4_K_M
ollama pull phi3:mini

# Aktive Modelle prüfen
ollama ps

# Nicht mehr benötigtes Modell entfernen
ollama rm llama3.2:3b

Open-WebUI: DSGVO-konforme Docker-Compose-Konfiguration

Open-WebUI speichert sämtliche Konversationen in einer SQLite-Datenbank (/app/backend/data/webui.db). Das schafft datenschutzrechtliche Pflichten: Löschfristen müssen technisch durchsetzbar sein, und der Zugriff auf die Datenbankdatei muss kontrolliert werden.

Drei Konfigurationspunkte sind nicht optional:

1. WEBUI_SECRET_KEY: Ohne diesen Schlüssel werden API-Keys und OAuth-Tokens unverschlüsselt gespeichert. Er muss persistent gesetzt bleiben – ein neuer Key bei Container-Neustart macht alle verschlüsselten Secrets unleserlich und loggt alle Nutzer aus.
2. Port-Bindung auf 127.0.0.1: Ohne explizite Bindung an localhost lauscht Docker auf allen Netzwerkinterfaces. Eine Firewall allein reicht nicht, weil Docker iptables-Regeln umgeht.
3. Telemetrie deaktivieren: Open-WebUI kann Nutzungstelemetrie senden; dies widerspricht dem Datenminimierungsgebot aus Art. 5 Abs. 1 lit. c DSGVO.

# Sicheren Secret-Key generieren und in .env speichern
echo "WEBUI_SECRET_KEY=$(openssl rand -hex 32)" > .env
chmod 600 .env

# .gitignore absichern (Key niemals in Git!)
echo ".env" >> .gitignore
# docker-compose.yml
version: '3.8'
services:
  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    ports:
      - "127.0.0.1:3000:8080"  # Nur localhost, KEIN 0.0.0.0
    environment:
      - OLLAMA_BASE_URL=http://ollama:11434
      - WEBUI_SECRET_KEY=${WEBUI_SECRET_KEY}        # Pflicht aus .env
      - WEBUI_AUTH=true                              # Authentifizierung erzwingen
      - WEBUI_REGISTRATION_ENABLED=false             # Keine offene Registrierung
      - DEFAULT_USER_ROLE=user                       # Neue Nutzer ohne Admin
      - ANONYMIZED_TELEMETRY=false                   # Datenminimierung
      - DO_NOT_TRACK=true
    volumes:
      - open-webui-data:/app/backend/data            # DB persistent halten
    restart: unless-stopped
    networks:
      - ai-internal

  ollama:
    image: ollama/ollama:latest
    container_name: ollama
    environment:
      - OLLAMA_KEEP_HISTORY=false
    volumes:
      - ollama-models:/root/.ollama
    restart: unless-stopped
    networks:
      - ai-internal
    # GPU-Support (optional, auskommentiert):
    # deploy:
    #   resources:
    #     reservations:
    #       devices:
    #         - driver: nvidia
    #           count: 1
    #           capabilities: [gpu]

volumes:
  open-webui-data:
  ollama-models:

networks:
  ai-internal:
    driver: bridge
    internal: true   # Container ohne direkten Internetzugang

Löschkonzept: Recht auf Vergessenwerden technisch umsetzen

Art. 17 DSGVO verpflichtet dich, personenbezogene Daten auf Antrag zu löschen. Bei einem LLM-Frontend bedeutet das: Die Konversationsverläufe müssen vollständig und nachweisbar entfernbar sein – inklusive aller Backups. Ein Löschkonzept ohne Backup-Berücksichtigung ist kein Löschkonzept.

Open-WebUI bietet zwei Wege für die Löschung:

1. Nutzer selbst: Settings → Chats → „Alle Chats löschen"
2. Admin per API: Für systemseitige Löschprozesse (z. B. nach Mitarbeiteraustritt)

# Alle Chats eines Nutzers per Admin-API löschen
curl -X DELETE http://localhost:3000/api/v1/chats/all \
  -H "Authorization: Bearer <ADMIN_TOKEN>"

# Einzelnen Nutzer löschen (inkl. aller Konversationen)
curl -X DELETE http://localhost:3000/api/v1/users/<USER_ID> \
  -H "Authorization: Bearer <ADMIN_TOKEN>"

# Löschung in der SQLite-Datenbank verifizieren
sqlite3 /app/backend/data/webui.db \
  "SELECT COUNT(*) FROM chat WHERE user_id='<USER_ID>';"
# Erwartetes Ergebnis: 0

Backup-Verschlüsselung nicht vergessen: Die webui.db enthält alle Konversationen im Klartext. Backups müssen verschlüsselt werden (z. B. mit age oder GPG), und die Backup-Rotation muss die DSGVO-Löschfristen widerspiegeln. Ein Backup, das nach einem Löschantrag noch 90 Tage unverschlüsselt aufbewahrt wird, verletzt Art. 17 DSGVO.

Verarbeitungsverzeichnis nach Art. 30 DSGVO

Auch ohne externen Auftragsverarbeiter ist das Verarbeitungsverzeichnis Pflicht – für Organisationen ab 250 Mitarbeitern generell, für kleinere Unternehmen wenn die Verarbeitung ein Risiko birgt oder nicht nur gelegentlich erfolgt. Ein interner LLM, der täglich genutzt wird, fällt nahezu immer darunter.

Mindestinhalt für einen On-Premise-LLM-Eintrag:

Name der Verarbeitung: Interne LLM-Nutzung (On-Premise)
Verantwortlicher: [Organisation, Adresse, Datenschutzbeauftragter]
Zweck: Unterstützung interner Arbeitsprozesse durch KI-Sprachmodell
Rechtsgrundlage: Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse)
                 oder lit. b (Vertragsdurchführung) oder lit. a (Einwilligung)
Betroffene Kategorien: Mitarbeiterdaten, ggf. Kundendaten (je nach Nutzung)
Empfänger: keine externen (reines On-Premise)
Drittlandtransfer: keiner
Löschfrist: Konversationen nach [X Tagen/Monaten], Logs nach 6 Monaten
TOM: Verschlüsselung at rest (WEBUI_SECRET_KEY), Zugriffskontrolle (RBAC),
     Netzwerkisolation (Docker internal network), Backup-Verschlüsselung

Die Wahl der Rechtsgrundlage hängt vom Einsatzzweck ab: Wird der LLM für die Vertragserfüllung mit dem Mitarbeiter genutzt (lit. b), für legitime Geschäftsinteressen (lit. f) oder verlangt der Einsatz eine Einwilligung (lit. a bei besonders sensiblen Daten)? Diese Frage sollte der DSB begleiten.

Wann ist eine DSFA Pflicht?

Eine Datenschutz-Folgenabschätzung (DSFA) nach Art. 35 DSGVO ist kein optionaler Mehraufwand, sondern gesetzliche Pflicht, sobald die Verarbeitung voraussichtlich ein hohes Risiko für Rechte und Freiheiten natürlicher Personen erzeugt. Die häufigsten Auslöser beim LLM-Einsatz:

1. Automatisierte Entscheidungen mit Rechtswirkung oder erheblicher Beeinträchtigung (Art. 22 DSGVO) – z. B. Bewerbungsscreening, Kreditwürdigkeitsprüfung
2. Profiling von Mitarbeitern oder Kunden
3. Verarbeitung besonderer Datenkategorien nach Art. 9 DSGVO (Gesundheitsdaten, Gewerkschaftszugehörigkeit, biometrische Daten)
4. Großflächige Verarbeitung personenbezogener Daten

Viele Aufsichtsbehörden empfehlen eine kombinierte DSFA für DSGVO und EU AI Act, um doppelten Aufwand zu vermeiden. Eine reine interne Textproduktionshilfe ohne Personenbezug erfordert in der Regel keine DSFA – aber diese Einschätzung muss dokumentiert sein.

EU AI Act: Was gilt ab 2026?

Der EU AI Act unterscheidet zwischen Hochrisiko-KI-Systemen (Annex III) und allen anderen Anwendungen. Interne Assistenz-Tools für Textentwürfe oder Wissensdatenbanken fallen meist nicht unter Hochrisiko – entscheidend ist der konkrete Verwendungszweck, nicht das eingesetzte Modell.

Wer jedoch ein LLM für Bereiche aus Annex III einsetzt (Personalverwaltung, Bildung, kritische Infrastruktur), muss ab dem 2. August 2026 folgendes sicherstellen:

1. Art. 12 EU AI Act: Automatisches Event-Logging über den gesamten Betriebszeitraum
2. Art. 19 EU AI Act: Aufbewahrung der Logs mindestens 6 Monate

Für selbst gehostete Deployments bedeutet das: Ein strukturiertes Logging-System (z. B. Loki, ELK-Stack oder Langfuse Self-Hosted) muss Prompts, Responses und Systementscheidungen mit Zeitstempel erfassen und revisionssicher aufbewahren. Legislative Verschiebungen für bestimmte Annex-III-Kategorien auf Dezember 2027 oder August 2028 sind in der Diskussion – die Pflicht kommt, der genaue Zeitpunkt ist zu verifizieren.

DSGVO-Gesamtcheckliste für On-Premise LLM

Troubleshooting / Typische Fallstricke

OLLAMA_KEEP_HISTORY nicht gesetzt

Die CLI-History in ~/.ollama/history enthält alle bisherigen Prompts als Klartext. In Produktivumgebungen ist dies ein klares Datenschutzproblem. Prüfen: cat ~/.ollama/history – wenn die Datei existiert und Inhalt hat, sofort OLLAMA_KEEP_HISTORY=false setzen und die Datei löschen.

WEBUI_SECRET_KEY nicht persistent

Wird kein Key in der .env-Datei festgeschrieben, generiert Open-WebUI bei jedem Container-Neustart einen neuen Schlüssel. Folge: Alle verschlüsselten API-Keys und OAuth-Tokens werden unleserlich, alle Nutzer werden ausgeloggt. Lösung: Key aus .env lesen und Volume für /app/backend/data persistent mounten.

Open-WebUI auf 0.0.0.0 exponiert

Docker umgeht standardmäßig iptables-Regeln. Eine Firewall-Regel allein schützt nicht. Im Compose-File muss der Port explizit auf 127.0.0.1:3000:8080 gebunden sein, nicht auf 3000:8080 (was 0.0.0.0 bedeutet).

Backups mit Klartext-Konversationen

Die webui.db-Backups enthalten alle Gespräche unverschlüsselt. Löschpflichten nach Art. 17 DSGVO gelten auch für Backup-Kopien. Backups verschlüsseln (z. B. mit age oder GPG) und Backup-Löschfristen dokumentieren.

Kein Verarbeitungsverzeichnis für LLM

Viele Organisationen führen LLMs als „interne Tool-Nutzung" ohne Art.-30-Eintrag. Bei einer Prüfung durch eine Aufsichtsbehörde ist das ein eindeutiges Bußgeldsignal. Jede neue Verarbeitungsform braucht einen eigenen Eintrag.

DSFA-Pflicht übersehen

Ein lokales Deployment ist nicht automatisch risikoarm. Wer den LLM für Personalentscheidungen, Kundenprofiling oder die Verarbeitung besonderer Datenkategorien einsetzt, muss eine DSFA durchführen – unabhängig davon, ob die Infrastruktur intern oder extern ist.

Häufige Fragen

Brauche ich einen AVV, wenn ich Ollama und Open-WebUI auf eigenem Server betreibe?

Nein – solange kein externer Dritter Zugang zu den Daten hat. Sobald ein Cloud-Hosting-Anbieter die Server betreibt oder ein Monitoring-SaaS Traces mit Prompts speichert, wird der AVV Pflicht. Den eigenen VPS bei Hetzner oder Netcup abzusichern erfordert zumindest einen Hoster-AVV.

Werden meine Prompts von Ollama gespeichert oder übertragen?

Bei lokalem Betrieb mit lokalen Modellen: nein. Laut offizieller Datenschutzerklärung von Ollama: „We do not collect, store, transmit, or have access to your prompts." Die einzige Ausnahme sind Cloud-Modelle (ab v0.12), die auf Ollama-eigener Datacenter-Hardware laufen.

Wie stelle ich sicher, dass Konversationen wirklich gelöscht sind?

Nach dem Löschen per Admin-API die SQLite-Datenbank direkt prüfen: sqlite3 webui.db "SELECT COUNT(*) FROM chat WHERE user_id='X';" – das Ergebnis muss 0 sein. Außerdem müssen verschlüsselte Backups in den Löschzyklus einbezogen werden.

Muss ich eine DSFA durchführen?

Nur wenn die KI-Verarbeitung voraussichtlich hohes Risiko erzeugt: automatisierte Entscheidungen mit Rechtswirkung, Profiling, biometrische Daten oder großflächige Verarbeitung besonderer Datenkategorien. Reine interne Textassistenz ohne Personenbezug erfordert in der Regel keine DSFA – aber diese Einschätzung muss dokumentiert werden.

Gilt der EU AI Act bereits für unseren lokalen LLM?

Nicht zwingend. Der EU AI Act unterscheidet klar zwischen Hochrisiko-KI und anderen Systemen. Interne Assistenz-Tools ohne entscheidungsrelevanten Einsatz fallen meist nicht unter Hochrisiko-Kategorien. Die Logging-Pflicht (Art. 12/19) gilt nur für als Hochrisiko eingestufte Systeme. Vollständige Anwendbarkeit ab dem 2. August 2026.

Muss das Verarbeitungsverzeichnis angepasst werden, wenn wir ein neues Modell einführen?

Nur wenn sich Zweck, Datenkategorien oder TOM-Maßnahmen ändern. Der Einsatz eines anderen Modells bei gleichem Einsatzzweck erfordert in der Regel keinen neuen Eintrag, wohl aber eine interne Dokumentation der Änderung.

Fazit

On-Premise-LLM-Deployments bieten echte Datenhoheit – aber nur, wenn die technischen und organisatorischen Maßnahmen konsequent umgesetzt werden. Der größte Vorteil gegenüber Cloud-KI: kein Drittland-Transfer, kein AVV mit einem externen Cloud-Anbieter nötig. Dafür liegt die gesamte Verantwortung für Löschkonzept, Zugriffssteuerung, Verschlüsselung und Dokumentation beim Betreiber selbst. Die technischen Maßnahmen – OLLAMA_KEEP_HISTORY=false, persistenter WEBUI_SECRET_KEY, Portbindung auf localhost, verschlüsselte Backups – sind in wenigen Minuten umgesetzt. Der organisatorische Teil – Verarbeitungsverzeichnis, Nutzungsrichtlinie, DSFA-Prüfung – braucht mehr Zeit, ist aber die Grundlage für einen rechtssicheren Betrieb.

Weiterführende Anleitungen und Quellen

1. Ollama und Open WebUI mit Docker: eigenes lokales KI-Sprachmodell ohne Cloud betreiben
2. Langfuse selbst hosten: LLM-Observability und Audit-Logging für KI-Anwendungen
3. Open WebUI absichern: Benutzergruppen, RBAC und Modell-Zugriffssteuerung
4. DSGVO-Praxis: TOMs dokumentieren und Auftragsverarbeitung regeln
5. EU AI Act für KMU: Compliance-Roadmap, KI-Inventar und Pflichten bis August 2026
6. Ollama Privacy Policy (ollama.com)
7. Open-WebUI Dokumentation: Chat History & Settings
8. BfDI: Datenschutz-Folgenabschätzungen und KI