Warum LLM-Demos im Unternehmen oft an der Produktion scheitern
Demos für Konversationsanalyse funktionieren meist auf einem sauberen Warehouse-Schema problemlos. In der Praxis brechen die Piloten aber an realen Datenbedingungen, unklaren Fragen und Edge Cases auseinander.
Jede Demo zu konversationeller Analytik folgt demselben Drehbuch. Jemand verbindet ein Modell mit einem sauberen Warehouse-Schema, tippt "zeige mir den Umsatz nach Region im letzten Quartal" und bekommt in vier Sekunden ein korrektes Diagramm. Der Raum nickt anerkannt. Dann sagt jemand den Satz, der bereits tausend zum Scheitern verurteilte Pilotprojekte ausgelöst hat: "Jetzt wollen wir das auf das ganze Unternehmen ausrollen."
Ich habe die letzten Jahre genau damit verbracht, eben diese Einführung umzusetzen, nämlich governed conversational analytics auf Basis von Looker und dessen semantischer Schicht aufzubauen, zuletzt zudem über das Model Context Protocol (MCP) für KI-Agenten zugänglich gemacht. Die Einführung, an der ich heute arbeite, läuft im Unternehmensmaßstab, und die entscheidende Kennzahl ist nicht die Nutzerzahl. Es ist die Genauigkeit, und zwar diejenige, die man in einem Vorstandsmeeting verteidigen kann. Diese wird nicht durch ein größeres Modell erreicht, sondern dadurch, dass das Modell die Rohdaten gar nicht erst berühren darf.
Hier ist, was zwischen Demo und Produktion tatsächlich bricht, und warum die Lösung architektonischer Natur ist und nicht im Prompt liegt.
Fragt man einen Demo-Datensatz nach "Umsatz", gibt es genau eine Spalte. Fragt man ein echtes Unternehmen, gibt es einen Kampf auf Messerschneiden. Der Umsatz der Finanzabteilung ist der bilanzielle recognized revenue, netto nach Rückerstattungen. Der Umsatz des Vertriebs sind Bookings. Der "aktive Kunde" des Supports hat seit 90 Tagen kein Ticket eröffnet; der "aktive Kunde" der Growth-Abteilung hat sich diese Woche angemeldet. Das sind keine Fehler. Es sind legitime, praxiserprobte Definitionen, die zufällig denselben Namen tragen.
Ein LLM, das auf Rohdaten losgelassen wird, hat keine Möglichkeit zu wissen, welche Definition gemeint war, und rät daher, flüssig und selbstbewusst, und rät am Dienstag anders als am Montag. Dies ist genau die Fehlerquelle, die in der Produktion das Vertrauen zerstört, und sie taucht in Demos nie auf, weil Demo-Schemas pro Konzept nur eine einzige Tabelle haben.
Die Lösung ist unspektakulär: eine semantische Schicht, in der jede Kennzahl genau einmal definiert wird, in Code, mit der Geschäftslogik in den Händen der Personen, die dafür verantwortlich sind. In Looker ist das LookML, also Kennzahlen, Dimensionen und Joins, kuratiert von den Data Teams, versionskontrolliert und reviewbar. Wenn das Modell nach "Umsatz" fragt, schreibt es kein SQL basierend auf einer Vermutung. Es ruft eine Definition auf, die die internen Debatten des Unternehmens bereits überstanden hat. Die semantische Schicht ist der Vertrag zwischen dem LLM und den Daten: Das Modell entscheidet, was der Nutzer fragt, die Schicht entscheidet, was die Daten bedeuten.
Das ist auch der Grund, warum Text-to-SQL-Demos so schlecht altern. Generiertes SQL leitet die Geschäftslogik bei jeder einzelnen Frage von Grund auf neu ab, mit einem probabilistischen Motor. Eine semantische Schicht leitet sie einmalig, deterministisch ab und verwendet sie für immer wieder.
Das zweite Element, das bricht, ist die Sicherheit, und es bricht leise. In einem klassischen BI-Setup liegt die Zugriffskontrolle nah an den Daten: Filter auf Zeilenebene, Spalteneinschränkungen, Benutzerattribute. Stellt man ein LLM mit einem breit gefassten Service Account vor das Warehouse, was bei den meisten Schnell-Integrationen der Standard ist, hat man soeben jedem Nutzer die Vereinigung aller Berechtigungen übergeben, die der Agent erreichen kann, verpackt in einer freundlichen Chat-Oberfläche.
Natürliche Sprache verschlimmert das noch, statt es zu verbessern. Niemand tippt versehentlich "SELECT salary FROM..." in ein Chat-Feld; man fragt: "wer im Team hat die größte Gehaltserhöhung bekommen?" Ein Modell, das hilfsbereit sein will, umgeht die eigene Absicht, sofern nicht die Datenschicht selbst ein Nein sagt.
Das Prinzip, das in der Produktion funktioniert: Der Agent erbt die Berechtigungen des Anfragenden, niemals seine eigenen, und die Durchsetzung erfolgt auf der Datenschicht, nicht im Prompt. Mit einer semantischen Schicht dazwischen trägt jede Abfrage des Agents die Attribute des Nutzers, und dieselben Regeln auf Zeilen- und Spaltenebene, die für die Dashboards gelten, gelten auch für die Konversation. "Bitte ignorieren Sie Ihre Beschränkungen" ist kein Angriff, um den sich eine Datenschicht kümmern müsste.
An anderer Stelle habe ich über die schwierigere Variante dieses Problems geschrieben, nämlich was passiert, wenn Agenten beginnen, Ergebnisse zwischenzuspeichern und untereinander zu teilen. Die Grundregel bleibt einfach: Existiert eine Kontrolle nur im Systemprompt, existiert sie nicht.
In einer Demo ist eine leicht falsche Zahl ein Schmunzeln. In der Produktion erwischt ein einziger Vorstand eine einzige falsche Zahl in einem einzigen Boardmeeting, und die Einführung ist für ein Jahr tot, nicht weil das System schlecht ist, sondern weil Vertrauen in Datenwerkzeuge binär ist, anders als Vertrauen in Suchergebnisse.
Genau deshalb ist die oben beschriebene Architektur keine optionale Dekoration. Deterministische Definitionen (die semantische Schicht), deterministische Berechtigungen (die Datenschicht) und ein Modell, das auf Intent-Analyse und Darstellung beschränkt ist, sind der Weg von der beeindruckenden Demo zu einer Antwortgenauigkeit, die man in der Produktion verteidigen kann. Das verschafft zudem etwas, das eine reine LLM-Integration nie bieten wird: einen Audit-Trail. Jede Antwort lässt sich auf eine kontrollierte Abfrage gegen benannte Definitionen zurückführen, was in einem regulierten Umfeld spätestens dann relevant wird, wenn jemand fragt: "Woher kommt diese Zahl?"
Die Anbindung an Agenten über MCP ist es, die das Ganze aktuell macht. Als wir die semantische Schicht über Lookers MCP-Server zugänglich machten, auch für Desktop-Agent-Clients im gesamten Unternehmen, erhielten die Agenten keine neuen Befugnisse. Sie bekamen einen hell erleuchteten Durchgang zu Befugnissen, die bereits kontrolliert waren. Genau dieses Muster würde ich überall empfehlen: Bauen Sie kein eigenes, schwächeres Governance-Regime für KI. Führen Sie KI durch die Governance, der Sie ohnehin vertrauen, und lassen Sie das Modell die Schnittstelle sein, nicht die Instanz.
Beginnen Sie mit zwanzig Fragen, die Ihr Unternehmen tatsächlich stellt, definieren Sie diese Kennzahlen sauber in einer semantischen Schicht und verbinden Sie erst danach das Modell. Widerstehen Sie dem unternehmensweiten Text-to-SQL-Launch; er ist eine Demo, die ihre Fehlerquellen genauso skaliert wie ihre Abdeckung. Setzen Sie Zugriffskontrollen dort durch, wo die Daten liegen. Messen Sie die Genauigkeit wie ein SLO, mit einem goldenen Satz von Fragen und bekannten korrekten Antworten, und veröffentlichen Sie die Zahl intern, denn nichts fördert die Einführung wie ein Team, das sich messen lässt.
Die Demo ist der einfache Teil; sie ist dazu da, zu funktionieren. In der Produktion hat dieselbe KPI drei Definitionen, das hilfsbereite Modell überläuft seine Berechtigungen, und eine einzige falsche Zahl kostet die Zustimmung des Raums. Alle drei Fehlerquellen lassen sich beheben, aber in der Datenarchitektur, nicht im Prompt.
Venkata M Sangaraju ist Senior Database Engineer und arbeitet an governed conversational analytics und KI-Agenten auf Unternehmensdaten. Er hat über diese Arbeit bei Google Cloud Next '26 gesprochen und ist Mitautor von "Lineage-Aware Memory Governance" (IEEE Access, 2026).
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
Every conversational analytics demo follows the same script. Someone connects a model to a clean warehouse schema, types "show me revenue by region last quarter," and gets a correct chart in four seconds. The room nods. Then somebody says the sentence that has launched a thousand doomed pilots: "Now let's roll it out to the whole company."
I have spent the last few years doing exactly that rollout — building governed conversational analytics on Looker and its semantic layer, most recently exposing it to AI agents through the Model Context Protocol (MCP). The rollout I work on now runs at enterprise scale, and the metric that matters isn't the user count. It's accuracy — the kind you can defend in a board meeting — achieved not by using a bigger model, but by refusing to let the model touch raw data at all.
Here is what actually breaks between the demo and production, and why the fix is architectural, not prompt-based.
Ask a demo dataset for "revenue" and there's one column. Ask a real company and you get a knife fight. Finance's revenue is recognized revenue, net of refunds, on an accrual basis. Sales' revenue is bookings. Support's "active customer" hasn't opened a ticket in 90 days; Growth's "active customer" logged in this week. These aren't errors. They're legitimate, battle-tested definitions that happen to share a name.
An LLM pointed at raw tables has no way to know which definition you meant — so it guesses, fluently and confidently, and it guesses differently on Tuesday than it did on Monday. This is the failure mode that kills trust in production, and it never appears in demos because demo schemas have one table per concept.
The fix is unglamorous: a semantic layer where each metric is defined exactly once, in code, with the business logic owned by the people accountable for it. In Looker, that's LookML — measures, dimensions, and joins curated by data teams, version-controlled, reviewable. When the model asks for "revenue," it isn't writing SQL against a guess. It's invoking a definition that already survived your company's internal arguments. The semantic layer is the contract between the LLM and your data: the model decides what the user is asking, the layer decides what the data means.
This is also why text-to-SQL demos age so badly. Generated SQL re-derives your business logic from scratch on every single question, with a probabilistic engine. A semantic layer derives it once, deterministically, and reuses it forever.
The second thing that breaks is security, and it breaks quietly. In a traditional BI setup, access control lives close to the data: row-level filters, column restrictions, user attributes. Put an LLM in front of the warehouse with a broad service account — the default in most quick integrations — and you have just handed every user the union of all permissions the agent can reach, wrapped in a friendly chat interface.
Natural language makes this worse, not better. Nobody types "SELECT salary FROM…" into a chat box by accident; they ask "who on the team got the biggest raise?" A model eager to be helpful will route around your intent unless the data layer itself says no.
The principle that works in production: the agent inherits the requester's permissions, never its own, and enforcement happens at the data layer, not in the prompt. With a semantic layer in the middle, every query the agent issues carries the user's attributes, and the same row- and column-level rules that govern your dashboards govern the conversation. "Please ignore your restrictions" is not an attack a data layer has to care about. I've written elsewhere about the harder version of this problem — what happens when agents start caching and sharing results with each other — but the baseline rule is simple: if a control only exists in the system prompt, it doesn't exist.
In a demo, a slightly wrong number is a chuckle. In production, one executive catches one wrong number in one board meeting, and your rollout is dead for a year — not because the system is bad, but because trust in data tools is binary in a way trust in search results isn't.
This is why the architecture above isn't optional decoration. Deterministic definitions (the semantic layer), deterministic permissions (the data layer), and a model constrained to intent-parsing and presentation is how you get from "impressive demo" to answer accuracy you can defend in production. It also gives you something a raw LLM integration never will: an audit trail. Every answer can be traced to a governed query against named definitions, which matters the first time someone asks "where did this number come from?" in a regulated business.
Connecting this to agents through MCP is what makes it timely. When we exposed the semantic layer through Looker's MCP server — including to desktop agent clients across the company — the agents didn't get new powers. They got a well-lit doorway into powers that were already governed. That's the pattern I'd argue for everywhere: don't build a special, weaker governance regime for AI. Route AI through the governance you already trust, and let the model be the interface rather than the authority.
Start with twenty questions your business actually asks, define those metrics properly in a semantic layer, and only then connect the model. Resist the warehouse-wide text-to-SQL launch; it's a demo that scales its failure modes along with its coverage. Enforce access where the data lives. Measure accuracy like an SLO, with a golden set of questions and known-good answers, and publish the number internally — nothing builds adoption like a team willing to be measured.
The demo is the easy part; it's supposed to work. Production is where the same KPI has three definitions, the helpful model outruns its permissions, and one wrong number costs you the room. All three failures are fixable — but they're fixed in your data architecture, not in your prompt.
Venkata M Sangaraju is a Sr Database Engineer working on governed conversational analytics and AI agents over enterprise data. He spoke on this work at Google Cloud Next '26 and co-authored "Lineage-Aware Memory Governance" (IEEE Access, 2026).