KI mit Firmendaten verbinden: Was technisch wirklich nötig ist

Ein Sprachmodell lässt sich in wenigen Tagen an eine Firmenumgebung anbinden. Der Test mit drei freigegebenen PDF-Dateien liefert brauchbare Antworten, die Geschäftsführung ist beeindruckt, und danach beginnt der eigentliche Teil: Der Assistent soll Fragen zu Angeboten, Aufträgen, Lieferanten und Arbeitsanweisungen beantworten. Genau dort zeigt sich, dass nicht das Modell die Grenze war, sondern die Datenbasis. Antworten zitieren eine Arbeitsanweisung, die seit zwei Jahren außer Kraft ist. Ein Vertriebsmitarbeiter erhält Margen aus einer Kalkulationstabelle, die er im Dateisystem nie hätte öffnen dürfen. Und niemand kann sagen, ob eine Antwort richtig war, weil es keinen Fragenkatalog gibt, an dem man sie prüfen könnte.

Solche Vorhaben scheitern selten an Rechenleistung. Sie scheitern an Quellen, Rechten, Aktualität und fehlender Messung. Dieser Beitrag beschreibt, was technisch nötig ist, bevor ein Assistent auf Firmendaten zugreifen sollte.

Warum die Demo funktioniert und der Betrieb scheitert

In einer Demo gibt es wenige Dokumente, eine Person, die alles kennt, keine Rechteunterschiede und keine Altversionen. Die Fragen stammen von der Person, die das System aufgebaut hat. Im Betrieb treffen andere Bedingungen zusammen: mehrere Hunderttausend Dateien aus fünf Systemen, Dokumente in vier Generationen, gewachsene Berechtigungen und Fragen, die niemand vorhergesehen hat.

Das amerikanische NIST beschreibt in seinem Risk Management Framework für KI genau diese Risikoklasse: ungeeignete, veraltete oder nicht repräsentative Daten sowie fehlende Nachvollziehbarkeit von Ergebnissen. Wer diese Punkte erst nach dem Pilotprojekt prüft, prüft sie zu spät. Zuständigkeiten und Leitplanken lassen sich vorab klären, wie wir es unter KI in Geschäftsprozessen sicher einsetzen beschrieben haben.

Die vier technischen Bausteine

Unabhängig vom gewählten Modell besteht jede tragfähige Anbindung aus vier Teilen:

1. Quellenanbindung: ein definierter, wiederholbarer Weg in die führenden Systeme wie ERP, CRM, DMS, Microsoft 365 und Ticketsystem.
2. Aufbereitung und Index: Text extrahieren, sinnvoll zerlegen, mit Metadaten versehen und suchbar ablegen.
3. Rechteprüfung: bei jeder Anfrage entscheiden, welche Inhalte dieser Nutzer sehen darf.
4. Protokollierung und Bewertung: Frage, Quellen, Antwort und Rückmeldung nachvollziehbar festhalten.

Der dritte Punkt ist der aufwendigste und der am häufigsten unterschätzte. Wie die Aufbereitung im Detail aussieht, steht im Beitrag zu RAG für eigene Dokumente.

Führende Systeme statt Kopien

Die entscheidende Regel lautet: Jede Information hat genau ein führendes System. Zeichnungen und Freigaben liegen im DMS, Kunden- und Auftragsdaten im ERP, Angebotsstände im CRM, Störungsprotokolle im Ticketsystem, Verträge in der Vertragsablage. Der Assistent verlinkt dorthin, statt eigene Kopien zu pflegen.

Wird diese Regel verletzt, entsteht ein fünftes Ablagesystem, das niemand verantwortet. Nach der dritten Kopie weiß kein Mitarbeiter mehr, welche Fassung gilt. Ein Index, der alle Dateien flach einsammelt, verschärft das Problem, weil er die veraltete Version genauso selbstbewusst zitiert wie die aktuelle.

Zweite Voraussetzung sind stabile Schlüssel. Kundennummer, Artikelnummer, Projektnummer und Anlagennummer müssen über Systeme hinweg identisch sein. Ohne sie lässt sich ein Dokument nicht sicher einem Vorgang zuordnen. Der Assistent findet dann zwar eine Datei, kann aber nicht sagen, zu welchem Auftrag sie gehört. Genau hier rächt sich ungepflegtes Stammdatenmanagement: Dubletten, Freitextfelder und abweichende Schreibweisen werden vom Modell nicht korrigiert, sondern vervielfacht.

Rechte, Aktualität und Verantwortung

Zugriff wird bei jeder Anfrage geprüft

Ein Assistent darf keine Inhalte preisgeben, die der fragende Nutzer im Quellsystem nicht sehen dürfte. Das betrifft Kalkulationen, Personalunterlagen, Kundenverträge, Entwicklungsdaten und Margen. Technisch übernimmt die Suche deshalb die bestehenden Gruppen und Rollen aus dem Identitätsmanagement, statt eigene Berechtigungen zu erfinden. Die Prüfung erfolgt bei der Anfrage, nicht nur beim Import.

Rechte wirken dabei auf zwei Ebenen. Auf Dokumentebene entscheidet die Schutzklasse, ob ein Text überhaupt in Frage kommt. Auf Feldebene geht es um einzelne Werte innerhalb eines Dokuments: Ein Angebot darf für den Außendienst sichtbar sein, die hinterlegte Marge darin nicht. Solche Fälle lassen sich nicht nachträglich in der Antwort wegfiltern. Sie müssen bereits beim Aufbereiten erkannt und getrennt abgelegt werden.

Praktisch enthält jede Antwort einen Verweis auf die Fundstelle im führenden System. Wer den Verweis öffnet, landet in einem System, das die dort gültigen Rechte ohnehin durchsetzt. Das ist der wirksamste Schutz gegen unbeabsichtigte Offenlegung – nicht eine besonders kluge Formulierung des Modells.

Ein häufig übersehener Punkt ist die Protokollierung selbst. Wenn Fragen und Antworten im Klartext in einem Protokoll landen, das breit gelesen werden darf, entsteht ein neuer Datenabfluss. Protokolle gehören in denselben Schutzbereich wie die Inhalte, die sie referenzieren.

Löschung, Versionen und Eigentümer

Ein Index altert schneller als erwartet. Deshalb braucht die Pipeline inkrementelle Importe, eine Erkennung geänderter Dateien, die Übernahme von Löschungen und einen klaren Rhythmus für die erneute Aufbereitung. Wird eine Arbeitsanweisung zurückgezogen, muss sie aus Suche und Antwortkontext verschwinden. Ein nächtlicher Komplettimport ohne Qualitätskontrolle erfüllt diese Anforderung nicht.

Ebenso wichtig ist der Umgang mit Versionen. Wird ein Dokument ersetzt, müssen alter und neuer Stand unterscheidbar bleiben. Andernfalls zitiert der Assistent einen Stand, den der Fachbereich nie freigegeben hat. Bei sicherheitsrelevanten Inhalten gehört eine kurze inhaltliche Kontrolle in den Import, nicht nur ein technischer Abgleich von Dateidatum und Prüfsumme.

Zum Betrieb gehört außerdem ein Plan für den Fall, dass der Index vollständig neu aufgebaut werden muss. Wer Modelle, Konfiguration und Quellenstände nicht versioniert, kann nach einem Ausfall nicht mehr nachvollziehen, auf welcher Grundlage frühere Antworten entstanden sind.

Verantwortung lässt sich nicht an die IT delegieren. Die IT betreibt die Pipeline, kann aber fachlich nicht entscheiden, ob eine Prüfanweisung noch gilt. Für jeden Datenbereich braucht es einen benannten Eigentümer, der Inhalte freigibt und in festen Abständen prüft. Fehlt diese Rolle, wächst der Index, während die Verlässlichkeit sinkt. Wie eine solche Wissensbasis organisatorisch aufgebaut wird, beschreibt der Beitrag zur internen Wissensdatenbank mit KI.

Woran sich der Nutzen messen lässt

Vor dem Start werden 50 bis 100 echte Fragen gesammelt – aus E-Mail, Übergabe, Support und Vertrieb – und von Fachleuten verbindlich beantwortet. Dieser Katalog ist der Maßstab. Gemessen werden Trefferquote, Anteil der Antworten mit korrekter Quelle, Anteil unbeantworteter Fragen und die Zahl veralteter Aussagen. Zusätzlich lohnt der Blick auf die Suchzeit im Alltag.

Erst wenn diese Werte über mehrere Wochen stabil sind, ist der Schritt in weitere Datenbereiche sinnvoll. Vorher ist jede Ausweitung nur eine Vergrößerung des ungeprüften Teils.

Fazit: KI mit Firmendaten zu verbinden ist zuerst eine Integrations- und Governance-Aufgabe und erst danach eine Modellfrage. Wer Quellen, Rechte, Aktualität und Messung klärt, bekommt einen Assistenten, dem Fachleute trauen. Wer diese Arbeit überspringt, bekommt ein System, das überzeugend klingt und niemandem hilft. Wie wir solche Anbindungen aufbauen, beschreiben wir unter Leistungen.