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

Ein lokales LLM ist nicht automatisch DSGVO-konform, senkt aber den Aufwand: Es gibt keinen Drittlandtransfer, und Sie kontrollieren die Daten vollständig. Sobald Mitarbeiter- oder Kundendaten in den Modell-Kontext gelangen, greifen Art. 5, 25, 30, 32 und je nach Einsatz Art. 35 DSGVO. Diese Anleitung ist eine umsetzbare Checkliste für KMU-Admins und Selfhoster; sie ersetzt keine Rechtsberatung.

Voraussetzungen

1. Laufende Ollama- und Open-WebUI-Installation oder ein Linux-Host mit Docker für die Compose-Datei unten (Hardware siehe Ollama und Open WebUI mit Docker)
2. TLS-Zertifikat für HTTPS-Zugriff (Let's Encrypt oder interne CA)
3. Verarbeitungsverzeichnis und, falls benannt, Datenschutzbeauftragter (DSB)
4. Backup-Lösung mit Verschlüsselung (z. B. Restic, verschlüsselt Repositories immer)

Wann brauche ich überhaupt einen AVV?

Ein Auftragsverarbeitungsvertrag (Art. 28 DSGVO) ist nötig, wenn ein Dritter personenbezogene Daten in Ihrem Auftrag verarbeitet. Bei einem rein internen Deployment (eigener Server, eigenes Netz, kein externer Zugriff) entfällt er.

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: laufen auf Hardware von Ollama

Verstöße gegen Art. 28 DSGVO sind nach Art. 83 Abs. 4 DSGVO mit Bußgeldern bis zu 10 Millionen Euro oder 2 Prozent des weltweiten Jahresumsatzes bedroht. Selbst gehostetes Langfuse auf eigener Infrastruktur braucht keinen AVV.

Ollama absichern: History-Logging und Cloud-Modelle

Bei lokalen Modellen speichert Ollama laut Privacy Policy keine Prompts. Aber: Die interaktive CLI (ollama run) speichert eine Prompt-History als Klartext in ~/.ollama/history.

Die Umgebungsvariable OLLAMA_NOHISTORY schaltet das ab. Sie wirkt auf der Client-Seite, also in der Shell der Benutzer, die ollama run aufrufen:

# Dauerhaft für alle Benutzer des Hosts
echo 'export OLLAMA_NOHISTORY=1' | sudo tee /etc/profile.d/ollama-nohistory.sh

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

# Verifizieren (neue Shell): Ausgabe 1
echo $OLLAMA_NOHISTORY

Wichtig ab Ollama v0.12+: Es gibt jetzt Cloud-Modelle, die auf Ollama-Datacenter-Hardware laufen. Unterbinden oder regeln Sie in Unternehmensumgebungen den Login mit einem Ollama-Account, damit Mitarbeiter nicht versehentlich Cloud-Modelle auswählen und Daten die eigene Infrastruktur verlassen.

Lokale Modelle laden Sie einmalig aus der Ollama-Registry; die Inferenz läuft danach ohne externe Dienste:

# 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). Löschfristen müssen daher technisch durchsetzbar und der Zugriff auf die Datei kontrolliert sein.

Drei Konfigurationspunkte sind Pflicht:

1. WEBUI_SECRET_KEY: Ohne gesetzten Wert erzeugt Open WebUI beim Start einen Schlüssel in einer Datei im Container, die beim Neuerstellen verloren geht. Ein neuer Schlüssel meldet alle Nutzer ab und macht damit verschlüsselte Secrets (z. B. OAuth-Tokens) unlesbar. Setzen Sie ihn daher fest.
2. Port-Bindung auf 127.0.0.1: Ohne explizite Bindung an localhost veröffentlicht Docker den Port auf allen Netzwerkschnittstellen. Eine UFW-Regel allein reicht nicht, weil Docker eigene iptables-Regeln vor UFW einträgt. Zugriff von außen über einen Reverse-Proxy mit TLS.
3. Telemetrie deaktiviert lassen: Das offizielle Image setzt ANONYMIZED_TELEMETRY=false, DO_NOT_TRACK=true und SCARF_NO_ANALYTICS=true; die explizite Angabe dokumentiert das im Sinne der Datenminimierung (Art. 5 Abs. 1 lit. c DSGVO).

# Secret-Key erzeugen 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
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
      - ENABLE_SIGNUP=false                          # Keine offene Registrierung (nach Anlage des Admins)
      - DEFAULT_USER_ROLE=pending                    # Neue Nutzer erst nach Freigabe
      - ANONYMIZED_TELEMETRY=false                   # Datenminimierung (Image-Standard)
      - DO_NOT_TRACK=true
      - SCARF_NO_ANALYTICS=true
    volumes:
      - open-webui-data:/app/backend/data            # DB persistent halten
    restart: unless-stopped
    networks:
      - ai-internal
      - default

  ollama:
    image: ollama/ollama:latest
    container_name: ollama
    environment:
      - OLLAMA_NOHISTORY=1
    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   # Ollama ohne Internetzugang; Open WebUI zusätzlich im default-Netz für die Portfreigabe

Ein Container nur in einem internal-Netz kann keine Ports veröffentlichen; Open WebUI hängt deshalb zusätzlich am Standardnetz. Ollama bleibt isoliert. Für ollama pull entfernen Sie internal: true kurzzeitig.

Verifizieren: docker compose up -d, danach zeigt ss -tlnp | grep 3000 nur 127.0.0.1:3000, und docker compose exec ollama env | grep NOHISTORY liefert OLLAMA_NOHISTORY=1.

Löschkonzept: Recht auf Vergessenwerden technisch umsetzen

Art. 17 DSGVO verpflichtet Sie, personenbezogene Daten auf Antrag und nach Wegfall des Zwecks zu löschen. Bei einem LLM-Frontend bedeutet das: Die Konversationsverläufe müssen vollständig und nachweisbar entfernbar sein – einschließlich einer dokumentierten Regel für Backups.

Zwei Wege zur Löschung:

1. Nutzer selbst: Settings → Chats → „Alle Chats löschen“
2. Admin per API: Löschen eines Benutzerkontos einschließlich seiner Chats (z. B. nach Mitarbeiteraustritt)

# Eigene Chats löschen (Token des betroffenen Nutzers)
curl -X DELETE http://localhost:3000/api/v1/chats/ \
  -H "Authorization: Bearer <ADMIN_TOKEN>"

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

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

Backup-Verschlüsselung nicht vergessen: Die webui.db enthält alle Konversationen im Klartext. Verschlüsseln Sie Backups (z. B. mit age oder GPG); mit Ablauf der Rotation verschwinden gelöschte Daten auch aus den Sicherungen. Dokumentieren Sie diese Frist im Löschkonzept und stellen Sie sicher, dass gelöschte Daten bei einer Rücksicherung nicht wieder produktiv genutzt werden.

Verarbeitungsverzeichnis nach Art. 30 DSGVO

Auch ohne externen Auftragsverarbeiter ist das Verarbeitungsverzeichnis Pflicht: ab 250 Beschäftigten generell, darunter nach Art. 30 Abs. 5 DSGVO, wenn die Verarbeitung ein Risiko birgt, nicht nur gelegentlich erfolgt oder besondere Datenkategorien betrifft. Ein täglich genutztes internes LLM 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 (Vertrag); Beschäftigtendaten ggf. § 26 BDSG
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

Einwilligungen von Beschäftigten sind wegen des Abhängigkeitsverhältnisses nur eingeschränkt freiwillig und als Grundlage für ein Arbeitswerkzeug ungeeignet. Besondere Datenkategorien (Art. 9 DSGVO) brauchen zusätzlich eine Ausnahme nach Art. 9 Abs. 2 DSGVO. Klären Sie die Wahl mit dem DSB.

Wann ist eine DSFA Pflicht?

Eine Datenschutz-Folgenabschätzung (DSFA) nach Art. 35 DSGVO ist 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 (Art. 22 DSGVO), z. B. Bewerbungsscreening
2. Profiling von Mitarbeitern oder Kunden
3. Verarbeitung besonderer Datenkategorien nach Art. 9 DSGVO (Gesundheitsdaten, Gewerkschaftszugehörigkeit, biometrische Daten)
4. Umfangreiche Verarbeitung personenbezogener Daten

Betreiber von Hochrisiko-KI nutzen nach Art. 26 Abs. 9 KI-Verordnung die Herstellerinformationen für ihre DSFA; beides lässt sich daher gemeinsam dokumentieren. Eine interne Textassistenz ohne Personenbezug braucht in der Regel keine DSFA; dokumentieren Sie diese Einschätzung.

EU AI Act: Was gilt seit dem Digital Omnibus?

Der EU AI Act unterscheidet zwischen Hochrisiko-KI-Systemen (Anhang III) und allen anderen Anwendungen. Interne Assistenz-Tools für Textentwürfe oder Wissensdatenbanken sind meist nicht hochriskant; entscheidend ist der Verwendungszweck, nicht das Modell.

Wer ein LLM für Bereiche aus Anhang III einsetzt (Personalverwaltung, Bildung, kritische Infrastruktur), muss die Hochrisiko-Pflichten erfüllen. Der Digital Omnibus (Verordnung (EU) 2026/1744, in Kraft seit 27. Juli 2026) hat den Termin für Anhang-III-Systeme vom 2. August 2026 auf den 2. Dezember 2027 verschoben. Dazu gehören:

1. Art. 12 EU AI Act: Das System muss Ereignisse automatisch protokollieren können (Pflicht des Anbieters)
2. Art. 26 Abs. 6 EU AI Act: Betreiber bewahren die Logs mindestens 6 Monate auf

Selbst gehostet heißt das: Ein Logging-System (z. B. Loki oder Langfuse Self-Hosted) erfasst Ereignisse mit Zeitstempel und bewahrt sie manipulationssicher auf. Unabhängig davon gilt seit Februar 2025 die KI-Kompetenzpflicht nach Art. 4.

DSGVO-Gesamtcheckliste für On-Premise LLM

Troubleshooting / Typische Fallstricke

OLLAMA_NOHISTORY nicht gesetzt

Prüfen Sie mit ls -l ~/.ollama/history; existiert die Datei, setzen Sie OLLAMA_NOHISTORY=1 und löschen sie.

WEBUI_SECRET_KEY nicht persistent

Symptom: Nach dem Neuerstellen des Containers sind alle Nutzer abgemeldet. Lösung: Key in .env festschreiben, siehe Abschnitt Open WebUI.

Open WebUI auf 0.0.0.0 veröffentlicht

ss -tlnp | grep 3000 zeigt 0.0.0.0:3000. Binden Sie den Port im Compose-File auf 127.0.0.1:3000:8080; eine UFW-Regel allein schützt nicht.

Backups mit Klartext-Konversationen

Siehe Abschnitt Löschkonzept: Backups verschlüsseln, Rotationsfrist als Löschfrist dokumentieren.

Kein Verarbeitungsverzeichnis für LLM

Ein fehlender Art.-30-Eintrag ist nach Art. 83 Abs. 4 DSGVO bußgeldbewehrt. Tragen Sie jede neue Verarbeitung ein.

DSFA-Pflicht übersehen

Auch ein lokales Deployment braucht eine DSFA, wenn es für Personalentscheidungen, Profiling oder besondere Datenkategorien genutzt wird.

Häufige Fragen

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

Nein, solange kein Dritter Zugang zu den Daten hat. Bei gemietetem Server oder Monitoring-SaaS mit Prompts ist ein AVV Pflicht.

Werden meine Prompts von Ollama gespeichert oder übertragen?

Bei lokalem Betrieb mit lokalen Modellen laut Ollama-Datenschutzerklärung nein. Ausnahmen: Cloud-Modelle (ab v0.12) und die lokale CLI-History, siehe oben.

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

Prüfen Sie nach dem Löschen die SQLite-Datenbank mit der Abfrage aus dem Abschnitt Löschkonzept; das Ergebnis muss 0 sein. Backups verlieren die Daten mit Ablauf der Rotation.

Muss ich eine DSFA durchführen?

Nur bei voraussichtlich hohem Risiko, siehe Abschnitt DSFA. Dokumentieren Sie auch eine Entscheidung dagegen.

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

Nicht zwingend; interne Assistenz-Tools ohne entscheidungsrelevanten Einsatz sind meist nicht hochriskant, Details siehe Abschnitt EU AI Act. Die KI-Kompetenzpflicht nach Art. 4 gilt aber bereits.

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

Nur wenn sich Zweck, Datenkategorien oder TOM ändern. Ein Modellwechsel bei gleichem Zweck braucht keinen neuen Eintrag; dokumentieren Sie ihn intern.

Fazit

On-Premise-LLMs vermeiden Drittlandtransfers; die Verantwortung liegt vollständig beim Betreiber. Die technischen Maßnahmen (OLLAMA_NOHISTORY=1, fester WEBUI_SECRET_KEY, Portbindung auf localhost, verschlüsselte Backups) sind schnell umgesetzt; Verarbeitungsverzeichnis, Nutzungsrichtlinie und DSFA-Prüfung brauchen mehr Zeit.

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
8. BfDI: Datenschutz-Folgenabschätzungen
9. Ollama: Umgebungsvariablen (envconfig)