bbv KI Webinar - Robustes KI-Grundgerüst

Im Rahmen der BBV-Webinarreihe zur Künstlichen Intelligenz steht diese Folge vom 20. November 2025 im Zeichen der KI-Infrastruktur als Grundlage moderner Anwendungen. Moderiert wird die Veranstaltung von Emre; ich ergänze die Diskussion mit Einblicken aus der Praxis, welche Bausteine Unternehmen für einen stabilen und skalierbaren KI-Betrieb benötigen. Im Fokus stehen dabei weniger einzelne KI-Use-Cases als vielmehr die wiederverwendbaren Plattform-Komponenten, die Modellwechsel, Kostensteuerung, Datenanbindung, Qualitätssicherung und Nachvollziehbarkeit ermöglichen. Ziel ist eine nüchterne Einordnung, wie KI-Infrastruktur als organisatorischer und technischer Unterbau langfristig tragfähige KI-Lösungen unterstützt.

KI-Infrastruktur als Grundlage für skalierbare Anwendungen

Wenn in Projekten der Begriff „KI-Infrastruktur“ fällt, denken viele zuerst an GPU-Cluster, Rechenpower und Cloud. In der Praxis liegt der Engpass aber oft woanders: KI wird erst dann nachhaltig nutzbar, wenn es einen use-case-übergreifenden Unterbau gibt, der wiederkehrende Anforderungen zentral löst – unabhängig davon, ob am Ende ein Chatbot, ein Assistenzsystem oder ein Hintergrund-Agent entsteht.

„Heute geht’s um die Herdplatte, den Backofen und so Zeug.“

Infrastruktur meint dabei nicht das Endprodukt, sondern die Basis, auf der mehrere KI-Anwendungen zuverlässig aufsetzen können. Im Blueprint liegt unten die KI-Infrastruktur als Fundament, oben entstehen verschiedene Use Cases, die sich diese Basis teilen.

Modelle zentral austauschbar machen

Eine häufige Anforderung aus Unternehmen: Modelle müssen schnell und zentral austauschbar sein. Gründe sind Vendor Lock-in, unterschiedliche Modellgrössen (Kosten vs. Qualität), Datenschutzanforderungen (z. B. Standort/Jurisdiktion) und die schnelle Entwicklung neuer Modellgenerationen.

„Es kommen ja neue Modelle im Monatsrhythmus … da möchte man natürlich einen raschen Wechsel ermöglichen.“

Technisch ist der Wechsel innerhalb vergleichbarer Modelltypen oft machbar, aber das Verhalten kann sich ändern. Deshalb braucht es eine Infrastruktur, die Modellwechsel als kontrollierbaren Betriebsvorgang ermöglicht.

LM Proxies und Gateways

Hier kommen LLM Proxies / LLM Gateways ins Spiel: Use Cases sprechen nicht direkt konkrete Anbieter-Modelle an, sondern stabile interne Endpunkte wie „thinking-large“ oder „embedding-small“. Im Gateway wird gemappt, welches Modell dahinter hängt. So kann man zentral umschalten, ohne in jedem Use Case Code anzupassen – eine Adapter-Schicht zwischen Anwendung und Modell.

Kosten planbar und überwachbar halten

Bei „LLM as a Service“ sind Kosten meist tokenbasiert und damit dynamisch: abhängig von Anfragevolumen, Textlängen, Tool-Aufrufen und Agenten-Schritten. Unternehmen wollen deshalb Budgets setzen, Kosten pro Team/Key/Modell sehen und Missbrauch verhindern (z. B. bei extern zugänglichen Bots).

Weil Anfragen über das Gateway laufen, kann es Tokenverbrauch und Kosten messen, aufschlüsseln und begrenzen (Limits, Rate Limits, Alerts). Häufig hängt daran auch zentrales Access Management: API-Keys, Rollen, Benutzergruppen und Policies.

Unternehmenswissen per RAG integrieren

Sprachmodelle kennen öffentliches Trainingswissen, aber nicht das aktuelle interne Wissen eines Unternehmens. Um dieses Wissen nutzbar zu machen, wird typischerweise Retrieval Augmented Generation (RAG) eingesetzt: Dokumente werden in Abschnitte zerlegt, semantisch indexiert und bei einer Anfrage werden relevante Textstellen gesucht und dem Modell im Kontext übergeben.

Dazu braucht es vor allem:

• Embedding-Modelle zur Vektorisierung
• Vektordatenbanken für die semantische Suche

Ingestion: Daten aktuell halten

RAG funktioniert nur, wenn Daten aktuell und kontrolliert sind. Dokumente ändern sich, müssen gelöscht werden (Compliance), oder veraltete Versionen sollen nicht mehr auftauchen. Daher gehört eine Ingestion-Pipeline zur Infrastruktur: Sie überwacht Datenquellen (z. B. SharePoint, Confluence, Fileshares), erkennt Änderungen und aktualisiert die Vektordatenbank.

Ein praktischer Punkt: schlecht gepflegte Versionierung („v1/v2/v3“ parallel) führt zu Duplikaten und verschwendet Kontext. Besser ist, alte Versionen zu archivieren und nur aktuelle Quellen zu indexieren.

Qualität absichern: Evaluation statt Blindflug

Wenn Modelle zentral austauschbar sind und Systeme sich ändern, wird Evaluation zentral: Wie erkennt man, ob ein Modellwechsel, Prompt-Update oder neue Datenpipeline die Qualität verbessert oder verschlechtert?

Typisch ist ein Evaluations-Setup mit Testfragen, Referenzantworten (und bei RAG optional erwarteten Quellen) sowie Metriken wie Korrektheit, Vollständigkeit und Prägnanz. Zur Skalierung wird häufig LLM-as-a-Judge genutzt, um Bewertungen automatisiert zu erzeugen. Idealerweise passiert Evaluation vor einem Umschalten (Vergleich alt vs. neu) und kontinuierlich im Betrieb.

Nachvollziehbarkeit durch Observability

KI-Systeme bestehen aus mehreren Verarbeitungsschritten: Kontextaufbau, Query-Rewriting, Retrieval, Guardrails, Tool-Aufrufe, Postprocessing. Wenn etwas schief läuft, ist entscheidend, welcher Schritt das Ergebnis beeinflusst hat.

„Jeder Schritt … sollte nachvollziehbar sein.“

Dafür nutzt man Logs und Traces (z. B. OpenTelemetry, OpenInference) und passende Observability-Tools, die Requests als Ablauf visualisieren. Das ist sowohl für Debugging als auch für Betrieb und Governance relevant.

Datenschutz: PII-Schutz als letzte Schranke

Bei externen Modell-Services entsteht das Risiko, dass Anfragen beim Anbieter zumindest temporär gespeichert oder ausserhalb der gewünschten Jurisdiktion verarbeitet werden. Deshalb wird oft eine PII Detection als letzter Schritt vor dem Modell eingesetzt: personenbezogene Daten (Name, E-Mail, IBAN etc.) werden ersetzt oder die Anfrage wird blockiert. Zentral im Gateway umgesetzt gilt das automatisch für alle Use Cases.

Plattform-Ansatz statt Einzellösungen

Der gemeinsame Nenner: Viele Anforderungen wiederholen sich über alle KI-Anwendungen hinweg. Wenn jede Anwendung sie separat löst, entstehen Inkonsistenzen bei Modellzugriff, Kostensteuerung, Datenanbindung, Qualitätsmessung und Observability. Der Plattform-Ansatz bündelt diese Themen als Infrastruktur-Bausteine, damit neue Use Cases schneller entstehen und konsistent betrieben werden können.

In diesem Rahmen ordne ich auch den bbv AI Hub ein: als „opinionated“ Zusammenstellung von Modulen (z. B. Gateway, RAG-Stack, Ingestion, Evaluation, Observability, PII-Protection) plus Integrationen, die in Projekten immer wieder gebraucht werden – nicht als einzelnes Feature, sondern als stabiler Unterbau für mehrere KI-Lösungen.