Die Datenbasis, die KI-Agenten wirklich brauchen

Ein verbreiteter Reflex vor dem ersten KI-Projekt ist, zunächst eine umfassende Dateninfrastruktur aufzubauen: ein zentrales Data Warehouse, saubere Pipelines aus allen Systemen, eine einheitliche Datenplattform. Das klingt nach solider Vorbereitung. In der Praxis verzögert es den ersten produktiven Anwendungsfall um Monate, oft um länger als die gesamte spätere Umsetzung dauert. Am Ende dieser Vorbereitung steht dann häufig eine Plattform, für die noch niemand einen konkreten Anwendungsfall definiert hat.

Ein Agent für einen konkreten Anwendungsfall braucht nicht alle Daten des Unternehmens. Er braucht gezielten Zugriff auf die wenigen Quellen, die für genau diesen Anwendungsfall relevant sind. Ein Agent für Rechnungsprüfung braucht Zugriff auf Rechnungen, Bestellungen und Zahlungsbedingungen – nicht auf die gesamte Kundenhistorie oder das Personalsystem.

Diese Eingrenzung ist kein Kompromiss, sondern ein Vorteil. Weniger Systeme bedeuten weniger Integrationsaufwand, weniger Berechtigungsfragen und ein kleineres Risiko, dass der Agent Zugriff auf Daten bekommt, die er für seine Aufgabe gar nicht braucht. Ein eng zugeschnittener Agent ist leichter zu prüfen als ein Agent mit Zugriff auf alles.

Drei Bausteine reichen für die meisten ersten Anwendungsfälle. Erstens: relevante Dokumente in durchsuchbarer Form – Richtlinien, Produktinformationen, frühere vergleichbare Fälle, aktuell gehalten und ohne widersprüchliche Duplikate. Zweitens: strukturierter Zugriff auf die operativen Systeme, über eine Schnittstelle, nicht über einen manuellen Export, der schon am nächsten Tag veraltet ist. Drittens: ein Berechtigungsmodell, das den bestehenden Zugriffsregeln im Unternehmen entspricht – ein Agent sollte nicht mehr sehen dürfen als die Person, in deren Auftrag er handelt.

Fehlt einer dieser drei Bausteine, kompensiert kein noch so leistungsfähiges Sprachmodell die Lücke. Ein Agent ohne aktuelle Dokumente rät. Ein Agent ohne strukturierten Systemzugriff arbeitet mit veralteten Ständen. Ein Agent ohne klares Berechtigungsmodell ist ein Compliance-Risiko, sobald er produktiv geht.

Diese drei Bausteine lassen sich in der Reihenfolge ihrer Dringlichkeit angehen. Zuerst die Dokumente, weil sie meist am schnellsten zu bereinigen sind. Dann der Systemzugriff, weil er in der Regel eine technische Anbindung braucht, die etwas Vorlaufzeit hat. Das Berechtigungsmodell zuletzt, aber nie ganz am Ende – es sollte feststehen, bevor der Agent zum ersten Mal mit echten Daten arbeitet, nicht erst, nachdem eine Prüfung danach gefragt hat.

Erstens: veraltete oder doppelte Dokumentation, bei der niemand mehr weiß, welche Version gilt. Zweitens: Wissen, das nur in unstrukturierter Form existiert – gescannte PDFs, E-Mail-Verläufe, handschriftliche Vermerke –, auf die kein System programmatisch zugreifen kann. Drittens: inkonsistente Kennungen zwischen Systemen, etwa wenn dieselbe Bestellung im CRM und im ERP unterschiedliche Nummern trägt und sich beide Datensätze nicht automatisch zuordnen lassen. Viertens: das Fehlen einer Person, die für ein Datenthema tatsächlich zuständig ist und Zugriff freigeben kann, ohne dass die Anfrage in einer Warteschlange zwischen Abteilungen verschwindet.

Jeder dieser vier Blocker lässt sich beheben, aber keiner davon durch ein besseres Sprachmodell. Es sind organisatorische und keine technischen Probleme, auch wenn sie sich wie technische Probleme anfühlen, wenn ein Agent-Projekt daran scheitert. Wer diese vier Punkte vor dem Projektstart prüft, erspart sich die häufigste Ursache für gescheiterte erste Anwendungsfälle.

Ein Sprachmodell gleicht sprachliche Unschärfe erstaunlich gut aus – unpräzise Formulierungen, uneinheitliche Terminologie, informelle Notizen. Es gleicht keine falschen oder fehlenden Fakten aus. Wenn die hinterlegte Rückgaberichtlinie veraltet ist, gibt der Agent selbstbewusst die veraltete Antwort, ununterscheidbar von einer korrekten.

Das macht Datenbereinigung gefährlicher zu ignorieren als bei klassischer Software. Ein herkömmliches System ohne Daten liefert offensichtlich keine Antwort. Ein Agent auf Basis eines Sprachmodells liefert eine Antwort, die überzeugend klingt und trotzdem falsch ist. Diese Fehler fallen später auf, meist bei einem Kunden oder in einer Prüfung, nicht während der Entwicklung.

Deshalb lohnt sich vor jedem Projektstart eine ehrliche Stichprobe: Nehmen Sie zehn typische Anfragen aus dem geplanten Anwendungsfall und prüfen Sie von Hand, ob die vorhandenen Quellen jede davon korrekt beantworten würden. Scheitert die Stichprobe bereits bei zwei oder drei Fällen, ist das kein Grund, das Projekt zu verschieben – es ist die Liste der Dinge, die vor dem Start noch bereinigt werden müssen.

Für einen ersten Anwendungsfall reicht eine bewusst kleine Ausstattung: eine gut gepflegte Quelle der Wahrheit für den gewählten Prozess, ein Weg für den Agenten, sie programmatisch abzurufen, eine klare Entscheidung darüber, wer Zugriff freigibt, und ein definierter Rückfallpunkt für Fälle, in denen sich der Agent unsicher ist. Diese vier Elemente lassen sich für einen einzelnen, gut gewählten Anwendungsfall in Wochen aufbauen, nicht in Quartalen.

Der Fehler liegt selten darin, zu wenig Infrastruktur zu haben. Er liegt darin, die falsche Reihenfolge zu wählen – erst die große Plattform, dann der erste Anwendungsfall, statt umgekehrt. Die kleine Ausstattung ist dabei kein Provisorium, das später komplett ersetzt wird. Sie ist die erste, korrekt dimensionierte Version einer Infrastruktur, die mit jedem weiteren Anwendungsfall gezielt wächst.

Der Rückfallpunkt verdient dabei besondere Aufmerksamkeit, weil er am häufigsten vergessen wird. Er sollte festlegen, dass ein unsicherer Fall an einen Menschen geht, und mit welchem Kontext: welche Frage der Agent nicht beantworten konnte, welche Daten er dafür herangezogen hat, und woran die Unsicherheit lag. Ohne diesen Kontext beginnt die Person, die übernimmt, wieder bei null.

Sobald ein Agent Entscheidungen trifft, die für einen Kunden oder eine Prüfung relevant sind, wird nachvollziehbar sein müssen, welche Daten er zum Zeitpunkt der Entscheidung gesehen hat. Diese Protokollierung von Anfang an einzubauen, ist deutlich günstiger, als sie später nachzurüsten, wenn bereits produktiv gearbeitet wird und ein Nachweis gebraucht wird.

Dieselbe Protokollierung ist auch die Grundlage für Qualitätskontrolle: Wenn ein Agent falsch entscheidet, zeigt das Protokoll, ob die Ursache eine fehlende, veraltete oder falsch interpretierte Information war. Ohne dieses Protokoll bleibt jede Fehlersuche eine Vermutung. Für Unternehmen, die unter den EU AI Act fallen oder ihn absehbar tun werden, ist dieselbe Protokollierung außerdem die Grundlage für die geforderte Nachvollziehbarkeit automatisierter Entscheidungen.

Bevor ein Unternehmen sein erstes offizielles KI-Projekt startet, nutzen einzelne Mitarbeitende meist längst öffentliche KI-Werkzeuge auf eigene Faust – für Textentwürfe, Zusammenfassungen, manchmal auch für die Analyse interner Dokumente. Dabei gelangen häufig Kundendaten, Vertragsinhalte oder interne Kennzahlen in Systeme außerhalb der Kontrolle des Unternehmens, ohne böse Absicht, einfach weil es die schnellste verfügbare Lösung war.

Diese Schatten-Nutzung ist kein Randthema, sondern der eigentliche Ausgangspunkt vieler Datenprojekte. Ein Blick darauf, was Mitarbeitende bereits heute in welche Werkzeuge eingeben, zeigt zuverlässiger als jeder Workshop, wo der tatsächliche Bedarf liegt – und wo eine offizielle, kontrollierte Lösung mit klarem Datenzugriff dringend gebraucht wird. Ein offenes Gespräch darüber, ohne Vorwurf an die Mitarbeitenden, bringt diese Praxis meist schneller ans Licht als eine formale Richtlinie.

Der richtige Zeitpunkt für eine größere Investition in gemeinsame Dateninfrastruktur ist der Moment, in dem mehrere Agenten oder Anwendungsfälle beginnen, um dieselben Datenquellen zu konkurrieren – wenn zum Beispiel der dritte Agent denselben Kundendatensatz braucht, den die ersten beiden bereits jeweils eigenständig angebunden haben. Dann lohnt sich eine gemeinsame Schicht, die alle Agenten teilen, statt für jeden Anwendungsfall eine eigene Anbindung zu bauen.

Vor diesem Punkt ist eine große Dateninvestition eine Wette auf zukünftigen Bedarf, den Sie noch nicht kennen. Nach diesem Punkt ist sie eine Reaktion auf einen Bedarf, der bereits sichtbar geworden ist. Die zweite Wette ist die deutlich sicherere – und meist auch die günstigere, weil sie genau die Anforderungen abdeckt, die tatsächlich entstanden sind, statt solcher, die sich jemand im Voraus vorgestellt hat.