AI Data Strategy
Welche Datenarchitektur KI im Unternehmen braucht
KI braucht mehr als Modelle. Tragfähig wird sie erst, wenn Daten, Bedeutung, Katalog, Governance und Betrieb zusammenpassen.
Diese Seite sortiert die Landkarte: zentrale Plattform, Data Fabric, Data Mesh, Hub-and-Spoke, AI Registry, Lifecycle und Runtime Governance.
Das Missverständnis
„KI ist nur so gut wie die Daten“ greift zu kurz
Der Satz stimmt. Aber er ist zu ungenau. Für KI sind Daten nicht nur Rohstoff. Sie werden Training, Kontext, Feedback, Produkt, Risiko und Betriebssignal.
Deshalb reicht klassische Data Governance nicht mehr aus. Die entscheidende Frage ist nicht nur, ob Daten sauber sind. Die Frage ist, welche Daten unter welchen Regeln in welche Umgebung dürfen, wer Bedeutung und Qualität verantwortet, und wie sich AI-Systeme im Betrieb kontrollieren lassen.
Die entscheidende Frage ist nicht: Welche Plattform kaufen wir? Die Frage ist: Welche Daten, Bedeutungen, Verantwortlichkeiten und Kontrollpunkte müssen tragfähig sein, damit AI im Betrieb funktioniert?
Ralfs Perspektive
Die fünf Bausteine
Woraus eine AI Data Strategy besteht
Eine AI Data Strategy ist keine reine Plattformentscheidung. Sie verbindet Datenbasis, Bedeutung, Katalog, Lifecycle und Kontrolle im Betrieb.
Datenbasis
Quellen, Qualität, Zugriff, Residency und Klassifikation. Ohne diese Basis bleiben AI Use Cases zufällig.
Semantic / Context Layer
Business-Begriffe, Metriken, Kontext und Bedeutung. AI braucht nicht nur Daten, sondern verstandene Daten.
AI Solution Catalog
Modelle, Agents, Tools und Use Cases mit Owner, Risk Tier, Status, Datenquellen und Review-Datum.
Lifecycle Management
Assess, Select, Build, Validate, Deploy, Monitor, Change, Retire. Governance endet nicht beim Go-live.
Runtime Governance
Policies, Human Oversight, Tool-Call-Kontrolle, Tracing, Monitoring, Incidents und Audit Evidence.
Architekturpfade
Zentral, Fabric, Mesh oder Hub-and-Spoke?
Die Entscheidung ist selten entweder zentral oder dezentral. Die meisten Organisationen brauchen zentrale Standards und lokale Verantwortung zugleich.
Zentrale AI Data Platform
- Stärke
- Einheitliche Governance, Standards, Zugriff und Betriebsfähigkeit.
- Risiko
- Kann zum Bottleneck oder Plattform-Monolithen werden.
- Passt, wenn
- Frühe Reife, wenige Domänen, hoher Standardisierungsbedarf.
Data Fabric
- Stärke
- Aktive Metadaten, Lineage, Katalog, Policies und Zugriff über verteilte Quellen.
- Risiko
- Funktioniert nur mit guter Metadatenqualität und klaren Policies.
- Passt, wenn
- Wenn Daten verteilt bleiben, aber auffindbar, governbar und nutzbar werden müssen.
Data Mesh
- Stärke
- Domänen besitzen Datenprodukte, Qualität, Semantik und SLAs.
- Risiko
- Ohne gemeinsame Standards entsteht Fragmentierung.
- Passt, wenn
- Wenn Fachdomänen viel Kontext haben und zentrale Teams zum Engpass werden.
Hub-and-Spoke
- Stärke
- Zentrale Standards und Guardrails plus lokale Ownership und Delivery.
- Risiko
- Unklare Zuständigkeit, wenn Hub und Spokes nicht sauber getrennt sind.
- Passt, wenn
- Wenn AI skalieren soll, ohne zentrale Plattform zum alleinigen Flaschenhals zu machen.
Begriffe entwirren
Drei Verwechslungen, die man vermeiden sollte
Data Fabric ≠ Microsoft Fabric ≠ Fabric AI
Data Fabric ist ein Architekturansatz. Microsoft Fabric ist eine konkrete Plattform. Fabric AI von Daniel Miessler ist ein Open-Source-Framework für AI-Workflows und Prompt-Patterns.
AI Registry ≠ Model Registry ≠ Data Catalog
Die AI Registry trägt Business-Kontext, Risiko und Governance über alle AI-Systeme. Die Model Registry versioniert Modelle. Der Data Catalog beschreibt Datenbestände und Lineage.
Data Mesh ist kein Tool
Data Mesh ist ein Ownership-Modell. Domänen übernehmen Verantwortung für Datenprodukte. Technologie unterstützt diese Logik, ersetzt sie aber nicht.
AI Solution Catalog
Ein Katalog ist mehr als eine Toolliste
Ein AI Solution Catalog ist der Kontrollpunkt für AI Assets. Er macht sichtbar, was läuft, wer es besitzt, welche Daten es nutzt, welches Risiko es trägt und ob es weiter betrieben werden darf.
Lifecycle und Betrieb
Governance beginnt nach dem Go-live erneut
AI-Systeme verändern sich im Betrieb. Daten driften, Nutzung wandelt sich, Modelle und Agenten handeln in neuen Kontexten. Deshalb braucht AI Lifecycle und Runtime Governance.
01
Assess
02
Select
03
Build
04
Validate
05
Deploy
06
Monitor
07
Change
08
Retire
Runtime Governance heißt:
Policies werden nicht nur dokumentiert, sondern zur Laufzeit geprüft. Bei Agents bedeutet das: Input, Kontext, Tool Calls, Output, Human Escalation, Logging und Audit Evidence müssen zusammen gedacht werden.
Hören, ansehen, weiterlesen
Quellen, die die Architekturfragen vertiefen
Nicht als Autoritätsdeko, sondern als Vertiefung: Jede Quelle beantwortet eine andere Architekturfrage.
From AI Governance to AI Enablement
DataFramed · 53 minGovernance & Enablement
The New Paradigm for Enterprise AI Governance
DataFramed · 59 minEnterprise Governance
Atlan: What Is an AI Registry?
Konkretisiert, welche Felder ein AI Registry braucht und warum Spreadsheet-Inventare nicht reichen.
Quelle öffnen →Microsoft: Agent Control Specification
Zeigt, wie Runtime Governance für Agents über Interception Points, Policy Inputs und Enforcement funktionieren kann.
Quelle öffnen →Alation: Data Fabric vs. Data Mesh
Ordnet Fabric als metadata-driven Architektur und Mesh als Ownership-Modell ein.
Quelle öffnen →ISACA: Governing AI Across its Lifecycle
Macht Lifecycle Governance als Stufenmodell von Strategie bis Retirement greifbar.
Quelle öffnen →Entscheidungshilfe
Sechs Fragen, bevor Tools entschieden werden
- Müssen Daten physisch zentralisiert werden oder reicht governter Zugriff?
- Gibt es Domänen, die Datenprodukte wirklich besitzen können?
- Gibt es einen AI Registry oder Solution Catalog?
- Gibt es ein Lifecycle-Modell nach Deployment?
- Gibt es Runtime Policies für Agents und automatisierte Workflows?
- Sind Semantik und Business-Begriffe zentral genug geklärt?
Weiterführende Pfade
Das hängt mit diesen Themen zusammen
Data Governance & KI
Welche Governance-Fragen entstehen, wenn Daten Training, Kontext, Feedback und Risiko werden?
Weiterlesen →AI Operating Model
Wie verankert eine Organisation AI in Strategie, Rollen, Governance, Use Cases und Betrieb?
Weiterlesen →MLOps
Warum AI-Prototypen im Betrieb andere Qualitäts-, Monitoring- und Lifecycle-Fragen erzeugen.
Weiterlesen →Agentic AI
Warum handelnde AI-Systeme Zugriff, Kontext, Tools und Runtime-Governance brauchen.
Weiterlesen →RAG & Semantic Layer
Drei Retrieval-Ebenen: Chunk, Graph, Ontologie — und warum Evaluierung der blinde Fleck ist.
Weiterlesen →