Lokale KI im Unternehmen: Ollama und Open WebUI datenschutzfreundlich einsetzen

ChatGPT, Claude, Gemini und andere generative KI-Systeme sind längst im Arbeitsalltag angekommen. Mitarbeiter lassen E-Mails formulieren, Protokolle zusammenfassen, Quellcode analysieren oder technische Dokumentationen erstellen.

Für Unternehmen entsteht dabei jedoch ein Problem: Welche Informationen dürfen überhaupt an einen externen KI-Dienst übertragen werden?

Kundendaten, interne Dokumente, Quellcode, Verträge, personenbezogene Informationen oder vertrauliche Geschäftsdaten einfach in irgendeinen Cloud-Chatbot zu kopieren, kann schnell zum Datenschutz- und Sicherheitsrisiko werden.

Eine interessante Alternative ist deshalb eine lokale KI im Unternehmen. Mit Ollama als Laufzeitumgebung für Large Language Models und Open WebUI als komfortabler Weboberfläche können Unternehmen eigene KI-Systeme auf ihrer Infrastruktur betreiben. Eine Schritt-für-Schritt-Installationsanleitung findest du in Open WebUI + Ollama: Eigene ChatGPT-Alternative unter Linux (Zum Artikel).

Doch „lokal installiert“ bedeutet nicht automatisch „sicher“ oder gar „DSGVO-konform“.

Dieser Artikel zeigt, wie Unternehmen Ollama und Open WebUI so betreiben können, dass Datenschutz und IT-Sicherheit von Anfang an berücksichtigt werden.

Warum lokale KI für Unternehmen interessant wird

Bei klassischen Cloud-KI-Diensten verlässt eine Anfrage normalerweise die eigene Infrastruktur.

Vereinfacht sieht der Datenfluss so aus:

Mitarbeiter → Internet → KI-Anbieter → KI-Modell → Antwort

Für viele alltägliche Fragen ist das unproblematisch. Schwieriger wird es bei Informationen wie:

• Kundendaten
• Mitarbeiterdaten
• Vertragsinhalten
• internen E-Mails
• Tickets aus dem Helpdesk
• Serverkonfigurationen
• Logdateien
• Quellcode
• internen Prozessbeschreibungen
• unveröffentlichten Geschäftszahlen
• vertraulichen Dokumenten

Bei einer lokalen KI kann der Datenfluss dagegen beispielsweise so aussehen:

Mitarbeiter → internes Open WebUI → interner Ollama-Server → lokales KI-Modell

Die eigentliche Modellberechnung findet dann auf Hardware statt, die das Unternehmen selbst kontrolliert.

Ollama erklärt für lokal ausgeführte Modelle ausdrücklich, dass lokale Prompts und Antworten nicht an Ollama übertragen werden. Gleichzeitig bietet Ollama inzwischen aber auch Cloud-Modelle an. Ein Ollama-System ist deshalb heute nicht automatisch ein ausschließlich lokales System.

Genau dieser Unterschied ist für Unternehmen entscheidend.

Was sind Ollama und Open WebUI?

Ollama

Ollama stellt eine Laufzeitumgebung bereit, mit der sich zahlreiche offene beziehungsweise lokal verfügbare KI-Modelle ausführen lassen. Die Anwendung stellt außerdem eine API bereit, über die andere Anwendungen mit den Modellen kommunizieren können.

Beispiele für verfügbare Modellfamilien sind unter anderem:

• Qwen3
• Gemma 3
• gpt-oss
• zahlreiche spezialisierte Coding-, Embedding- und Reasoning-Modelle

Qwen3 steht beispielsweise in Größen von kleinen Modellen bis hin zu sehr großen Varianten zur Verfügung. Gemma 3 ist ebenfalls in mehreren Größen verfügbar, während OpenAIs gpt-oss unter anderem als lokale 20B- und 120B-Variante angeboten wird.

Dadurch kann ein Unternehmen das verwendete Modell an Hardware und Einsatzzweck anpassen.

Open WebUI

Open WebUI stellt eine benutzerfreundliche Oberfläche vor die eigentlichen Modelle. Für Mitarbeiter sieht das Ergebnis ähnlich wie ein bekannter KI-Chat aus:

• neue Chats erstellen
• Modelle auswählen
• Dateien hochladen
• Dokumente analysieren
• Wissen bereitstellen
• Benutzer verwalten
• Rollen und Berechtigungen vergeben
• APIs verwenden
• SSO integrieren

Open WebUI unterstützt unter anderem OIDC, LDAP, Rollen, Gruppen und weitere Mechanismen zur Zugriffskontrolle. Damit eignet sich das System wesentlich besser für einen zentralen Unternehmensbetrieb als eine Ollama-Installation auf jedem einzelnen Arbeitsplatz.

Der wichtigste Irrtum: Lokal bedeutet nicht automatisch DSGVO-konform

Einer der häufigsten Denkfehler lautet: „Die KI läuft auf unserem Server. Also haben wir kein Datenschutzproblem mehr.“

So einfach ist es nicht.

Eine lokale Architektur kann zwar einen erheblichen Datenschutzvorteil bieten, weil Daten nicht zwangsläufig an einen externen KI-Anbieter übertragen werden.

Personenbezogene Daten bleiben aber personenbezogene Daten – unabhängig davon, ob sie in Frankfurt, bei einem Hyperscaler oder im eigenen Serverraum verarbeitet werden.

Die DSGVO verlangt unter anderem:

• Rechtmäßigkeit der Verarbeitung
• Zweckbindung
• Datenminimierung
• Speicherbegrenzung
• Integrität und Vertraulichkeit

Artikel 32 fordert zusätzlich technische und organisatorische Maßnahmen, die zum jeweiligen Risiko der Verarbeitung passen.

Eine lokale KI kann also datenschutzfreundlicher gestaltet werden. Sie macht Datenschutz aber nicht überflüssig.

Wo lokale KI echte Datenschutzvorteile bietet

1. Unternehmensdaten können im eigenen Netzwerk bleiben

Der offensichtlichste Vorteil entsteht beim Datenfluss. Wird ein lokales Modell verwendet und externe Schnittstellen werden konsequent deaktiviert oder blockiert, müssen Prompts nicht zu einem externen Modellanbieter übertragen werden.

Damit reduziert sich die Anzahl beteiligter Systeme und möglicherweise auch die Anzahl externer Dienstleister. Das kann insbesondere interessant sein für:

• Rechtsabteilungen
• Personalabteilungen
• interne IT
• Softwareentwicklung
• Support
• Forschung und Entwicklung
• technische Dokumentation
• interne Wissensdatenbanken

2. Das Unternehmen kontrolliert die Infrastruktur

Bei einer selbst betriebenen Lösung können Administratoren selbst festlegen:

• auf welchem Server das System läuft
• wer darauf zugreifen darf
• welche Modelle verfügbar sind
• welche Daten gespeichert werden
• welche Netzwerke erreichbar sind
• welche Backups erstellt werden
• wann Daten gelöscht werden
• welche Logs entstehen
• welche externen Dienste erreichbar sind

Das ist ein wesentlicher Unterschied zu einem vollständig extern betriebenen SaaS-System.

3. Eigene Sicherheitsrichtlinien können technisch umgesetzt werden

Eine KI-Richtlinie für Mitarbeiter ist sinnvoll. Wie eine solche Richtlinie konkret aufgebaut sein kann, zeigen wir in KI-Richtlinie fürs Unternehmen: Was Mitarbeiter dürfen – und was nicht (Zum Artikel). Noch besser ist es allerdings, wenn bestimmte Regeln zusätzlich technisch durchgesetzt werden.

Beispiele:

Cloud-Modelle verboten? Dann werden Cloud-Funktionen deaktiviert.

Nur freigegebene Modelle? Dann werden ausschließlich diese Modelle bereitgestellt.

Keine öffentlichen Chat-Freigaben? Dann wird Sharing abgeschaltet.

Zugriff nur für Mitarbeiter? Dann erfolgt die Anmeldung beispielsweise über den zentralen Identity Provider.

Technische Kontrollen sind wesentlich zuverlässiger als die Hoffnung, dass jeder Mitarbeiter jede Richtlinie jederzeit korrekt beachtet.

Achtung: Ollama besitzt inzwischen Cloud-Funktionen

Dieser Punkt ist besonders wichtig. Ollama wird häufig weiterhin pauschal als „lokale KI“ bezeichnet.

Inzwischen unterstützt die Plattform jedoch zusätzlich Cloud-Modelle und weitere Cloud-Funktionen.

Wer ein echtes Local-Only-System betreiben möchte, sollte diese Funktionen deshalb ausdrücklich deaktivieren. Ollama unterstützt dafür beispielsweise:

OLLAMA_NO_CLOUD=1

Alternativ kann die Einstellung in der Ollama-Konfiguration vorgenommen werden:

{
  "disable_ollama_cloud": true
}

Nach dem Neustart werden die Cloud-Funktionen deaktiviert. Damit stehen unter anderem Ollamas Cloud-Modelle und dessen Websuche nicht mehr zur Verfügung.

Für besonders sensible Umgebungen sollte man sich jedoch nicht ausschließlich auf eine Anwendungseinstellung verlassen. Zusätzlich empfiehlt sich eine Netzwerkregel auf Firewall- oder Proxy-Ebene.

Dann gilt: Was das KI-System nicht erreichen darf, sollte es technisch auch nicht erreichen können.

Eine sinnvolle Architektur für lokale Unternehmens-KI

Eine einfache Unternehmensarchitektur kann folgendermaßen aufgebaut werden:

Mitarbeiter
  |
  | HTTPS
  v
Reverse Proxy / Load Balancer
  |
  v
Open WebUI
  |
  | internes Netzwerk
  v
Ollama Server
  |
  v
Lokale KI-Modelle

Optional kommen weitere Komponenten hinzu:

+----------------+
| Identity       |
| Provider / SSO |
+-------+--------+
        |
        v
Mitarbeiter --> Reverse Proxy --> Open WebUI
                                      |
                      +---------------+----------------+
                      |                                |
                      v                                v
                Ollama Server                    PostgreSQL
                      |
                      v
                 lokale LLMs

Für größere Installationen können auch mehrere Ollama-Backends genutzt werden. Open WebUI unterstützt mehrere beziehungsweise lastverteilte Ollama-Verbindungen.

Ollama-Port 11434 niemals ungeschützt veröffentlichen

Ollamas API läuft standardmäßig unter:

127.0.0.1:11434

Das ist zunächst sinnvoll, da sie damit nur lokal erreichbar ist. Über OLLAMA_HOST kann sie jedoch beispielsweise auf:

0.0.0.0:11434

umgestellt werden. Damit ist Ollama potenziell über das Netzwerk erreichbar.

Hier ist Vorsicht geboten. Für die lokale Ollama-API ist standardmäßig keine Benutzeranmeldung erforderlich. Deshalb sollte Port 11434 niemals einfach ins Internet veröffentlicht werden. Auch im Unternehmens-LAN sollte der Zugriff eingeschränkt werden.

Besser:

Benutzer
  |
  v
Open WebUI
  |
  v
Firewall
  |
  v
Ollama:11434

Nur Open WebUI beziehungsweise ausdrücklich autorisierte Systeme sollten Ollama erreichen dürfen.

Open WebUI gehört hinter HTTPS

Auch wenn eine Anwendung ausschließlich intern betrieben wird, sollten Benutzer nicht per unverschlüsseltem HTTP darauf zugreifen.

Open WebUI empfiehlt für produktive Installationen den Betrieb über HTTPS beziehungsweise einen entsprechend konfigurierten Reverse Proxy. HTTPS schützt unter anderem Chatverläufe, Anmeldedaten und hochgeladene Dateien während der Übertragung.

Typischer Aufbau:

https://ki.firma.intern
  |
  v
Nginx / HAProxy / Caddy
  |
  v
Open WebUI

Zusätzlich sollte ein gültiges internes oder öffentlich vertrauenswürdiges TLS-Zertifikat verwendet werden.

Authentifizierung niemals abschalten

Open WebUI kann ohne Benutzeranmeldung betrieben werden. Dafür existiert beispielsweise:

WEBUI_AUTH=False

Für einen persönlichen Testrechner mag dies praktisch sein. Für eine Unternehmensinstallation ist es normalerweise die falsche Entscheidung. Open WebUI aktiviert Authentifizierung standardmäßig.

Im Unternehmen sollte stattdessen nach Möglichkeit eine zentrale Authentifizierung eingesetzt werden. Geeignet sind beispielsweise:

• OpenID Connect
• OAuth
• LDAP
• Keycloak
• Microsoft Entra ID
• Okta
• andere vorhandene Identity Provider

Open WebUI unterstützt entsprechende SSO-Verfahren. Damit können Benutzerkonten mit der vorhandenen Unternehmensidentität verbunden werden.

Noch wichtiger: Verlässt ein Mitarbeiter das Unternehmen, kann sein Zugriff zentral entzogen werden.

Lokale Passwörter bei SSO deaktivieren

Ist SSO vollständig eingerichtet, kann es sinnvoll sein, zusätzlich die lokale Kennwortanmeldung zu deaktivieren. Open WebUI stellt dafür beispielsweise:

ENABLE_PASSWORD_AUTH=false

bereit. Die Dokumentation empfiehlt diesen Ansatz insbesondere für entsprechend konfigurierte produktive SSO-Installationen. So reduziert sich die Anzahl paralleler Authentifizierungswege.

Chatverläufe sind ebenfalls Unternehmensdaten

Die eigentliche Modellanfrage ist nur ein Teil des Datenschutzthemas. Open WebUI kann Chats, Dateien, Benutzerkonten und Konfigurationen persistent speichern.

Ein Mitarbeiter könnte beispielsweise schreiben: „Fasse mir bitte die Krankmeldung von Mitarbeiter X zusammen.“

Selbst wenn dieser Prompt niemals das Unternehmensnetzwerk verlässt, kann er anschließend in der Open-WebUI-Datenbank vorhanden sein.

Deshalb müssen Unternehmen entscheiden:

• Wie lange werden Chats gespeichert?
• Dürfen sensible Daten eingegeben werden?
• Wer kann Chatverläufe administrativ einsehen?
• Wann werden Daten gelöscht?
• Welche Daten landen im Backup?
• Wer hat Zugriff auf die Datenbank?
• Werden Speichermedien verschlüsselt?

Datenschutz endet nicht am KI-Modell.

Administratoren sind ein besonderer Vertrauensbereich

Open WebUI besitzt weitreichende Administratorrechte. Standardmäßig existieren Funktionen, mit denen Administratoren auf Chatinformationen und Exporte zugreifen können. Open WebUI weist ausdrücklich darauf hin, dass ein Administrator infrastrukturell einem sehr privilegierten Benutzer entspricht: Wer Zugriff auf Server und Datenbank besitzt, kann technische Zugriffsbeschränkungen innerhalb der Oberfläche grundsätzlich umgehen.

Für sensible Installationen sollten deshalb unter anderem Einstellungen wie diese geprüft werden:

ENABLE_ADMIN_CHAT_ACCESS=false
ENABLE_ADMIN_EXPORT=false
BYPASS_ADMIN_ACCESS_CONTROL=false

Wichtig: Diese Einstellungen ersetzen keine Trennung administrativer Verantwortlichkeiten. Ein Root-Benutzer auf dem Datenbankserver bleibt ein Root-Benutzer.

Dasselbe Least-Privilege-Prinzip gilt letztlich auch für KI-Agenten, die möglicherweise auf ein solches System zugreifen dürfen. Wie sich Rechte für KI-Agenten sauber begrenzen lassen, erklären wir in Welche Rechte darf ein KI-Agent bekommen? Sicherheitsregeln für Agenten (Zum Artikel).

Für besonders sensible Abteilungen kann deshalb sogar eine getrennte KI-Instanz sinnvoll sein. Beispielsweise:

• Open WebUI Allgemein
• Open WebUI Personal
• Open WebUI Rechtsabteilung
• Open WebUI Entwicklung

So können Datenbestände und administrative Zuständigkeiten stärker getrennt werden.

Datenbank verschlüsseln

Für kleine Installationen verwendet Open WebUI häufig SQLite. Die Hardening-Dokumentation unterstützt für verschlüsseltes SQLite SQLCipher:

DATABASE_TYPE=sqlite+sqlcipher

Für produktive Installationen mit mehreren Benutzern empfiehlt die Open-WebUI-Dokumentation dagegen PostgreSQL aufgrund besserer Skalierbarkeit und Zuverlässigkeit. Die Datenbank sollte dabei ausschließlich über interne Netzwerke erreichbar sein.

Bei PostgreSQL muss die Verschlüsselung des Speichers entsprechend auf Datenbank-, Storage- oder Betriebssystemebene umgesetzt werden.

Auch Backups gehören in diese Betrachtung. Ein verschlüsselter Produktivserver hilft wenig, wenn jede Nacht eine unverschlüsselte Datenbanksicherung auf einem frei zugänglichen NAS landet.

Open WebUI wirklich offline betreiben

Für stark abgeschottete Umgebungen besitzt Open WebUI einen Offline-Modus:

OFFLINE_MODE=true

Dieser deaktiviert unter anderem verschiedene ausgehende Funktionen und Update-Abfragen. Benötigte Modelle und Embeddings müssen dann lokal verfügbar sein.

Zusätzlich sollte geprüft werden, welche Funktionen tatsächlich benötigt werden. Eine Security-orientierte Umgebung könnte beispielsweise bewusst verzichten auf:

• externe Modellprovider
• Websuche
• externe Tools
• Benutzer-Webhooks
• öffentliche Freigaben
• externe Embedding-Dienste
• direkten Provider-Zugriff
• serverseitige Codeausführung

Je kleiner die Angriffsfläche, desto einfacher lässt sich das System kontrollieren.

Community Sharing abschalten

Open WebUI ermöglicht verschiedene Freigabefunktionen. Für sensible Unternehmensumgebungen sollte insbesondere geprüft werden:

ENABLE_COMMUNITY_SHARING=false

Die Open-WebUI-Hardening-Dokumentation empfiehlt, Sharing bei sensiblen Daten zu deaktivieren.

Das verhindert nicht jeden denkbaren Datenabfluss – ein Benutzer kann Inhalte beispielsweise weiterhin kopieren oder fotografieren. Es verhindert aber unnötige technische Freigabemöglichkeiten innerhalb der Anwendung.

Direkte Provider-Verbindungen verhindern

Eine besonders problematische Situation wäre: Das Unternehmen baut eine sichere lokale KI auf – Mitarbeiter können innerhalb der Oberfläche anschließend aber selbst wieder externe KI-Anbieter hinterlegen.

Damit wäre das eigentliche Ziel teilweise ausgehebelt. Open WebUI besitzt hierfür entsprechende Konfigurationsmöglichkeiten. Die Option:

ENABLE_DIRECT_CONNECTIONS=false

ist standardmäßig deaktiviert und sollte für ein kontrolliertes Local-Only-System entsprechend ausgeschaltet bleiben. Das gleiche Prinzip gilt für unnötige API-Passthrough-Funktionen.

CORS nicht auf „*“ lassen

Ein weiterer klassischer Sicherheitsfehler betrifft Cross-Origin Resource Sharing. Die Open-WebUI-Dokumentation weist darauf hin, dass CORS_ALLOW_ORIGIN standardmäßig * sein kann.

Für eine produktive Installation sollte stattdessen die tatsächlich verwendete Adresse freigegeben werden. Beispiel:

CORS_ALLOW_ORIGIN=https://ki.firma.de

Oder für mehrere interne Oberflächen:

CORS_ALLOW_ORIGIN=https://ki.firma.de;https://portal.firma.de

Auch dies gehört zum allgemeinen Hardening einer Webanwendung.

Codeausführung nur aktivieren, wenn sie wirklich gebraucht wird

Moderne KI-Oberflächen können längst mehr als nur Texte generieren. Tools, Python-Code, Funktionen und externe Schnittstellen machen ein System leistungsfähiger. Sie erhöhen aber gleichzeitig die Angriffsfläche.

Wenn Mitarbeiter lediglich Texte formulieren, Dokumentationen erstellen, Inhalte zusammenfassen oder technische Fragen beantworten sollen, wird möglicherweise überhaupt keine serverseitige Codeausführung benötigt.

Open WebUI empfiehlt für entsprechend gehärtete Installationen, nicht benötigte Codeausführung und automatische Paketinstallation zu deaktivieren.

Das Prinzip lautet: Nicht benötigte KI-Funktionen sollten nicht nur unbenutzt bleiben – sie sollten deaktiviert werden.

Updates kontrolliert durchführen

Bei produktiven Open-WebUI-Systemen sollte außerdem nicht blind ein Rolling-Tag wie :main verwendet werden.

Open WebUI empfiehlt für reproduzierbare beziehungsweise produktive Deployments ausdrücklich das Festlegen einer konkreten Version. Beispielsweise nach dem Schema:

ghcr.io/open-webui/open-webui:vX.Y.Z

Eine vernünftige Update-Strategie lautet:

Neue Version
  |
  v
Release Notes prüfen
  |
  v
Backup erstellen
  |
  v
Staging aktualisieren
  |
  v
Funktionstest
  |
  v
Security-Test
  |
  v
Produktion aktualisieren

Gerade bei Datenbankmigrationen ist Vorsicht notwendig. Open WebUI weist darauf hin, dass Datenbankmigrationen nicht zwangsläufig durch ein einfaches Downgrade des Containers rückgängig gemacht werden können.

Welche Hardware braucht lokale KI?

Die benötigte Hardware hängt stark vom Modell ab. Dabei spielen unter anderem eine Rolle:

• Modellgröße
• Quantisierung
• Kontextfenster
• Anzahl gleichzeitiger Benutzer
• CPU-Leistung
• RAM
• GPU
• VRAM

Kleine Modelle lassen sich teilweise problemlos auf normalen Rechnern ausführen. Größere Modelle profitieren erheblich von leistungsfähigen GPUs.

Beispiele aus der aktuellen Ollama-Modellbibliothek zeigen die Größenordnung:

Diese Werte entsprechen den jeweiligen veröffentlichten Ollama-Modellvarianten und sind nicht mit dem insgesamt erforderlichen Arbeitsspeicher beziehungsweise VRAM gleichzusetzen.

Für ein Unternehmen ist deshalb ein Pilotbetrieb sinnvoll, bevor teure GPU-Hardware gekauft wird.

Welche Aufgaben eignen sich für lokale KI?

Lokale KI muss nicht zwangsläufig versuchen, den leistungsfähigsten Cloud-Dienst in jedem Szenario zu ersetzen. Besonders interessant sind Aufgaben, bei denen Datenschutz wichtiger ist als maximale Modellleistung.

IT-Support

Beispiel: „Analysiere diesen journalctl-Auszug und erkläre, warum der Dienst nicht startet.“

Logs können sensible Informationen enthalten. Eine lokale Verarbeitung kann hier interessant sein.

Interne Dokumentationen

Beispiel: „Erstelle aus diesen technischen Notizen eine verständliche interne Dokumentation.“

Dabei bleiben interne Systemnamen, IP-Adressen oder Architekturinformationen im Unternehmen.

E-Mail-Entwürfe

Beispiel: „Formuliere aus diesen Stichpunkten eine professionelle Antwort an den Kunden.“

Der Mitarbeiter sollte trotzdem nur Daten verwenden, deren Verarbeitung für diesen Zweck erlaubt ist.

Quellcode analysieren

Entwickler können interne Projekte untersuchen lassen, ohne den Code zwangsläufig an einen externen Modellprovider übertragen zu müssen. Gerade bei proprietärer Software kann das ein erheblicher Vorteil sein.

Interne Wissensdatenbank

In Kombination mit Retrieval-Augmented Generation – kurz RAG – können interne Dokumentationen durchsuchbar gemacht werden. Beispielsweise: „Wie setzen wir laut unserer internen Dokumentation einen neuen HAProxy-Server auf?“

Das kann aus einer einfachen Chatoberfläche einen internen Wissensassistenten machen. Allerdings müssen auch die hierfür erzeugten Embeddings und Dokumentenspeicher in die Datenschutz- und Sicherheitsbetrachtung einbezogen werden.

Vorsicht bei personenbezogenen Daten

Nur weil eine Verarbeitung lokal stattfindet, bedeutet das nicht, dass beliebige personenbezogene Daten in ein KI-System eingegeben werden dürfen.

Vor der Einführung sollten Unternehmen beispielsweise definieren:

Grün – normalerweise unkritisch: öffentlich verfügbare Informationen, allgemeine technische Fragen, anonymisierte Texte, Musterkonfigurationen, allgemeine Dokumentationen.

Gelb – vorher prüfen: interne Dokumentationen, Logdateien, Kundentickets, interne E-Mails, geschäftliche Vertragsinformationen.

Rot – nur mit klar geregeltem Zweck und Freigabe: Gesundheitsdaten, umfangreiche Personalakten, besondere Kategorien personenbezogener Daten, hochsensible Geschäftsgeheimnisse, Zugangsdaten, Passwörter, private Schlüssel, API-Secrets.

Eine interne KI-Richtlinie sollte diese Kategorien für Mitarbeiter verständlich definieren.

Datenschutzfreundliche lokale KI als Gesamtkonzept

Eine sichere Installation besteht also nicht lediglich aus: Docker installieren, Ollama starten, Open WebUI starten, fertig.

Eine bessere Architektur berücksichtigt mehrere Ebenen:

Erst die Kombination dieser Maßnahmen macht aus einer lokalen KI einen ernsthaften Unternehmensdienst.

Beispiel für ein Local-Only-Sicherheitsprofil

Eine gehärtete Umgebung könnte konzeptionell beispielsweise folgende Einstellungen verwenden:

# Ollama
OLLAMA_NO_CLOUD=1

# Open WebUI
WEBUI_AUTH=true
OFFLINE_MODE=true

ENABLE_COMMUNITY_SHARING=false
ENABLE_DIRECT_CONNECTIONS=false
ENABLE_ADMIN_CHAT_ACCESS=false
ENABLE_ADMIN_EXPORT=false

BYPASS_ADMIN_ACCESS_CONTROL=false

CORS_ALLOW_ORIGIN=https://ki.firma.de

Bei eingerichtetem SSO zusätzlich beispielsweise:

ENABLE_PASSWORD_AUTH=false

Je nach Einsatzgebiet können weitere Funktionen wie Codeausführung, Tools, Webzugriff und Uploads eingeschränkt werden.

Wichtig ist, solche Konfigurationen nicht blind zu übernehmen. Das konkrete Sicherheitsprofil muss zum Unternehmen, dessen Bedrohungsmodell und den tatsächlich benötigten Funktionen passen.

Local-Only bedeutet auch Kontrolle des ausgehenden Netzwerkverkehrs

Für besonders sensible Systeme würde ich noch einen Schritt weiter gehen.

Nicht: „Unsere Konfiguration sagt, dass keine Cloud benutzt wird.“

Sondern: „Unser Netzwerk verhindert technisch, dass das KI-System unerlaubte Cloud-Dienste erreichen kann.“

Beispielsweise:

KI VLAN
  |
  v
Firewall
  |
  +--> DNS erlaubt
  +--> NTP erlaubt
  +--> Updates kontrolliert erlaubt
  |
  +--> Internet standardmäßig blockiert

Updates oder neue Modelle können über einen kontrollierten Prozess bereitgestellt werden. Damit entsteht ein wesentlich nachvollziehbareres Sicherheitsmodell.

Kann eine lokale KI Shadow AI verhindern?

Vollständig verhindern kann sie Shadow AI nicht. Sie kann jedoch einen wichtigen Teil der Lösung darstellen. Was Shadow AI genau bedeutet und welche Risiken dabei entstehen, erklären wir ausführlich in Shadow AI im Unternehmen: Wenn Mitarbeiter heimlich ChatGPT nutzen (Zum Artikel).

Wenn Mitarbeiter keinen brauchbaren internen KI-Dienst bekommen, suchen sie sich häufig selbst einen. Das Ergebnis können private Accounts bei beliebigen KI-Plattformen sein.

Stellt das Unternehmen dagegen einen schnellen und komfortablen internen KI-Assistenten bereit, sinkt der Anreiz für solche Umgehungslösungen. Welche technischen und organisatorischen Maßnahmen eine lokale KI dabei sinnvoll ergänzen, zeigen wir Schritt für Schritt in Shadow AI verhindern: Technische und organisatorische Maßnahmen für Unternehmen (Zum Artikel).

Das Ziel sollte deshalb nicht lauten: „KI ist verboten.“ Sondern eher: „Für interne und vertrauliche Aufgaben steht euch unsere freigegebene KI zur Verfügung.“

Technik, Richtlinien und Schulungen müssen dabei zusammenspielen.

Ist Ollama mit Open WebUI eine echte ChatGPT-Alternative?

Für viele interne Aufgaben: ja. Für alle Aufgaben: nein.

Große kommerzielle Cloudmodelle besitzen weiterhin Vorteile bei bestimmten komplexen Aufgaben, besonders großen Kontexten, spezialisierten Werkzeugen oder sehr rechenintensiven Reasoning-Aufgaben. Wie sich ChatGPT, Claude und Gemini dabei im Systemadministrations-Alltag konkret unterscheiden, zeigen wir in ChatGPT vs. Claude vs. Gemini für Systemadministratoren (Zum Artikel).

Lokale Modelle besitzen dagegen andere Vorteile:

• Datenhoheit
• eigene Infrastruktur
• kontrollierbare Netzwerkgrenzen
• keine klassischen Tokenkosten pro Anfrage bei lokaler Berechnung
• freie Modellwahl
• Offline-Betrieb
• Integration in interne Systeme

Unternehmen müssen deshalb nicht zwingend zwischen Cloud oder lokal wählen. Eine interessante Strategie kann auch sein:

Öffentliche Daten       → freigegebene Cloud-KI
Interne Daten           → lokale KI
Besonders sensible Daten → lokale isolierte KI oder keine KI-Verarbeitung

Entscheidend ist die Datenklassifizierung.

Fazit: Lokale KI ist Datenschutz durch Architektur

Ollama und Open WebUI ermöglichen Unternehmen heute mit überschaubarem Aufwand den Aufbau einer leistungsfähigen eigenen KI-Plattform.

Der größte Vorteil ist dabei nicht, dass plötzlich sämtliche Datenschutzprobleme verschwinden. Der eigentliche Vorteil lautet: Das Unternehmen erhält wesentlich mehr Kontrolle über den Datenfluss.

Modelle können auf eigener Hardware laufen. Externe Provider lassen sich vermeiden. Benutzer können zentral authentifiziert werden. Netzwerkzugriffe können technisch begrenzt und Daten innerhalb der eigenen Infrastruktur verarbeitet werden.

Genau darin liegt das Potenzial lokaler KI. Dafür muss sie allerdings wie ein echter Unternehmensdienst betrieben werden: mit Zugriffskontrollen, mit Verschlüsselung, mit Backups, mit Patchmanagement, mit Netzwerksegmentierung, mit Rollen und Berechtigungen, mit Löschkonzept und mit dokumentierten Richtlinien.

Ein ungeschützter Open-WebUI-Container und ein offen erreichbarer Ollama-Port sind keine Datenschutzstrategie.

Eine durchdachte Local-Only-Architektur dagegen kann für viele Unternehmen ein sinnvoller Baustein sein, um generative KI produktiv einzusetzen, ohne bei jedem internen Prompt automatisch Daten an einen externen KI-Anbieter übertragen zu müssen.

Häufige Fragen zu Ollama, Open WebUI und Datenschutz

Ist Ollama DSGVO-konform?

Eine Software ist nicht pauschal „DSGVO-konform“. Entscheidend ist, wie und zu welchem Zweck personenbezogene Daten verarbeitet werden. Lokale Ollama-Modelle können Datenübermittlungen an externe KI-Anbieter vermeiden und dadurch eine datenschutzfreundliche Architektur erleichtern. Die übrigen DSGVO-Pflichten des Unternehmens bleiben bestehen.

Sendet Ollama meine Prompts ins Internet?

Bei lokal ausgeführten Modellen gibt Ollama an, lokale Prompts und Antworten nicht zu erhalten. Ollama unterstützt inzwischen allerdings zusätzlich Cloud-Modelle und Cloud-Funktionen. Für einen konsequent lokalen Betrieb sollten diese mit OLLAMA_NO_CLOUD=1 beziehungsweise disable_ollama_cloud abgeschaltet werden.

Ist Open WebUI für Unternehmen geeignet?

Open WebUI unterstützt unter anderem Multi-User-Betrieb, Rollen, Gruppen, OIDC, LDAP und weitere Zugriffskontrollen. Für produktive Installationen ist allerdings ein entsprechendes Hardening erforderlich.

Braucht Open WebUI Internetzugriff?

Nicht zwingend. Open WebUI besitzt einen Offline-Modus. Für vollständig isolierte Installationen müssen benötigte Modelle, Embeddings und andere Komponenten lokal bereitgestellt werden.

Kann Ollama komplett ohne Cloud betrieben werden?

Ja. Ollama unterstützt einen Local-Only-Modus, bei dem Cloud-Funktionen deaktiviert werden. Für besonders hohe Sicherheitsanforderungen sollte zusätzlich der ausgehende Netzwerkverkehr durch Firewall-Regeln begrenzt werden.

Sollte Ollama Port 11434 im Internet erreichbar sein?

Nein. Ollama bindet standardmäßig an 127.0.0.1:11434, kann jedoch für Netzwerkzugriff umkonfiguriert werden. Da die lokale API nicht wie ein klassischer öffentlich angebotener Webdienst mit Benutzeranmeldung betrieben werden sollte, gehört sie hinter Firewall, Reverse Proxy beziehungsweise in ein vertrauenswürdiges internes Netzwerk.

Quellen und weiterführende Informationen

Der Beitrag berücksichtigt den Rechts- und Informationsstand vom 12. September 2026. Für die technischen und datenschutzrechtlichen Angaben wurden insbesondere die aktuelle Ollama-Dokumentation, die aktuelle Open-WebUI-Hardening-Dokumentation sowie Informationen der Europäischen Union und des Europäischen Datenschutzausschusses berücksichtigt. Ollama dokumentiert unter anderem den Local-Only-Modus, die standardmäßige Bindung der API an localhost sowie die inzwischen verfügbaren Cloud-Funktionen. Open WebUI dokumentiert umfangreiche Hardening-, Authentifizierungs-, Datenbank- und Netzwerkoptionen.

Die datenschutzrechtliche Einordnung orientiert sich unter anderem an den Grundsätzen aus Artikel 5 sowie den Sicherheitsanforderungen aus Artikel 32 DSGVO. Der Europäische Datenschutzausschuss weist außerdem darauf hin, dass der Einsatz von KI-Systemen weiterhin datenschutzrechtliche Fragestellungen bei der Verarbeitung personenbezogener Daten mit sich bringt.

Hinweis: Dieser Artikel stellt keine individuelle Rechts- oder Datenschutzberatung dar.

Weiterführende Themen

Open WebUI + Ollama: Eigene ChatGPT-Alternative unter Linux (Zum Artikel)

Shadow AI im Unternehmen: Wenn Mitarbeiter heimlich ChatGPT nutzen (Zum Artikel)

Shadow AI verhindern: Technische und organisatorische Maßnahmen für Unternehmen (Zum Artikel)

KI-Richtlinie fürs Unternehmen: Was Mitarbeiter dürfen – und was nicht (Zum Artikel)

Welche Rechte darf ein KI-Agent bekommen? Sicherheitsregeln für Agenten (Zum Artikel)

ChatGPT vs. Claude vs. Gemini für Systemadministratoren (Zum Artikel)