Wie baut man eine auf den Unternehmenseinsatz ausgerichtete praxistaugliche konsequent auf Open-Source basierte KI Lösung auf? Dazu habe ich ein paar Gedanken zusammengetragen – und natürlich ist das keine rein theoretische Betrachtung.

Für den ersten Ausbauschritt meiner Private-AI-Plattform ergänze ich eine benutzerfreundliche Oberfläche: Open WebUI für generische Chat-Interaktionen und Danswer für unternehmensweites, wissensbasiertes Fragen-und-Antworten. Beides bleibt vollständig in der eigenen Private Cloud und basiert auf Open Source – ohne Vendor Lock-in, mit klarer Governance und von Anfang an nach dem Prinzip Security by Design.

Architektonisch sitzt ein OpenAI-kompatibler Gateway (etwa LiteLLM) vor der Inferenzschicht mit vLLM bzw. TGI. Diese Vereinheitlichung sorgt dafür, dass Open WebUI und Danswer lediglich eine interne API adressieren, während Zugriff, Ratenbegrenzung, Logging und Routing zentral gesteuert werden. Open WebUI liefert den intuitiven Chat-Einstieg für unterschiedliche Modelle und Kontexte; Danswer wird zur Wissensschnittstelle, die Unternehmensquellen wie Confluence, SharePoint oder Git-Repositories erschließt und Antworten nur im Rahmen der jeweiligen Berechtigungen liefert. Die feingranulare Zugriffskontrolle erfolgt über OIDC-SSO mit Keycloak: Gruppen und Rollen werden zentral gepflegt und in beiden UIs strikt durchgesetzt. Damit bleiben sensible Inhalte dort, wo sie hingehören und sind nur für Personen sichtbar, die sie auch sehen dürfen.

Security by Design bedeutet hier, dass jede Komponente mit minimalen Rechten läuft, Netzwerkwege explizit erlaubt werden und Lieferketten abgesichert sind. Images werden in Harbor gehalten und mit Cosign signiert; Admission-Policies (z. B. Kyverno) lassen ausschließlich signierte Artefakte in den Cluster. Laufzeitschutz übernimmt Falco, während Wazuh Ereignisse aus System, Kubernetes und Anwendungen korreliert und zentral auswertet. Secrets werden nicht in Repos abgelegt, sondern über den External Secrets Operator aus einem Vault bezogen. Daten liegen verschlüsselt in MinIO (S3) und auf dem Block-Storage (z. B. Longhorn), Transportverschlüsselung per mTLS/TLS ist obligatorisch. Änderungen an der Plattform erfolgen deklarativ via GitOps mit Argo CD – jede Anpassung ist nachvollziehbar, reviewt und reproduzierbar. Observability ist ab Tag eins aktiv: Metriken, Logs und Traces laufen über Prometheus, Loki und OpenTelemetry in Grafana-Dashboards; Service-Level sowie Kosten- und Lastkennzahlen (etwa Token- und Latenzmetriken) werden transparent gemacht.

Der datenschutzkonforme Betrieb wird durch mehrere Maßnahmen gestützt: Daten bleiben on-premises; Egress ist standardmäßig gesperrt oder strikt allowlist-basiert. Danswer respektiert die Quellberechtigungen, sodass Retrieval nur auf Inhalte erfolgt, für die die anfragende Person auch in der Ursprungssystematik Zugriff hat. Für Protokollierung und Fehlersuche werden nur die notwendigen Metadaten erhoben; Aufbewahrungsfristen, Pseudonymisierung und Löschroutinen sind definiert. Optional können Prompt- und Antwort-Logs mit PII-Erkennung und -Redaktion (PII = persönlich identifizerbarer Informationen) zusätzlich gehärtet werden. Dieser Ansatz unterstützt eine DSGVO-kompatible Verarbeitung, weil er Datenminimierung, Zweckbindung und Zugriffstrennung praktisch umsetzt.

Auch in Bezug auf NIS2 ist die Plattform von Grund auf anschlussfähig: Asset-Transparenz durch GitOps und Service-Katalog, Härtung durch Policies und signierte Lieferketten, lückenlose Protokollierung und zentrale Auswertung, definierte Backups und Restores, dokumentierte Betriebs- und Incident-Runbooks sowie ein etabliertes Change- und Releasemanagement. Risikomanagement, Zugriffskontrollen, Security Monitoring und Notfallvorsorge sind nicht nachträgliche Anhängsel, sondern integraler Bestandteil der Betriebsarchitektur.

Quick Wins in der Umsetzung: Innerhalb von ein bis drei Tagen lässt sich ein funktionsfähiger Kern aufbauen, indem LiteLLM als Gateway vor vLLM/TGI gesetzt und per Keycloak-SSO abgesichert wird; Open WebUI wird direkt an das Gateway angebunden und dient als erste, kontrollierte Nutzerschnittstelle; Danswer wird mit read-only-Konnektoren für Confluence und/oder SharePoint verbunden und indexiert ausschließlich Inhalte im Rahmen bestehender ACLs; parallel aktivieren wir signierte Deployments (Harbor + Cosign) samt Admission-Policy, sodass nur verifizierte Images in den Cluster gelangen; abschließend entstehen Basis-Dashboards zu Latenz, Fehlerraten und Tokenkosten in Grafana und sicherheitsrelevante Telemetrie fließt in Wazuh.

Technische Komponenten im Kern: Der Gateway (LiteLLM) bündelt Zugriffe und Policies vor der Inferenzschicht (vLLM oder TGI) und bedient die UIs Open WebUI und Danswer über eine OpenAI-kompatible Schnittstelle. Identität und Berechtigungen liefert Keycloak via OIDC/RBAC. Artefakte liegen in Harbor und werden mit Cosign signiert; Kyverno setzt die Signaturpflicht und Basis-Policies durch. Falco schützt die Laufzeit, Wazuh korreliert Ereignisse. Secrets verwaltet der External Secrets Operator mit einem Vault-Backend. Daten und Modelle landen verschlüsselt in MinIO (S3) bzw. auf Longhorn; Ingress läuft über Traefik mit mTLS/TLS und NetworkPolicies. Deployments erfolgen GitOps-basiert mit Argo CD. Für Observability sorgen Prometheus, Loki und OpenTelemetry mit Visualisierung in Grafana; Backups und Wiederherstellung übernimmt Velero.

Blueprint für den ersten Ausbau: Nutzer authentifizieren sich gegen Keycloak und greifen über Open WebUI oder Danswer auf den zentralen Gateway zu. Dieser prüft Quoten, Protokollierung und Policies und leitet Anfragen an die jeweilige Inferenz-Engine (vLLM/TGI) weiter. Danswer synchronisiert definierte Wissensquellen, respektiert dabei die Quell-ACLs und erstellt einen Vektorindex (z. B. Qdrant oder Elasticsearch), sodass Antworten stets aus autorisierten Inhalten gespeist werden. Der Cluster akzeptiert ausschließlich signierte Images, Secrets kommen zur Laufzeit aus dem Vault, und der Ost-West-Verkehr ist über NetworkPolicies strikt segmentiert; Egress ist per Default dicht. Alle Änderungen an Konfiguration und Apps entstehen als Pull Requests, werden geprüft und von Argo CD ausgerollt; Telemetrie landet zentral, sicherheitsrelevante Ereignisse werden in Wazuh korreliert, und Velero fährt tägliche Backups mit regelmäßigem Restore-Test. So entsteht ein stabiler, auditierbarer und skalierbarer Pfad von der ersten Idee bis zum belastbaren Betrieb – DSGVO-konform, NIS2-tauglich und für den Unternehmenseinsatz geeignet.