Wenn der Semantic Layer 3 von 11 Fragen verweigert: Wer in Ihrem Team beantwortet sie?

Natural-Language-BIBITechnologien und Prozesse, die Rohdaten über Reporting, Dashboards und Analysen in verwertbare Insights überführen, damit Teams auf Basis von Fakten statt Intuition entscheiden.Vollständige Definition ansehen → ist die Standard-Demo des Jahres 2026. In jedem Warehouse, jeder BI-Suite und jedem Agent-Framework kann ein Sales-VPVPEine klare Aussage darüber, welchen Nutzen Ihr Produkt liefert, welche Probleme es löst und warum Kunden sich für Sie und nicht für Alternativen entscheiden sollten.Vollständige Definition ansehen → inzwischen eine Frage eintippen und bekommt ein Diagramm zurück. Der aktuelle Beitrag von The New Stack zu Semantic Layers für Enterprise-AI bringt das Argument klar auf den Punkt: Ein Katalog sagt Menschen, wo die Daten liegen. Ein Semantic LayerSemantic LayerEine gemeinsame Ebene für Geschäftsdefinitionen zwischen Rohdaten und Berichten, damit alle Umsatz, Churn oder Marge gleich berechnen.Vollständige Definition ansehen → sagt der KI, was sie bedeuten. Der Artikel ist ein Sponsored Post von Precisely, einem Anbieter für Datenintegrität. Behandeln Sie seine Statistiken also als Marketing, bis Sie sie gegenprüfen kkDie durchschnittliche Zahl neuer Nutzer, die jeder bestehende Nutzer über Empfehlungen generiert. Über 1,0 verstärkt sich das Wachstum selbst und wird exponentiell.Vollständige Definition ansehen →önnen. Laut Artikel sagen nur 12 % der Unternehmen, ihre Daten seien AI-ready, und nur 31 % können ihre KI-Initiativen an klare KPIs koppeln. Gartner, ein unabhängiges Haus, geht weiter: Bis 2030 werden universelle Semantic Layers als kritische Infrastruktur gelten, gleichrangig mit Datenplattformen und Cybersecurity.

Meine These: Der Konsens liegt bei der Technik richtig und bei den Menschen falsch. Ein Semantic Layer macht Natural-Language-BI nicht in einem absoluten Sinn genau. ErErDas Verhältnis von Interaktionen (Likes, Kommentare, Shares) zur Reichweite eines Inhalts. Zeigt, wie stark die Zielgruppe reagiert, gemessen an der Zahl der Personen, die den Inhalt gesehen haben.Vollständige Definition ansehen → verändert, wie das System scheitert: Aus selbstsicher falschen Zahlen werden Verweigerungen und Lücken in der Abdeckung. Jemand muss diese Verweigerungen verantworten, und der naheliegende Owner ist der Analyst, den gerade alle auf „Insight und Storytelling“ umsetzen wollen. Wenn Sie die Analysten von der Lücke abziehen, gehört die Lücke niemandem.

Warum Semantic Layers zum Konsens-Fix für Natural-Language-BI wurden

Die Argumente für Semantic Layers sind stark und verdienen zuerst eine faire Anhörung. Large Language Models raten bei der geschäftlichen Bedeutung, wenn sie SQLSQLSales Qualified Lead: ein Prospect, den das Sales-Team als bereit für direkte Ansprache und ein Angebot validiert hat, weil er klare Qualifizierungskriterien erfüllt.Vollständige Definition ansehen → gegen Rohtabellen schreiben. Die Vermutungen sehen gut aus und sind falsch. AWS-Architekten beschrieben auf dem dbt Summit 2026, wie falsche Joins Zeilen stillschweigend doppelt zählen und erfundene Metrikdefinitionen dazu führen, dass „Revenue“ in der Query des Agenten nicht der Umsatz des Unternehmens ist. In ihrem Beispiel, das dbt Labs (ein Anbieter genau dieses Semantic Layers) aufgeschrieben hat, lieferte eine Query im Agent-Stil, die Bruttobestellbeträge summierte, 14,86 Millionen Dollar, während der tatsächliche Umsatz bei 11,36 Millionen Dollar lag. Das ist eine Überzeichnung um 30,8 %.

Die Benchmarks zeigen in dieselbe Richtung. AtScale verkauft einen Semantic Layer, lesen Sie die Zahlen also mit diesem Wissen. Das Unternehmen ließ sieben LLMs 410 Business-Fragen beantworten und stellte fest, dass ein Wechsel des LLMLLMEin Large Language Model ist ein KI-System, das auf riesigen Textmengen trainiert wurde, um Sprache vorherzusagen und zu erzeugen. Damit sind Aufgaben wie Schreiben, Zusammenfassen und Beantworten von Fragen möglich.Vollständige Definition ansehen → die Genauigkeit um bis zu 17,6 Punkte verschob, während der Semantic Layer die Genauigkeit jedes Modells um 20 bis 31 Prozentpunkte verbesserte. Der verwendete Benchmark stammt nicht von AtScale: BIRD-Interact ist ein unabhängiger Benchmark des BIRD Team und von Google Cloud, angenommen auf der ICLR 2026. Die Studie von dbt Labs aus dem Jahr 2026 zur ACME-Insurance-Suite berichtet einen ähnlichen Effekt. Im modellierten Projekt steigt Claude Sonnet 4.6 von 90,0 % (Text-to-SQL) auf 98,2 % (Semantic Layer), GPT-5.3-Codex von 84,1 % auf 100,0 %.

Gartners Market Guide for Agentic Analytics vom Februar 2026, zitiert vom Anbieter Unsupervised, warnt: „Bis 2028 werden 60 % der Agentic-Analytics-Projekte, die sich ausschließlich auf MCPMCPEin offener Standard, mit dem KI-Assistenten einheitlich und kontrolliert an die Werkzeuge und Daten des Unternehmens angebunden werden, statt jede Integration einzeln zu bauen.Vollständige Definition ansehen → stützen, am Fehlen eines konsistenten Semantic Layers scheitern.“ Die Konsensgeschichte über die Menschen folgt daraus. Die Maschine schreibt die Queries, der Semantic Layer hält sie ehrlich, und Analysten rücken in der Wertschöpfungskette nach oben, zu Interpretation und Storytelling.

Die ersten beiden Aussagen stimmen. Bei der dritten fängt das Problem an.

Was Semantic-Layer-Benchmarks über Fehlermuster verraten

Verweigerungen ersetzen falsche Zahlen, und Verweigerungen brauchen einen Owner

Schauen Sie über die Genauigkeit in der Schlagzeile hinaus darauf, wie jeder Ansatz scheitert. Ein unabhängiger Paired Benchmark auf arXiv fasst das dbt-Ergebnis zusammen: Fehler des Semantic Layers sind typischerweise Verweigerungen („kann ich nicht beantworten“), Fehler von Text-to-SQL sind selbstsicher falsche Zahlen. Eine Aufschlüsselung desselben dbt-Benchmarks zeigt, wie scharf die Trennung ist. Im Scope: Der dbt Semantic Layer erreichte bei beiden Modellen 100 %. Text-to-SQL kam auf 62,5 % und 51,2 %. Bei Fragen mit zu vielen Entity-Hops: Der Semantic Layer erreichte 0 %, weil er verweigerte. Text-to-SQL kam dort auf 70,0 % und 100,0 %.

Ein Semantic Layer ist also ein Perimeter. Innerhalb ist er nahezu perfekt, außerhalb ist die Antwort Schweigen. Der Perimeter ist so breit wie die Metriken und Beziehungen, die jemand modelliert und freigegeben hat. Jede Verweigerung ist ein Arbeitsauftrag.

Die verbleibenden falschen Antworten sind meist Meinungsverschiedenheiten über Policies. Fivetran (ein Anbieter für Datenintegration) testete Agents auf einem dbt-Projekt und stellte fest, dass die Fehler von Claude Opus bei reinem SQL auf eine geschäftliche Policy-Entscheidung zurückgingen: Das Modell schloss stornierte Bestellungen bei der Berechnung des Gesamtumsatzes aus. Hinter einer governten Metrik lieferte Opus in 75 Durchläufen 0 falsche Antworten. Das Modell war nicht schlecht in SQL. Es traf eine Finance-Policy-Entscheidung, die niemand aufgeschrieben hatte. OWOX, ein weiterer Anbieter, ergänzt, dass ein Semantic Layer keine 100-prozentige Garantie ist: Der Agent kann immer noch eine andere Zahl als erwartet in den Vordergrund stellen, wenn die Frage vage formuliert ist.

Zu entscheiden, ob stornierte Bestellungen zählen, eine vage formulierte „Top Line“-Frage zu behandeln und den Entity-Hop zu ergänzen, den der Layer verweigert hat: Das ist alles Analystenarbeit. Nichts davon ist Storytelling.

KI-Rollouts schaffen neue semantische Silos

Der zweite blinde Fleck: Der KI-Rollout selbst erzeugt oft einen zweiten Semantic Layer. Der Fall Okta, aufgeschrieben von dbt Labs (einem Anbieter), ist das deutlichste Beispiel. Oktas frühe KI-Experimente liefen auf Semantic Views, die direkt in der Oberfläche von Snowflake gebaut und unmittelbar an Snowflake-Cortex-Agents angebunden waren. Das funktionierte, und zwar schnell, aber diese Semantic Views waren vollständig von den governten dbt-Modellen abgekoppelt, in denen die Geschäftslogik tatsächlich definiert war. Die Lösung war ein dreischichtiges Agent-Context-Framework, komplett in dbt gebaut und über normale Pull Requests ausgeliefert. Manches davon ist banal, etwa unternehmensweite Fakten (Oktas Geschäftsjahr beginnt am 1. Februar).

Sigma verkauft ein BI-Tool und hat hier also ein eigenes Interesse. Das Unternehmen ging weiter und kompiliert ein einziges dbt-Projekt in mehrere Targets. Sein Lead Data Platform Engineer beschrieb, wie 63 Jobs kontinuierlich über 2.883 dbt-Modelle und 6 Datenregionen hinweg bauen und deployen. Der Governance-Gewinn ist bescheiden und real: Wenn jemand die ARRARRAnnual Recurring Revenue (ARR) ist der normalisierte, planbare Umsatz, den ein Subscription-Geschäft aus aktiven Verträgen innerhalb eines Jahres erwartet.Vollständige Definition ansehen →-Formel anpasst, lässt sich der Diff reviewen und die Historie abfragen.

Auch Gartners eigene Prognose untergräbt die Idee eines einzigen Eingangs. Sie sagt voraus: „Bis 2028 werden 60 % der Nutzer allgemeine LLMs für Ad-hoc- und explorative Analysen verwenden, während produktionsreifes Reporting in klassischen ABI-Plattformen bleibt.“ Ihr governter Layer deckt die Reporting-Spur ab. Das Chatfenster auf jedem Laptop deckt den Rest ab, ob Sie zustimmen oder nicht. Die Analystin Cindi Howson, zitiert in AIwire, liefert die ehrliche Version der Architektur: Kunden sollten nicht den einen Semantic Layer anstreben, der alle beherrscht.

Menschliche Prüfung von KI-Antworten verkommt zum Abnicken

Der dritte blinde Fleck ist das Standard-Sicherheitsnetz: „Ein Analyst prüft die Antworten der KI.“ Im November 2026 veröffentlichte die MIT Sloan Management Review das Argument von Shefali Patil, dass AI-Governance-Frameworks in Hochrisikobranchen einen versteckten Fehler haben: Indem sie „Humans in the Loop“ auf KI-generierte Alerts reagieren lassen, statt potenzielle Bedrohungen proaktiv zu erkennen, könnten diese Frameworks wichtige menschliche Verhaltensweisen schleichend aushöhlen. Ein Analyst, der den ganzen Tag Maschinenantworten freigibt, verliert die Gewohnheiten, mit denen man das Problem der stornierten Bestellungen überhaupt erst bemerkt.

Gartners Rita Sallam sagt, analytische Workflows sollten so umgebaut werden, dass sie eine verpflichtende Evaluierungsstufe enthalten. Diese Evaluierungsstufe sollte eine Testsuite sein, die der Analyst schreibt und pflegt, ohne dass ein Analyst jede Antwort mit bloßem Auge prüft. Okta bewegt sich in diese Richtung: Der nächste Schritt sind automatisierte Regressionstests, die bei jeder Kontextänderung verifizierte Queries gegen die Agents laufen lassen.

Was sollten Analysten tun, wenn Natural-Language-BI live geht?

Analysten sollten die Grenze des Semantic Layers verantworten: welche Fragen er beantwortet, welche er verweigert und wie schnell aus Verweigerungen governte Metriken werden. Die Aufgabe verbindet Definitionsarbeit (Entscheidungen wie „zählen stornierte Bestellungen“) mit Test Engineering (verifizierte Queries, die bei jeder Änderung laufen). Sie liegt näher am Produktmanagement für Metriken als am Bau von Dashboards.

Die Drei-Spuren-Regel

Hier ist die Entscheidungsregel, kurz genug für ein Whiteboard:

Verlässt die Zahl den Chat, kommt sie aus einer governten Metrik. Gibt es keine governte Metrik, verweigert das System und protokolliert die Frage. Alles andere wird als Entwurf gekennzeichnet.

In der Praxis ergibt das drei Spuren:

• Governte Spur. Board Packs, Forecasts, Vergütung und alles, was Kunden sehen, gehen auf eine benannte Metrik im Semantic Layer zurück, mit Owner und Versionshistorie.
• Verweigerungsspur. Fragen außerhalb der Abdeckung bekommen ein explizites „kann ich nicht beantworten“. Sie landen in einem Backlog, das das Analystenteam gegen ein Service Level abarbeitet, zum Beispiel neue Metriken innerhalb von zwei Sprints.
• Explorative Spur. Text-to-SQL oder ein allgemeines LLM ist für Hypothesen in Ordnung, solange der Output als Entwurf gekennzeichnet ist und ohne Hochstufung in die governte Spur nicht in ein Deck wandern kann.

Drei Kennzahlen messen dann das Analystenteam. Coverage ist der Anteil der Fragen, die in der governten Spur beantwortet werden. Time-to-Metric ist die Zeit, bis eine Verweigerung geschlossen ist. Die Regression Pass Rate ist der Anteil der verifizierten Fragen, die nach jeder Änderung noch korrekt beantwortet werden. Alle drei sind messbar, und keine zählt ausgelieferte Dashboards. Wenn Sie das Team darauf neu ausrichten, beginnt die technische Arbeit damit, Metrikdefinitionen als versionierten Code zu behandeln.

Ein durchgerechnetes Beispiel aus dem dbt-Benchmark

Nehmen Sie die 11 Fragen des dbt-Labs-Benchmarks und denken Sie daran, dass dbt Labs den getesteten Layer verkauft. Auf dem vollständigen Set: 72,7 % für den Semantic Layer, 64,5 % für Text-to-SQL bei beiden Modellen.

• 72,7 % von 11 sind 8 richtige Antworten. Die 3 Fehler waren Verweigerungen, ein Nutzer sah also dreimal „kann ich nicht beantworten“.
• 64,5 % von 11 sind etwa 7 richtige Antworten. Die rund 4 Fehler kamen als Zahlen an, und nichts sagte dem Nutzer, welche falsch waren.

Der Abstand in der Schlagzeile beträgt etwa eine Frage. Der eigentliche Abstand: Das eine System hat alle seine Fehler markiert, das andere keinen. Dann sehen Sie sich an, was die Lücke geschlossen hat: Nachdem ein LLM drei dbt-Modelle ergänzt hatte, erreichte der Semantic Layer 98,2 % und 100 %. Drei Modelle machten aus drei Verweigerungen richtige Antworten. Die Arbeit war modellgestützt, aber jemand muss trotzdem freigeben, was diese Modelle definieren, und dieser Jemand ist ein Analyst.

Wenden Sie dieselbe Rechnung auf den AWS-Umsatzfall an. 14,86 Millionen Dollar minus 11,36 Millionen Dollar sind 3,5 Millionen Dollar, und 3,5 Millionen Dollar geteilt durch 11,36 Millionen Dollar ergeben 30,8 %. Die Zusammenfassung der Session merkt an, dass unklar ist, ob die Beispiel-Query von einem echten Agent ausgeführt wurde oder nur zur Illustration dient. Behandeln Sie sie also als Demonstration. Der Mechanismus, den sie zeigt, nämlich Bruttobestellwert als Ersatz für Umsatz, ist dieselbe Policy-Lücke, die Fivetran bei stornierten Bestellungen gefunden hat.

Was Sie am Montag tun sollten

• Ziehen Sie die 20 Metriken, die am häufigsten in Executive-Decks auftauchen. Prüfen Sie für jede, ob sie als eine einzige governte Definition in Ihrem Semantic Layer existiert oder an drei Orten lebt (BI-Tool, Semantic Views im Warehouse, Agent-Prompts).
• Prüfen Sie, ob Ihr Natural-Language-BI-Tool verweigern kann. Wenn es jede Frage beantwortet, konfigurieren Sie es so, dass Nutzer der governten Spur außerhalb modellierter Metriken Verweigerungen bekommen, und beginnen Sie, diese Verweigerungen zu protokollieren.
• Schreiben Sie ein Kontextdokument nach Okta-Vorbild mit fünf Unternehmensfakten, die ein LLM nicht ableiten kann, etwa Beginn des Geschäftsjahres, Regeln zur Umsatzrealisierung und den Umgang mit Stornierungen und Retouren.
• Wählen Sie 10 Fragen mit bekannten, von Finance freigegebenen Antworten und lassen Sie sie jede Woche gegen Ihren Assistenten laufen. Dieses Set ist Ihre Regressionssuite.
• Finden Sie heraus, wo Ihr Unternehmen bereits allgemeine Chat-Tools auf Unternehmensdaten nutzt. Einigen Sie sich auf das Entwurfslabel und den Weg zur Hochstufung, bevor Gartners 60 % in Ihren eigenen Logs auftauchen.
• Schreiben Sie eine Analysten-Stellenbeschreibung so um, dass Coverage und Time-to-Metric „baut Dashboards“ ersetzen. Planen Sie damit anschließend, wie Sie das aktuelle Team umschulen.

Zählen Sie Ihre Verweigerungen in diesem Monat. Ein Natural-Language-BI-Tool, das nie „kann ich nicht beantworten“ sagt, rät bei manchen Fragen trotzdem, und niemand kann sagen, bei welchen. Der Analyst, dem das Verweigerungsprotokoll gehört, ist die Person, die aus diesen Vermutungen governte Antworten macht.