KI-Demo vs Produktion: die Datengrundlage entscheidet

Constantin, Consultant für Azure und Datenplattformen bei Pexon Consulting | 11 Min. Lesezeit | 15.09.2026

TL;DR: Demo gegen Produktion

Ein produktives KI-System braucht Evaluation, Tracing und eine Datengrundlage, bevor das Modell zählt. Das Demo auf einem Excel-Ausschnitt überlebt den Sign-off nicht. Pexon Consulting (80 Mitarbeitende, Microsoft Partner, ISO 27001) baut die erste Strecke als 30 Tage Data Sprint: eine Pipeline, ein Modell, ein bis zwei Reports. Databricks ist eine Gabel, kein zweiter Hub. Fabric oder Databricks steht im Vs-Blog.

Warum stirbt das KI-Demo nach dem Sign-off?

Montag nach dem Workshop. Fachbereich hat die richtige Zahl gesehen. Freitag in Produktion halluziniert der Agent. Die Tabelle hat keinen Kommentar. Keinen Owner. Kein PII-Tag. Menschen verzeihen das. Agenten nicht.

Das Muster ist immer dasselbe. Druck von oben, zuerst GPT oder Claude, Demo auf einem Ausschnitt, Sign-off, drei Wochen später: „was macht die KI“. Drei Lücken: niemand misst, niemand sieht den Pfad, die Daten waren für Menschen gebaut.

Das ist nicht der Ein-Tages-PoC gegen den Data Sprint. Dort geht es um einen Tag Folie gegen 30 Tage Strecke. Hier geht es um Demo gegen Produktion auf der Datenstrecke. Derselbe H1 wäre Kannibalisierung. Zwei Texte, zwei Jobs.

Ein Agent in Databricks Apps in drei Minuten ist kein Produktionsnachweis. Der Playground startet. Catalog, Qualität und Trace fehlen weiter. Genau so kippt die Store-Demo: Genie liefert die Trainingsstunden, die Jahresziele stehen in keinem Playbook, die Antwort bleibt leer.

Unsere klare Empfehlung: Modell zuletzt. Zuerst messen, sehen, Daten. Dann orchestrieren und absichern.

Was muss Evaluation messen, das Accuracy nicht misst?

Accuracy ist die falsche Einheit. „Stimmt die Antwort“ ohne Testset ist Geschmack. Ein Golden Dataset entsteht mit der Fachseite, nicht im Notebook des Anbieters.

Drei Schichten, sonst bleibt die Messung Dekoration.

1. Deterministisch. Format, Schema, Regex, PII darf nicht im Klartext raus. Das ist prüfbar ohne zweites Modell.
2. Semantisch. Groundedness, LLM-as-Judge gegen die Belegstelle. Die Zahl in der Antwort muss in der Tabelle stehen.
3. Verhalten. Richtige Tools, keine Loops, keine dreifachen API-Calls. Ein Agent, der dreimal dieselbe Rechnung zieht, ist kein Qualitätsgewinn.

Ohne Schwelle geht die Änderung live, sobald jemand „besser“ sagt. Mit Schwelle bleibt ein Modellwechsel ein Test gegen das eigene Set, nicht gegen das Marketing des Vendors.

Wer das Set schreibt, ist die Fachseite, nicht der Vendor. Zehn echte Fragen aus dem Betrieb schlagen hundert synthetische. Jede Frage braucht die geprüfte Antwort und die Belegstelle in der Tabelle. Fehlt die Belegstelle, misst ihr nur Stil.

Das Set lebt neben der Pipeline. Ein Prompt-Tweak, ein neues Modell, ein anderer Chunk: derselbe Lauf. Sinkt Groundedness oder das Format, stoppt der Rollout. So wird KI-Demo vs Produktion eine Zahl, kein Bauchgefühl.

Warum brauchen Agenten eine andere Datenqualität als ein Power-BI-Bericht?

Ein Bericht verzeiht. Der Controller kennt die Mappe. Er sieht, dass „Umsatz“ diesmal ohne Storno gemeint ist. Der Agent sieht eine Spalte ohne Beschreibung und erfindet den Rest.

Zwei Sorten Daten, die das Demo nie trennt.

Frage-Daten. Was die KI braucht, um zu antworten: Tabelle, Maß, Rechte, Kommentar. Unity Catalog ist genau dafür da. Nicht als Katalog-Folie, sondern als Kontext.

Tracking-Daten. Traces für Audit, Judge, Monitoring. Ohne Trace keine Dispute-Fähigkeit. Ein Support-Chat ohne Pfad ist in Europa keine belastbare Auskunft. Wir verkaufen das nicht als Klinik- oder Banking-Case. Es ist das Muster.

Der Stack darunter ist langweilig und richtig: Object Storage, Delta Lake, Unity Catalog (Rechte, Ownership, Spaltenbeschreibung, PII-Tags), darauf Warehouse, BI, Genie, Agenten. Die Schicht-Tabelle steht im Glossar Databricks. Genie als Fläche erst, wenn Catalog und Space stehen: Genie Conversational Analytics.

-- Kontext, den der Agent braucht. Kein zweites Modell.
COMMENT ON TABLE finance.umsatz IS
  'Tagesumsatz, eine Zeile pro Beleg, Buchungskreis, ohne Storno';
COMMENT ON COLUMN finance.umsatz.netto IS
  'Netto in EUR, Buchungskreis-Währung, ohne Steuer';
ALTER TABLE finance.umsatz
  ALTER COLUMN kunde_id SET TAGS ('pii' = 'true');

Ohne diese drei Zeilen antwortet Genie oder der Agent auf eine leere Beschreibung. Ein Dictionary-Agent auf information_schema liest dann „nichts gefunden“. Das ist kein fehlendes Chat-Fenster. Das ist fehlende Handarbeit im Catalog. Der Sprint schreibt Tags. Genie fragt danach.

Was der 30 Tage Data Sprint in diesem Schnitt konkret anfasst: eine Quelle, Delta-Tabellen, Rechte, Kommentar an Tabelle und den Spalten, die der erste Bericht braucht, PII-Tag wo Personenbezug sitzt. Kein Konzern-Katalog. Keine Ontology. Kein zweites fachliches Modell. Wer fünf Schemas parallel „gleich mitbeschreiben“ will, sprengt die 30 Tage. Dann scopen wir nach, statt so zu tun, als wäre der Catalog nebenbei fertig.

Tracking-Daten gehören dazu, sobald ein Agent antwortet. Der Trace ist die zweite Tabelle: welcher Prompt, welches Tool, welche Zeile. Ohne sie endet jeder Streit im Chatverlauf, den niemand auditieren kann.

Unity Catalog: Rechte, Beschreibungen, Tags – warum das die KI-Antwort ändert

Unity Catalog ist nicht Unity AI Gateway. Catalog steuert, wer welche Tabelle sieht. Das Gateway steuert Modell-Endpunkte, MCP-Tools, Budgets, Guardrails. Beide gehören zusammen. Sie sind nicht dasselbe Produkt.

Was die Antwort ändert, ist oft der Kommentar, nicht Claude.

• Rechte: der Agent sieht die Tabelle, oder er sieht sie nicht. Ein Demo-User mit Admin-Recht ist kein Produktivrecht.
• Beschreibung: „Umsatz“ ohne Satz ist drei Wahrheiten. Controlling, Vertrieb, der Agent.
• Tags: PII-Tag ist Input für das Gateway. Der Tag scannt den Inhalt nicht. Wer hofft, das Gateway finde Personalnummern von allein, hat keinen Catalog.

Gateway stoppt PII im Prompt. Es stoppt keine falsche Zahl. Evaluation und Tracing bleiben Pflicht, auch wenn das Gateway grün ist.

MLflow Tracing zeigt den Pfad: Intent, Kontodaten, Policy, Reasoning, Guardrail, Antwort. Reicht das, oder braucht ihr ein Gateway für Coding Agents? Tracing erklärt die eine Antwort. Das Gateway steuert, welches Modell und welches Tool der Coding Agent überhaupt rufen darf. Beides. Eins allein ist Admin-Folie oder Debug-Folie.

Wann Fabric, wann Databricks, wann reicht der 30-Tage-Sprint?

Die Gabel bleibt der Databricks-vs-Fabric-Blog. Dieser Text wiederholt sie nicht.

Kurz, weil der Buyer danach fragt:

• Microsoft 365, Power BI, eine Quelle, montags Zahlen: 30 Tage Data Sprint.
• SAP vorne, Fabric Mitte, Power BI hinten: Microsoft Fabric Partner Deutschland.
• Databricks schon im Tenant, Fabric das Ziel: Databricks zu Microsoft Fabric Migration.
• Lakehouse und Catalog stehen, Fachbereich will fragen: Genie.

Der Sprint ist der Standard, weil die Lücke fast immer die Strecke ist, nicht das Modell. Ontology, Dictionary-Agent, Apps-Playground und Store-Agent sind keine Einstiegsangebote. Wir bauen sie nicht als Landingpage.

Wer fünf Agenten ohne Orchestrierung startet, bekommt doppelte API-Calls, Kosten ohne Grenze, keinen Fallback. Ein Agent geht ohne Orchestrator. Ab mehreren braucht ihr eine Grenze und Human-in-the-loop unter Schwelle. Das scoped ihr nach dem Sprint, nicht darin.

Prompt-Änderungen sind Change-Management, kein Chat. Dieselbe Disziplin wie an einem Measure: Version, Owner, Test gegen das Golden Dataset. Ein Modellwechsel ohne diesen Lauf ist ein neues Demo. Genau das soll KI-Demo vs Produktion verhindern.

Häufig gestellte Fragen

Reicht MLflow Tracing, oder brauchen wir ein Gateway für Coding Agents?

Tracing erklärt, was passiert ist. Das Gateway steuert, was Cursor oder Codex rufen dürfen: Modell, MCP, Budget. Für Produktion braucht ihr beides. Gateway ohne Golden Dataset bleibt Blindflug mit Log.

Ist das dasselbe wie der Ein-Tages-PoC gegen den Data Sprint?

Nein. PoC gegen Sprint ist Folie gegen erste Pipeline. Dieser Text: Demo gegen Produktion auf Evaluation, Trace und Catalog. Zwei URLs, zwei Suchfragen.

Reicht Genie statt eines Dictionary-Agenten?

Genie fragt gegen beschriebene Tabellen. Das Dictionary sind Kommentar, Tag, Lineage, Recht. Ein Chat auf Systemtabellen ersetzt das nicht. Tags gehen sofort, ohne auf Ontology zu warten.

Baut Pexon einen Databricks-Hub?

Nein. Mutter bleibt Data Services. Databricks ist die Gabel. Money ist der Sprint.

Gehört Predictive Maintenance in diesen Schnitt?

Nein. Tiefe Data Science und OEE sind ein anderer Lead. Hier zählt, ob die erste Tabelle einen Owner hat.

Nächster Schritt

Das Demo hat Sign-off. Was fehlt, sind Golden Dataset, Trace und drei Zeilen Catalog. Das ist der Sprint, nicht ein zweites Modell.

Verwandte Themen