Pexon Consulting | 10 Min. Lesezeit | 13.06.2026
TL;DR
AI Data Engineering 2026 scheitert selten am Modell, sondern an der Datenebene — und dort am häufigsten an fehlender Metadata-Strategie. Wer Data Catalogs, Feature Stores und Lineage nicht als First-Class-Citizens behandelt, baut AI-Stacks auf Sand. Pexon-Default: Unity Catalog oder OpenMetadata plus Feast als Feature Store plus AI-Asset-Tracking. Investment 80-120 k EUR, Amortisation in 12-18 Monaten.
Warum die meisten AI-Projekte beim Data Engineering scheitern
Wir sehen in jedem dritten Pexon-Audit dasselbe Bild: Ein gutes Modell, ein durchdachter Agent-Loop, ein passables Frontend — und darunter eine Datenebene, die niemand versteht. Quellen sind unklar, Owner unbekannt, Aktualität nicht messbar, Lineage nicht vorhanden. Das LLM gibt dann Antworten, die niemand validieren kann.
Aus drei laufenden Pexon-Projekten bei Versicherern und Industrie-Mittelstand 2025/2026: Etwa 55-70 % des Engineering-Aufwands bei produktiven AI-Systemen geht in Daten und Metadata, nicht in Modell-Code. Das ist keine Anomalie, das ist die neue Normalität. Wer AI Data Engineering nicht als eigene Disziplin behandelt und stattdessen erwartet, dass das klassische Data-Engineering-Team „auch mal eben AI“ macht, läuft in Probleme.
Die regulatorische Verschärfung kommt dazu. DORA Artikel 6 verlangt nachvollziehbare Datenherkunft, EU AI Act Artikel 10 verlangt explizite Datenqualitäts-Dokumentation. Beides ist ohne Metadata-Strategie nicht erfüllbar — und beides wird 2027 in den Audits geprüft.
Was AI Data Engineering von klassischem ETL unterscheidet
Klassisches Data Engineering hat klare Aufgaben: Daten aus Quellen extrahieren, transformieren, in ein Warehouse laden, Reports darauf bauen. AI Data Engineering erbt diese Aufgaben und erweitert sie um vier Dimensionen, die in klassischen Stacks oft fehlen:
- Embedding-Pipelines. Textuelle und multimodale Daten müssen in Vektoren überführt werden. Mit Versionierung, Schema-Konsistenz und Wiederholbarkeit.
- Feature Stores. Strukturierte Features für Modelle (klassische ML und LLM-Workflows) brauchen einen einheitlichen Speicher mit Online/Offline-Symmetrie.
- Provenance über LLM-Layer. Lineage nicht nur „Spalte X stammt aus Quelle Y“, sondern „diese AI-Antwort stützt sich auf Dokumente A, B, C, die zu Embedding V-12 gehören, das aus Snapshot 2026-04-15 stammt“.
- AI-Asset-Tracking. Embeddings, Indizes, Prompts, Agent-Definitionen, Eval-Datasets — alles sind versionierbare Assets mit eigenen Metadata-Bedarfen.
Pexon-Position: AI Data Engineering ist nicht „Data Engineering plus AI-Skin“. Es ist eine eigene Disziplin mit eigenen Werkzeugen und eigener Owner-Struktur. Wer das ignoriert, zahlt es im Betrieb mehrfach.
Die 5 Metadata-Ebenen — was wirklich nötig ist
Aus drei abgeschlossenen Setups die fünf Ebenen, die in einem produktiven AI Data Engineering Stack abgedeckt sein müssen:
Ebene 1 — Technische Metadata. Schema, Datentypen, Constraints, Primärschlüssel, Partitionen. Klassisches Catalog-Material. Wird durch Unity Catalog, Microsoft Purview oder OpenMetadata automatisch erfasst.
Ebene 2 — Geschäftliche Metadata. Wer ist Owner? Was bedeutet das Feld „status_id“ fachlich? Wie wird es interpretiert? Welche SLAs gelten? Diese Ebene wird in den meisten Mittelstands-Stacks vernachlässigt — und sie ist genau die, die für AI-Antworten zur Wahrheits-Grundlage wird.
Ebene 3 — Operational Metadata. Letzte Aktualisierung, Datenqualitäts-Scores, Anomalien, Pipeline-Status. Quasi die „Vitalwerte“ jeder Datenquelle. dbt plus Great Expectations decken das gut ab.
Ebene 4 — Semantische Metadata. Glossar, Taxonomien, Synonyme, Beziehungen zwischen Konzepten. Für RAG-Systeme die Brücke zwischen User-Vokabular und Daten-Vokabular. Verwandt mit dem Ontologie-Light-Ansatz aus unserem Beitrag zu GraphRAG Knowledge Graphs.
Ebene 5 — AI-Asset-Metadata. Welche Embeddings auf welchem Snapshot, mit welchem Modell, in welcher Version? Welche Indizes leben, welche sind veraltet? Welche Prompts laufen produktiv? Diese Ebene ist 2026 noch in keinem Standard-Tool sauber abgedeckt — wir bauen sie typisch als Custom-Layer mit MLflow plus Phoenix.
Alle fünf zusammen bilden die Grundlage für nachvollziehbare, auditfähige, evolutionsfähige AI-Systeme. Eine davon weglassen heißt: Sie ist trotzdem da, nur nicht dokumentiert.
Data Catalogs — Unity Catalog vs Purview vs OpenMetadata
Drei Optionen, jede mit klarem Profil:
Unity Catalog (Databricks). Native im Databricks-Ökosystem, Source-Of-Truth für alle Workloads im Lakehouse. Stärke: tiefe Integration in Delta Lake, automatische Lineage, ACLs auf Spalten-Ebene. Schwäche: außerhalb des Databricks-Stacks weniger nützlich. Beste Wahl für Databricks-zentrische Organisationen.
Microsoft Purview. Microsoft’s Data Governance Plattform. Stärke: native Integration mit Azure, Fabric, SQL, Synapse, Power BI. Großer Connector-Park für Drittsysteme. Schwäche: User-Experience ist 2026 noch sperrig, Lineage-Visualisierung weniger reif als bei Unity. Beste Wahl für Microsoft-Stack-Organisationen mit M365 E5.
OpenMetadata. Open-Source, Apache 2.0. Stärke: vendor-neutral, breit anschlussfähig, sehr aktive Community, sehr gute Glossar- und Owner-Features. Schwäche: Setup-Aufwand höher als bei Managed-SaaS-Optionen. Beste Wahl für Vendor-neutrale Stacks und für regulierte Branchen mit Self-Hosting-Pflicht.
Pexon-Default für Mittelstands-Setups ohne harte Microsoft-Bindung: OpenMetadata. Für Organisationen mit Databricks: Unity Catalog. Für Microsoft-Häuser mit M365 E5: Purview. Die Wahl ist weniger Religion als Anschluss-Frage — alle drei können einen sauberen AI-Data-Engineering-Stack tragen, wenn sie konsequent gepflegt werden.
Feature Stores — Feast als pragmatischer Default
Feature Stores lösen ein konkretes Problem: Features (strukturierte Eingangsvariablen für Modelle und Prompts) müssen sowohl im Training als auch in der Inferenz konsistent verfügbar sein. Online (Echtzeit) und Offline (Batch) dürfen nicht auseinanderlaufen, sonst entsteht Training-Serving-Skew.
Drei Optionen:
- Feast. Open-Source, Apache 2.0, Cloud-agnostisch. Pexon-Default für die meisten Mittelstands-Setups.
- Databricks Feature Store / Tecton. Tiefe Databricks-Integration, kommerzieller Support. Sinnvoll für Databricks-Häuser mit hohem Feature-Volumen.
- Native Cloud-Options (Azure ML, Vertex AI Feature Store, SageMaker Feature Store) — vendor-spezifisch, aber pragmatisch wenn die Cloud-Wahl klar ist.
Was Feature Stores in AI Data Engineering konkret bringen: Wenn ein RAG-System User-spezifische Kontext-Features braucht (z.B. „aktuelle Kunden-Tier“, „letzte Bestellung“, „Service-Level“), liefert der Feature Store diese mit garantierter Konsistenz zwischen Offline-Training und Online-Inferenz. Ohne Feature Store bauen Sie diese Logik 5-10 mal neu, jedes Mal etwas anders.
Lineage End-to-End — von Source bis Embedding
Klassische Lineage endet beim Data Warehouse. AI-Lineage muss weiter gehen — bis zum Embedding, bis zum Index, bis zur LLM-Antwort. Aus drei laufenden Setups die Pflicht-Tiefe:
Quellsystem (SAP, SharePoint, CRM)
↓ ingestiert von Pipeline-Job-ID
Raw-Layer (Bronze)
↓ transformiert via dbt model X
Conformed-Layer (Silver)
↓ aggregiert via Job Y
Business-Layer (Gold)
↓ chunked + embedded via Pipeline Z (Modell: text-embedding-3-large, Version 2026-04)
Vector Index (Snapshot 2026-06-12)
↓ verwendet in RAG-Antwort am 13.06.2026 für User U-42Diese durchgehende Lineage erlaubt, jede LLM-Antwort zu ihren Quelldaten zurückzuverfolgen. Bei Audit-Findings oder Bug-Reports ist das nicht „Nice-to-Have“, sondern Pflicht. dbt liefert die Lineage bis zur Business-Layer, OpenLineage erweitert sie über die ML-Pipelines, MLflow oder eine Custom-Lösung tracken die Embedding-Pipelines.
In den meisten Mittelstands-Setups fehlt dieser letzte Schritt — die Embedding-Pipeline ist eine Black Box, der niemand traut. Genau dort liegt der größte Hebel für saubere AI Data Engineering.
AI-Assets als First-Class-Citizens
Was wir in 2025 noch unter „proof of concept“ abgelegt haben, ist 2026 Produktiv-Realität: AI-Assets sind versionierbare Artefakte mit Metadata-Bedarf, genau wie Datentabellen.
Diese AI-Assets unterliegen denselben Disziplin-Anforderungen wie Daten: Owner, Versionsstand, Lebenszyklus, Deprecation-Plan. Wer das ignoriert, baut innerhalb von 18 Monaten einen Schatten-Wildwuchs an Indizes, Prompts und Agents, den niemand mehr beherrscht.
Pexon-Pattern — die produktive Metadata-Architektur
Aus zwei laufenden Pexon-Projekten der typische Stack für AI Data Engineering bei einem deutschen Mittelständler 500-3.000 MA:
+-------------------+ +---------------------+ +------------------+
| Quellsysteme | | Data Platform | | AI-Asset-Layer |
| (SAP, CRM, |---| (Azure Fabric ODER |---| (MLflow + custom)|
| SharePoint, | | Databricks ODER | | - Embeddings |
| ServiceNow) | | Snowflake) | | - Indizes |
+-------------------+ +---------------------+ | - Prompts |
| | - Agents |
v +------------------+
+---------------------+ |
| Metadata Layer | |
| OpenMetadata / Unity|<-------------+
| Catalog / Purview |
+---------------------+
|
v
+---------------------+
| Discovery + Audit |
| (Web-Frontend + |
| SIEM + Eval-Loop) |
+---------------------+Drei Pattern-Entscheidungen, die in jedem Setup wiederkehren:
- Ein Metadata-Layer pro Organisation, nicht pro Use-Case. Wenn jedes AI-Team seinen eigenen Catalog baut, verlieren Sie Konsistenz und Suchbarkeit. Ein Catalog, viele Use-Cases.
- AI-Assets in einem dedizierten Repository plus Mirror im Catalog. Embeddings und Indizes leben in ihrem Tool (Phoenix, MLflow), die Metadata wird in den Catalog gespiegelt. Dadurch ist alles aus einer Sucht-Frontend findbar.
- Audit-Trail jeder Metadata-Änderung. Wer hat wann welchen Owner geändert? Welche Glossar-Definition wurde wann angepasst? Pflicht für DORA- und AI-Act-Audit-Trail.
Anti-Patterns
Drei wiederkehrende Fallen aus unseren Audits:
1. „Wir machen Metadata später.“ Klassischer Fehler. Erst kommt das AI-System, dann „bauen wir den Catalog drumherum“. Funktioniert nie. Metadata muss von Anfang an Teil der Pipeline sein, sonst entsteht Schulden, die später nie aufgeholt werden.
2. Owner als „Team-Postkasten“. Ein Catalog mit „Owner: Data-Team“ ist kein Owner. Pflicht ist eine konkrete Person plus Stellvertreter. Sonst hängen Entscheidungen wochenlang in Slack-Diskussionen.
3. AI-Assets ohne Lebenszyklus-Modell. Embeddings werden gebaut, aber nie gelöscht. Indizes laufen veraltet weiter. Prompts werden experimentiert, aber nicht versioniert. Pflicht: Pro Asset-Klasse ein klares Lifecycle-Modell mit Deprecation-Datum.
Konfidenz für alle drei: hoch.
Kosten und Zeitrahmen
Aus zwei laufenden Pexon-Projekten der typische Aufwand für ein produktives AI Data Engineering Setup mit Metadata-Strategie:
Laufende Kosten: OpenMetadata Self-Hosted ca. 400-800 EUR pro Monat (Compute), Unity Catalog in Databricks-Bundle eingerechnet, Purview je nach Lizenzplan. AI-Asset-Layer-Maintenance 0,5-1,5 PT pro Monat.
ROI-Rechnung: Aus drei Audit-Findings unserer Kunden: Pro fehlendem Metadata-Element kostet die nachträgliche Klärung typisch 2-8 Stunden Engineering-Zeit plus Stop-Of-Work für AI-Projekte. Bei einem Mittelständler mit 5-10 produktiven AI-Workloads sparen Sie 0,3-0,8 FTE pro Jahr. Amortisation 12-18 Monate.
Häufig gestellte Fragen
Brauche ich Unity Catalog oder Purview, wenn ich kein Databricks und kein Azure habe?
Nein. OpenMetadata deckt beide Funktionalitäten vendor-neutral ab und ist Open-Source. Für reine AWS-Setups gibt es zusätzlich AWS Glue Data Catalog, der aber nur die technische Metadata-Ebene abdeckt — Glossar und Owner-Workflow müssen extra gebaut werden.
Wie groß muss mein Unternehmen sein, damit sich AI Data Engineering Metadata-Strategie lohnt?
Aus unserer Praxis: Ab etwa 300 MA und mindestens zwei produktiven AI-Workloads. Darunter ist der Setup-Aufwand größer als der Nutzen. Wer mit einem einzelnen RAG-Pilot startet, sollte die Metadata-Strategie planen, aber erst beim Skalierungs-Schritt voll ausbauen.
Was passiert mit den Embeddings, wenn ich das Embedding-Modell wechsle?
Re-Embedding plus Re-Indexing. Das ist einer der häufigsten Grunde für AI-Data-Engineering-Aufwand. Mit sauberer AI-Asset-Lineage ist das eine geplante Pipeline-Aktion, ohne Lineage wird es zur dreiwöchigen Detektivarbeit.
Wie pflege ich das Glossar über die Zeit?
Iterativ und aus dem Betrieb. Jeder Bug-Report über „falsche Definition“ wird zum Glossar-Update. Jeder neue Use-Case bringt potenziell neue Begriffe. Wir empfehlen monatliche Glossar-Reviews mit den Fach-Ownern, plus ein Quartals-Audit durch das AI-Data-Team. Ohne diese Routine veraltet jedes Glossar innerhalb von 9-12 Monaten.
Können wir AI Data Engineering ohne dediziertes Team aufsetzen?
Nicht sinnvoll. Mindestens 0,5 FTE als „Data Steward“ plus ein technischer Data Engineer sind Mindestbesetzung. Wir liefern Mittelständlern den initialen Setup-Schub im 6-Wochen-Pilot, das interne Team übernimmt den Betrieb. Wer das ohne dedizierte Owner aufsetzt, baut Schatten-IT, die im nächsten Audit aufläuft.
Wie verbindet sich das mit Multi-Model Routing und AI Evaluation Engineering?
Sehr eng. Multi-Model Routing braucht zuverlässige Metadata zu den Modellen (Cost, Capability, Region). AI Evaluation Engineering braucht zuverlässige Lineage zu den Eval-Datasets und Test-Cases. Beide setzen voraus, dass die Datenebene und der AI-Asset-Layer sauber gepflegt sind.
Nächster Schritt
Wenn Sie aktuell zwei oder mehr produktive AI-Systeme betreiben und merken, dass die Datenebene zur Engpass-Routine wird: Wir machen das im 6-Wochen-Pilotprojekt für Generative AI konkret — Stack-Architektur, Catalog-Setup, Lineage-Pipeline und AI-Asset-Layer als Pilot mit 3-5 Datenbereichen.
Verwandte Themen
→GraphRAG Knowledge Graph: Neo4j, Microsoft, RDF im Vergleich
→AI Evaluation Engineering: Ragas vs LangSmith vs TruLens vs Phoenix
