Ugur Tarlig

Fallstudie

Interne KI-Assistenzplattform für Unternehmenswissen im regulierten Gesundheitsumfeld

Eine öffentlich teilbare Zusammenfassung einer Plattform, die ich intern verantwortet habe: eine produktive KI-Assistenzlösung, mit der Mitarbeitende freigegebene Unternehmensdokumente, SOPs, QMS-Inhalte, Wikis und weitere Wissensquellen per Chat durchsuchen, verstehen und nutzen können. Mit Quellenangaben, Rollenrechten und klaren Datengrenzen.

Abstrakte Illustration: eine lose Idee verdichtet sich von links nach rechts schrittweise zu einem fertigen, produktiven System

Kontext

In einem regulierten klinischen Umfeld liegt viel entscheidendes Wissen verteilt: in Dokumenten, Intranet-Seiten, QMS-Systemen, SOPs, Wikis und Fachanwendungen. Mitarbeitende wissen oft, dass die Information irgendwo existiert, aber nicht immer, wo sie liegt, welche Version aktuell ist oder wie sie schnell in den eigenen Arbeitskontext übersetzt werden kann.

Genau dafür wurde die Plattform aufgebaut: als interne KI-Assistenzschicht über freigegebenem Unternehmenswissen. Mitarbeitende stellen Fragen in natürlicher Sprache und erhalten Antworten, die nicht nur auf Modellwissen beruhen, sondern auf angebundenen internen Quellen. Die Antworten enthalten Quellenverweise zurück auf die Originaldokumente, damit Aussagen überprüfbar bleiben. Das war kein isolierter Chatbot und keine Demo, sondern ein sicher betreibbarer Enterprise-Service: Fachbereiche sollten eigene Assistenten für konkrete Wissens- und Supportfälle erstellen können, während IT, Security und Governance die Kontrolle über Zugriff, Datenflüsse, Betrieb und Kosten behalten.

Als interner Lead für GenAI Platform Delivery habe ich die Evaluation, das Enterprise-Hardening und die produktive Einführung dieser Plattform end-to-end verantwortet. Die Arbeit lag an der Schnittstelle von AI-Fähigkeit, bestehender Enterprise-IT, regulierten Datengrenzen, Stakeholder-Vertrauen und realer organisatorischer Adoption. Der Ansatz folgte einem Prinzip, das ich generell vertrete: die Engine kaufen, die Integration bauen. Modell und Plattformbasis kamen aus bewährten, gemanagten Bausteinen. Der eigentliche Unterschied entstand durch die Einbettung in ein reguliertes Unternehmen: Identität, Berechtigungen, Datengrenzen, Sicherheit, Wissensanbindung, Betrieb und Rollout.

Wie das Projekt entstand

Die Plattform entstand im Kontext des Innovationsmanagements, als eines von mehreren KI-Vorhaben. Ich habe mein Konzept vor einem Innovationsbeirat aus Vorständen und Geschäftsführung präsentiert; es wurde als einer der KI-Use-Cases zur Umsetzung ausgewählt.

Der naheliegende Weg wäre ein klassisches Beratungsprojekt gewesen: sechsstelliges Budget, lange Konzeptphase, rund 18 Monate Laufzeit. Nach einer Make-or-Buy-Analyse habe ich stattdessen einen schlankeren Weg gewählt: eine bewährte Referenzarchitektur auf AWS als Ausgangspunkt, darauf aufbauend internes Enterprise-Hardening, produktionsfähiges Deployment und schrittweise Weiterentwicklung. Wesentliche Teile der Wissensanbindung, darunter eigene Crawler für interne Quellen, habe ich selbst umgesetzt. Der Ansatz war bewusst pragmatisch: klein starten, früh ausliefern, mit echten Nutzenden lernen und die Plattform entlang realer Anforderungen weiterentwickeln, Ownership statt Lastenheft. So blieben Architekturwissen und Betriebsfähigkeit im Haus, und die Plattform konnte rund 80 Prozent unter dem ursprünglich veranschlagten Budget produktiv eingeführt werden.

Was ich verantwortet habe

Was die Plattform konkret leistet

Die Plattform ermöglicht Mitarbeitenden, mit internen Wissensbeständen über spezialisierte KI-Assistenten zu arbeiten. Statt allgemeine Fragen an ein generisches Sprachmodell zu stellen, nutzen sie Assistenten, die auf freigegebene Unternehmensquellen begrenzt sind. Typische Anwendungsfälle waren die Navigation durch SOPs, Qualitätsmanagement- und Prozessdokumente, die schnelle Orientierung in internen Leitfäden und Wissensartikeln, die Unterstützung bei IT- und Fachsupport-Fragen, fachbereichsspezifische Assistenten für wiederkehrende Informationsbedarfe sowie die Self-Service-Erstellung neuer Bots durch berechtigte Fachbereiche.

Ein zentraler Bestandteil war die Quellenbindung. Antworten sollten nicht einfach überzeugend klingen, sondern nachvollziehbar sein. Deshalb verweist die Plattform auf die zugrunde liegenden Originaldokumente. Gerade in einem regulierten Umfeld ist das kein Komfortmerkmal, sondern eine Grundanforderung.

Eine breite, gemeinsame Wissensbasis am Boden, von der dünne Linien zu mehreren unterschiedlichen Assistenten-Formen aufsteigen
Eine gemeinsame, freigegebene Wissensbasis, darüber spezialisierte Assistenten je Anwendungsfall (zum Vergrößern klicken).

Architektur im Überblick

Die Plattform ist eine serverlose Three-Tier-Architektur auf AWS. Sie kommt ohne eigene Server aus, skaliert nach Last und hält die Betriebslast klein. Die folgenden Bausteine sind bewusst auf Architekturebene beschrieben, ohne interne Details offenzulegen.

Frontend und Auslieferung

Das Frontend ist eine React-SPA, ausgeliefert als statische Dateien aus S3 über CloudFront. Dadurch braucht es keinen eigenen Webserver und keinen separaten Patch-Aufwand für eine Web-Schicht. CloudFront übernimmt zusätzlich das Pfad-Routing zu den Backend-Komponenten.

Authentifizierung und Berechtigungen

Die Anmeldung läuft über Cognito mit Federation zum Unternehmens-Identity-Provider per OIDC. Mitarbeitende melden sich mit ihrem bestehenden Unternehmens-Account an, ohne separate Zugangsdaten für die Plattform. Beim Login mappt eine Pre-Token-Funktion die Gruppen des Identity-Providers auf rollenbasierte Berechtigungen in der Plattform. So wird gesteuert, wer Assistenten nutzen, erstellen oder administrieren darf. Credentials für die Föderation liegen im Secrets Manager, nicht im Code.

Zwei API-Kanäle: Verwaltung und Streaming

Die Plattform trennt zwei unterschiedliche Lastprofile sauber. Ein HTTP-API-Kanal bedient synchrone Operationen wie Konversationen, Bot-Konfigurationen, Einstellungen und Administration über eine Lambda-basierte API. Ein zweiter Kanal über WebSocket liefert die Modellantworten in Echtzeit, Token für Token, über eine eigene Streaming-Funktion. So bleibt die Oberfläche reaktionsschnell, auch wenn längere Antworten generiert werden.

Quellenbasierte Antworten mit RAG

Die Plattform nutzt Retrieval Augmented Generation, kurz RAG. Antworten entstehen also nicht nur aus dem allgemeinen Modellwissen, sondern werden mit passenden Ausschnitten aus internen Dokumenten angereichert. Eigene Crawler halten die Wissensbasis aktuell und synchronisieren freigegebene Quellen wie Intranet, QMS, SOPs und Wikis nach S3. Eine gemanagte Knowledge Base zerlegt die Dokumente in Chunks, erzeugt Embeddings und legt die Vektoren in einer OpenSearch-Serverless-Vektordatenbank ab. Bei einer Anfrage werden semantisch passende Stellen geholt und dem Modell als Kontext übergeben. Die Antwort enthält Quellenangaben zurück auf die Originaldokumente, damit Nutzende prüfen können, worauf eine Aussage beruht. Die eigentliche Arbeit lag dabei weniger im Sprachmodell selbst als in der Datenpipeline: verteiltes, oft unstrukturiertes Wissen identifizieren, zugänglich machen, aufbereiten, aktuell halten und personenbezogene Daten ausblenden. Faustregel aus dem Projekt: das Modell ist 20 Prozent des Erfolgs, die Datenpipeline 80 Prozent. Warum die Quellenbindung kein Detail, sondern eine Architekturanforderung ist, habe ich an anderer Stelle beschrieben.

Verstreute bunte Fragmente links laufen durch einen Trichter und werden rechts zu einem geordneten, gleichmäßigen Raster
Die eigentliche Arbeit: verstreutes, unstrukturiertes Wissen wird zu einer sauberen, abfragbaren Wissensbasis. Das Modell ist 20 Prozent, die Datenpipeline 80 Prozent (zum Vergrößern klicken).

Sicherheit und Datengrenzen

Vor der Plattform sitzt eine WAF an CloudFront: IP-Allowlist für autorisierte Netze, Rate-Limiting und gemanagte Regeln gegen die OWASP-Top-10. Nur freigegebene Netzwerke erreichen die Anwendung. Sensible Konfiguration liegt im Secrets Manager. Datengrenzen, Berechtigungen und Protokollierung wurden nicht nachträglich ergänzt, sondern von Beginn an als Designbedingungen behandelt.

Datenhaltung

Enterprise-Hardening für ein reguliertes Umfeld

In einem regulierten Umfeld reicht es nicht, ein leistungsfähiges Modell bereitzustellen. Entscheidend ist, ob die Plattform sicher, nachvollziehbar und kontrollierbar betrieben werden kann. Konkret hieß das: klare Datengrenzen und rollenbasierte Zugriffe, Quellenbindung statt freier Behauptung, nachvollziehbare Antworten, Protokollierung und Observability für Nutzung und Kosten, menschliche Kontrolle dort, wo Output folgenreich wird, und Betrieb innerhalb bestehender Enterprise-IT- und Security-Anforderungen. Diese Anforderungen haben die Architektur stärker geprägt als jeder Modell-Benchmark. Die wichtigste Frage war nicht, welches Modell am beeindruckendsten ist, sondern welche Plattform in diesem Umfeld verantwortbar genutzt, betrieben und skaliert werden kann.

Ein solider Kern, umgeben von mehreren konzentrischen Schutzschichten, an denen Zugriffe von außen gefiltert stoppen
Eine bewährte Engine im Kern, umgeben von gehärteten Schichten: Identität, Datengrenzen, Zugriff und Kontrolle (zum Vergrößern klicken).

Adoption und Rollout

Eine Plattform, die niemand nutzt, ist gescheitert, egal wie sauber sie gebaut ist. Deshalb war Adoption Teil der Delivery, nicht ein nachgelagerter Kommunikationsschritt. Der Weg führte von einer kontrollierten Einführung zu rund 750 aktiven Nutzern, mit einem Pfad Richtung Konzern-Rollout an über 18.000 Mitarbeitende. Ein Bot-Marketplace erlaubt Fachbereichen, spezialisierte Assistenten selbst anzulegen und zu teilen, statt auf ein zentrales Team zu warten: Assistenten für Wissensnavigation, Qualitätsmanagement und SOPs, fachliche Leitfäden, IT-Support oder Fachanwendungen, dazu ein geführter Bot-Creator für Self-Service. Nutzungs-Analytics und rollenbasierte Administration halten den Betrieb steuerbar. Enablement, klare Use Cases und Support waren genauso Teil der Arbeit wie Architektur und Modellanbindung.

Sichere Übergabe

Produktion heißt: das System läuft auch dann, wenn die ursprüngliche Projektperson nicht mehr im Raum ist. Über sechs Monate habe ich die Plattform strukturiert übergeben, mit Workshops, Coaching und Hands-on-Sessions, an ein internes Team aus zwei Technikern und zwei Fachanwendern sowie einen externen Dienstleister für den laufenden Betrieb. Ziel war ein sicherer, eigenständiger Plattformbetrieb ohne Abhängigkeit von einer einzelnen Person.

Ergebnis

Aus einer allgemeinen AI-Ambition wurde ein konkretes, produktives und genutztes System: eine interne KI-Assistenzplattform für Unternehmenswissen, mit Quellenbindung, rollenbasiertem Zugriff, regulierten Datengrenzen und produktionsfähigem Betrieb. In-house geliefert, compliant ab Tag 1, und auf einem Stack, der austauschbar bleibt: Modelle lassen sich wechseln, ohne die Plattform neu zu bauen.

Überblick der Plattform: links freigegebene Quellen (Intranet, QMS, SOPs, Wikis), in der Mitte die kontrollierte KI-Schicht mit Governance, Wissensaufbereitung, Kontextsuche und Antworterzeugung, rechts die Nutzung im Alltag mit Bot-Marketplace und Antworten mit Quellen
Die ganze Plattform in einem Blick: freigegebene Quellen rein, kontrollierte KI-Schicht dazwischen, nachvollziehbare Antworten raus (zum Vergrößern klicken).

Rolle

Solution Architecture, Entscheidungsrahmen, Stakeholder Alignment und Delivery, als verantwortlicher interner Lead. Meine Rolle verband Executive-Kontext mit hands-on technischer Urteilskraft: genug Detailtiefe, um die Plattform real und betreibbar zu machen, genug Abstraktion, um Entscheidungen für Führung, Fachbereiche, IT und Governance verständlich zu halten.