Datenherkunft für KI dokumentieren richtig

Eine KI-Anwendung kann fachlich überzeugende Ergebnisse liefern und dennoch im produktiven Betrieb scheitern, wenn niemand belastbar beantworten kann, aus welchen Daten sie gelernt hat oder welche Daten eine konkrete Ausgabe beeinflusst haben. Gerade bei SAP-nahen Prozessen, integrierten Datenlandschaften und regulierten Fachbereichen ist Datenherkunft für KI dokumentieren deshalb keine nachgelagerte Compliance-Aufgabe. Es ist eine Voraussetzung für steuerbare Modelle, nachvollziehbare Entscheidungen und revisionssicheres Reporting.

Die entscheidende Frage lautet nicht nur: Welche Daten sind verfügbar? Entscheidend ist, ob Herkunft, Verarbeitung und Verwendung über den gesamten Lebenszyklus nachvollziehbar bleiben. Das betrifft Trainingsdaten ebenso wie Daten für Tests, Validierung, laufende Inferenz und menschliche Entscheidungen im Anschluss an eine KI-Empfehlung.

Warum Datenherkunft bei KI eine Betriebsfrage ist

Datenherkunft, häufig auch Data Lineage genannt, beschreibt den Weg von Daten von ihrer Quelle bis zu ihrer Verwendung. Bei KI erweitert sich dieser Weg: Rohdaten werden extrahiert, bereinigt, zusammengeführt, angereichert und in Merkmale, Embeddings oder Trainingsdatensätze überführt. Anschließend fließen sie in Modelltraining, Evaluation oder produktive Entscheidungen ein.

Fehlt diese Kette, entstehen operative Risiken. Ein Fachbereich kann dann beispielsweise nicht beurteilen, ob eine Prognose noch auf aktuellen Stammdaten basiert. Das Data-Team kann einen Qualitätsfehler nicht gezielt eingrenzen. Und die IT kann bei Änderungen an einer Schnittstelle nicht sicher abschätzen, welches Modell, welcher Report oder welcher Geschäftsprozess betroffen ist.

In Unternehmen mit SAP-Landschaften ist das besonders relevant. Eine Materialnummer, ein Kundenmerkmal oder ein Buchungsstatus kann seinen Ursprung in S/4HANA haben, über Middleware, Data Warehouse und Analyseplattform weitergegeben werden und schließlich in einem KI-Use-Case landen. Werden fachliche Bedeutung, technische Transformationen und Verantwortlichkeiten an einer Stelle getrennt oder nur informell festgehalten, ist die Nachvollziehbarkeit schnell unterbrochen.

Der Dokumentationsumfang hängt vom Einsatz ab. Ein internes Assistenzsystem mit klar abgegrenztem Wissensbestand benötigt eine andere Tiefe als ein Modell zur Bedarfsprognose, zur Priorisierung von Servicefällen oder zur Unterstützung qualitätsrelevanter Entscheidungen. Auch vertragliche Anforderungen, Datenschutz, Informationssicherheit und die Einordnung nach EU AI Act können den erforderlichen Nachweisumfang beeinflussen. Die technische Dokumentation sollte diese Anforderungen vorbereiten, ersetzt aber keine rechtliche Bewertung.

Datenherkunft für KI dokumentieren: Was konkret festzuhalten ist

Eine brauchbare Dokumentation ist kein einmaliger Datenkatalog und keine Sammlung von Screenshots. Sie verbindet fachliche und technische Sicht und bleibt mit Veränderungen nachvollziehbar. Für jeden Datensatz oder Datenbereich, der für den KI-Einsatz relevant ist, sollten mindestens die folgenden Informationen strukturiert erfasst werden:

• Ursprungsquelle, verantwortliches System und Datenobjekt, etwa SAP-Stammdaten, Prozessdaten, Dokumentenablagen oder externe Datenlieferungen.

• Fachlicher Zweck, Bedeutung einzelner Attribute sowie zugelassene und ausgeschlossene Verwendungszwecke.

• Erhebungszeitraum, Aktualisierungsfrequenz, Datenstand und Regeln für Aufbewahrung oder Löschung.

• Verarbeitungsschritte einschließlich Bereinigung, Dublettenbehandlung, Aggregation, Pseudonymisierung und Anreicherung.

• Qualitätskriterien, bekannte Einschränkungen, Prüfungen und die Ergebnisse von Datenqualitätskontrollen.

• Zugriff, Freigaben, verantwortliche Rollen und die konkrete Modell-, Prompt- oder Pipeline-Version, für die Daten verwendet wurden.

Diese Angaben müssen nicht zwingend in einem einzigen Werkzeug liegen. In der Praxis können Datenkatalog, Architekturrepository, Ticket-System, Quellcodeverwaltung und Modellregister zusammenwirken. Entscheidend ist, dass die Verweise eindeutig sind, Versionen verbunden werden und ein Prüfer den Weg ohne Interpretationslücken nachvollziehen kann.

Besonders oft fehlt die Verbindung zwischen Datenstand und Modellversion. Ein Modellname allein reicht nicht aus. Wenn ein Training am 15. Mai mit einem bestimmten Daten-Snapshot durchgeführt wurde, müssen Datenumfang, Selektionslogik, Vorverarbeitung und Ergebnis der Freigabe diesem Trainingslauf zugeordnet sein. Andernfalls lässt sich später nicht reproduzieren, warum eine Modellversion bestimmte Eigenschaften oder Fehler aufweist.

Vom Datenfluss zur belastbaren Nachweiskette

Der praktikable Einstieg ist selten die vollständige Dokumentation aller Daten im Unternehmen. Sinnvoller ist es, mit einem priorisierten KI-Use-Case zu beginnen und dessen Datenfluss Ende zu Ende aufzunehmen. Dabei wird der fachliche Prozess nicht ausgeblendet: Wer nutzt das Ergebnis, welche Entscheidung wird vorbereitet, und welche Auswirkungen hätte eine fehlerhafte Ausgabe?

1. Use Case und Entscheidungsgrenze festlegen

Zunächst braucht das Projekt eine klare Grenze. Bei einer Absatzprognose kann sie von der Extraktion historischer Auftragsdaten bis zur Übergabe eines Forecasts an die Disposition reichen. Bei einem Retrieval-Augmented-Generation-System umfasst sie zusätzlich die Dokumentenauswahl, Segmentierung, Indexierung und die Quellen, die dem Sprachmodell zur Beantwortung bereitgestellt werden.

Diese Abgrenzung verhindert einen typischen Fehler: Teams dokumentieren das Modell, aber nicht die Datenbereitstellung davor oder die fachliche Nutzung danach. Gerade die Schnittstellen sind jedoch häufig der Ort, an dem Verantwortung, Datenqualität und Freigaben verloren gehen.

2. Quellen und Transformationen fachlich lesbar modellieren

Eine technische Pipeline-Bezeichnung genügt nicht. Für jedes relevante Objekt sollte klar sein, welche fachliche Aussage darin steckt und durch welche Regel sie verändert wird. Aus dem Feld `Kundenstatus` wird beispielsweise nicht automatisch ein brauchbares KI-Merkmal. Wird es kategorisiert, zeitlich versetzt oder mit Vertriebsdaten kombiniert, muss die Logik beschrieben und versioniert werden.

Dabei sollten Teams zwischen Datenlineage und Entscheidungslineage unterscheiden. Datenlineage beantwortet, wo ein Wert herkommt. Entscheidungslineage ergänzt, wie dieser Wert in eine KI-Ausgabe und anschließend in eine Handlung eingeflossen ist. Für kritische Prozesse ist beides erforderlich.

3. Qualität und Eignung nachweisbar prüfen

Herkunft allein belegt noch nicht, dass Daten geeignet sind. Trainingsdaten können vollständig dokumentiert und dennoch verzerrt, veraltet oder fachlich falsch interpretiert sein. Daher gehören Qualitätsregeln direkt in die Nachweiskette: Pflichtfeldquoten, Wertebereiche, Zeitbezug, Dublettenraten und Verteilungen relevanter Gruppen sind typische Prüfgrößen.

Wichtig ist die fachliche Abnahme. Eine auffällige Verteilung kann ein technischer Fehler sein, sie kann aber auch die Realität des Geschäfts abbilden. Ohne den zuständigen Fachbereich lässt sich das nicht belastbar entscheiden. Die Abnahme sollte deshalb nicht als informelle E-Mail erfolgen, sondern als nachvollziehbarer Status mit Datum, Prüfumfang, Entscheidung und offenen Einschränkungen.

4. Änderungen kontrolliert in den Betrieb überführen

Datenquellen ändern sich laufend. Neue SAP-Attribute, angepasste Customizing-Regeln, veränderte Extraktionslogiken oder eine neue Dokumentenstruktur können die Aussagekraft eines KI-Systems beeinflussen. Ein wirksames Änderungsverfahren verknüpft daher Changes in Quellsystemen mit einer Auswirkungsanalyse für Datenprodukte und KI-Modelle.

Nicht jede Änderung erfordert ein neues Training. Eine Umbenennung ohne inhaltliche Änderung ist anders zu bewerten als eine geänderte Berechnungslogik für Liefertermine. Das Projekt braucht aber definierte Kriterien dafür, wann Tests, Datenfreigaben, Modellvalidierung oder eine erneute Risikoanalyse erforderlich werden.

Rollenmodell: Wer steht für welchen Nachweis ein?

Datenherkunft scheitert selten an fehlenden Tabellen. Sie scheitert an ungeklärten Zuständigkeiten. Der Data Owner verantwortet in der Regel die fachliche Bedeutung und zulässige Nutzung eines Datenbereichs. Der System- oder Applikationsverantwortliche steht für die technische Quelle und Änderungen am Quellsystem ein. Data Engineering verantwortet die Verarbeitungskette, während das KI-Team Modellierung, Evaluation und Versionsführung dokumentiert.

Für die Freigabe eines produktiven Use Cases sollten zusätzlich Fachverantwortung, Informationssicherheit, Datenschutz und gegebenenfalls Compliance eingebunden sein. Die konkrete Ausgestaltung hängt von Organisation und Risikolage ab. Entscheidend ist eine nachvollziehbare Entscheidungsinstanz, nicht möglichst viele Unterschriften.

Bei rechtlicher Einordnung etwa zu Datenschutz oder EU AI Act sollte das technische Projektteam seine Nachweise so aufbereiten, dass die Fragestellungen prüfbar sind. Soweit erforderlich, kann die rechtlich eigenständige Quteco Rechtsanwaltsgesellschaft mbH die rechtliche Bewertung im Kontext von IT-, Daten- und KI-Projekten übernehmen. Die Verantwortung für Datenflüsse und deren technische Dokumentation bleibt jedoch im Unternehmen verankert.

Typische Lücken, die Audits und Betrieb erschweren

Ein verbreitetes Problem sind manuelle Excel-Listen, die beim Go-Live vollständig wirken, aber nach wenigen Releases nicht mehr gepflegt werden. Ebenso kritisch sind Datenkataloge ohne Bezug zu konkreten Modellversionen. Sie beschreiben die Landschaft, liefern aber keinen Nachweis für einen bestimmten Trainings- oder Inferenzlauf.

Auch generative KI wird oft zu eng betrachtet. Bei einem unternehmensinternen Assistenten ist nicht nur das Basismodell relevant. Dokumentenquellen, Berechtigungsfilter, Index-Version, Retrieval-Konfiguration und verwendete Prompt-Vorlagen prägen die Antwort. Werden diese Elemente nicht protokolliert, lassen sich fehlerhafte oder unzulässige Antworten kaum zielgerichtet untersuchen.

Schließlich darf Dokumentation nicht zum Selbstzweck werden. Für einen begrenzten Pilotbetrieb kann ein schlankes, aber vollständiges Set an Nachweisen sinnvoller sein als ein umfassendes Metadatenprogramm, das erst nach Monaten nutzbar wird. Mit wachsender Kritikalität und produktiver Reichweite muss die Tiefe allerdings mitwachsen.

Datenflüsse vor dem Go-Live belastbar machen

Quteco unterstützt Teams mit Quick Checks, Workshops und operativer Projektbegleitung dabei, Datenflüsse für konkrete KI-Use-Cases aufzunehmen, Verantwortlichkeiten festzulegen und prüfbare Nachweise in bestehende SAP-, Daten- und Governance-Strukturen zu integrieren. Im Fokus stehen ein klarer Scope, umsetzbare Artefakte und ein Vorgehen, das auch unter Zeitdruck vor einem produktiven Einsatz tragfähig bleibt.

Eine gute Herkunftsdokumentation beantwortet nicht jede Frage im Voraus. Sie stellt aber sicher, dass die richtigen Fragen bei einer Änderung, einem Incident oder einer Prüfung ohne langwierige Rekonstruktion beantwortet werden können.