Ein lokales Sprachmodell lässt sich schnell ausprobieren. Ein gemeinsamer KI-Assistent braucht zusätzlich einen geregelten Zugang, klare Datenwege und jemanden, der den Betrieb übernimmt. Ollama und Open WebUI können dafür zusammenarbeiten: Die eine Komponente führt Modelle aus, die andere stellt die Oberfläche für die tägliche Arbeit bereit.
Für ein Unternehmen beginnt die Planung mit einer konkreten Aufgabe: etwa Textentwürfe aus freigegebenen Stichpunkten, die Aufbereitung interner Notizen oder Unterstützung bei technischen Fragen. Welche Eingaben zulässig sind, wie Ergebnisse geprüft werden und welche Antwortzeiten im Alltag passen, gehört vor die Auswahl der Hardware.
Zwei Komponenten mit unterschiedlichen Aufgaben
Ollama stellt die Laufzeit und eine Programmierschnittstelle für Sprachmodelle bereit. Open WebUI ergänzt eine verwaltbare Weboberfläche. Eine lokal installierte Oberfläche sagt allerdings noch nicht, wo jedes verbundene Modell rechnet. Cloud-Modelle, Websuche und zusätzliche Werkzeuge können andere Datenwege verwenden.
Im hier dargestellten Betriebskonzept erreichen Mitarbeitende die Oberfläche über einen freigegebenen Zugang. Open WebUI verbindet sich intern mit Ollama. Die Modell-Schnittstelle bleibt auf die tatsächlich benötigten Dienste beschränkt. Bei getrennten Containern oder Servern müssen deren Verbindungen ausdrücklich geplant werden: localhost bezeichnet jeweils die eigene Netzwerkumgebung.
Vom Einzelplatz zum gemeinsamen Dienst
Der Unterschied liegt vor allem darin, was nach dem ersten erfolgreichen Chat passiert. Diese Gegenüberstellung beschreibt eine mögliche Ausbaustufe für einen kleinen Betrieb; sie ist eine Planungshilfe und kein dokumentiertes Kundenprojekt.
| Bereich | Einzeltest | Gemeinsamer Einsatz |
|---|---|---|
| Zugang | Eine Person testet am eigenen Rechner. | Eigene Konten, festgelegte Rollen und geregelter Entzug des Zugriffs. |
| Daten | Unkritische Beispieldaten. | Freigegebene Datenarten, Aufbewahrung und nachweisbare Quellrechte. |
| Erreichbarkeit | Der Rechner ist während des Tests eingeschaltet. | Vereinbarte Nutzungszeiten und ein dokumentierter Wiederanlauf. |
| Kapazität | Eine Anfrage liefert eine brauchbare Antwort. | Gleichzeitige Aufgaben, Wartezeiten und längere Eingaben werden gemessen. |
| Änderungen | Modell und Software werden ausprobiert. | Getestete Versionen, Sicherung vor Änderungen und ein belastbarer Rückweg. |
Zugang und Modell-API getrennt absichern
Die lokale Ollama-API verlangt laut Hersteller keine eigene Authentifizierung. Eine Netzwerkfreigabe ersetzt deshalb keine Zugangskontrolle. Für einen Unternehmensdienst sollte die Modell-API nur aus den benötigten internen Verbindungen erreichbar sein. Ein frei erreichbarer Port für alle Arbeitsplätze oder das Internet ist kein geeigneter Ausgangspunkt. Ollama: Authentifizierung (externer Link).
Für die Oberfläche werden Anmeldung, Benutzerfreigabe und Administrationsrechte bewusst konfiguriert. Ein vorhandener Identitätsdienst kann ein sinnvoller Anschluss sein; die passende Integration hängt von der Umgebung ab. Ein Proxy darf eine angemeldete Identität nur über vertrauenswürdige, von ihm selbst gesetzte Informationen weitergeben. Open WebUI: Zugang und Berechtigungen (externer Link).
HTTPS schützt die Verbindung vom Browser zum Zugangspunkt. Bei mehreren beteiligten Systemen wird auch der weitere Weg zum Backend nach Schutzbedarf verschlüsselt und begrenzt. Zertifikate, Weiterleitungen und die für die Oberfläche benötigten Verbindungen werden gemeinsam getestet. Open WebUI: HTTPS und Reverse Proxy (externer Link).
„Lokal“ durch den tatsächlichen Datenweg prüfen
Für ausschließlich lokale Modellaufrufe bietet Ollama einen Modus ohne seine Cloud-Funktionen an. Das ersetzt nicht die Prüfung weiterer Verbindungen in Open WebUI oder ergänzten Werkzeugen. Auch Modell-Downloads und Softwareupdates benötigen einen geplanten Bezugsweg. Ollama: lokale Nutzung und Cloud-Funktionen (externer Link).
- Modell: Welche konkrete Fassung verarbeitet die Anfrage, und an welchem Ort läuft sie?
- Dokumente: Wo werden Uploads, extrahierte Texte, Suchindizes und Sicherungen gespeichert?
- Zusatzdienste: Werden für Suche, Texterkennung, Sprache oder Einbettungen weitere Anbieter angesprochen?
- Werkzeuge: Welche Verbindung darf Daten lesen oder Aktionen auslösen, und mit wessen Rechten?
Cloud und Hybrid können geeignete Ergänzungen sein. Dann werden Anbieter, Datenarten und Freigaben ausdrücklich festgelegt. Ein Wechsel auf einen externen Dienst sollte nicht unbemerkt passieren, nur weil das lokale Modell gerade ausgelastet ist.
Firmenwissen erhält keine pauschale Freigabe
Eine Anmeldung beantwortet zunächst, wer die Oberfläche benutzt. Daraus folgt nicht automatisch das Recht, alle hochgeladenen Dokumente zu sehen. Im Beispiel könnte ein freigegebener Leitfaden für alle Pilotnutzer verfügbar sein, während Personalunterlagen vollständig außerhalb des Piloten bleiben.
Bei späterer Anbindung weiterer Quellen sind Rechte je Sammlung, Dokument und Nutzer zu prüfen. Auch Suchtreffer, Zitate, Chatfreigaben und gespeicherte Antworten können Informationen offenlegen. Änderungen an Gruppen oder Quellrechten müssen in der Wissenslösung wirksam werden. Mehr dazu auf den Fachseiten Unternehmenswissen & RAG und KI-Sicherheit und Berechtigungen.
Sicherung und Updates gehören zum Konzept
Gesichert werden die tatsächlich verwendeten Datenbestände: Datenbank, Uploads und Konfiguration sowie die für eine Wiederherstellung erforderlichen Schlüssel. Modellbezeichnung und exakte Fassung werden dokumentiert; angepasste Modelle und eigene Ergänzungen ebenfalls. Die Sicherung wird zugriffsgeschützt getrennt vom laufenden System aufbewahrt.
Vor einem Update gehören eine wiederherstellbare Sicherung, die Prüfung der Versionshinweise und ein Test außerhalb des Produktivdienstes dazu. Ein altes Container-Image allein stellt nach einer Datenbankmigration den vorherigen Zustand nicht zwingend wieder her. Open WebUI: Updates, Sicherung und Rückweg (externer Link).
Ein sinnvoller Wiederherstellungstest beginnt in einer getrennten Umgebung. Dort werden Anmeldung, Modellverbindung, eine unkritische Testaufgabe und die erwarteten Freigaben geprüft. Erst dann lässt sich einschätzen, wie lange ein Ausfall tatsächlich dauern würde. Eine laufende VM oder ein existierendes Backup-Verzeichnis allein belegt das noch nicht.
Eine laufende Oberfläche ist noch kein funktionierendes Modell
Die Überwachung sollte unterscheiden, ob die Oberfläche erreichbar ist, das gewählte Modell bereitsteht und eine vollständige Anfrage funktioniert. Diese Ebenen trennt auch die Open-WebUI-Dokumentation. Open WebUI: Funktionsüberwachung (externer Link).
Für den vereinbarten Betrieb werden zusätzlich Speicherbelegung, verfügbare Kapazität, Fehlerraten und Wartezeiten beobachtet. Testanfragen enthalten keine vertraulichen Inhalte. Protokolle sollten für die Fehlersuche ausreichen, ohne pauschal alle Gespräche zu duplizieren. Wer bei einer Störung reagiert und wer Updates freigibt, wird vor der breiteren Nutzung festgelegt.
Eine überschaubare Abnahme vor dem Start
- Zugang prüfen: Ein freigegebener Nutzer kommt hinein; ein nicht freigegebener Nutzer und ein unzulässiger Netzbereich bleiben ausgeschlossen.
- Datenweg prüfen: Modell, Oberfläche und alle Zusatzdienste verwenden ausschließlich die vereinbarten Verbindungen.
- Rechte prüfen: Zwei Testrollen erhalten nur die jeweils freigegebenen Inhalte. Ein entzogener Zugriff wirkt auch nach einer früheren erfolgreichen Suche.
- Last prüfen: Typische Aufgaben laufen einzeln und gleichzeitig; akzeptable Wartezeiten und Grenzen werden festgehalten.
- Wiederanlauf prüfen: Eine Sicherung lässt sich getrennt zurückspielen; Zuständigkeiten und Rückweg sind dokumentiert.
Die erforderliche Hardware hängt von Modell, Kontextlänge, paralleler Nutzung und Qualitätsziel ab. Aus der Architektur lässt sich deshalb keine allgemeine Zahl gleichzeitig bedienbarer Personen ableiten. Der vorhandene Beitrag Lokale KI testen: Ein Pilot mit aussagekräftiger Last vertieft diese Kapazitätsprüfung.
Mit einer begrenzten Aufgabe sinnvoll beginnen
DAXS kann die vorhandene Infrastruktur einordnen, Datenwege und Zugriffe planen und die Lösung in den vereinbarten Betrieb integrieren. Ein guter erster Schritt ist ein abgegrenzter Anwendungsfall mit prüfbarem Nutzen. Daraus ergibt sich, ob ein lokaler Dienst, eine Cloud-Anbindung oder eine Kombination wirtschaftlich und organisatorisch passt.
Lokale LLM & Infrastruktur · MCP & Schnittstellen · KI-Beratung & Automatisierung anfragen
Technischer Quellen: Das Beispiel beschreibt eine mögliche Architektur und einen Prüfablauf, keine universelle Installationsanleitung. Produktfunktionen, Modelllizenzen und die konkrete Systemkompatibilität werden für die eingesetzten Fassungen geprüft.