Der wertvollste KI-Anwendungsfall in den meisten Unternehmen zeigt sich nach aussen gar nicht. Es ist der interne Assistent, den Mitarbeitende fragen, statt zum dritten Mal die Kollegin im Grossraumbüro zu unterbrechen. Er scheitert selten am Modell – er scheitert an Berechtigungen, an widersprüchlicher Dokumentation und daran, dass die wichtigste Hälfte des Wissens in einer Datenbank liegt und nicht in einem Text.

Fragen Sie in einem Unternehmen mit einigen hundert Mitarbeitenden, wo das Prozesswissen liegt, und Sie erhalten eine ehrliche Antwort: teils in Confluence, teils in Jira-Tickets, teils im ERP oder in der Fachanwendung, und der Rest in den Köpfen von drei bis vier Personen, die alle zu viel zu tun haben. Die Suche in Confluence findet Seiten. Antworten findet sie nicht. Und wer ein Ticket sucht, in dem dieselbe Frage vor zwei Jahren schon einmal geklärt wurde, braucht Glück oder die richtige Kollegin.

Genau hier setzt ein firmeneigener Assistent an – nicht als Chatbot auf der Website, sondern als interne Anlaufstelle für Fragen, die heute Menschen unterbrechen. Wir haben solche Systeme gebaut, und wir haben gesehen, an welchen Stellen sie kippen. Fast keine davon ist ein KI-Problem im engeren Sinn.

Das Ausgangsproblem: Die Antwort existiert – nur nicht an einem Ort

Wenn eine Sachbearbeiterin fragt «Wie gehe ich bei einer Mutation mit rückwirkender Gültigkeit vor?», dann ist die Antwort im Unternehmen vorhanden. Sie besteht aber aus vier Teilen: einer Confluence-Seite mit dem offiziellen Prozess, einem Jira-Ticket, in dem eine Ausnahme für einen bestimmten Fall beschlossen wurde, einem Blick in die Fachanwendung, um zu sehen, welcher Status dort gesetzt ist, und einer Handvoll Erfahrung, die niemand aufgeschrieben hat.

Drei Muster machen das Zusammensetzen mühsam – und sie sind der eigentliche Grund, warum ein Assistent hier Wert schafft:

• Verstreutheit. Kein System hat die ganze Antwort. Die Suche in jedem einzelnen System liefert Treffer aus genau diesem System.
• Widerspruch. Die Confluence-Seite beschreibt Variante A, das neuere Ticket beschreibt Variante B. Beides steht da, nichts ist als überholt markiert.
• Alter. Dokumentation verfällt, ohne sich zu beschweren. Eine Seite von 2021 sieht genauso vertrauenswürdig aus wie eine von letzter Woche.

Ein Assistent, der diese drei Muster nicht adressiert, ist eine bessere Suche mit einem flüssigeren Tonfall. Das ist nicht wertlos, aber es ist kein Grund für ein Projekt.

Warum «RAG über Confluence» allein nicht reicht

Der naheliegende erste Ansatz lautet: Confluence-Export embedden, Vektorsuche darüber, Modell antworten lassen. Das funktioniert in der Demo und stösst in der Praxis auf drei harte Grenzen.

Alle Seiten sind gleich viel wert. Textähnlichkeit kennt kein Datum, keinen Status und keine Zuständigkeit. Eine verwaiste Entwurfsseite konkurriert auf Augenhöhe mit dem freigegebenen Prozessdokument – und gewinnt manchmal, weil sie die Frage wörtlicher trifft. Der Index muss Metadaten mitführen und sie auch benutzen: Änderungsdatum, Space, Freigabestatus, Autorenschaft. Eine Seite, die seit Jahren niemand angefasst hat, darf nicht dieselbe Stimme haben wie die aktuell gepflegte.

Ticket-Kommentare widersprechen der Doku – und haben oft recht. In Jira steht, was tatsächlich entschieden wurde, häufig präziser als in der Dokumentation. Zugleich ist ein Ticket-Kommentar ein Gesprächsfetzen und keine Regel: «Machen wir für diesen Kunden einmalig anders» darf nicht als generelle Vorgehensweise zurückkommen. Tickets brauchen deshalb Kontext – Status, Auflösung, Projekt, Zeitpunkt – und eine Behandlung, die zwischen «so ist es entschieden» und «so wurde einmal diskutiert» unterscheidet.

Tabellen und Datenbankinhalte lassen sich nicht sinnvoll zerschneiden. Eine Tarifmatrix, eine Zuständigkeitstabelle, eine Liste von Produktvarianten: Zerlegt in Textschnipsel verliert sie genau das, was sie ausmacht – den Zusammenhang zwischen Zeile und Spaltenkopf. Die Antwort auf «Welcher Satz gilt für Kategorie 3 ab Juli?» kommt aus einer Abfrage, nicht aus einer Ähnlichkeitssuche. Wer versucht, das mit Chunking zu lösen, bekommt plausibel klingende falsche Zahlen. Wir haben die Mechanik dahinter in unserem Beitrag zur Retrieval-Architektur ausführlicher beschrieben.

Berechtigungen: der Punkt, an dem die meisten Projekte kippen

Das ist die Anforderung, die in Workshops als Nebensatz auftaucht und später die Architektur bestimmt: Der Assistent darf einer Person nur zeigen, was sie ohnehin sehen dürfte.

Das klingt selbstverständlich und ist es technisch nicht. Confluence hat Space- und Seitenrechte, Jira hat Projekt- und Issue-Level-Sicherheit, das Fachsystem hat Rollen und Mandantentrennung. Wenn Sie all das in einen gemeinsamen Index schreiben, haben Sie diese Grenzen in dem Moment aufgelöst, in dem Sie den Index angelegt haben. Ein Assistent, der aus dem HR-Space zitiert, weil dort die Antwort am besten passte, ist kein Komfortproblem. Er ist ein Vorfall.

Praktisch heisst das:

• Berechtigungen gehören in den Index, nicht in den Prompt. Jeder Chunk trägt die Zugriffsinformationen seiner Quelle mit. Gefiltert wird vor dem Retrieval, nicht danach – und schon gar nicht durch eine Anweisung an das Modell, bestimmte Inhalte nicht zu verwenden. Ein Modell ist keine Zugriffskontrolle.
• Rechte ändern sich, der Index muss nachziehen. Eine Person wechselt die Abteilung, ein Space wird eingeschränkt, ein Projekt wird geschlossen. Wenn Ihre Synchronisation Inhalte kopiert, aber Rechteänderungen erst beim nächsten Vollimport übernimmt, haben Sie ein Zeitfenster, das Sie niemandem erklären möchten.
• Sensible Quellen bleiben besser draussen. Nicht jede Datenquelle muss angebunden werden. Lohndaten, Personaldossiers, laufende arbeitsrechtliche Fälle: Der Mehrwert im Assistenten ist klein, das Risiko gross. Diese Entscheidung trifft man am Anfang, nicht nach dem ersten Vorfall.
• Protokollieren, wer was gefragt hat. Nicht zur Überwachung, sondern weil Sie im Zweifelsfall nachweisen müssen, welche Inhalte an wen ausgeliefert wurden.

Wer diesen Teil früh ernst nimmt, baut ein System, das man ausrollen kann. Wer ihn aufschiebt, baut einen Piloten, der die Freigabe nie bekommt.

Strukturiert oder unstrukturiert: Abfrage statt Textähnlichkeit

Die zweite Architekturentscheidung ist weniger heikel, aber ebenso folgenreich. Fragen im Alltag teilen sich in zwei Sorten, und sie brauchen unterschiedliche Wege.

Fragen nach Wissen – «Wie läuft der Offboarding-Prozess?», «Was gilt bei einer Reklamation nach Ablauf der Garantie?» – beantwortet man mit Textsuche über Dokumentation und Tickets. Hier sind Vektorsuche, Stichwortsuche und ein Reranking-Schritt das richtige Werkzeug.

Fragen nach Fakten – «Wie viele offene Tickets hat Team B mit Priorität hoch?», «Welche Verträge laufen im November aus?», «Wer ist für Mandant X zuständig?» – beantwortet man mit einer Abfrage. Jira hat eine Abfragesprache, die Datenbank hat SQL, das Fachsystem hat eine API. Diese Wege sind exakt, nachvollziehbar und aktuell; eine Ähnlichkeitssuche über einen Datenbankdump ist keines davon.

In der Praxis kombiniert man beides, indem der Assistent zuerst entscheidet, welche Art von Frage vorliegt, und dann das passende Werkzeug einsetzt – bei Fakten eine parametrisierte, vorgegebene Abfrage statt frei generiertem SQL. Der Assistent wählt aus einem Katalog erlaubter Abfragen und füllt Parameter; er formuliert keine neuen Zugriffe auf Ihre Produktionsdatenbank. Das begrenzt, was schiefgehen kann, auf eine überschaubare und testbare Menge.

Die meisten Fragen sind übrigens gemischt: «Wie behandeln wir Fall Y, und haben wir das schon einmal gehabt?» braucht die Regel aus der Doku und den Präzedenzfall aus den Tickets. Ein System, das nur einen der beiden Wege kennt, antwortet auf die Hälfte der Frage.

Belege statt Behauptungen

Ein interner Assistent lebt von Vertrauen, und Vertrauen entsteht nicht durch guten Ton, sondern durch Überprüfbarkeit. Jede Antwort nennt ihre Quellen: die Confluence-Seite mit Änderungsdatum, das Ticket mit Nummer und Status, den Datensatz mit Stand der Abfrage. Verlinkt, nicht paraphrasiert.

Das wirkt nach zwei Seiten. Erstens kann die fragende Person prüfen, ob die Antwort trägt – und sie wird es in den ersten Wochen tun. Zweitens macht es die Verfallsdaten Ihrer Dokumentation sichtbar: Wenn ein Assistent eine Seite von 2022 als Grundlage nennt, fällt das auf. Mehrere Teams haben ihre Dokumentation erst aufgeräumt, nachdem der Assistent ihnen vorgehalten hat, worauf er sich stützt.

Dazu gehört die Fähigkeit, nicht zu antworten. Ein Assistent, der bei fehlender Grundlage sagt «dazu finde ich keine verbindliche Quelle, zuständig ist Team Z», ist deutlich mehr wert als einer, der immer etwas liefert. Die erste selbstbewusst erfundene Antwort auf eine Prozessfrage kostet mehr Vertrauen, als zwanzig gute Antworten aufbauen.

Woran Sie merken, dass es funktioniert

Der häufigste Fehler in der Einführung ist, dass niemand vorher definiert hat, was «gut» heisst. Dann entscheidet der Eindruck der Person, die am lautesten Feedback gibt.

Sammeln Sie stattdessen echte Fragen, bevor Sie ausrollen. Nicht erfundene Beispiele, sondern das, was tatsächlich gefragt wird: aus dem internen Support-Postfach, aus dem Team-Chat, aus den Tickets mit der Kategorie «Rückfrage». Hundert bis zweihundert solcher Fragen, mit der jeweils korrekten Antwort und der Quelle, an der sie steht – das ist Ihr Prüfmass. Nehmen Sie die unangenehmen mit: die, deren Antwort widersprüchlich dokumentiert ist, und die, bei denen die richtige Reaktion «das darf ich dir nicht zeigen» wäre.

Daran messen Sie zwei Dinge getrennt: Ob die nötige Information überhaupt gefunden wurde, und ob die Antwort daraus korrekt war. Das ist eine wichtige Trennung, weil sie die Korrekturmassnahme bestimmt – ein Retrieval-Problem löst man mit Indexierung, Metadaten und Reranking, ein Antwortproblem mit Prompting und Modellwahl. Wer nur die Endqualität betrachtet, optimiert die falsche Stufe. Zum systematischen Aufbau solcher Prüfsets haben wir einen eigenen Beitrag zu Evaluation Harnesses geschrieben.

Und lassen Sie die Fragensammlung nicht beim Go-live erfrieren. Jede Frage, bei der der Assistent daneben lag, kommt in die Sammlung. Nach einem halben Jahr ist das die genaueste Beschreibung Ihres Wissensstands, die Ihr Unternehmen besitzt.

Einführung: ein Team, eine Wissensdomäne

Interne Assistenten scheitern selten technisch. Sie scheitern daran, dass sie am ersten Tag alles können sollen.

Fangen Sie mit einer Domäne an, in der die Fragen hoch frequent, die Quellen überschaubar und die Konsequenzen einer falschen Antwort tragbar sind. Interne IT-Fragen, ein einzelner Fachbereich, das Onboarding neuer Mitarbeitender: Sie brauchen ein Feld, in dem Sie schnell lernen, ohne Schaden anzurichten. Ein Assistent, der für einen Bereich verlässlich ist, wird genutzt und weiterempfohlen. Einer, der überall halb funktioniert, wird nach zwei Wochen nicht mehr geöffnet.

Zwei Rollen müssen dabei benannt sein, mit Namen, nicht mit Abteilung:

• Wer entscheidet, welche Quelle bei Widerspruch gilt? Ohne diese Person bleibt jeder Konflikt in der Dokumentation ungelöst und der Assistent gibt beides zurück.
• Wer pflegt die Inhalte? Ein Assistent macht Dokumentationspflege nicht überflüssig, sondern sichtbar. Diese Pflege ist Betrieb, nicht Projekt – sie braucht Zeit im Kalender.

Der unangenehme Teil: Ein Teil des Projekts ist Aufräumarbeit. Veraltete Seiten archivieren, Doppelungen zusammenführen, Zuständigkeiten klären. Das ist nicht der spannende Teil, aber es ist der Teil, der über die Antwortqualität entscheidet – und er zahlt sich unabhängig vom Assistenten aus. Wie man den Zustand der eigenen Wissensbasis vorher einschätzt, beschreiben wir in unserem Beitrag zur Data Readiness.

Datenschutz und Betrieb in der Schweiz

Bei einem internen Assistenten fliessen Inhalte aus Ihren Kernsystemen in ein Modell. Drei Fragen müssen Sie beantworten können, bevor die erste Abfrage läuft.

Wo läuft das Modell? Ein Modell in der Schweiz oder in der EU, ein Modell bei einem Hyperscaler mit vertraglich zugesicherter Region, ein Modell in Ihrer eigenen Infrastruktur: Diese Optionen unterscheiden sich in Kosten, Qualität und Aufwand deutlich. Die Entscheidung ist nicht rein technisch – sie hängt daran, welche Datenkategorien der Assistent zu sehen bekommt.

Was bekommt es zu sehen? Nicht der ganze Index geht bei jeder Frage an das Modell, sondern die abgerufenen Ausschnitte. Diese Unterscheidung ist in Datenschutzgesprächen zentral und wird regelmässig übersehen. Prüfen Sie ausserdem, ob und wie lange Prompts beim Anbieter gespeichert werden und ob sie zum Training verwendet werden dürfen – das ist Vertragssache, nicht Vertrauenssache.

Was gilt zusätzlich in Ihrer Branche? Im Finanzsektor, im Versicherungsbereich, im Gesundheitswesen und bei öffentlichen Auftraggebern kommen Auslagerungsvorgaben, Berufsgeheimnisse und Aufsichtserwartungen hinzu. Dann kann die zulässige Variante eine andere sein als die technisch attraktivste, und Rückfragen bei der Aufsicht oder beim Datenschutzverantwortlichen brauchen Vorlaufzeit. Wir planen diese Abklärung in solchen Projekten von Anfang an ein, weil sie sonst am Ende zum Terminrisiko wird – mehr dazu in unserer Beratung zu IT-Strategie und Consulting.

Wann sich ein interner Assistent nicht lohnt

Es gibt Situationen, in denen wir davon abraten – und das sind nicht die Ausnahmefälle.

Wenn es kaum Dokumentation gibt. Ein Assistent kann Wissen zusammenführen, nicht erzeugen. Liegt der Prozess ausschliesslich in Köpfen, ist das erste Projekt ein Dokumentationsprojekt. Das ist eine unpopuläre, aber ehrliche Auskunft.

Wenn die Fragen selten sind. Wenn eine Frage im Monat dreimal gestellt wird, sparen Sie mit einer guten Übersichtsseite mehr als mit einem System, das gepflegt, betrieben und aktualisiert werden muss.

Wenn niemand die Inhalte verantwortet. Ohne benannte Zuständigkeit verfällt die Wissensbasis, und der Assistent wird mit ihr zusammen unzuverlässig – nur schneller, weil er Fehler nun in flüssigen Sätzen ausliefert.

Wenn die eigentliche Frage ein Prozessproblem ist. Wenn Mitarbeitende dauernd nachfragen müssen, weil ein Formular unklar oder ein Ablauf widersprüchlich ist, dann ist der Assistent ein Pflaster. Den Ablauf zu korrigieren ist günstiger und wirkt länger. Genau diese Unterscheidung – automatisieren oder vorher vereinfachen – nehmen wir in Projekten zur Automatisierung und KI zuerst vor.

Wenn das Ziel Personalabbau ist. Interne Assistenten wirken über weniger Unterbrechungen und kürzere Einarbeitung, nicht über eingesparte Stellen. Wer sie mit einer Abbauerwartung einführt, bekommt ein System, das niemand mit Inhalten füttert.

Entscheidungs-Checkliste

1. Welche fünf Fragen werden intern am häufigsten gestellt, und wo liegen ihre Antworten heute?
2. Welche Quellen sind so gepflegt, dass man ihnen eine Antwort zutrauen kann – und welche nicht?
3. Wie werden die Berechtigungen jeder Quelle im Index abgebildet, und wie schnell wirken Änderungen?
4. Welche Fragen brauchen eine Abfrage statt einer Textsuche, und welche Abfragen erlauben wir?
5. Nennt jede Antwort eine prüfbare Quelle mit Stand?
6. Haben wir eine Sammlung echter Fragen mit korrekten Antworten als Prüfmass?
7. Wer entscheidet bei widersprüchlichen Quellen, und wer pflegt die Inhalte im Betrieb?
8. Welche Datenkategorien sieht das Modell, wo läuft es, und was gilt in unserer Branche zusätzlich?

Die gridz-Sicht

Ein interner Assistent ist kein KI-Projekt mit Wissensanteil, sondern ein Wissensprojekt mit KI-Anteil. Der Modellteil ist heute der berechenbarste Baustein; die Arbeit liegt in den Berechtigungen, in der Entscheidung, welche Quelle bei Widerspruch gilt, und in der Disziplin, Antworten belegbar zu machen. Genau diese Reihenfolge trennt Systeme, die nach sechs Monaten noch benutzt werden, von Piloten, die als Demo in Erinnerung bleiben.

Unser Vorgehen ist entsprechend unspektakulär: eine Domäne, echte Fragen als Prüfmass, Berechtigungen vor dem ersten Index, Belege in jeder Antwort. Wenn Sie überlegen, ob sich das für Ihre Prozesse lohnt, schauen wir uns gerne an, welche Fragen bei Ihnen heute Menschen unterbrechen – sprechen Sie uns an.