Was ich beim Rollout von CompanyGPT in Unternehmen gelernt habe – Stakeholder, Pilotdesign, Governance, typische Widerstände und messbarer Fortschritt

Hook: Das Problem mit der 'Demo-Euphorie' im Meetingraum

Ich erinnere mich an ein Meeting in einem mittelständischen Maschinenbauunternehmen. Der Vertriebsleiter hatte gerade eine glänzende Demo von CompanyGPT gesehen: Eine Frage in natürlicher Sprache, und die KI lieferte sofort die passende Spezifikation aus dem Produktkatalog. Die Stimmung war euphorisch – „Das ändert alles!“ Doch nach der Demo stellte sich schnell die Ernüchterung ein: Wer darf welche Daten sehen? Wie stellen wir sicher, dass die Antworten nicht aus vertraulichen Entwicklungsnotizen gezogen werden? Und wie messen wir, ob die Antwort tatsächlich relevant ist?

Dieses Muster sehe ich immer wieder: Die erste Begeisterung vergeht, sobald die ersten konkreten Fragen auftauchen. Der Grund liegt nicht an der Technologie selbst, sondern daran, dass wir die Einführung als reines Feature-Projekt behandeln, statt sie als organisatorischen und governance‑lastigen Veränderungsprozess zu begreifen.

Einordnung: Warum RAG mehr ist als nur eine API-Anbindung

Retrieval‑Augmented Generation (RAG) klingt nach einem einfachen Aufruf: Frage → Vector‑Suche → LLM → Antwort. In der Praxis ist das nur die Spitze des Eisbergs. Ein funktionierendes RAG‑System benötigt drei eng verzahnte Schichten:

1. Datenaufbereitung – Dokumente müssen in ein Format gebracht werden, das der Vector‑Store versteht (Chunking, Metadaten, Sprache).
2. Zugriffssteuerung – Jeder Chunk muss mit den gleichen ACLs versehen sein, die im Quellsystem gelten.
3. Generierung mit Kontrolle – Das LLM darf nur aus den zurückgegebenen Chunks generieren; zusätzlich braucht es Filter, die Halluzinationen und das Auslesen von nicht autorisierten Inhalten verhindern.

Wenn irgendeine dieser Schichten fehlt, entsteht entweder ein Sicherheitsrisiko oder ein nutzloses Produkt, das zwar schnell antwortet, aber falsche oder vertrauliche Informationen preisgibt.

Aus der Praxis: Datenleck durch fehlende Metadaten

Bei einem Kunden aus dem Finanzbereich hatten wir die Produktdokumente in den Vector‑Store geladen, vergaßen aber, das Feld "Vertraulichkeitsstufe" mitzunehmen. Beim ersten Test fragte ein Analyst nach „aktuellen Risikomodellen“. Das LLM zog aus einem Chunk, der eigentlich nur für das Risiko‑Controllingteam bestimmt war, und gab detaillierte Annahmen preis, die nach internen Richtlinien streng vertraulich waren. Der Vorfall führte zu einem sofortigen Stopp des Pilots und einer Nachschulung des Daten‑Engineering‑Teams.

Stakeholder: Wer entscheidet wirklich über die Datenfreigabe?

In vielen Unternehmen wird angenommen, dass die IT‑Abteilung allein über den Zugriff auf die Daten entscheidet. Tatsächlich liegt die Entscheidungsgewalt oft bei den Fachbereichen, die die Daten besitzen – beispielsweise bei der Rechtsabteilung für Verträge, bei der Forschung für Experimente oder beim Vertrieb für Kundenlisten.

Ein erfolgreicher Rollout benötigt daher ein Stakeholder‑Board, das folgende Rollen klar definiert:

• Data Owner – verantwortet die Datenqualität und legt die Zugriffsregeln fest.
• Compliance Officer – prüft, ob die geplanten Zugriffe mit Datenschutz und Industrie‑Regulierungen vereinbar sind.
• Business Owner – definiert den Anwendungsfall und bewertet.
• IT‑Architekt – sorgt für die technische Umsetzung der ACLs im Vector‑Store und überwacht die Log‑Ströme.
• Anwendervertreter – repräsentiert die täglichen Nutzer und gibt Feedback zur Relevanz der Antworten.

Ohne dieses Gremium neigen Projekte dazu, entweder zu vorsichtig zu werden (keine Daten freigegeben → nutzloser Bot) oder zu risikofreudig (zu breite Freigabe → Datenleck).

Was oft schiefgeht: Unterschätzte Fachbereichs‑Politik

In einem Projekt mit einem internationalen Konsumgüterhersteller wollten wir die Produktdaten der Marketing‑Abteilung einbinden. Die Marketing‑Leitung sah darin eine Chance, die Kampagnenplanung zu beschleunigen. Doch die Rechtsabteilung blockierte die Freigabe, weil sie befürchtete, dass preis‑ und launchrelevante Informationen frühzeitig an die Konkurrenz gelangen könnten. Statt das Problem frühzeitig im Stakeholder‑Board zu adressieren, versuchten wir, eine technische Lösung zu finden – etwa durch Verschleierung der Chunks. Das führte zu komplizierten Workarounds, die die Antwortqualität stark beeinträchtigten. Erst nach einem moderierten Workshop, bei dem beide Seiten ihre Risiken und Chancen offenlegten, konnten wir ein vereinbartes Daten‑Freigabemodell definieren, das sowohl die Marketingziele als auch die rechtlichen Bedenken berücksichtigte.

Pilotdesign: Warum kleine, datenintensive Testgruppen besser sind

Ein häufiger Fehler ist der Versuch, CompanyGPT gleich flächendeckend auszurollen. Das führt zu einer Flut von Support‑Tickets, unklaren Erwartungen und einer diffusen Messbarkeit.

Mein Ansatz ist ein datenintensiver Pilot: Eine kleine Gruppe von Power‑Usern (5‑10 Personen) erhält Zugriff auf einen tiefen, thematisch fokussierten Datenbestand – beispielsweise alle Konstruktion drawings und zugehörigen Änderungsanfragen eines bestimmten Produktlinien. Warum das funktioniert:

• Hohe Signal‑zu‑Noise‑Rate – Die Fragen sind spezifisch, die Antworten lassen sich leicht auf Richtigkeit überprüfen.
• Schnelle Feedback‑Schleifen – Die Nutzer können täglich konkrete Use‑Cases testen und sofort melden, ob die Antwort hilfreich war.
• Begrenzter Risikoradius – Sollte ein Datenleck auftreten, betrifft es nur einen klar definierten Teil des Wissensbestands.
• Skalierbare Learnings – Die gewonnenen Erkenntnisse über Chunking‑Strategien, ACL‑Implementierung und Prompt‑Design lassen sich später auf andere Bereiche übertragen.

Aus der Praxis: Pilot in der Wartungsabteilung

Bei einem Energieversorger haben wir den Pilot mit den Wartungstechnikern gestartet. Sie benötigten schnellen Zugriff auf Wartungspläne, Ersatzteilkataloge und frühere Störungsmeldungen. Der Datenbestand umfasste etwa 250.000 Dokumente – ausreichend reich, um komplexe Abfragen zu testen, aber überschaubar genug, um die ACLs präzise zu pflegen. Nach vier Wochen zeigte sich, dass die Techniker die durchschnittliche Suchzeit von 8 Minuten auf unter 30 Sekunden reduzierten. Gleichzeitig konnten wir anhand eines einfachen Relevanz‑Scores (siehe unten) einen Zuwachs von 38 % bei treffenden Antworten messen.

Governance: ACLs und die Gefahr von Datenlecks durch LLMs

Access Control Lists (ACLs) sind das Rückgrat jeder sicheren RAG‑Implementierung. Sie bestimmen, welcher Benutzer welche Dokument‑Chunks sehen darf. Die Herausforderung besteht darin, dass die ACLs nicht nur beim Einladen, sondern auch bei jedem Update konsistent gepflegt werden müssen.

Ein häufig übersehenes Risiko ist das „Prompt‑Leaking“: Ein geschickter Angreifer kann durch gezielte Fragen versuchen, das LLM dazu zu bringen, Informationen aus Chunks zu rekonstruieren, die ihm eigentlich nicht zugänglich wären. Selbst wenn der Vector‑Store nur autorisierte Chunks zurückliefert, kann das LLM durch Kombination mehrerer erlaubter Antworten indirekt geschützte Daten ableiten.

Um dem entgegenzuwirken, setzen wir auf drei Ebenen:

1. Strenge Chunk‑Granularität – Kleine, thematisch fokussierte Chunks reduzieren die Chance, dass aus mehreren erlaubten Stücken ein sensibles Ganzes rekonstruiert wird.
2. Answer‑Filtering – Nach der Generierung prüfen wir das Ergebnis gegen eine Liste von Mustern (z. B. Kontonummern, interne Projektcodes) und blockieren oder schwärzen Treffer.
3. Audit‑Logging – Jede Anfrage, die zurückgelieferten Chunks und die generierte Antwort werden unveränderlich protokolliert. Bei einem Vorfall lässt sich so rückverfolgen, wer welche Daten angefordert hat und ob ein Leak stattgefunden hat.

Was oft schiefgeht: Verlassen auf die Standard‑Sicherheit des Vector‑Stores

Ein Kunde verließ sich ausschließlich auf die Rollen‑basierte Zugriffskontrolle seines Elasticsearch‑Clusters, glaubend, dass das ausreichend sei. Wir entdeckten jedoch, dass beim Chunking ein Dokument mit 12 Seiten in sechs Chunks aufgeteilt wurde, wobei jedes Chunk nur die Überschrift und einen Absatz enthielt. Durch gezielte Fragen nach den Absatznummern konnten Angreifer das komplette Dokument rekonstruieren, obwohl jedes einzelne Chunk laut ACL nur für die Abteilung „Produktmanagement“ freigegeben war. Die Lösung bestand darin, die Chunks so zu gestalten, dass sie keine sinnvolle Rekonstruktion erlaubten – etwa durch Überlappung und Zufalls‑Padding.

Widerstände: Wenn Experten Angst um ihr Expertenwissen haben

Wissen ist Macht. In vielen Fachbereichen sieht man die Einführung eines KI‑Assistenten als Bedrohung: Wenn die Maschine die Antworten liefert, wird das eigene Expertenwissen überflüssig. Dieser Widerstand zeigt sich oft subtil – durch fehlende Teilnahme an Workshops, durch das Weitergeben von veralteten Informationen oder durch das bewusstes Stellen von schlechten Testfragen, um das System schlecht aussehen zu lassen.

Der Schlüssel liegt darin, die KI nicht als Ersatz, sondern als Verstärker zu positionieren:

• Experten bleiben die Quelle – Das System holt nur das, was bereits in den Dokumenten steht; neues Wissen muss weiterhin von den Experten erzeugt werden.
• Zeitersparnis für höherwertige Tätigkeiten – Durch das Beantworten von Routinefragen können Experten sich auf komplexe Problemlösungen, Mentoring und Innovation konzentrieren.
• Transparente Beteiligung – Experten werden in den Prozess der Dokumentenaufbereitung und der Qualitätskontrolle eingebracht; sie sehen unmittelbar, wie ihr Wissen genutzt und verbessert wird.

Aus der Praxis: Der Widerstand der Senior‑Ingenieure

Bei einem Maschinenbauer lehnten die Senior‑Ingenieure zunächst die Nutzung von CompanyGPT ab, weil sie befürchteten, dass ihre jahrzehntelang erworbenen Konstruktions‑Tricks nun von jedem Nachwuchs‑Ingenieur abgefragt werden könnten. Wir lud sie zu einem Co‑Creation‑Workshop ein, bei dem sie selbst entschieden, welche Konstruktionsrichtlinien in den Vector‑Store aufgenommen werden und welche als „experten‑only“ markiert bleiben sollten (durch ein zusätzliches Metadata‑Feld expert_only: true). Anschließend erhielten sie ein Dashboard, das zeigte, wie oft ihre Richtlinien tatsächlich abgefragt wurden und welchen Einfluss sie auf die Fehlerquote in der Produktion hatten. Die Sichtbarkeit ihres Einflusses verwandelte die Skepsis in aktive Befürwortung.

Messbarkeit: Relevanz statt nur 'Gefühl' durch Benchmarks

Viele Teams messen den Erfolg eines KI‑Projekts anhand von Zufriedenheitsumfragen oder der einfachen Anzahl der gestellten Fragen. Diese Metriken sagen wenig darüber aus, ob die Antworten tatsächlich zutreffend und nützlich sind.

Ich setze auf einen relevanzbasierten Benchmark, der aus drei Komponenten besteht:

1. Precision@k – Anteil der richtigen Informationen unter den ersten k zurückgegebenen Chunks (gemessen anhand eines manuell gelabelten Testsets).
2. Answer‑Correctness – Ob die generierte Antwort faktisch korrekt ist (wieder anhand eines Testsets mit Expertenbewertung).
3. User‑Effort‑Reduction – Vergleich der durchschnittlichen Zeit, die ein Nutzer vorher für eine ähnliche Suche benötigte, mit der Zeit nach Einführung von CompanyGPT.

Wir führen monatlich ein kleines Evaluation‑Set durch (ca. 50 Fragen pro Bereich), das von den Fachbereichen selbst erstellt wird. Die Ergebnisse werden in einem einfachen Dashboard visualisiert und mit den Zielen des Stakeholder‑Boards abgeglichen.

Was oft schiefgeht: Verlassen auf reine Nutzungszahlen

In einem Projekt mit einem großen Versicherer wurde der Erfolg ausschließlich an der Anzahl der aktiven Nutzer gemessen. Nach drei Monaten zeigte das Dashboard einen steady‑growth‑Trend von 12 % pro Monat. Gleichzeitig stieg jedoch die Anzahl der falschen Antworten laut den monatlichen Audits von 4 % auf 11 %. Das Management bemerkte den Trend erst, nachdem ein Kunde aufgrund einer falschen Police‑Auslegung eine Beschwerde eingereicht hatte. Die Korrektur bestand darin, die Relevanzmetriken in das monatliche Reporting aufzunehmen und die Zielvorgaben anzupassen (z. B. Maximal 5 % falsche Antworten).

Fazit: Mein Ansatz für einen stabilen Betrieb

Der Rollout von CompanyGPT ist kein reines Technologieprojekt, sondern ein soziotechnisches Veränderungsvorhaben. Mein bewährter Fahrplan sieht wie folgt aus:

1. Stakeholder‑Board etablieren – Klare Rollen, regelmäßige Treffen, Entscheidungsprotokoll.
2. Datenintensiven Pilot definieren – Kleine, fachlich relevante Datenmenge, klare Success‑Criteria.
3. Governance von Anfang an verankern – ACL‑Design, Chunk‑Strategie, Answer‑Filtering, Audit‑Logging.
4. Widerstände früh adressieren – Experten als Co‑Creator einbinden, Nutzen klar kommunizieren.
5. Messbare Relevanz etablieren – Benchmark‑Framework mit Precision, Correctness und Effort‑Reduction.
6. Iterativ skalieren – Erkenntnisse aus dem Pilot auf weitere Bereiche übertragen, dabei jedes Mal die Governance‑Checkliste durchlaufen.

Wenn diese Schritte konsequent befolgt werden, verwandelt sich die anfängliche Demo‑Euphorie in einen nachhaltigen, vertrauenswürdigen Produktivitätsgewinn – ohne die Kontrolle über sensible Daten zu verlieren und ohne das wertvolle Expertenwissen zu unterminieren.

Mehr über meine Arbeit und aktuelle Projekte findet ihr auf LinkedIn: https://www.linkedin.com/in/michel-fritzsch