LibreChat als zentrale KI-Plattform im Unternehmen
LibreChat verbindet verschiedene KI-Modelle, interne Datenquellen und Werkzeuge in einer zentralen Plattform. Entscheidend ist dabei weniger die Oberfläche als die Architektur dahinter: Datenwege, Berechtigungen, Integrationen und Betrieb müssen sauber zusammenspielen.
Wer KI über einzelne Experimente hinaus einsetzt, landet früher oder später bei drei Entscheidungen. Welches Modell soll eine Aufgabe übernehmen? Auf welche Unternehmensdaten darf es zugreifen? Und wie soll es damit arbeiten, damit aus einem einzelnen Chat eine wiederholbare Arbeitsweise wird?
Bei proprietären KI-Diensten sind diese Entscheidungen auf das beschränkt, was Anbieter, Tarif und Integrationsmodell zulassen. Auch der Zugriff auf interne Systeme folgt den technischen und vertraglichen Bedingungen des jeweiligen Dienstes.
LibreChat ist Open Source und damit anpassbar. Statt eine fertige Umgebung zu übernehmen, bauen Sie sich Ihre eigene: mit den Modellen, die Sie einsetzen wollen, mit Anbindungen an Ihre Fachsysteme und mit Berechtigungen, die zu Ihrer Organisation passen. So entsteht die Architektur, die Sie brauchen, und daraus eine Arbeitsumgebung statt eines Chatfensters. Wie souverän sie am Ende ist, hängt an genau diesen Entscheidungen.
Modellwahl nach Aufgabe und Schutzbedarf
Was Nutzende zuerst merken, ist eine gemeinsame Oberfläche für unterschiedliche Modelle und Dienste statt getrennter Abonnements und Gesprächsverläufe. LibreChat bringt native Anbindungen für die großen Anbieter mit; über sogenannte Custom Endpoints lassen sich weitere OpenAI-kompatible Dienste einbinden. Dahinter können ein Hyperscaler mit wählbarer Region, ein Router, ein direkter Hersteller-Endpunkt oder ein lokal betriebenes Modell stehen. Für erste lokale Installationen eignet sich beispielsweise Ollama. Entscheidend ist jedoch nicht der Name des Anbieters: Wo die Daten tatsächlich verarbeitet werden, hängt vom Vertrag und vom konkreten Endpunkt ab.
Die technische Vielfalt muss nicht vollständig bei den Nutzenden ankommen. In der Oberfläche sehen sie nur die Modelle, die für ihren Aufgabenbereich freigegeben sind. Verständliche Namen und ein klarer Hinweis auf den Verarbeitungsort erleichtern die Auswahl. Doch selbst diese begrenzte Auswahl muss nicht bei den Nutzenden liegen. Für die automatische Auswahl kann LibreChat einen Router wie LiteLLM als zentralen Modellendpunkt ansprechen. Er prüft jede Anfrage und leitet sie an die passende Route weiter. Unkritische Inhalte können an jedes dafür freigegebene Modell gehen, sensible Inhalte ausschließlich an ein Modell in der EU oder in der eigenen Umgebung. Das Sensitive Data Routing von LiteLLM arbeitet regelbasiert und erkennt definierte Muster oder Schlüsselbegriffe. Eine modellgestützte Bewertung lässt sich als zusätzliche Stufe ergänzen. Welche Variante sinnvoll ist, hängt vom Anwendungsfall und vom Schutzbedarf ab. Welche Daten wohin gelangen, darf jedoch nicht das Modell selbst entscheiden. Diese Grenze muss technisch vorgegeben und kontrollierbar sein.
Unternehmenswissen gezielt verfügbar machen
Nachdem feststeht, welches Modell eine Anfrage verarbeitet, folgt die zweite Entscheidung: Auf welche internen Informationen darf es zugreifen? Allgemeines Modellwissen allein reicht für viele betriebliche Aufgaben nicht aus. Der Nutzen entsteht, wenn Informationen aus Datenbanken, ERP-, CRM- oder anderen Fachsystemen hinzukommen. Statt Inhalte zu kopieren oder ganze Datenbestände hochzuladen, lassen sich die benötigten Informationen direkt aus ihrer Quelle abrufen.
LibreChat nutzt dafür unter anderem das Model Context Protocol, kurz MCP. Der offene Standard legt fest, wie KI-Anwendungen auf Werkzeuge und Datenquellen zugreifen. Ein solches Werkzeug kann beispielsweise eine Suche in der Warenwirtschaft oder einer Fachdatenbank anbieten. Es beschreibt, welche Aufgabe es erfüllt und welche Angaben es dafür benötigt. Stellt jemand eine passende Frage, ruft das Modell das Werkzeug mit den entsprechenden Kriterien auf. Ein Dienst im Unternehmensnetz fragt daraufhin das Fachsystem ab und liefert das Ergebnis zurück. Der gesamte Datenbestand muss dafür nicht übertragen werden.
Auch dieses Ergebnis gelangt allerdings in den Kontext des Modells und folgt der zuvor festgelegten Modellroute. Damit greifen Modellwahl und Datenzugriff unmittelbar ineinander: Die Anbindung bestimmt, welche Informationen in welchem Umfang zurückgegeben werden, die Modellroute bestimmt, wohin sie gelangen. Zugriffsrechte und Datenminimierung müssen deshalb bereits im Werkzeug durchgesetzt werden und dürfen nicht allein von der Entscheidung des Modells abhängen.
Anbinden lässt sich grundsätzlich jedes System, das eine geeignete Schnittstelle bereitstellt. Für verbreitete Anwendungen gibt es bereits fertige MCP-Server, deren Herkunft, Rechteumfang und Umgang mit Zugangsdaten vor dem produktiven Einsatz geprüft werden sollten. In LibreChat können solche Verbindungen zentral konfiguriert oder von berechtigten Nutzenden direkt über die Oberfläche eingerichtet werden. Anschließend lassen sie sich gezielt für einzelne Personen, Gruppen oder Rollen freigeben. Wo es für ein unternehmenseigenes Fachsystem keine fertige Anbindung gibt, kommt ein eigener MCP-Server ins Spiel. Hier helfen wir von wonk.ai mit unserer Erfahrung gerne weiter.
Einen eigenen MCP-Server bauen
Fertige MCP-Server decken verbreitete Systeme ab. Den größten Nutzen schaffen jedoch häufig individuelle Anbindungen an unternehmenseigene Fachsysteme. Dafür entwickeln wir MCP-Server, die auf den jeweiligen Anwendungsfall zugeschnitten sind. Ist bereits eine REST-Schnittstelle vorhanden, lässt sich ein erster Prototyp meist mit überschaubarem Aufwand entwickeln.
Ein MCP-Server kann unterschiedliche Bausteine bereitstellen. Tools sind Funktionen, die das Modell selbst aufruft, etwa eine Suche in einer Fachdatenbank. Resources stellen Inhalte bereit, die in ein Gespräch einbezogen werden können. Prompts stellen vorbereitete Anweisungen oder Gesprächseinstiege bereit, die Nutzende gezielt auswählen. Die Hauptlast tragen in der Praxis meist die Tools, und nicht jede KI-Anwendung unterstützt alle drei Arten gleichermaßen.
Bei individuellen Anbindungen endet die Arbeit nicht mit der technischen Verbindung. Ein Werkzeug muss so beschrieben sein, dass das Modell es in den passenden Situationen auswählt, und so begrenzt sein, dass es nur die erforderlichen Daten und Aktionen bereitstellt. Besonders Schreibzugriffe benötigen klare Berechtigungen, eine Prüfung der Eingaben und eine nachvollziehbare Protokollierung.
Auch die Darstellung der Ergebnisse entwickelt sich weiter. Bisher bereitet das Modell die zurückgegebenen Daten häufig als Text auf, wodurch Formulierung und Aufbau bei jeder Anfrage anders ausfallen können. MCP Apps ermöglichen stattdessen programmierte Oberflächen wie Tabellen, Formulare oder interaktive Auswertungen direkt im Gespräch. Die enthaltenen Daten bleiben dynamisch, ihre Darstellung folgt jedoch einer festgelegten Logik und lässt sich an das Corporate Design anpassen. Das Modell entscheidet weiterhin, wann es das Werkzeug verwendet; die Anwendung bestimmt, wie das Ergebnis erscheint.
MCP Apps sind seit Januar 2026 die erste offizielle Erweiterung für das Model Context Protocol. Die eingesetzte Plattform muss diese Erweiterung jedoch ausdrücklich unterstützen. In der von uns geprüften LibreChat-Version 0.8.7 ist das noch nicht der Fall.
Vom Datenzugriff zum Arbeitsergebnis
Nicht jedes Werkzeug muss selbst gebaut werden. Neben eigenen MCP-Servern bringt LibreChat Funktionen für Dokumente und Websuche mit. Gemeinsam lösen sie zunächst dasselbe Problem: Sie versorgen das Modell gezielt mit Informationen, die nicht in seinem Trainingswissen stecken. Beide Funktionen sind in die Oberfläche integriert, müssen aber zunächst konfiguriert werden und erzeugen eigene Datenwege. Bei Dokumenten können Originaldatei, extrahierter Text, Embeddings und die an das Modell übermittelten Treffer an verschiedenen Orten liegen. Bei der Websuche erreichen die Suchbegriffe Ihrer Mitarbeitenden den jeweiligen Suchanbieter.
Informationen abzurufen ist allerdings nur der erste Schritt. Häufig soll das Modell mit den gefundenen Daten weiterarbeiten, etwa eine Tabelle auswerten, eine Grafik erzeugen, einen Datenbestand bereinigen oder ein Szenario durchrechnen.
Genau dafür gibt es den Code Interpreter. LibreChat setzt dabei auf einen unter Apache 2.0 lizenzierten Open-Source-Dienst, der sich auf eigener Infrastruktur betreiben lässt. Das Modell schreibt Code, der Dienst führt ihn in einer isolierten Umgebung aus. Anders als bei einem fest gebauten MCP-Werkzeug muss deshalb niemand vorher wissen, welche konkrete Auswertung gebraucht wird. MCP kann den kontrollierten Zugriff auf die Daten liefern, der Code Interpreter übernimmt die flexible Verarbeitung.
Wo der Code ausgeführt und wie mit den entstehenden Dateien umgegangen wird, bleibt eine Architekturentscheidung. Der Dienst lässt sich abgeschottet auf eigener Infrastruktur betreiben. Nutzt man stattdessen die Ausführung eines externen Anbieters, richten sich Verarbeitungsort und Aufbewahrung nach dessen Bedingungen. Welcher Weg passt, entscheidet sich am Schutzbedarf der verarbeiteten Daten.
Agenten und Skills organisieren die Arbeit
Damit stehen die technischen Möglichkeiten fest: welches Modell arbeitet, auf welche Daten es zugreifen darf und welche Werkzeuge verfügbar sind. Eine wiederholbare Arbeitsweise entsteht daraus jedoch erst, wenn diese Möglichkeiten für eine konkrete Aufgabe zusammengeführt werden.
Dafür bündeln Agenten ein Modell, passende Anweisungen, Werkzeuge und Datenzugriffe. Sie lassen sich für bestimmte Aufgaben einrichten und gezielt für Personen oder Gruppen freigeben.
Skills ergänzen einen Agenten um wiederverwendbare Vorgehensweisen. Ein Controlling-Agent kann beispielsweise einen Skill für den Monatsbericht und einen weiteren für Szenarioanalysen verwenden. Im Qualitätsmanagement kann ein Skill festlegen, wie Dokumente geprüft, Abweichungen eingeordnet und Ergebnisse belegt werden.
Der Unterschied lässt sich einfach zusammenfassen: Der Agent bestimmt den Rahmen, der Skill beschreibt das Vorgehen. So werden aus einzelnen Funktionen wiederholbare Abläufe, die zentral gepflegt und für alle Beteiligten einheitlich bereitgestellt werden können.
Was der Betrieb verlangt
Von außen wirkt LibreChat zunächst wie eine einzelne Anwendung. Im Betrieb hängt die Plattform jedoch von vielen Komponenten ab: Benutzerverwaltung, Datenbank und Dateispeicher, Modellendpunkte und Router, Dokumentenverarbeitung, MCP-Server und Code Interpreter. Jede dieser Komponenten muss aktualisiert, abgesichert, überwacht und bei wachsender Nutzung skaliert werden. Je mehr Modelle, Agenten und Anbindungen hinzukommen, desto größer wird die Zahl der Abhängigkeiten.
Mit jedem Agenten entsteht deshalb nicht nur eine neue Funktion, sondern ein betriebliches Versprechen. Modell, Datenroute, Werkzeuge, Berechtigungen und Anweisungen müssen dauerhaft zusammenpassen. Aktualisierungen sind dabei ein eigener Betriebsprozess: Neue Versionen können Konfigurationen, Schnittstellen oder das Verhalten einzelner Funktionen verändern. Vor einem Update braucht es daher Sicherungen, nachvollziehbare Konfigurationen und Tests der wichtigsten Abläufe.
Viele Störungen bleiben zunächst unsichtbar. Die Oberfläche ist erreichbar, obwohl ein Modell nicht mehr antwortet, ein Zugangsschlüssel abgelaufen oder ein MCP-Server ausgefallen ist. Ein zentrales Monitoring, beispielsweise mit Prometheus und Grafana, sollte deshalb nicht nur die Anwendung selbst prüfen. Es muss auch Modellendpunkte, angebundene Dienste und die Code-Ausführung erfassen, Fehler und Laufzeiten sichtbar machen und bei Störungen aktiv alarmieren.
Zum Monitoring gehört auch die Kostentransparenz. Neben den nutzungsabhängigen Kosten für Modelle, Websuche, Embeddings, Speicher und Code-Ausführung entstehen laufende Aufwände für Infrastruktur, Überwachung und Wartung. Verbräuche und Kosten sollten deshalb je Dienst, Modell und Anwendungsfall nachvollziehbar sein. Budgets und Warnschwellen machen unerwartete Verbräuche und Fehlkonfigurationen sichtbar, bevor sie teuer werden.
Erst im laufenden Betrieb zeigt sich, ob die Architektur tatsächlich einwandfrei funktioniert. Anfragen müssen verlässlich beim richtigen Modell landen, Werkzeuge dürfen nur die freigegebenen Daten liefern, und Agenten sowie Skills müssen auch nach Aktualisierungen wie vorgesehen funktionieren. Die eigentliche Leistung liegt deshalb nicht in der Installation einer Oberfläche, sondern im dauerhaften Zusammenspiel dieser Komponenten.
Die Installation ist nur der Anfang. Wer eine solche Plattform als kleines IT-Projekt betrachtet, das nach der Inbetriebnahme abgeschlossen ist, unterschätzt ihre technische und organisatorische Komplexität. Souveränität entsteht nicht durch die eigene Installation allein, sondern durch einen verlässlichen Betrieb.
Genau diese Arbeit übernehmen wir für unsere Kunden: von der Architektur und der Modellroute über die Anbindung der Fachsysteme bis zur laufenden Überwachung.
Sie planen eine solche Plattform oder möchten eine bestehende stabilisieren? Beginnen wir mit einem Architektur- und Datenflusscheck Ihrer wichtigsten Anwendungsfälle.