IT-Wissen · IT-Wissen

KI-Modelle selbst betreiben: Open WebUI, LLM-Server und lokale KI

Kurz zusammengefasst: Lokale KI kann kleinen Unternehmen und dem Mittelstand mehr Kontrolle über Daten, Prozesse und Verfügbarkeit geben. Dafür braucht es eine passende Modell- und Serverauswahl, sichere Betriebsprozesse und realistische Erwartungen. Dieser Artikel ordnet Open WebUI, LLM-Server und Open-Source-Modelle ein und zeigt, worauf Unternehmen vor einem produktiven Einsatz achten sollten.

Nutzen und Einordnung

KI-Modelle selbst zu betreiben bedeutet, ein Sprachmodell auf eigener oder kontrollierter Infrastruktur bereitzustellen und über eine Anwendung nutzbar zu machen. Open WebUI kann dabei als webbasierte Bedienoberfläche dienen. Der eigentliche Modellbetrieb erfolgt jedoch durch einen angebundenen LLM-Server. Diese Bausteine erfüllen unterschiedliche Aufgaben und sollten nicht miteinander verwechselt werden.

Für kleine Unternehmen und den Mittelstand kann ein eigener Betrieb interessant sein, wenn interne Dokumente, Wissensabfragen oder Assistenzfunktionen verarbeitet werden sollen und dabei eine kontrollierbare technische Umgebung wichtig ist. Der Ansatz ist aber kein automatischer Datenschutz- oder Qualitätsnachweis. Zugriffsschutz, Protokollierung, Aktualisierung, Modelllizenzen, Backups und die fachliche Prüfung von Antworten bleiben Aufgaben des Betreibers.

Die Bausteine: Oberfläche, Server und Modell

Open WebUI ist die Bedien- und Integrationsschicht. Mitarbeitende können dort mit Modellen chatten und, abhängig von der Konfiguration, Dateien oder angebundene Wissensbestände nutzen. Open WebUI ist nicht selbst das Sprachmodell und ersetzt auch keinen Modellserver. Die Dokumentation sieht Verbindungen zu lokalen und OpenAI-kompatiblen Modellanbietern vor.

Ein LLM-Server stellt das Modell über eine lokale oder interne Schnittstelle bereit. Er übernimmt unter anderem das Laden des Modells, die Verarbeitung von Anfragen und die Kommunikation mit anfragenden Anwendungen. Je nach Produkt unterscheiden sich unterstützte Modellformate, Hardwareanforderungen, Parallelverarbeitung, API-Kompatibilität und Verwaltungsfunktionen. Deshalb sollte der Server nach dem konkreten Modell, der vorhandenen Hardware und den erwarteten Zugriffen ausgewählt werden.

Ollama ist ein möglicher lokaler Modellserver mit API. Eine andere technische Basis ist llama.cpp, das Modelle lokal ausführen und einen eigenen Server bereitstellen kann. Beide Ansätze stehen beispielhaft für die Trennung zwischen Benutzeroberfläche und Inferenzdienst.

Das Modell ist die Komponente, die Texte verarbeitet und erzeugt. Open-Source- oder offene Modelle sind nicht automatisch gemeinfrei und nicht automatisch für jede kommerzielle Nutzung freigegeben. Vor dem Einsatz müssen die konkrete Modelllizenz, mögliche Einschränkungen sowie die Herkunft der Gewichte und ergänzender Daten geprüft werden. Auch ein lokal betriebenes Modell kann falsche, veraltete oder unvollständige Antworten erzeugen.

Wie ein sinnvoller Betriebsaufbau aussieht

Ein belastbarer Aufbau beginnt mit einem klar begrenzten Anwendungsfall. Danach werden Datenklassen, Nutzergruppen, Antwortqualität und Verfügbarkeitsbedarf festgelegt. Erst dann folgt die technische Auswahl.

Typisch ist eine Trennung in vier Ebenen: die Weboberfläche für Nutzer, der LLM-Server für die Inferenz, das Modell samt zugehöriger Lizenz und die Daten- beziehungsweise Identitätsebene. Diese Trennung erleichtert Updates und reduziert die Gefahr, dass ein einzelner Dienst ungeprüft alle Funktionen und Datenzugriffe erhält.

Für den Betrieb gehören mindestens Netzwerksegmentierung, starke Authentisierung, Rollen und Berechtigungen, verschlüsselte Verbindungen, nachvollziehbare Protokollierung, regelmäßige Updates und ein Wiederanlaufkonzept dazu. Besonders wichtig ist die Frage, welche Eingaben und Dokumente gespeichert werden, wie lange sie vorgehalten werden und wer Administrations- oder Exportrechte besitzt.

Bei internen Wissensassistenten reicht es nicht, Dokumente in eine Oberfläche zu laden. Es muss geprüft werden, ob Berechtigungen aus dem Quellsystem erhalten bleiben, ob Inhalte nach Änderungen aktualisiert werden und ob Antworten auf die zugelassenen Dokumente zurückgeführt werden können. Eine Such- oder Retrieval-Komponente kann die Informationsbasis verbessern, beseitigt aber weder Berechtigungsfehler noch Halluzinationen.

Auswahl von Hardware und Modell

Die erforderliche Hardware hängt vom Modell, seiner Quantisierung, dem Kontextumfang, der Zahl gleichzeitiger Nutzer und dem gewünschten Antworttempo ab. Ein kleiner Einzelplatztest ist deshalb kein verlässlicher Nachweis für den späteren Mehrbenutzerbetrieb.

Für einen ersten Proof of Concept sollte mit repräsentativen, freigegebenen Testdaten gemessen werden: Antwortzeit, Fehlerrate, Abbruchverhalten, Speicherbedarf, gleichzeitige Anfragen und Verhalten bei langen Dokumenten. Die Ergebnisse sollten mit einem definierten Referenzdatensatz und einer fachlichen Bewertung dokumentiert werden.

Bei der Modellauswahl sind neben der Qualität auch Lizenzbedingungen, unterstützte Sprachen, Sicherheits- und Wartungsperspektive, verfügbare Dokumentation sowie die Möglichkeit eines kontrollierten Modellwechsels relevant. Ein größeres Modell ist nicht in jedem Anwendungsfall die bessere Wahl; entscheidend ist die Eignung für die konkrete Aufgabe.

Datenschutz, Sicherheit und Verantwortlichkeit

Lokale Verarbeitung kann den Datenfluss zu einem externen KI-Dienst reduzieren. Sie macht eine Verarbeitung aber nicht automatisch rechtmäßig oder sicher. Unternehmen müssen weiterhin Zweck, Rechtsgrundlage, Zugriffsrechte, Aufbewahrung, Löschung und gegebenenfalls eine Datenschutz-Folgenabschätzung prüfen.

Für produktive Systeme sollte außerdem festgelegt werden, welche Aufgaben das Modell nicht übernehmen darf. Personenbezogene, vertrauliche oder geschäftskritische Inhalte benötigen abgestufte Schutzmaßnahmen. Prompts, Dokumente, Ausgaben und Administrationsprotokolle können selbst sensible Informationen enthalten.

Die organisatorische Verantwortung bleibt beim Unternehmen. Ein Modell sollte daher nicht ohne fachliche Kontrolle verbindliche Entscheidungen treffen oder ungeprüft Inhalte an Kunden, Behörden oder Geschäftspartner senden. Mitarbeitende brauchen klare Regeln für Eingaben, Prüfung und Meldung von Fehlern.

Einführung in kontrollierten Schritten

Sinnvoll ist ein gestufter Ablauf: Anwendungsfall und Datenbestand abgrenzen, Modell und Lizenz prüfen, Testumgebung aufbauen, Messkriterien definieren, Sicherheitskonzept festlegen, Pilot mit einer kleinen Nutzergruppe durchführen und erst danach über den Regelbetrieb entscheiden.

Für den Übergang in den Betrieb sollten Verantwortlichkeiten, Updatefenster, Monitoring, Backup und Wiederherstellung, Supportweg sowie ein Rückfall auf eine vorherige Modellversion dokumentiert sein. Jede Änderung an Modell, Server, Plugins oder angebundenen Datenquellen kann die Ergebnisse und Risiken verändern und sollte deshalb nachvollziehbar freigegeben werden.

Beispiel aus der Praxis

Beispiel: Ein mittelständischer Betrieb möchte seine interne IT-Dokumentation, freigegebene Arbeitsanweisungen und ausgewählte Prozessbeschreibungen über einen internen Assistenten durchsuchbar machen. In einem abgegrenzten Pilotnetz betreibt er einen LLM-Server mit einem für den Anwendungsfall geeigneten Modell und stellt die Nutzung über Open WebUI bereit. Zunächst dürfen nur einige Mitarbeitende auf einen kuratierten Dokumentbestand zugreifen. Die Antworten werden anhand typischer Fragen geprüft, dürfen keine verbindlichen Freigaben auslösen und müssen bei kritischen Themen auf die Originaldokumentation verweisen. Vor einer Erweiterung werden Berechtigungen, Protokollierung, Aktualisierung der Dokumente, Modelllizenz und Wiederherstellung getestet. Das ist ein realistischer Einstieg; es ist keine erfundene Kundenreferenz.

Chancen für Unternehmen

• Kontrollierbarer Datenfluss: Bei geeigneter Konfiguration können ausgewählte Inhalte innerhalb der eigenen oder administrativ kontrollierten Umgebung verarbeitet werden.
• Anpassbare Integration: Oberfläche, LLM-Server, Modelle und Datenquellen lassen sich getrennt bewerten und schrittweise weiterentwickeln.
• Interne Verfügbarkeit: Ein Unternehmen kann die Nutzung seiner Assistenzlösung stärker von einzelnen externen Benutzeroberflächen oder Anbieteränderungen entkoppeln.
• Prozessunterstützung: Recherche, Entwürfe, Zusammenfassungen und Wissenszugriff können gezielt in interne Abläufe eingebunden werden, sofern die Ergebnisse geprüft werden.

Grenzen und Prüfpunkte

• Betriebsaufwand: Installation, Updates, Modellverwaltung, Rechte, Monitoring, Backups und Fehleranalyse müssen dauerhaft organisiert werden.
• Hardware- und Kapazitätsgrenzen: Antwortzeiten und gleichzeitige Nutzung hängen stark von Modell, Speicher, Beschleuniger und Konfiguration ab; ein Test mit einer Person belegt keinen stabilen Mehrbenutzerbetrieb.
• Keine automatische Fehlerfreiheit: Auch lokal betriebene Modelle können falsche oder überzeugend formulierte Antworten liefern.
• Lizenz- und Herkunftsprüfung: Modellgewichte, Software, Plugins und Dokumente können unterschiedliche Nutzungsbedingungen haben; kommerzielle Nutzung muss im Einzelfall geprüft werden.
• Datenschutz bleibt eine Aufgabe: Lokaler Betrieb beseitigt weder unzulässige Inhalte in Eingaben noch falsche Berechtigungen oder zu lange Aufbewahrung.
• Abhängigkeiten bleiben möglich: Hardware, Betriebssysteme, Modellformate, Treiber und Open-Source-Komponenten können sich ändern und müssen gepflegt werden.