Private AI Governance: SSO, Audit Logs und Compliance für Self-Hosted LLMs

Pexon Consulting | 10 Min. Lesezeit | 27.03.2026

TL;DR

Self-Hosted LLMs allein machen nicht compliant. Private AI Governance erfordert nachweisbare Authentifizierung, lückenlose Audit Logs und rollenbasierte Zugriffskontrolle. Dieser Artikel zeigt den konkreten Governance-Stack mit LiteLLM, Langfuse und Keycloak — inklusive Konfigurationsbeispielen, regulatorischen Anforderungen aus NIS2, DORA und EU AI Act sowie realistischer Aufwandsschätzung.

Self-Hosted ist nicht automatisch compliant

492 Millionen Dollar geben Unternehmen weltweit 2026 für AI Governance aus — und die Zahl steigt bis 2030 auf über eine Milliarde (Gartner, Februar 2026). Der Grund ist nicht Überregulierung, sondern ein konkretes Problem: Unternehmen betreiben KI-Systeme produktiv, ohne nachweisen zu können, wer wann welches Modell mit welchen Daten genutzt hat.

Wir sehen das regelmässig in Assessments. Ein Unternehmen hat Open WebUI oder LobeChat auf Azure deployed, vielleicht sogar mit Private Endpoints. Die Geschäftsleitung ist zufrieden — Daten bleiben im eigenen Tenant. Dann fragt der Auditor: Zeigen Sie mir die Zugriffsprotokolle der letzten 90 Tage. Wer hat personenbezogene Daten in welches Modell eingegeben? Nach welchen Kriterien wurden Zugriffsrechte vergeben?

Stille.

Das Deployment ist technisch sauber. Aber es fehlt die Governance-Schicht. Und genau das wird ab August 2026 zum regulatorischen Problem — nicht nur für Banken und Versicherungen, sondern für jedes Unternehmen, das unter NIS2 fällt.

Authentifizierung: Wer nutzt Ihr LLM?

Die erste Frage jedes Auditors lautet nicht „Welches Modell nutzen Sie?“, sondern „Wie authentifizieren sich Ihre Nutzer?“

Ohne zentrale Authentifizierung gibt es keine Zurechenbarkeit. Und ohne Zurechenbarkeit gibt es keine Compliance — egal ob DSGVO, NIS2 oder EU AI Act. Lokale Benutzerkonten in Open WebUI oder LobeChat reichen regulatorisch nicht aus, weil sie ausserhalb Ihres Identity Lifecycle Managements existieren. Mitarbeiter verlassen das Unternehmen, der Account bleibt aktiv. Klassisches Offboarding-Problem.

Was stattdessen nötig ist: SSO-Integration über OIDC oder SAML mit Ihrem bestehenden Identity Provider. In der Praxis bedeutet das Azure Entra ID (ehemals Azure AD) oder Keycloak. Open WebUI unterstützt seit 2025 SAML, OIDC und sogar SCIM 2.0 für automatisiertes User Provisioning. LiteLLM als API-Gateway bietet SSO-Integration ab Version 1.76 — für bis zu fünf Nutzer sogar kostenlos.

Eine minimale LiteLLM-Konfiguration mit Azure Entra ID sieht so aus:

# litellm_config.yaml — SSO + Modell-Routing
general_settings:
  master_key: "sk-live-xxxxx"
  store_audit_logs: true

litellm_settings:
  # Audit Logging aktivieren
  success_callback: ["langfuse"]
  failure_callback: ["langfuse"]

# SSO via Azure Entra ID (OIDC)
environment_variables:
  GENERIC_CLIENT_ID: "your-entra-app-id"
  GENERIC_CLIENT_SECRET: "your-client-secret"
  GENERIC_AUTHORIZATION_ENDPOINT: "https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize"
  GENERIC_TOKEN_ENDPOINT: "https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token"
  GENERIC_USERINFO_ENDPOINT: "https://graph.microsoft.com/oidc/userinfo"

model_list:
  - model_name: gpt-4o
    litellm_params:
      model: azure/gpt-4o
      api_base: https://your-endpoint.openai.azure.com/
      api_key: os.environ/AZURE_API_KEY
  - model_name: llama-3.1-70b
    litellm_params:
      model: ollama/llama3.1:70b
      api_base: http://ollama-internal:11434

Entscheidend: Die store_audit_logs: true Direktive muss gesetzt sein, sonst feuern die Audit-Callbacks nicht — ein Fehler, den wir in fast jedem zweiten Setup finden.

Audit Logs: Was der Regulator sehen will

Jetzt wird es konkret. Ein KI-Audit-Log muss mehr erfassen als klassische Application Logs. Die DSGVO verlangt Nachweispflichten bei der Verarbeitung personenbezogener Daten (Art. 30 DSGVO). NIS2 fordert Risikomanagement-Massnahmen für ICT-Systeme. Der EU AI Act bringt ab August 2026 Transparenzpflichten für KI-generierte Inhalte.

In der Praxis bedeutet das: Ihr Logging muss mindestens diese Felder pro Request erfassen:

Ob Sie Prompts im Volltext oder als Hash speichern, hängt von Ihrer Datenschutz-Folgenabschätzung ab. Wir raten bei Systemen mit Zugang zu personenbezogenen Daten dringend zu einer separaten DSFA — das ist keine optionale Fleissübung, sondern Pflicht nach Art. 35 DSGVO.

Langfuse als Observability-Plattform speichert genau diese Daten und lässt sich vollständig self-hosted betreiben — ein entscheidender Punkt für regulierte Unternehmen, die Trace-Daten nicht an Drittanbieter-Cloud-Dienste senden dürfen. Mit über 21.000 GitHub-Stars und der Übernahme durch ClickHouse ist Langfuse 2026 die am weitesten verbreitete Open-Source-Lösung in diesem Bereich.

Ein beispielhafter Query gegen die Langfuse-Datenbank, um alle Zugriffe eines bestimmten Nutzers in einem Zeitraum zu ermitteln:

-- Audit Query: Alle LLM-Zugriffe eines Nutzers in den letzten 90 Tagen
SELECT
  t.id AS trace_id,
  t.user_id,
  t.name AS operation,
  o.model,
  o.input,
  o.completion_tokens,
  o.start_time,
  o.end_time
FROM traces t
JOIN observations o ON t.id = o.trace_id
WHERE t.user_id = 'maria.schmidt@versicherung.de'
  AND t.timestamp >= NOW() - INTERVAL '90 days'
ORDER BY t.timestamp DESC;

Dieser Query beantwortet exakt die Frage, die ein Auditor stellt. Ohne diese Datengrundlage wird aus einer Routine-Prüfung schnell ein Finding.

Zugriffskontrolle: Nicht jeder braucht GPT-4o

RBAC für LLM-Zugriff klingt trivial, ist aber in der Praxis erstaunlich selten implementiert. Die meisten Self-Hosted-Setups geben allen authentifizierten Nutzern Zugriff auf alle Modelle. Das ist aus zwei Gründen problematisch.

Erstens: Kostenexplosion. GPT-4o über Azure OpenAI kostet ein Vielfaches von Llama 3.1 auf eigener Infrastruktur. Wenn die Marketingabteilung GPT-4o für Newsletter-Entwürfe nutzt, zahlen Sie Enterprise-Preise für eine Aufgabe, die ein 8B-Modell genauso gut erledigt.

Zweitens: Risikosegmentierung. Modelle mit Zugriff auf interne Wissensdatenbanken (RAG) sollten nur Nutzern zugänglich sein, die diese Daten auch einsehen dürfen. Das ergibt sich direkt aus dem Need-to-Know-Prinzip, das NIS2 in Art. 21 Abs. 2 fordert.

LiteLLM löst das über Team-basierte Modellzuweisung. Sie definieren Teams, weisen Modelle zu und setzen Budget-Limits — alles über die Admin-API oder die UI:

Was NIS2, DORA und der EU AI Act konkret fordern

Drei Regulierungen treffen 2026 zusammen und betreffen KI-Systeme direkt — auch wenn sie ursprünglich nicht dafür geschrieben wurden.

NIS2 gilt seit Oktober 2024 und wird in Deutschland über das NIS2-Umsetzungsgesetz durchgesetzt. Die Bussgelder für wesentliche Einrichtungen betragen bis zu 10 Millionen Euro oder 2 % des weltweiten Jahresumsatzes. Art. 21 fordert explizit Massnahmen zur Zugriffskontrolle und zum Risikomanagement für ICT-Systeme — und ein produktives LLM ist ein ICT-System. Die persönliche Haftung der Geschäftsleitung bei grober Fahrlässigkeit macht das Thema zum Vorstandsthema.

DORA betrifft Banken, Versicherungen und deren ICT-Dienstleister. Die Verordnung ist seit Januar 2025 anwendbar, aber nur 50 % der betroffenen Institute erwarten volle Compliance bis Ende 2025 — der Rest peilt 2026 an. DORA fordert in Art. 6-9 ein ICT-Risikomanagement-Framework, das ausdrücklich neue Technologien wie KI-Systeme umfasst. Ein Self-Hosted LLM ohne dokumentiertes Risikomanagement ist ein offenes Finding.

Der EU AI Act entfaltet seine volle Wirkung ab August 2026. Die Transparenzpflichten betreffen jeden, der KI-generierte Inhalte erstellt — auch intern. Besonders relevant für Self-Hosted-Setups: Wer ein GPAI-Modell (General Purpose AI) so modifiziert, dass er als Provider gilt, übernimmt Dokumentationspflichten. Das kann bei Fine-Tuning oder RAG-Erweiterungen der Fall sein. Die Strafen bei Verstössen erreichen bis zu 35 Millionen Euro oder 7 % des weltweiten Jahresumsatzes.

Praxis-Blueprint: Der Governance-Stack

Genug Regulatorik. So sieht eine Private AI Governance-Architektur in der Praxis aus:

Die entscheidende Erkenntnis: Das LLM selbst ist austauschbar. Die Governance-Schicht — Identity Provider, Gateway, Observability — bleibt stabil. Ob Sie morgen von Llama auf Mistral wechseln oder Azure OpenAI dazuschalten, ändert an Ihrer Compliance-Architektur nichts.

Kosten und Zeitrahmen

Transparenz bei Kosten gehört für uns zur Beratungsethik. Hier die realistischen Aufwände für den beschriebenen Governance-Stack:

Bei einem externen Tagessatz von 1.200-1.500 EUR landen Sie bei 18.000-36.000 EUR für die initiale Implementierung. Das klingt nach viel — bis Sie es mit den Alternativen vergleichen: Ein NIS2-Bussgeld von 10 Millionen Euro. Oder die durchschnittlichen Kosten eines Data Breach von 4,44 Millionen Dollar (IBM Cost of a Data Breach Report 2025). Organisationen, die KI-gestützte Sicherheitsmassnahmen einsetzen, sparen laut IBM durchschnittlich 1,9 Millionen Dollar pro Breach und verkürzen die Reaktionszeit um 80 Tage.

Private AI Governance ist keine Kostenstelle. Es ist eine Versicherung.

Häufig gestellte Fragen

Was kostet Private AI Governance für ein mittelständisches Unternehmen?

Rechnen Sie mit 18.000 bis 36.000 EUR für die initiale Implementierung des Governance-Stacks (LiteLLM, Langfuse, SSO-Integration, RBAC-Konzept, DSFA). Die laufenden Kosten für Infrastruktur liegen bei 150-450 EUR pro Monat. Der grösste Kostentreiber ist nicht die Technik, sondern die Dokumentation — insbesondere die Datenschutz-Folgenabschätzung und das Risikomanagement-Framework, das NIS2 und DORA fordern.

Reicht Open WebUI allein für Compliance?

Nein. Open WebUI unterstützt seit 2025 SAML, OIDC und SCIM 2.0 — das ist gut für Authentifizierung und User Provisioning. Was fehlt: granulares Audit Logging auf Prompt-Ebene, budgetbasierte Zugriffskontrolle pro Team und die Integration in ein SIEM-System. Für regulierte Unternehmen empfehlen wir Open WebUI als Frontend in Kombination mit LiteLLM als Gateway und Langfuse für Observability.

Welche NIS2-Anforderungen betreffen KI-Systeme direkt?

Art. 21 NIS2 fordert Massnahmen in zehn Bereichen, von denen vier direkt auf KI-Systeme zutreffen: Zugriffskontrolle (Abs. 2i), Risikomanagement (Abs. 2a), Incident Handling (Abs. 2b) und Sicherheit der Lieferkette (Abs. 2d) — letzteres relevant, wenn Sie externe Modelle über APIs einbinden. Die Bussgelder betragen bis zu 10 Millionen Euro oder 2 % des weltweiten Jahresumsatzes für wesentliche Einrichtungen.

Brauchen wir eine Datenschutz-Folgenabschätzung für unser Self-Hosted LLM?

In den allermeisten Fällen: ja. Art. 35 DSGVO verlangt eine DSFA, wenn eine Verarbeitung voraussichtlich ein hohes Risiko für die Rechte und Freiheiten natürlicher Personen mit sich bringt. Ein LLM, das Mitarbeiterdaten, Kundendaten oder Geschäftsgeheimnisse verarbeitet, erfüllt dieses Kriterium. Die DSFA dokumentiert Risiken, Gegenmassnahmen und die Rechtsgrundlage der Verarbeitung — und genau das wollen Auditoren sehen.

Können wir den Governance-Stack auch On-Premise statt auf Azure betreiben?

Ja, vollständig. LiteLLM, Langfuse und Keycloak sind alle als Docker-Container oder Helm Charts verfügbar. Für echtes On-Premise-Deployment entfällt Azure Entra ID als Identity Provider — Keycloak übernimmt dann die Rolle. Die Architektur bleibt identisch, nur der Identity Provider und die Compute-Infrastruktur ändern sich. Gerade für Unternehmen mit strengen Datenlokalitätsanforderungen — etwa im Rüstungssektor oder bei Betreibern kritischer Infrastrukturen — ist das der bevorzugte Weg.

Nächster Schritt

Wenn Sie bereits ein Self-Hosted LLM betreiben und unsicher sind, ob Ihr Setup den Anforderungen von NIS2, DORA oder dem EU AI Act standhält: Wir bieten ein Private AI Security Assessment an. In fünf Tagen bewerten wir Ihre aktuelle Architektur, identifizieren Governance-Lücken und liefern einen konkreten Implementierungsplan mit Aufwandsschätzung.

Alternativ starten viele unserer Kunden mit einem halbtägigen Workshop, in dem wir gemeinsam den Governance-Reifegrad Ihres KI-Setups bestimmen und Quick Wins identifizieren.

Zum Private AI Assessment →

Verwandte Themen