Was sind Data Products für KI?

Data Products für KI sind gesteuerte, kontextreiche Datenbestände, die eigens dafür entworfen sind, von KI-Systemen verlässlich genutzt zu werden: von großen Sprachmodellen, agentischen Abläufen, Pipelines für maschinelles Lernen und Analysen in natürlicher Sprache. Wo ein klassisches Data Product für Menschen und BI-Werkzeuge gebaut ist, ist ein Data Product für KI für die Nutzungsmuster gebaut, die KI-Systeme tatsächlich zeigen: semantische Suche, Retrieval-Augmented Generation, Werkzeugaufrufe von Agenten und fortlaufende Schleifen des Schließens.

Die Verschiebung zählt, weil KI Daten anders verbraucht als die Analytik. Ein Dashboard stellt eine feste Abfrage gegen eine kuratierte Tabelle dar. Ein LLM-Agent entscheidet zur Laufzeit, welche Daten er holt, verbindet fachlichen Kontext aus einem Glossar, führt eine Abfrage gegen einen Semantic Layer aus und schließt über die Ergebnisse. Wurde das zugrunde liegende Data Product in der Annahme entworfen, dass ein Mensch die Spaltennamen deutet, wird das LLM sie falsch deuten: selbstbewusst, häufig und in großem Umfang. Data Products für KI sind die Disziplin, Dateninfrastruktur für nicht menschliche Nutzer lesbar zu machen.

Data Products für KI im Überblick

Ein Data Product für KI ist eine Einheit gesteuerter Daten, deren Schnittstelle alles enthält, was ein KI-System braucht, um die Daten richtig zu nutzen. Das ist die Arbeitsdefinition. Klassische Data Products erfüllen die Eigenschaften, die Zhamak Dehghani in ihrer Formulierung des Data Mesh unter „DAUTNIVS“ zusammenfasst: auffindbar, adressierbar, verständlich, vertrauenswürdig, von Haus aus zugänglich, interoperabel, wertvoll und sicher. Data Products für KI ergänzen drei Eigenschaften, die auf nicht menschliche Nutzung zielen:

• Semantisch annotiert: Jedes Feld trägt eine Definition, idealerweise verankert in einem gesteuerten Business Glossary, in einer Form, die ein LLM zur Laufzeit lesen kann, um „Umsatz“ oder „aktiver Kunde“ so aufzulösen, wie die Organisation es festgelegt hat.
• Programmatisch von Agenten auffindbar: Metadaten werden über maschinenfreundliche Schnittstellen bereitgestellt (MCP Server, strukturierte API-Antworten, eingebettete Schemadateien), sodass ein Agent die verfügbaren Produkte auflisten und das richtige auswählen kann, ohne dass ein Mensch ihn dorthin leitet.
• Vertrauen zur Laufzeit bewertbar: Qualitätswerte, Angaben zur Aktualität, Kennzeichnungen der Klassifizierung und Informationen zur Verantwortung sind abfragbar, sodass der Agent entscheiden kann, ob die Daten für die aktuelle Aufgabe taugen, und die Antwort mit angemessener Sicherheit ausweist.

Warum klassische Data Products für KI nicht reichen

Das übliche Muster für Data Products entstand in einer auf Menschen ausgerichteten Analytik: einen kuratierten Datensatz bauen, ihn in einem Wiki oder Katalog dokumentieren, ihm einen Verantwortlichen geben, seine Qualität überwachen und ihn über SQL-Endpunkte und BI-Dashboards verfügbar machen. Für menschliche Nutzer trägt das, weil Menschen ihren eigenen Kontext mitbringen: Sie lesen die Dokumentation, fragen den Verantwortlichen, bemerken, wenn eine Kennzahl falsch aussieht, und passen ihre Abfragen an.

LLMs und Agenten tun das von sich aus nicht. Die Fehlerbilder sind gut belegt:

• Schema ohne Semantik: Eine Spalte namens cust_active_flg mit dem Kommentar „1 wenn aktiv“ sagt einem Menschen genug. Ein LLM weiß nicht, ob „aktiv“ heißt, in diesem Monat angemeldet, in den letzten 90 Tagen bezahlt oder nie abgewandert. Ohne eine im Glossar verankerte Definition rät das Modell.
• Dokumentation als Fließtext: Seiten in Notion und Confluence, die Menschen lesen, lassen sich von Agenten nur schwer verlässlich und in der richtigen Granularität abrufen. Dass die Dokumentation existiert, heißt nicht, dass das LLM sie findet, wenn es sie braucht.
• Fehlende Herkunft: Wenn ein Agent eine Zahl erzeugt, muss der nachgelagerte Empfänger (Auditor, Aufsicht, Nutzer) sie zurückverfolgen können. Legt das Data Product keine Lineage offen, ist die Spur unmöglich.
• Keine Zugriffsregeln auf Ebene des Data Product: Klassische Data Products behandeln Sicherheit als Sache der Infrastruktur. Data Products für KI brauchen Zugriffsregeln in den Metadaten des Produkts, damit Agenten zum Zeitpunkt der Anfrage abgewiesen oder gefiltert werden können und der Grund der Abweisung prüfbar ist.
• Qualität für Nutzer undurchsichtig: Menschliche Nutzer ertragen unklare Qualität, weil sie Auffälligkeiten in Diagrammen sehen. Agenten können das nicht. Data Products für KI brauchen maschinenlesbare Signale zu Qualität und Aktualität.

Aufbau eines Data Product für KI

Ein vollständiges Data Product für KI hat sieben miteinander verbundene Bestandteile. Fehlt einer davon, entsteht eine Sprödigkeit, die nachgelagerte Agenten früher oder später offenlegen.

1. Daten und Schema (maschinenlesbar)

Die Daten selbst, mit einem strukturierten Schema, das ein Agent untersuchen kann: Tabellen, Spalten, Typen, Constraints, Beispiele. Nicht nur die Speicherschicht, sondern eine veröffentlichte, versionierte Beschreibung des Schemas, die beim Produkt liegt.

2. Semantischer Kontext

Jede bedeutsame Spalte verweist auf eine Definition in einem gesteuerten Business Glossary. Die Definition enthält die maßgebliche fachliche Bedeutung, die Berechnungsregel, Synonyme, die ein Nutzer verwenden könnte, und Beispiele. Ein LLM, das „active_customer“ liest, erreicht die Definition über denselben MCP Server, über den es das Produkt gefunden hat.

3. Lineage und Herkunft

Lineage auf System- und auf Spaltenebene, abfragbar als Teil des Produkts. Wenn ein Agent eine Zahl erzeugt, kann die Antwort lauten „abgeleitet aus [Quelle A] über [Transformation B], zuletzt aktualisiert am [Datum]“, und aus einer KI-Ausgabe wird aus einer Vermutung eine prüfbare Aussage.

4. Zugriffsregeln

Eingebettete Regeln, die beschreiben, wer und was das Produkt lesen darf, zu welchen Zwecken und mit welcher Maskierung. Ein Agent, der sensible Daten ohne Berechtigung anfordert, erhält eine strukturierte Abweisung, die die verletzte Regel benennt, und kein allgemeines 403.

5. Verantwortung und Pflege

Benannte Verantwortliche und Data Stewards, auflösbar zu tatsächlichen Personen, mit ausdrücklichen Pflichten für Richtigkeit, Weiterentwicklung und SLAs des Data Product. Ohne das haben Agenten keinen Eskalationsweg, wenn sie Qualitätsprobleme feststellen.

6. Signale zu Qualität und Aktualität

Maschinenlesbare Werte: Anteil der Vollständigkeit, Genauigkeit gegen geprüfte Referenzen, Zeitstempel der letzten Aktualisierung, Hinweise auf Drift. Agenten fragen diese ab, bevor sie entscheiden, ob die Daten für die aktuelle Aufgabe taugen. Fällt die Aktualität durch, gibt der Agent die Antwort mit einem Vorbehalt aus, statt eine selbstbewusst falsche Zahl zu erzeugen.

7. Agentenfreundliche Schnittstelle

Eine Schnittstelle, die KI-Systeme unmittelbar nutzen können, üblicherweise ein MCP Server, der das Data Product als auffindbare Werkzeuge und Ressourcen bereitstellt, dazu strukturierte Werkzeugbeschreibungen für Werkzeugaufrufe und stabile URIs für Ressourcen. Ohne sie ist jede KI-Anbindung ein eigener Bau statt einer Konfiguration.

Data Products gegenüber RAG und Vektordatenbanken

Mehrere benachbarte Muster liefern Teile dessen, was Data Products für KI leisten, doch keines ersetzt sie:

• RAG (Retrieval-Augmented Generation): holt Textabschnitte, die zu einer Anfrage passen, und fügt sie in die Eingabe ein. Gut für Grounding auf unstrukturierten Inhalten. RAG ersetzt keine gesteuerten strukturierten Daten, und die meisten RAG-Systeme im Unternehmen scheitern genau dort, wo ungesteuerte Daten sie speisen.
• Vektordatenbanken: speichern Embeddings für die Ähnlichkeitssuche. Sie sind Infrastruktur für Speicherung und Abruf. Sie liefern weder Schema noch Lineage, Verantwortung oder Zugriffsregeln. Sie liegen innerhalb des Aufbaus eines Data Product für KI, nicht darüber.
• Semantic Layer: übersetzen fachliche Begriffe in SQL. Dem Gedanken nach näher an Data Products für KI, aber üblicherweise auf BI ausgerichtet und nicht auf die volle Fläche, die KI-Nutzer brauchen (Lineage, Verantwortung, Klassifizierung, Qualitätssignale).
• Schlichte Datensätze in S3 oder im Warehouse: brauchbar für klassische Analytik, gefährlich für die Nutzung durch KI. Jede der oben genannten Grenzen greift.

Data Products für KI sind der Punkt, an dem das zusammenläuft: die Schicht, die strukturierte Daten, den Semantic Layer, das RAG-Korpus, den Vektorspeicher und die Metadaten der Governance zu einer stimmigen, nutzbaren Fläche für KI-Systeme verbindet.

Data Products für KI bauen

Die meisten Organisationen können Data Products für KI nicht von Grund auf bauen, und sie sollten es auch nicht versuchen. Ausgangspunkt ist die Infrastruktur für Data Governance und Data Products, die bereits vorhanden ist, mit drei Ergänzungen:

1. Den vorhandenen Katalog maschinell nutzbar machen. Stellen Sie Datenkatalog, Business Glossary, Lineage, Klassifizierung und die Graphen der Verantwortung über einen MCP Server oder eine strukturierte API bereit. Agenten lesen denselben Kontext, den menschliche Nutzer sehen, mit derselben Governance.
2. Zuerst eine kleine Menge wertvoller Data Products festlegen. Die vordringlichen fachlichen Kennzahlen, Kundenstammdaten, Produktkatalog, finanzielle Kennzahlen. Jedes wird zu einem Data Product für KI mit den sieben Bestandteilen von oben. Vermeiden Sie die Falle, alles auf einmal zu wollen und jeden Datensatz umzustellen.
3. Das Verhalten des Agenten als Teil der Qualitätssicherung behandeln. Der schnellste Weg, Lücken in Semantik, Lineage oder Klassifizierung sichtbar zu machen, ist, einen Agenten vor das Data Product zu setzen und zu beobachten, wo er falsche Schlüsse zieht. Jeder Fehlschlag zeigt auf eine Lücke in Dokumentation, Klassifizierung oder Regeln, die zu schließen ist.

Governance für Data Products für KI

Data Products für KI schaffen die Governance nicht ab, sie verschärfen sie. Drei Disziplinen der Governance tragen hier besonders:

• Klassifizierung: Jede Spalte braucht eine zutreffende Kennzeichnung der Sensibilität (PII, finanziell, gesundheitsbezogen, vertraulich), denn die Zugriffsregeln für KI-Agenten hängen an diesen Kennzeichnungen. Eine falsche Klassifizierung erzeugt beides: zu viel Einschränkung (Agenten scheitern an Aufgaben, die sie lösen dürften) und zu wenig (Agenten geben Daten preis, die sie nie sehen dürften).
• Lineage: Wenn eine Aufsichtsbehörde fragt, wie eine von KI erzeugte Antwort zustande kam, ist die Lineage die Antwort. Lineage auf Spaltenebene an den Data Products ist der Unterschied zwischen „wir können die Spur zeigen“ und „wir rekonstruieren sie gerade unter Druck“.
• Verantwortung: Jedes Data Product für KI hat einen benannten Verantwortlichen, der für die Richtigkeit des Produkts und die Folgen seiner Nutzung geradesteht. KI-Fehler ohne auflösbaren Verantwortlichen führen zu langsamer Reaktion auf Vorfälle und zu ungesteuerter Behebung.

Dieselbe Infrastruktur für Data Governance, die DORA, NIS2, DSGVO und BCBS 239 erfüllt, ist der Unterbau von Data Products für KI. Sie einmal für den einen Zweck zu bauen und für den anderen wiederzuverwenden ist der günstige Weg. Sie zweimal zu bauen ist das, was die meisten Organisationen tun, und das, was die meisten bereuen.

Fazit

Data Products für KI sind der Weg, auf dem Organisationen die Frage „können wir der Antwort der KI trauen?“ in ein konstruiertes, belegtes Ja verwandeln. Der Übergang von Data Products für Menschen zu Data Products für Agenten ist nicht kosmetisch, er ist strukturell. Organisationen, die bereits in Kataloge, Glossare, Lineage und Verantwortung investiert haben, werden Data Products für KI als natürlichen nächsten Schritt erleben. Die anderen werden feststellen, dass der Einsatz von KI die Lücken in ihrer Dateninfrastruktur schneller und öffentlicher sichtbar macht, als es je ein menschlicher Nutzer getan hätte.