Bootcamp AI-Agents - Organisationen mit KI-Agenten transformieren
KI-Agenten in Produktion
Am 13. März 2026 durfte ich beim FHNW Bootcamp KI-Agenten einen Vortrag zum Thema „KI-Agenten in Produktion" halten. Im Zentrum stand die Frage, was eine KI-Plattform leisten muss, damit Agents nicht nur als Proof of Concept funktionieren, sondern zuverlässig im Unternehmensalltag skalieren.
Den Einstieg machte ein konkreter Use Case: Schlüsselpersonen verlassen das Unternehmen und ihr Wissen geht mit. Ein KI-Assistent beantwortet rund 80 Prozent der Anfragen direkt aus Handbüchern und der Wissensbasis. Reicht das nicht aus, übernimmt ein KI-Agent, leitet die Frage an eine Expertin oder einen Experten weiter und speichert das neue Wissen dauerhaft für alle. Dieses Setup funktioniert gut für einen einzelnen Agent. Doch sobald ein zweiter oder dritter Agent hinzukommt, entsteht das sogenannte Day-Two-Problem: dreifache Wissensbasis, dreifache Zugriffskontrolle, dreifaches Testing, dreifache Modellanbindung. Das skaliert nicht.
Die Strassenverkehr-Analogie bringt es auf den Punkt: Ein einzelnes Auto fährt auch ohne Ampeln. Aber hundert Autos brauchen Verkehrsregeln, Ampeln, Überwachung und einen TÜV, nicht schnellere Motoren. Ab dem dritten Use-Case braucht es eine Plattform, die diese Querschnittsthemen einmal zentral löst, statt sie für jeden Use-Case zu replizieren.
Modul 1: Wissensbasis — Firmenwissen anbinden
Der erste Baustein ist die zentrale Wissensbasis. Das Problem ist simpel: Ein Service-Agent soll aus Handbüchern, Tickets und Prozessdokumenten antworten, aber das Sprachmodell kennt diese Inhalte nicht. Retrieval-Augmented Generation (RAG) schliesst diese Lücke. Dokumente werden in kleine Abschnitte aufgeteilt und als Vektoren gespeichert. Eine eingehende Frage wird ebenfalls vektorisiert und das System findet inhaltlich ähnliche Abschnitte, die als Kontext ans Modell übergeben werden. Das Ergebnis: Das Modell antwortet mit Firmenwissen, obwohl es dieses nie im Training gesehen hat.
Heute pflegt oft jeder Agent seine eigene Datenbank, Dokumente werden doppelt aufbereitet und die Ergebnisse sind inkonsistent. Eine zentrale Wissensbasis mit klar definierten Bereichen löst das einmal für alle. Neue Agents sind sofort angebunden, ohne Zusatzaufwand.
Modul 2: Governance — Wer darf was?
Das zweite Modul adressiert eine Frage, die in der Praxis oft zu spät gestellt wird: Unter wessen Identität arbeitet ein Agent, der auf Kundendaten, Prozessdokumente und technische Handbücher zugreift? Es gibt zwei grundlegend verschiedene Ansätze. Der Agent als Assistent erbt die Berechtigungen des angemeldeten Nutzers, wie ein Praktikant, der unter dem Login einer Kollegin arbeitet, mit maximalem Zugriff des Nutzers. Der Agent als eigenständige Entität hingegen hat eine eigene Identität und eigene Rechte, exakt die minimalen Berechtigungen, die er für seine Aufgabe benötigt.
Agents als eigenständige Entitäten machen KI beherrschbar: Sie folgen dem Least-Privilege-Prinzip, können ohne Nutzer-Kontext arbeiten (etwa für nächtliche Batch-Verarbeitungen oder automatische Ticket-Beantwortungen), liefern konsistente Inputs für systematische Tests und hinterlassen klare, zuordenbare Traces und Logs.
Modul 3: Transparenz — Was ist passiert?
Stellen wir uns vor, ein Service-Agent gibt einem Techniker eine falsche Reparaturanleitung. Der Kunde ist verärgert. Was passiert als nächstes? Ohne Transparenz lautet die Antwort: Wir haben keine Ahnung, wie das passieren konnte. Kein Audit-Trail, keine Nachvollziehbarkeit, das Vertrauen ist verloren. Mit Transparenz hingegen kann man nachvollziehen, was passiert ist: welche Dokumente herangezogen wurden, wie der Kontext zusammengebaut wurde, was das Modell geliefert hat und welche Zwischenschritte bei längeren Workflows durchlaufen wurden.
Ich stelle den Teilnehmenden eine einfache Frage: Würden Sie einen Geschäftsprozess betreiben, den niemand nachvollziehen kann? Transparenz ist kein Nice-to-have. Sie ist die Voraussetzung für verantwortungsvollen KI-Betrieb.
Modul 4: Evaluation — KI testen wie Software
Die Transparenz-Logs sind nicht nur für den Betrieb wertvoll, sie sind die Grundlage für systematische Qualitätssicherung. KI-Qualität ist messbar, nicht Glückssache. Mit einem Referenz-Datensatz aus typischen Fragen und geprüften Antworten, einem LLM-as-Judge-Ansatz (ein Sprachmodell bewertet die Antwort eines anderen Modells) sowie eigenen Evaluatoren für domänenspezifische Kriterien wie Quellenkorrektheit, Compliance und Tonalität lässt sich Qualität automatisiert messen. Bei jeder Änderung, ob neuer Prompt, neue Dokumente oder ein neues Modell, läuft die Evaluation und zeigt sofort, ob die Qualität gestiegen oder gesunken ist.
Wichtig dabei: Agents mit eigener Identität liefern konsistente Inputs und machen systematische Evaluation erst möglich. Die Module bauen aufeinander auf.
Modul 5: LLM Gateway — Modellwechsel ohne Chaos
Modelle werden häufiger gewechselt, als man denkt: wegen Abkündigung durch den Anbieter, besserer Qualität eines neuen Modells, deutlich geringerer Kosten oder juristischer Gründe. Ohne Gateway ist jeder Agent hart mit einem bestimmten Modell verdrahtet. Bei einer wachsenden Anzahl von Agents wird ein notwendiger Modellwechsel schnell zum Chaos, besonders wenn es schnell gehen muss.
Das LLM Gateway entkoppelt Agents von konkreten Modellen. Use-Cases sprechen logische Endpunkte an, etwa "thinking-large", "fast-small" oder "embedding", und das Gateway mappt diese auf die jeweils aktuellen, konkreten Modelle. Ein Service-Agent, ein Onboarding-Agent und ein Compliance-Agent kommunizieren alle mit dem Gateway, welches die Anfragen an Claude Opus, GPT-4o mini oder das Embedding-Modell weiterleitet, je nach Anforderung. Kostenkontrolle durch zentrale Rate Limits und Budget-Grenzen ist ein weiterer Vorteil dieser Architektur.
Modul 6: PII-Schutz — Sensible Daten schützen
Das sechste Modul ist ein zentrales Anliegen im Schweizer Unternehmenskontext: Personenbezogene Daten dürfen das Unternehmen nicht unkontrolliert verlassen. Ein Service-Agent, der Kundenanfragen bearbeitet, hat es mit Namen, E-Mail-Adressen, Kundennummern und manchmal Kreditkartendaten zu tun. Je nach Anbieter werden Anfragen gespeichert oder für Trainingszwecke verwendet, DSGVO und DSG verlangen den Schutz personenbezogener Daten, und selbst bei Nicht-Speicherung stellt sich die Frage, ob sensible Daten überhaupt über das Internet versendet werden sollten.
Die Lösung: PII-Schutz auf Gateway-Ebene, automatisch, zentral und ohne Code-Änderung in den einzelnen Agents. Bevor eine Anfrage das Unternehmen verlässt, werden sensible Daten erkannt und behandelt: Namen werden zu Platzhaltern maskiert, E-Mail-Adressen und IBANs ersetzt, Kreditkartendaten blockieren die Anfrage vollständig. Einmal zentral gelöst, gilt dasselbe Muster wie bei allen anderen Modulen.
Das Zusammenspiel: Die Module als System
Die sechs Module entfalten ihren eigentlichen Wert erst im Zusammenspiel. Ein vollständiger Request durch die Plattform sieht so aus: Der Service-Techniker stellt eine Frage. RAG durchsucht die zentrale Wissensbasis. Governance prüft, ob dieser Agent auf die betreffenden Daten zugreifen darf. Transparenz loggt, welche Dokumente herangezogen und welcher Prompt aufgebaut wurde. PII-Schutz maskiert sensible Daten in der Anfrage. Das LLM Gateway routet ans richtige Modell. Und die Evaluation prüft regelmässig, ob die Qualität noch stimmt.
Jedes Modul wird einmal gebaut und funktioniert dann für alle Agents. Das ist das entscheidende Prinzip: einmal zentral lösen, statt für jeden Use-Case replizieren.
Synthese: Die Plattform entscheidet, ob KI skaliert
Die Abschlussfrage des Vortrags bringt alles auf den Punkt: Lösen wir dieses Problem einmal zentral, oder wiederholen wir es für jeden Use-Case? Ein PoC ist schnell gebaut. Aber die Plattform entscheidet, ob KI im Unternehmen wirklich skaliert.
Die Diskussions-Impulse am Ende sorgten für lebhafte Gespräche: Welches Modul würde man als erstes aufbauen? Wie würde man die eigenen heutigen KI-Agents beschreiben, als Assistenten oder als eigenständige Entitäten? Und was passiert im eigenen Unternehmen heute, wenn ein KI-System einen Fehler macht? Diese Fragen trafen den Nerv der Teilnehmenden und zeigten, dass der Weg von erfolgreichen Proof of Concepts hin zu produktionsreifer KI für viele Unternehmen noch vor ihnen liegt.
