Open WebUI einordnen und Bedarf klären

Open WebUI einordnen und Bedarf klären

0:00 Willkommen zum ersten Modul. In vielen Unternehmen läuft es gerade so wie bei Brandtner Fördertechnik: Einzelne Teams nutzen irgendeinen KI-Assistenten aus der Cloud, jeder ein bisschen anders, niemand hat den Überblick. Die naheliegende Antwort lautet: Wir betreiben selbst eine Plattform. Genau darum geht es in diesem Seminar, um Open WebUI und um die Plattform Lotsenhaus, die wir Modul für Modul aufbauen.

0:23 Bevor wir aber auch nur einen Container starten, klären wir die wichtigere Frage: Was soll diese Plattform eigentlich besser machen, für wen, und woran merken wir das? Am Ende dieses Moduls halten Sie einen Anwendungsfall in der Hand, der sich prüfen lässt.

Open WebUI einordnen und Bedarf klären

0:38 Der erste Tag gehört der Planung, und der Satz auf dieser Folie erklärt, warum. Ein laufender Container ist schnell geschafft, das dauert eine Kaffeepause. Eine Plattform, die eine Arbeit messbar besser macht, ist etwas ganz anderes. Wir ordnen Open WebUI deshalb zuerst ein, sortieren Anwendungsfälle nach Nutzen und Risiko, stellen das Team zusammen und formulieren Erfolgskriterien, an denen sich der Pilot später messen lassen muss.

Open WebUI im KI-Gesamtsystem

1:04 Fangen wir mit der Landkarte an. Wer über Open WebUI spricht, meint oft das ganze KI-System. Dabei ist die Oberfläche nur ein Teil davon, und zwar einer von fünf. Stellen Sie sich Open WebUI wie die Empfangshalle eines großen Hauses vor. Hier melden sich die Leute an, hier wird entschieden, wer in welchen Raum darf, und hier liegen die Mappen mit dem Hauswissen bereit.

1:28 Die eigentliche Denkarbeit findet aber in anderen Räumen statt, bei den Sprachmodellen. Open WebUI verbindet lokale Modelle über Ollama, OpenAI-kompatible Schnittstellen und weitere Anbieter unter einer gemeinsamen Oberfläche. Dazu kommen Benutzerverwaltung, Wissensbasen und Erweiterungen. Die Modelle selbst betreibt es nicht.

1:47 Diese Unterscheidung klingt banal, aber sie entscheidet später über Architektur, Kosten und Verantwortung. Behalten Sie sie im Kopf. Die fünf Schichten zeigen, wie viel unter der Oberfläche liegt. Oben arbeitet Open WebUI mit Benutzern, Rechten und Assistenten. Darunter kann optional ein API-Gateway sitzen, das Budgets und Richtlinien durchsetzt und Anfragen an die passenden Anbieter verteilt.

2:12 Dann folgen die Modellserver, ob lokal mit Ollama oder extern. Daneben stehen Wissen und Werkzeuge, also Dokumente, Vektorsuche und Fachanwendungen wie ein Ticketsystem. Und ganz unten tragen die Plattformdienste alles: Identitätsanbieter, Datenbank, Speicher und Monitoring. Für Ihre Planung heißt das: Jede Schicht braucht einen Betrieb und eine Verantwortung. Wer nur die oberste plant, wird von den anderen überrascht.

2:39 Open WebUI ist nicht immer die richtige Antwort, und diese Tabelle hilft bei der ehrlichen Einordnung. Die Logik dahinter ist eine Abwägung zwischen Kontrolle und Aufwand. Ein SaaS-Assistent ist sofort da, verlangt aber, dass die Daten zum Anbieter dürfen. Eine eigene RAG-Anwendung passt genau auf einen Fachprozess, aber eben nur auf diesen einen.

3:00 Eine Workflow-Plattform arbeitet im Hintergrund, ganz ohne Menschen im Dialog. Open WebUI besetzt die Mitte: eine gemeinsame Arbeitsumgebung mit eigenen Daten, eigenen Modellen und eigenen Regeln. Und die Fußzeile ist wichtig. Diese Lösungen schließen sich nicht aus, sie lassen sich kombinieren. Der häufigste Irrtum: Man hält Open WebUI für das Modell. Ist eine Antwort schlecht, liegt das aber am Modell, nicht an der Oberfläche. Der zweite betrifft die Erwartung.

3:29 Wer eine vollwertige Agentenlaufzeit sucht, bekommt hier eine Chat-Oberfläche mit Werkzeugen, und das ist ein Unterschied. Der dritte ist technisch und fällt gern durch: Es gibt ein Image mit eingebauten Modellen für Embedding und Sprache. Wer ohnehin nur externe Modelle nutzen will, schleppt dann unnötig Ballast mit. Und der vierte ist der gefährlichste. Eigenbetrieb heißt nicht automatisch rechtskonform.

3:54 Die Verantwortung bleibt beim Unternehmen, egal wo der Server steht.

Anwendungsfälle und ihre Grenzen

3:58 Jetzt wird es konkret. Wofür soll Lotsenhaus bei Brandtner eigentlich da sein? Und genauso wichtig: Wofür ausdrücklich nicht? Denn nicht jede Aufgabe gehört in ein Chatfenster. Diese Tabelle zeigt fünf typische Einsätze, und das Spannende steht in der rechten Spalte. Sie verrät, was jeder Anwendungsfall technisch voraussetzt.

4:20 Textarbeit, etwa ein Rundschreiben überarbeiten, braucht nur ein gutes Chatmodell. Wissensassistenz zur Reisekostenrichtlinie braucht schon eine Wissensbasis mit Quellen. Recherche braucht Websuche, und zwar erst nach Freigabe. Analyse von Projektstatusberichten verlangt Dateiupload und langen Kontext. Und wer den Status eines Störmelder-Tickets abfragen will, braucht ein angebundenes Werkzeug. Von oben nach unten steigt also der Aufwand.

4:47 Das ist kein Zufall, sondern ein guter Hinweis darauf, in welcher Reihenfolge Sie einführen. Sprachmodelle haben eine unangenehme Eigenschaft: Sie klingen immer gleich überzeugt, ob sie recht haben oder nicht. Fehlt das passende Dokument, füllen sie die Lücke einfach mit dem Wahrscheinlichsten auf. Das ist kein Fehler im üblichen Sinn, sondern die Arbeitsweise dieser Technik.

5:10 Daraus folgen zwei klare Grenzen. Streng vertrauliche Daten haben in keinem Anwendungsfall etwas verloren, so verlockend er auch klingt. Und Automatisierung ohne Freigabe ist riskant. Solange ein Mensch die Antwort liest, bleibt ein Fehler ein Antwortfehler. Handelt das System selbst, wird daraus ein Prozessfehler, und der ist deutlich teurer.

5:31 Mit diesen vier Quadranten sortieren Sie Ideen nach Nutzen und Risiko. Oben rechts liegt das, womit Sie beginnen sollten: hoher Nutzen, Daten höchstens intern, und Fehler fallen beim Lesen auf. Hoher Nutzen mit vertraulichen Daten geht auch, aber nur mit Auflagen, also lokalem Modell und engen Rechten. Was wenig bringt und wenig riskiert, darf ruhig beim SaaS-Assistenten bleiben, dafür lohnt kein Eigenbetrieb.

5:55 Und alles mit hohem Risiko oder unkontrollierter Automatisierung stellen Sie zurück. Das Raster wirkt schlicht, aber es schützt vor dem typischen Fehler, mit dem spektakulärsten Projekt anzufangen. Und genau dieser Fehler steht hier ganz oben: mit dem eindrucksvollsten Anwendungsfall starten statt mit dem, der sich am besten prüfen lässt.

6:15 Der zweite Stolperstein ist eine Rechnung ohne Grundlage. Wer Zeitersparnis in Minuten pro Woche verspricht, muss wissen, wie lange die Arbeit heute dauert. Drittens die Wissensassistenz: Sie ist nur so gut wie ihre Dokumente. Sind die veraltet, antwortet der Assistent trotzdem, nur eben falsch. Und viertens: Werkzeuge mit Schreibrechten gehören nicht in den ersten Pilot. Lesen lernen, dann schreiben, das gilt hier wie überall.

Das Einführungsteam

6:41 Wer soll das alles verantworten? Die reflexhafte Antwort lautet: die IT. Dieses Kapitel zeigt, warum das nicht reicht und wer noch mit an den Tisch gehört. Eine KI-Plattform einzuführen ist ein bisschen wie eine neue Kantine zu eröffnen. Die Haustechnik sorgt für Strom, Herde und Kühlung. Was auf den Teller kommt, ob es schmeckt und welche Allergene drin sind, entscheiden aber andere. Bei Open WebUI ist es ähnlich. Das Plattformteam betreibt die Installation.

7:10 Doch was ein Assistent wissen darf, welches Modell welche Daten sieht und wann ein Pilot als gelungen gilt, sind keine Betriebsfragen. Das sind fachliche, rechtliche und organisatorische Entscheidungen. Wer sie trotzdem allein dem Plattformteam überlässt, macht es zum heimlichen Entscheider über Dinge, für die es weder Mandat noch Fachwissen hat.

7:30 Hier sehen Sie, wie sich das bei Brandtner verteilt. Lesen Sie die Tabelle als Checkliste, nicht als Organigramm. Plattformbetrieb und Identität liegen bei der IT-Infrastruktur, das ist naheliegend. Für jeden Bereich braucht es aber auch eine Person, die fachlich verantwortet, ob der Anwendungsfall taugt. Die Gruppe lh-wissen kümmert sich darum, dass Dokumente aktuell und freigegeben sind.

7:54 Datenschutz und Informationssicherheit bewerten Datenklassen und Risiken, und der Betriebsrat redet bei Nutzungsregeln und Auswertungen mit. Die Fußzeile bringt es auf den Punkt: Mehrere Rollen dürfen bei einer Person liegen. Unbesetzt bleiben darf keine. Vier Entscheidungen sollten Sie bewusst aus dem Plattformteam heraushalten, so kompetent es auch ist.

8:16 Welche Datenklassen ein Modell erreichen darf, ist eine Frage für Datenschutz und Sicherheit. Ob eine Antwort fachlich gut genug ist, kann nur die Fachseite beurteilen. Welche Auswertungen über die Nutzung erlaubt sind, berührt die Mitbestimmung. Und wann ein Anwendungsfall eingestellt wird, entscheidet, wer den Nutzen verantwortet.

8:35 Der Gewinn dieser Trennung ist nicht nur rechtlich. Sie entlastet auch das Plattformteam, das sich sonst für Dinge rechtfertigen müsste, die es gar nicht entscheiden kann. In der Praxis passiert das Gegenteil oft schleichend. Weil niemand sonst zuständig ist, entscheidet das Plattformteam still über Datenfreigaben. Oder es fehlt die Wissensverantwortung, die Dokumente veralten, und der Assistent antwortet munter weiter.

8:59 Ein Klassiker ist auch der späte Anruf beim Betriebsrat und beim Datenschutz, wenige Tage vor dem Rollout. Dann wird aus einer Abstimmung eine Vollbremsung. Und der letzte Punkt verdient besondere Aufmerksamkeit: Administratoren können Chats einsehen. Das ist technisch so, und es muss geregelt und bekannt sein, bevor die erste Person dort etwas Persönliches eintippt.

Anforderungen und Erfolgskriterien

9:21 Bleibt die Frage, woran Sie den Erfolg erkennen. Ein gutes Gefühl reicht nicht für eine Freigabe. Was nicht gemessen wird, lässt sich auch nicht guten Gewissens verlängern oder beenden. Diese Tabelle legt die Rahmenbedingungen für den Pilot fest, und die rechte Spalte ist mindestens so wichtig wie die mittlere. Sechzig Personen, bis zu fünfzehn gleichzeitig, das erste Token in unter drei Sekunden: Das sind konkrete Zahlen. Aber jede wirft eine Frage auf.

9:50 Gilt die Antwortzeit auch für das lokale Modell? Reicht eine Instanz, wenn ein Arbeitstag Ausfall tragbar ist? Wer nimmt Fehlermeldungen an? Diese Fragen tauchen in den nächsten Modulen wieder auf, in Architektur und Betrieb. Und beachten Sie die Fußzeile: Die Werte sind Annahmen fürs Labor. Im eigenen Haus erheben Sie sie zuerst.

10:11 Erfolg hat bei einer KI-Plattform drei Gesichter. Erstens die Arbeit selbst: Geht ein Vorgang schneller, gibt es weniger Rückfragen als heute? Zweitens die Qualität: Wie viele Referenzfragen beantwortet der Assistent richtig, und zwar mit der korrekten Quelle? Drittens die Kosten: Bleibt der Betrieb je aktivem Nutzer und Monat im Budget? Erst zusammen ergeben sie ein ehrliches Bild.

10:34 Ein schneller, aber falscher Assistent hilft niemandem, ein guter, aber unbezahlbarer auch nicht. Und der letzte Punkt macht aus Wünschen Kriterien: Ausgangswert, Ziel und Messzeitpunkt, sonst lässt sich am Ende nichts belegen. Wie kommen Sie zu solchen Kriterien? Der Weg beginnt bewusst ohne KI. Sie beschreiben zunächst, wie der Vorgang heute abläuft, und messen, was er kostet: Dauer, Fehler oder Rückfragen.

10:59 Erst dann legen Sie fest, was der Pilot erreichen soll und wie Sie es messen. Ebenso wichtig ist die Gegenrichtung, also Ausschlusskriterien, die den Pilot stoppen. Und am Ende unterschreiben Fachseite und Plattformbetrieb gemeinsam. Dadurch sprechen beide später über dieselben Zahlen. Die Fußzeile ist ein guter Prüfstein: Ein Satz wie Nutzer sind zufrieden klingt schön, lässt sich aber weder messen noch abnehmen.

11:25 Vier Fallen begegnen einem hier immer wieder. Die Zahl der Anmeldungen sagt nur, dass Leute neugierig waren, nicht, dass ihre Arbeit besser wurde. Eine Antwortzeit, die mit einem einzigen Nutzer gemessen wurde, sagt wenig über einen Montagmorgen mit fünfzehn gleichzeitigen Anfragen. Kosten für ein externes Modell lassen sich nur schätzen, wenn Sie den Tokenverbrauch pro Vorgang kennen.

11:47 Und Ausschlusskriterien, die erst während des Pilots entstehen, sind keine Kriterien mehr, sondern Ausreden oder Rechtfertigungen. Legen Sie sie fest, bevor der erste Nutzer sich anmeldet.

Übung

11:58 Zeit, das Gelernte anzuwenden. Sie bauen jetzt den ersten Baustein für Lotsenhaus, und zwar keinen technischen, sondern einen fachlichen: einen Anwendungsfall, der sich prüfen lässt. Ihre Aufgabe ist ein Steckbrief für einen einzigen Anwendungsfall bei Brandtner Fördertechnik. Ausgangspunkt sind die drei Pilotbereiche IT, Projektmanagement und interne Kommunikation.

12:20 Es geht dabei weniger um die perfekte Idee als um eine Fähigkeit: einen Anwendungsfall nüchtern nach Nutzen, Datenbedarf und Risiko zu beurteilen und daraus Kriterien zu machen, die sich wirklich überprüfen lassen. Gelungen ist der Steckbrief, wenn er Zielgruppe und Datenklasse nennt, zwei Risiken mit passender Gegenmaßnahme enthält und drei Kriterien mit Ausgangswert, Ziel und Messmethode.

12:42 Wer das schafft, hat die Arbeit erledigt, an der viele echte Projekte scheitern. Gehen Sie in fünf Schritten vor. Sammeln Sie zunächst drei Kandidaten und ordnen Sie sie im Quadranten von vorhin ein. Wählen Sie einen und begründen Sie die Wahl in zwei Sätzen, das zwingt zur Klarheit. Dann beschreiben Sie Zielgruppe, Nutzen und die benötigten Daten samt Datenklasse.

13:03 Halten Sie zwei Risiken mit Gegenmaßnahme fest und formulieren Sie schließlich die drei Akzeptanzkriterien. Nehmen Sie diese Übung ernst, denn der Steckbrief begleitet Sie weiter. Im nächsten Modul baut die Governance-Matrix darauf auf, und auch die Architektur im dritten Modul richtet sich danach.