semantic-layer ai-agents metrics data-governance mcp

Ihr semantisches Modell ist die API: Zertifizierte Metriken für Agenten bereitstellen.

Warum KI-Agenten eigene Definitionen von Umsatz und Lagerbestand erfinden und wie ein reguliertes semantisches Modell mit Details, Eigentümern und Ablehnungen ihnen einen Vertrag bietet.

Verlag: REACTAPP.TOPAuf dieser Website hinzugefügt 28. Okt. 202622 Min. Lesezeit4972 Wörter

Quellen: Your Semantic Model Is the API Agents Will Call

Zwei Zahlen, beide offiziell

Ein Planungstreffen begann mit einer Folie mit dem Titel „Letzte Woche, Verkäufe“. Am Abend zuvor waren beiden Co-Piloten dieselbe Frage gestellt worden, und beide hatten Diagramme mit angehängten SQL-Dateien zurückgegeben. Eine Zahl lag 4 Prozent über dem Plan, die andere 3 Prozent darunter.

Niemand im Raum machte den imaginären Spalten die Schuld. In der Datenbank gab es tatsächlich eine sales-Tabelle mit einer net_amt-Spalte sowie Datumsangaben. Die Abfragen ließen sich ausführen, die Verknüpfungsschlüssel existierten, und aus Sicht der Datenbank waren beide Ergebnisse gültig.

Die Finanzabteilung stellte anschließend eine dritte Berechnungsmethode vor, die bereits für den wöchentlichen Vorstandsbrief festgelegt worden war. Dabei wurden die anerkannten Einnahmen nach Rechnungsdatum erfasst, Gutschriften abgezogen, und sowohl Käufe durch Mitarbeiter als auch Großhandel ausgeschlossen. Copilot eins berücksichtigte das Bestelldatum und nahm die Käufe aus den Mitarbeiterläden mit auf. Copilot zwei nutzte das Versanddatum und bezog die Region aus der Versandadresse statt aus der Verkaufseinheit.

Als in demselben Thread gefragt wurde, nach welchem Datum jede Methode verwendet wurde, wies eine auf order_dt und die andere auf ship_dt hin. Keine der beiden erwähnte Gutschriften. Bezüglich der Einbeziehung von Käufen durch Mitarbeiter sagte eine, sie habe keinen Filter dafür gesehen, während die andere eine Geschichte über ein channel-Flag erfand, das sich als Marketing-Attributionsfeld ohne Verbindung zu den Mitarbeiterläden herausstellte.

Die Problematik lag hier in der Gehorsamkeit. Beide Agenten verhielten sich wie fähige Analysten, die einen schwierigen Tag hatten: Sie entdeckten eine Spalte, deren Name der Frage ähnelte, und fügten deren Werte zusammen. Ein Mensch würde normalerweise innehalten und fragen, welche Verkaufszahl gewünscht sei, während ein Agent eine plausibel erscheinende Spalte als grünes Licht zum Abschluss betrachtet.

Später enthielt der Slack-Thread drei Diagramme und eine Finanzzahl. Niemand fügte den Namen einer Kennzahl ein, nur Screenshots – und das ist ein nützliches Warnsignal. Wenn es um Bilder geht, wird der Vertrag niemals herangezogen.

Geben Sie einem Agenten ein Lager und eine klare Anweisung, und er wird das Geschäft selbst erfinden. Diese Erfindung wirkt wie Kompetenz und landet in Slack, wo die Leute über Modellgewichte streiten, anstatt sich über den fehlenden Vertrag zu unterhalten. Solche Streitigkeiten lassen sich leicht als Kulturproblem darstellen, doch sie entstehen eigentlich durch fehlende Schnittstellen – erst im Standup wird das Versagen sichtbar.

Eine praktische Art, das semantische Modell vorzustellen, ist als API – allerdings nicht im Sinne der REST-Tradition. Stellen Sie sich eine Schnittstelle vor, die private Interpretationen ausschließt. Wenn jemand nach den Verkäufen der letzten Woche fragt, hat der Anrufer keine Entscheidungsmacht darüber, welche Datumsspalte verwendet wird. Es wird entweder recognized_revenue zu einer festgelegten Auflösung ausgeführt, oder es erfolgt eine Ablehnung. Der Engine kann weiterhin SQL generieren, doch der Agent schreibt diesen Code nicht selbst.

Es ist in Ordnung, Endpunkte und API-Schlüssel visualisiert darzustellen, wenn das hilft. Entscheidend ist etwas Präziseres: eine Operation mit einem Namen und einer eindeutigen Bedeutung, die jeder zugelassene Aufrufer ausführen kann.

APIs verfügen außerdem über Eigentümer, Versionen sowie Regeln für brisante Änderungen. Eine Messgröße ohne Eigentümer ist lediglich ein Gerücht, das zufällig berechnet wird. Wenn die Finanzabteilung die Handhabung von Gutschriften ändert, sollte das zu einer Versionserhöhung führen, die jeder Aufrufer wahrnimmt – andernfalls kehren die alten Zustände zurück. Die Anzeige der Metriken-Version im Fußteil des wöchentlichen Briefes über einen Monat mag pedantisch erscheinen, doch dadurch wird die Frage „Welches Umsatzvolumen?“ von einem Konflikt zwischen Personen zu einer Frage der Version.

Die Abfrage war perfekt, die Bedeutung nicht

Wenn man einem modernen Modell ein Schema-Dump zusammen mit einer Umsatzfrage gibt, ergibt sich in der Regel eine SQL-Abfrage, die ordentlich genug ist, um vor zehn Jahren beeindruckend gewesen zu sein. Dort liegt jedoch nicht mehr das eigentliche Risiko.

Umsatz ist keine Spalte. Schon ein Unternehmen kann gebuchten, fakturierten, gelieferten und anerkannten Umsatz sowie alle Einnahmen aus Kassenbelegen vor Rückerstattungen haben. Gutschriften können die Summe ausgleichen oder auch nicht. Innenunternehmensverkäufe können berücksichtigt werden oder auch nicht. „Niederlande“ kann das Rechnungsland, das Lieferland oder die Vertriebsorganisation sein, die das Konto führt, und „letzter Monat“ kann ein Kalendermonat oder ein am Sonntag endender Geschäftsjahreszeitraum sein.

Kein Teil davon bezieht sich auf die JOIN-Syntax. Eine klassische JOIN-Operation kann dennoch eine falsche Antwort liefern, die für die darauf beruhende Entscheidung relevant ist.

Das Lagerverwaltungssystem verhält sich genauso. Der vorhandene Bestand ist nicht als versprechbar einzustufen, und das als versprechbar Angesehene wird auch nicht tatsächlich vom Zuweisungssystem noch in derselben Nacht an den E-Commerce freigegeben. Ein Mitarbeiter, der auf der Grundlage des vorhandenen Bestands antwortet „Können wir es bis Freitag versprechen?“, wirkt zwar operativ tätig, führt den Kunden aber dennoch in die Irre.

In einem Fall beruhigte ein Mitarbeiter einen Lagerleiter bezüglich eines bestimmten Artikels, da er die Summe von qty_on_hand aus allen Standorten zusammengezählt hatte – einschließlich des beschädigten Regals – obwohl die Planung dieses Regal bereits als unbrauchbar markiert hatte. Die SQL-Abfrage war ordentlich formuliert, doch die darin enthaltene Aussage war nur eine Vermutung. Der Lagerleiter hatte das Regal bereits früher am Tag physisch überprüft, während der Mitarbeiter nur auf Tabellendaten zurückgreifen konnte.

Die schnelle Berichterstattung zeigt denselben Unterschied. Die Filialleitung möchte Einheiten, die vor 16 Uhr die Kasse bedient haben, während die Finanzabteilung erfasste Einnahmen nach Abzug von Gutschriften haben will. In einem Meeting behaupten beide Seiten „Gestrige Umsätze“. Ein Mitarbeiter, dem dieser Satz gegeben wird, wählt eine Zeitstempelspalte und eine Geldspalte aus und hört auf – die Diskussion beginnt erst, nachdem der Diagramm angezeigt wurde.

Auch bei der Warenplanung gibt es dieselbe Falle. Die Nachfrage unterscheidet sich von den Daten am Verkaufspunkt, und die Verkaufspunktdaten unterscheiden sich wiederum von den Nettoverkäufen, sobald Rücksendungen berücksichtigt werden. Ein bestimmter Artikel kann im E-Commerce-System als ausverkauft angezeigt werden, während eine Tabelle, die dem Mitarbeiter sichtbar ist, weiterhin Lagerbestände auflistet – schließlich enthält diese Tabelle auch Waren auf dem Weg zum Kunden, Waren, die zur Qualitätskontrolle zurückgehalten werden, sowie Mengen, die für Großhandelslieferungen reserviert sind. Wenn der Mitarbeiter auf der Grundlage falscher Informationen „Haben wir ihn?“ beantwortet, übernimmt das Unternehmen bereits am Morgen übermäßige Versprechen und muss dann den Nachmittag damit verbringen, einen Mangel zu erklären, den die Tabelle ursprünglich nicht angezeigt hat.

Es ist unzutreffend, dies als Fehler des Prompts zu bezeichnen, da der Prompt „Haben wir es?“ in Ordnung war. Was fehlte, war ein available_to_promise-Objekt mit dokumentierten Details: die Liste der Standorte, die ausgeschlossenen Lagerarten, die Bestandszahlen im Transport sowie die Zeit, zu der der Abgleich erfolgt. Ohne dieses Objekt improvisiert jeder Anrufer seine eigene Lieferkette.

Deshalb überträgt sich das frühere Komfortgefühl bei self-service BI nicht. Zehn Personen, die sich ein Dashboard ansehen, teilen zumindest dieselben fehlerhaften Zahlen. Zehn Mitarbeiter, die jeweils eigene Abfragen erstellen, erscheinen lokal sinnvoll, doch am Ende herrscht nur Verwirrung ohne klare Zahlen.

Ein Analyst ohne Kontext stellt eine Nachfrage. Ein Agent ohne Kontext vervollständigt den Satz. In Demonstrationsumgebungen war das eine Kuriosität, in der Produktion hingegen eine Gefahr – denn derselbe Stack, der es ermöglichte, auf Daten leicht zuzugreifen, machte es auch einfach, ohne vorherige Absprache Abfragen durchzuführen.

Zwei Jahrzehnte wurden darauf verwendet, Daten über Data Warehouses, Lakehouses, ELT-Systeme, Notebooks und APIs zugänglich zu machen, wodurch sich das Engpassproblem nun an anderer Stelle befindet. Ob Software die Tabelle sehen kann, ist geklärt. Ob die Software entscheiden darf, was die Tabelle bedeutet, ist es nicht.

Was ein Bedeutungsvertrag beinhaltet

Ein Glossar reicht nicht aus, da es einfach falsch interpretiert werden kann, während ein Vertrag entweder funktioniert oder abgelehnt wird. Die Operationen, die ein nutzbares semantisches Modell benennt, sind jene, über die das Unternehmen bereits verhandelt und eine Einigung erzielt hat:

Erkannter Umsatz hat eine präzise Definition, und bestimmte Zeilen gehören niemals dazu.
Ein aktiver Kunde wird nach einer Regel definiert, nicht nach Bauchgefühl.
Die Beziehung zwischen Kunde und Region ist die, für die die Finanzabteilung einstehen will.
Bei diesem KPI wird die Zeiträumung anhand des Rechnungsdatums vorgenommen und niemals anhand des Bestelldatums.
Einige Dimensionen dürfen zur Unterteilung verwendet werden, die anderen dienen nur der Verzierung.

Darunter befinden sich Messwerte, Dimensionen, Hierarchien, berechnete Felder, Metadaten sowie Zeilenfilter – es spielt keine Rolle, in welchem Datei des Anbieters sie gespeichert sind. Funktional gesehen wurde ein Teil der Geschäftsprache in eine Form umgewandelt, die von Software aufgerufen werden kann. Bis vor Kurzem war der Hauptaufrufer ein Bericht. Der neue Aufrufer langweilt sich nie, geht nie zum Schreibtisch des Analysten und schämt sich nicht dafür, sich sicher im Unrecht zu befinden.

Die Datenerfassung ist etwas, was Teams überspringen, weil es sich wie Hausaufgaben im Bereich Modellierung anfühlt – doch es handelt sich dabei um ein zentrales Element der API. Wenn nichts deklariert wird, erfindet jeder Aufrufer seine eigene Struktur. Es reduziert sich auf vier Fragen, deren Antworten am selben Ort benötigt werden:

Welches Datum markiert das Ende des Zeitraums.
Welche Entität wird durch die Zahl beschrieben – sei es die Verkaufseinheit, der Empfänger oder der Zahler.
Welche Zeilen werden ausgeschlossen, wie beispielsweise Mitarbeiter, Großhandelsbestellungen, Unternehmensinterne Bestellungen und Testbestellungen.
Welche Sicherheitsregeln gelten weiterhin, wenn der Aufrufer ein Agent ist.

Fehlen diese Antworten im Modell, landen sie in einem Slack-Thread – also an keinem festen Ort.

Eine Marge-Metrik zeigt, wie es aussieht. Die Formel war gut, aber das Datum war ungenau. Ein Anrufer verwendete das Bestelldatum, weil die Fakttabelle standardmäßig darauf zurückgriff, und ein anderer das Rechnungsdatum, weil die Finanzansicht dies vornahm. Beide berichteten über die „Marge“, und innerhalb einer Woche, als die Frachtkosten in die Höhe schossen, lagen ihre Werte zwei Punkte auseinander. Der Agent wurde dafür verantwortlich gemacht, obwohl das eigentliche Problem das Fehlen von Details war. Durch Hinzufügen des Rechnungsdatums, einer Regel zur Berücksichtigung von Frachtkosten sowie eines Verantwortlichen wurde das Problem behoben, und die Berichte der folgenden Woche stimmten überein. Niemand dankte dem Modell, aber die Anfragen hörten auf.

Der zu verfolgende Weg ist aus Gründen der Einfachheit bewusst eintönig: Absicht festlegen, verknüpfen, durchsetzen, ausführen, antworten. Zu keinem Zeitpunkt entscheidet das Modell darüber, was Einnahmen bedeuten. Es ist zulässig, die geeignete, zertifizierte Metrik auszuwählen, die zur Frage passt – schließlich handelt es sich dabei um Klassifizierung. Die Zusammenstellung einer Metrik aus Rohdatenblättern ist Interpolation, und Interpolation ist der Mechanismus, durch den zwei offizielle Zahlen bereits vor dem ersten Kaffee vorliegen.

Die Protokolle erzählen die Geschichte. Wenn der Agent Spalten aufgrund von Namensähnlichkeit auswählt, handelt es sich um einen Sammler. Wenn er recognized_revenue zusammen mit einem Zeitraum und einer Region aufruft, handelt es sich um einen Anrufer. Das zweite Protokoll ist weniger dramatisch – doch genau dieses sollte bei einer Prüfung vorgelegt werden.

Metadata sind nicht mehr Dokumentation

Früher wurden Beschreibungen nachträglich hinzugefügt, sobald das Dashboard verfügbar war – und nur dann, wenn im Sprint noch Zeit übrig war, was selten der Fall war. Eine Messgröße mit dem Namen [NS Adj LY %] galt als akzeptabel, weil die drei Personen, die die Datei bearbeiteten, deren Historie kannten.

Ein Agent kennt dieses Hintergrundwissen nicht. Microsofts Anleitung zur Vorbereitung semantischer Modelle für Datenagenten besagt ausdrücklich, dass Namen, Beschreibungen, Beziehungen und reduzierte Mehrdeutigkeiten die Qualität der Antworten bestimmen – und das gilt auch außerhalb dieses Technologiestacks. Diese Zeichenketten sind nun verbindliche Eingabedaten. Eine leere Beschreibung hindert den Agenten nicht daran, zu antworten; sie führt lediglich zu einer ungenauen Antwort.

Der Wandel wird leicht unterschätzt, weil die Datei unverändert aussieht – es gibt weiterhin ein Modell mit Messgrößen darin. Was sich geändert hat, ist der Nutzer: Ein menschlicher Entwickler schließt Schlüsse, während ein Agent die Daten verarbeitet, und selbst eine ungenaue Verarbeitung liefert weiterhin eine Antwort mit einem angehängten Diagramm.

Ein rätselhafter Maßnamen gilt nun als Produktfehler, genauso wie eine undokumentierte öffentliche Funktion. Niemand würde fn_x3() als Abrechnungs-API veröffentlichen, doch jahrelang galt sie als Metriken-API, weil einfach nur Leute sie aufrufen konnten.

Die Plattformen setzen auf dasselbe

Wenn man den Markenfarben auf den Produktseiten beraubt, zeigt sich ein Muster. Microsoft, Snowflake, Databricks und ThoughtSpot investieren alle in semantische Schichten, Governance sowie das, was sie als vertrauenswürdigen Geschäftskontext bezeichnen. Ihr Ansatz besteht nicht in einer auffälligen Demonstration eines Modells, das SQL ausgibt.

Sie alle setzen darauf, dass ein Modell über zertifizierte Bedeutungen nachdenken sollte, anstatt über die Spalte zu entscheiden, die zufällig am nächsten an einem Wort in der Frage liegt. Datenagenten im Fabric-Stil, die in Lagerhäusern, Lakehouses und Power BI-Semantikmodellen antworten, drücken dieses Konzept aus. Ebenso tun es Cortex-ähnliche Analysten, die eine semantische Sicht vor einem rohen Schema-Export bevorzugen, sowie Metrikansichten und -kataloge, die einen KPI zu einem Plattformobjekt erheben. ThoughtSpot verkauft bereits seit Jahren „Fragen an die Daten“ über eine modellierte Schicht, und der Rest des Marktes verstand, warum, sobald Software zu einer möglichen Anfragerichtlinie wurde.

Eine Strategie, bei der das klügste Modell ausgewählt und auf den See gerichtet wird, steht im Widerspruch zur Richtung der bereits bezahlten Plattformen. Sie fügen eine Bedeutungsschicht vor den See hinzu, weil die Modelle in SQL gut geworden sind – schließlich erhöht die Flüssigkeit im Umgang mit Daten die Kosten für Meinungsverschiedenheiten, ohne diese beseitigen zu können. Der Kauf eines weiteren Copilots schafft keine Definition des Kunden. Stattdessen entstehen weitere Bereiche, in denen Meinungsverschiedenheiten auftreten können.

Ein Protokoll definiert keine Einnahmen

MCP taucht in denselben Diskussionen auf, und das Protokoll wird manchmal fälschlicherweise für eine Strategie gehalten. Es hat tatsächlich einen echten Wert. Nehmen wir einen Fabric-Datenagenten, der als MCP-Server veröffentlicht wurde – zu dem Zeitpunkt, als die Dokumente zuletzt gelesen wurden, noch in der Vorabversion: Er zeigt, dass der Ort, an dem eine Frage eingegeben wird, nicht unbedingt derselbe sein muss, an dem die Logik verwaltet wird. Qlik und andere Anbieter gehen in dieselbe Richtung und stellen kontrollierte Analysen Assistenten zur Verfügung, die das ursprüngliche Tool niemals starten. Die Oberfläche zur Stellung von Fragen und die Oberfläche zur Interpretation der Ergebnisse können voneinander getrennt sein.

Trotzdem ist es unklug, ein Protokoll fest mit etwas zu verbinden, da Protokolle ersetzt werden können. Das bleibende Prinzip ist, dass Bedeutung ein Service ist und der Chatbot ein Client.

Die Bereitstellung eines unübersichtlichen Power BI-Dateis über MCP macht das Problem nur entfernter. Der Agent in Claude, Copilot oder einem internen System wird weiterhin auf [NS Adj LY %] verweisen, wenn das veröffentlicht wurde.

Headless BI hat das bereits durchgemacht. Teams setzten eine einfache SQL-Schnittstelle über dieselben undokumentierten Messgrößen und gaben dem neuen Client die Schuld, wenn sich die Zahlen änderten. Das Protokoll erfüllte seine Aufgabe – doch das, was es transportierte, war lediglich Aberglaube in Form einer Netzwerkroute.

Deshalb bleibt das Protokoll im „Leitungsnetz“: Es dient dazu, Tools zu finden, Kontext weiterzugeben und zwischen Prozessen zu kommunizieren. Die Bedeutung wird separat behandelt, indem Metriken gebunden, ungültige Werte abgelehnt und Zeilen-Sicherheit angewendet wird. Ein hervorragendes Leitungsnetz – basierend auf einer Definition, die niemand vor der Finanzabteilung verteidigen würde – bleibt weiterhin Aberglaube, nur mit einer URL.

Die alte Debatte um Business Intelligence drehte sich darum, welches Tool standardisiert werden sollte. Wenn Agenten als Anrufer fungieren, ist die bessere Frage, wo der zuverlässige analytische Kontext vorhanden ist und welche Anrufer darauf zugreifen dürfen. Die Berichterstellung kann in einem Produkt verbleiben, während den Agenten ein gemanagtes Modell nahe am Lager zur Verfügung gestellt wird – oder umgekehrt. Was nicht funktionieren kann, ist es, jedem Anrufer eine private Kopie der Umsatzdaten zu ermöglichen und anschließend überrascht zu sein, wenn sich die Zahlen unterscheiden.

Dashboards wurden zu einem von mehreren Anrufern

Einst waren Dashboards der einzige ernsthafte Nutzer, was heute nicht mehr der Fall ist. Früher ging man davon aus, dass ein semantisches Modell zu einem einzigen BI-Tool gehörte: Power BI-Modelle versorgten Power BI-Berichte, und LookML-Modelle versorgten Looks. Diese Struktur war sinnvoll, solange Menschen die einzige Zielgruppe und der Bericht das Endprodukt war.

Heute kann ein einziger Vertrag für Dashboards, Excel, operative Anwendungen, Copiloten, Chat-Funktionen, Agenten sowie eine Funktion zur Erstellung von Tickets bei Überschreitung eines Wertes genutzt werden. Dashboards bleiben nützlich, sind aber nicht länger das Hauptziel des Modells, da ein Diagramm lediglich einer der Anwender dieser Definitionen ist.

Das ist eine willkommene Veränderung. Diagramme veralten schnell, während die Definitionen von Umsatz, Marge, Auslastung und Kundenabwanderung langsam angepasst werden sollten. Wenn diese Definitionen richtig verwaltet werden, muss ein neuer Copilot im nächsten Quartal den gesamten Prozess nicht erneut starten, und ein Agent, der nach Anomalien sucht, kann die zugrunde liegenden Metriken für den wöchentlichen Bericht wiederverwenden. In dieser Wiederverwendung liegt der eigentliche Nutzen. Ein ansprechendes Dashboard, dessen Logik in einer rein visuellen Messgröße verborgen ist, führt zu nichts, da eine visuelle Darstellung nicht abgerufen werden kann.

Jede Bewertung führt zu einer Gegenargumentation: Wenn Modelle SQL schreiben können, warum dann weiterhin Finanzmittel bereitstellen, und warum es nicht dem Agenten überlassen? Der Agent kann das zunehmend selbst erledigen. Aus geschäftlicher Sicht führt diese Fähigkeit jedoch genau dazu, dass Probleme entstehen. Der Zugriff wurde billig, während die Abstimmung weiterhin teuer blieb. Zehn Mitarbeiter, die sich einen einzigen Dashboard ansehen, teilen eine Zahl – auch wenn sie falsch ist –, während zehn Agenten, die ein Lager betreten, zehn unterschiedliche „Wahrheiten“ erzeugen, jede mit derselben Zuversicht präsentiert.

Eine günstige Version des Experiments zeigt das deutlich. Man nimmt ein Lager, eine Frage sowie drei Agentenkonfigurationen ohne gemeinsame Metrik – das Ergebnis sind drei Umsatzwerte zusammen mit drei Erklärungen, warum jeweils dieser Wert der „richtige“ sei. Eine Konfiguration nutzte Buchungen, weil der Name einer Tabelle order enthielt. Eine andere zählte Kits doppelt, weil sie die Zeilenstruktur mit der Überschriftenstruktur verwechselte. Eine weitere kam der Finanzberechnung nahe, indem sie das Rechnungsdatum verwendete, berücksichtigte aber dennoch den Großhandel. Jede dieser Methoden, die in einem Thread eines VPs veröffentlicht worden wären, hätte dazu geführt, dass eine Woche damit verbracht wurde, über den Chatbot zu streiten statt über die Definition.

Günstiger Zugang ohne Vertrag ermöglicht es mehr Menschen – und nun auch mehr Agenten –, eigene „private Wahrheiten“ zu schaffen. Das erklärt, warum das Modellieren wichtiger wurde, anstatt weniger, genauso wie die SQL-Generierung immer besser wurde.

Ein einziger Stack reicht nicht aus

Die nächste Falle, auf die man achten muss, ist die semantische Schicht der Souvenirs: Zertifiziert in einem Tool und als Folklore in allen anderen. Ein Team könnte ein Jahr damit verbringen, ein hervorragendes Modell innerhalb des von allen präsentierten BI-Produkts zu entwickeln, und anschließend einen Agenten direkt mit dem Lager verbinden, mit der Begründung, das Lager sei die Quelle der Wahrheit. In Wirklichkeit hat sich die Ambiguität nur verlagert. Das Dashboard meldet den erfassten Umsatz, der Agent meldet net_amt, und die Finanzabteilung behält ihre Tabellenkalkulation. Die Organisation hat einen weiteren „Dialekt“ gewonnen – ohne zusätzliche Klarheit.

Die Überprüfung ist einfach: Wenn die Definition einer Metrik nicht vom Lager auf das BI-Tool und weiter auf den Agenten übertragen werden kann, wurde lediglich der Name geändert, und der Streit besteht weiterhin.

Portabilität erfordert keine vierte Plattform. Voraussetzung ist vielmehr, dass ein Aufrufer außerhalb der ursprünglichen Datei dieselbe Operation ausführen und dasselbe Ergebnis erhalten kann. Das Medium kann ein auf dem Lager spezifisches Metrikenobjekt sein, das von jedem Engine unterstützt wird, ein headless Metriken-Service oder ein streng reguliertes semantisches Modell, das über eine Abfrageschnittstelle oder einen MCP-Adapter erreichbar ist. Ein einfacher Test klärt die Sache: Editieren Sie die Definition einmal und prüfen Sie, ob alle Aufrufer diesem Vorgang folgen. Alles, was unverändert bleibt, ist eine Kopie.

On-Premises-Metriken erscheinen attraktiv, wenn die meisten Daten auf einer Plattform liegen – mit einem bekannten Nachteil. Die Definition ist dort zertifiziert, während Agenten, die auf einem anderen Lager oder einer Kopie arbeiten, sie niemals erreichen. Federierte Ansätze versuchen, eine einheitliche Bedeutung über verschiedene Engines hinweg aufrechtzuerhalten, doch sie versagen, sobald die sogenannte universelle Schicht zu einer weiteren Kopie mit besserem YAML wird.

Ein etwas hässliches, portables metrisches Modell ist besser als eines, das in einer Datei gefangen ist, die nur drei Entwickler kompilieren können – schließlich werden Agenten nicht auf diese Datei warten, sondern stattdessen andere Quellen abfragen.

Wie ein für Agenten geeignetes Modell aussieht

Die meisten übernommenen Modelle wurden für Personen entwickelt, die bereits über die internen Gerüchte im Unternehmen Bescheid wussten. Ein Entwickler versteht, warum eine Set-Analyse-Expression einen Kanal ausschließt; ein Agent, der nur das Ergebnis sieht, nicht. Eine DAX-Messgröße mit einem scherzhaften Namen dient als privater Code und erscheint einem Aufrufer, der sie verarbeiten will, als Unsinn. Eine echte Datei verwendete [NS Adj LY %], um Nettoverkäufe, bereinigt, vom Vorjahr, prozentualer Änderungsgrad, abzüglich Großhandel und abzüglich der von den Pop-up-Läden nicht bevorzugten Finanzaspekte zu bezeichnen. Drei Personen konnten dies entschlüsseln, der vierte Leser war ein Agent, der NS als Nettoverkäufe interpretierte und nicht weiterging.

Die Checkliste ist nichts Exotisches. Es handelt sich dabei um die traditionelle BI-Methodik – mit höheren Kosten für Nachlässigkeit:

Ehrliche Bezeichnungen. Nutzen Sie den Begriffsvorrat, den das Unternehmen bereits verwendet, sodass recognized_revenue vor NS_Adj bevorzugt wird. Wenn zwei Teams unterschiedliche Begriffe verwenden, wählen Sie einen im Modell aus und dokumentieren den anderen als Alias in der Beschreibung, anstatt den Streit durch eine Abkürzung zu verbergen.
Nutzungsbedingungen. Legen Sie fest, wo die Kennzahl anwendbar ist – beispielsweise eine Anmerkung, dass sie sich für Vorstandsvorlagen eignet, für Vergleiche derselben Filialen ungeeignet ist und den Großhandel ausschließt. Früher optional, trennt dieser Absatz nun eine klare Regelung von einer Vermutung.
Ausdrücklich deklarierte Beziehungen. Kunde, Rechnung und Abonnement sollten explizit miteinander verknüpft werden, damit der Mitarbeiter nicht auf der Suche nach einer Verbindungskette landet, nur weil zwei IDs beide cust_id heißen.

Eine kleine Oberfläche. Jede sichtbar gelassene technische Spalte ist eine Gelegenheit, Metriken wegzulassen. Verbergen Sie die Rohdaten, die die Anrufer nicht neu aggregieren dürfen. Das ist politisch schwierig, aber es lohnt sich, denn eine API, die jedes private Feld freigibt, ist keine echte API.

Einheiten und Versionen. Kennzeichnen Sie, welche Metriken offiziell sind und welche nur Experimente, wer sie ändert, und was „v3“ bedeutet, wenn der Brief des Vorstands vom letzten Quartal noch v2 verwendete.

Sicherheit, die mitübertragen wird. Ein Agent sollte niemals in der Lage sein, über Unionen auf eine größere Anzahl von Zeilen zuzugreifen, als eine Person im Standardbericht sieht. Wenn Zeilenregeln nur im BI-Service vorhanden sind, während der Agent direkt auf das Datenlager zugreift, führt das zu einem Umgehen der Regeln und nicht zu einer Unterstützung.

Betrachten Sie recognized_revenue bei einem Einzelhändler. Seine Formel lautet der auf der Rechnung ausgewiesene Betrag abzüglich Rabatte, umgerechnet aus der Transaktionswährung zum Bilanzkurs zum Rechnungsdatum. Entscheidend ist das Rechnungsdatum zusammen mit der Verkaufseinheit, nicht das Lieferziel. Ausgeschlossen sind Mitarbeiterläden, Großhandel, Testbestellungen sowie Unternehmensinterne Verkäufe. Die rechtlichen Dimensionen sind Verkaufseinheit, Produkthierarchie und Kanal gemäß der Bestellart, und die Marketing-Last-Click-Tabelle ist nicht zugänglich. Der Finanzcontroller ist für dieses Konto verantwortlich, und die gültige Version ist jene, die letzten Freitag dem Vorstand gemeldet wurde.

Nehmen wir an, ein Nutzer fragt nach „Verkäufe über Instagram“. Diese Dimension existiert in dieser Metrik nicht, daher ist die richtige Antwort eine Ablehnung oder eine Weiterleitung an eine andere vom Marketing verwaltete, zertifizierte Metrik. Ein „Scavenger“ würde die Tabelle mit den letzten Klicks nutzen und das Ergebnis als Erkenntnis kennzeichnen. Die Verknüpfung könnte sogar technisch gültig sein, beschreibt aber ein anderes Geschäftsmodell.

Eine Ablehnung ist besser als Schweigen, und Schweigen ist besser als eine private Definition. Teams mögen es nicht, Ablehnungen zu erstellen, weil die Demonstrationen dadurch schlechter aussehen, doch Demonstrationen, die fehlschlagen, spiegeln besser die Arbeitsweise eines echten Unternehmens wider.

Es sind hier keine Tricks mit KI-Modellen im Spiel. Die alten BI-Methoden, die damals Universen rechtfertigten und Datenmodelle steuerten, erledigen die ganze Arbeit. Nur der Nutzer hat sich geändert: Früher führte Nachlässigkeit zu einem fehlerhaften Dashboard, das jemand entdecken konnte, heute führt sie zu falschen Aktionen in Maschengeschwindigkeit.

Die Arbeit, die nicht verschwindet

Vorausgesetzt, das funktioniert, verringert sich der Teil der Ticket-Warteschlange tatsächlich. Eine Anfrage, eine Grafik nach Regionen aufzuteilen, kann von einem Mitarbeiter bearbeitet werden, wenn die Region eine gültige Dimension dieser Metrik ist. Eine Anfrage, den letzten Jahr einzufügen, ist eine Frage der Zeitanalyse, die entweder bereits zuvor modelliert wurde oder nie modelliert wurde.

Es wäre falsch, einem BI-Team zu sagen, seine Aufgabe sei verschwunden, nur weil die Arbeit an einen anderen Ort verlagert wurde. Jemand muss weiterhin entscheiden, was jede KPI bedeuten kann und welche Version als offiziell gilt. Jemand muss festlegen, welche Beziehungen richtig sind, welche Quellen Vertrauen verdienen und welche Ausnahmen gelten. Ebenso ist jemand dafür verantwortlich zu bestimmen, wer welche Zeilen sehen darf, welche Modelle als autoritativ gelten, wie Änderungen getestet werden und wie Abstammungsverhältnisse sowie Verantwortlichkeiten bei der Überprüfung sichtbar werden.

Die Arbeit daran macht weniger Spaß als die Erstellung eines ansprechenden visuellen Elements, und in den meisten Wochen ist es verlockender, einen Chart zu versenden. Dennoch liegt der langfristige Wert auf der langweiligeren Seite. Visuelle Elemente sind wegwerfbar, während eine Definition, die sowohl der Board-Mitarbeiter als auch der Agent über Nacht verwenden können, ein wertvolles Asset darstellt.

Man kann mit weniger Anfragen rechnen, die still und heimlich „Bitte seid eine GUI“ bedeuten, und mit mehr Konflikten, die still und heimlich „Bitte seid ein Gesetzgebungsorgan“ bedeuten. Diejenigen, die nur Charts erstellen wollten, könnten diesen Zeitraum als Degradierung empfinden. Diejenigen, die wollten, dass Zahlen bei Interaktion mit Software stabil bleiben, werden feststellen, dass die undankbare Arbeit zur Hauptaufgabe geworden ist.

Immer wieder auftretende Fehlermuster

Diese werden weiterhin als Probleme der Modellqualität gemeldet, und das Muster sollte überprüft werden, bevor jemand das Modell austauscht.

Der Spalten-Sammler. Der Agent greift das erste Feld mit rev im Namen. Keine Metrik wird aufgerufen, obwohl die Überwachung aussieht, als wäre sie aktiv.
Das private Korn. Jeder Aufrufer wählt seinen eigenen Zeitpunkt aus und ist überzeugt, dass er mit „letzten Monat“ richtig geantwortet hat.
Der Wiki-Vertrag. Die tatsächliche Regel steht auf einer Confluence-Seite, an der seit einer Umstrukturierung niemand mehr gearbeitet hat, und das Modell selbst enthält nur einen Spaltenkommentar mit dem Text „Verkäufe“.
Das Stack-Souvenir. Die einzige zertifizierte Metrik befindet sich in einer BI-Datei, und der Agent kommuniziert mit dem Lager, weil das der einfachste Demo-Weg war.

Der Sicherheitsumgehungsweg: Der Berichtsdienst setzt Zeilenfilter durch, doch der Agent läuft unter einem Service-Principal, das alles einsehen kann – sonst wäre die Demo nicht funktionsfähig. Ein Copilot lieferte einem Regionalmanager die nationalen Gesamtwerte, weil die Lagerrolle keine selling_org-Einschränkung enthielt. Das am Montag üblicherweise genutzte Dashboard hätte diese Abfrage abgelehnt. Der Agent schien leistungsfähiger zu sein, da er die einzige Kontrollmechanismus umgangen hatte.

Die „Copy Farm“: Drei „semantische Schichten“ befinden sich in drei verschiedenen Tools, die sich nicht übereinanderstimmen – jedes davon wird als Lösung für das vorherige dargestellt.

Falls zwei dieser Punkte Ihnen bekannt vorkommen, sollten Chatbot-Evaluierungen nicht der erste Schritt sein. Beginnen Sie damit, die Metrik zu benennen und ihre Granularität im Modell festzulegen, verlangen Sie anschließend, dass der Agent sie aufruft, und messen Sie erst danach.

Ein schneller Test für Bewertungen: Fordern Sie den Umsatz des letzten Monats an und prüfen Sie anschließend die Details. Welche Datumsspalte wurde ausgewählt? Welche Ausnahmen wurden berücksichtigt? Wurden Mitarbeiterkäufe mitgezählt? Ein Agent, der seine Antworten selbst erfinden muss, ist im Grunde ein SQL-Generator, der zufällig Zugriff hat.

Ein zweiter Test ändert die offizielle Ausnahmeliste – beispielsweise indem Mitarbeiterkäufe endlich aus dem anerkannten Umsatz entfernt werden – und prüft anschließend, wer am selben Tag etwas aktualisiert. Wenn sich das Dashboard ändert, der Agent jedoch unverändert bleibt, stellt sich heraus, dass die eigentliche API die manuell kompilierte Datei ist, und der Agent ist lediglich ein „Tourist“.

Achten Sie auch auf den „hilfsbereiten“ Agenten, der heimlich eine Verknüpfung hinzufügt, wenn die zertifizierte Metrik keine Dimension besitzt. In diesem Moment stirbt der Vertrag. Das richtige Vorgehen ist, mitzuteilen, dass die Dimension für diese Metrik nicht vorhanden ist. Produktmanager mögen diesen Satz nicht, aber er ist besser als ein Brief an den Vorstand, der zurückgezogen werden muss.

Fangen Sie nicht mit dem Chatbot an

Die meisten Programme beginnen mit den sichtbaren Werkzeugen: Welches Modell, welche Vektor-Datenbank, ob MCP verwendet werden soll, welche Copilot-Lizenzen gekauft werden müssen. Wenn das Ziel zuverlässige Antworten zu einem bestimmten Unternehmen sind, funktioniert ein direkterer Ausgangspunkt besser.

Wo wird der Umsatz in einer Formular-Software definiert? Welche Klassifizierung des Kunden gilt als autoritativ? Wo befindet sich derzeit die Logik zur Berechnung des Bruttogewinns: in einer SQL-Ansicht, einer DAX-Messgröße, einer Qlik-Expression, in einem Notizbuch oder im Gedächtnis einer Person? Eine Antwort wie „mehrere dieser Optionen“ bedeutet, dass das eigentliche Problem nicht in der Erstellung liegt. Die Schnittstelle, auf die die Software zugreifen soll, wurde nie erstellt.

Eine praktische Vorgehensweise sieht so aus:

Identifizieren Sie den Konflikt. Wählen Sie eine Kennzahl aus, über die bereits zwei Teams streiten, ohne dass eine umfangreiche Ontologie erforderlich ist.
Erstellen Sie den Vertrag: Formel, Granularität, Ausschlüsse, Verantwortliche sowie die zulässigen Dimensionen.
Bereitstellen Sie diese Informationen über einen einzigen, gesicherten Abfragemechanismus, den sowohl Berichte als auch Agenten nutzen können.
Fügen Sie einen Aufrufer hinzu, und erst an diesem Punkt setzen Sie einen Copiloten oder Agenten ein, der sich mit dieser Kennzahl beschäftigt.

Ohne einen Verweis auf die offizielle Einnahmenabrechnung bewirbt der Chatbot ein Semantikproblem, das noch niemand benannt hat.

Ein Team musste einmal vor dem nächsten Lenkungsausschuss einen Planungskopiloten bereitstellen, und in den ersten zwei Wochen wurde dieser absichtlich beiseitegelegt. Die Arbeit fand in available_to_promise statt, wobei die Regeln auf einer Seite festgehalten wurden. Ware im Qualitätskontrolllager sowie beschädigte Käfige wurden ausgeschlossen. Pack- und Lagermengen wurden nur für Großhandelsbestellungen berücksichtigt, und Waren auf dem Transport wurden erst dann gezählt, wenn die ASN eingegangen war. Diese Regeln wurden in das bereits vom Lager verwendet Modell aufgenommen, und bei Fragen zum Bestand durfte der Kopilot nur diese Kennzahl heranziehen. Die erste Demo verlief ruhiger. Bis zur zweiten Woche führte niemand mehr eine dritte Zahl im Standup-Meeting an, was ein Erfolg war, und der Anbieter des Modells blieb unverändert.

Dashboards bleiben bestehen. Ein gut gestaltetes Visuell vermittelt die wöchentlichen Entwicklungen besser als eine Chat-Blase. Sie sind einfach nicht mehr die einzige Informationsquelle – derselbe Kontext muss nun auch dann noch funktionieren, wenn er von einem Menschen, einem Bericht oder einem automatisierten Prozess aufgerufen wird, der nicht bemerkt, wenn eine Zahl falsch ist.

Die bereits vorhandene Schnittstelle

Die täglichen Besprechungen mit zwei offiziellen Zahlen erklären alles. Die Modelle waren in keiner interessanten Hinsicht verwirrt – die Organisation hingegen schon, und die Mitarbeiter übertrugen diese Verwirrung in Sätze, die wie Wissen klangen.

Sobald Software eine zertifizierte Beschreibung davon verwendet, wie das Unternehmen seine Daten betrachtet, sind Tabellen keine Schnittstelle mehr – stattdessen treten die benannten Metriken in den Vordergrund.

Eine Aufforderung an die Mitarbeiter, bei den Umsätzen vorsichtig zu sein, verblasst schnell. Was bleibt, ist ein Modell, das es nicht zulässt, Umsätze ad hoc neu zu ermitteln.

Was auch immer veröffentlicht wird, ist das, was der Agent verwenden wird. Wenn rohe Tabellen freigegeben werden, entsteht daraus ein Geschäftsmodell; wenn eine benannte Operation freigegeben wird, kann der Agent schließlich die wählen, die die Analysten bereits festgelegt haben.

Die auffälligen Hilfsmittel haben weiterhin ihren Reiz: ein Copilot, der um 6 Uhr morgens nach Anomalien sucht, oder ein Agent, der ein Ticket erstellt, wenn die verfügbare Zeit unter einen bestimmten Wert fällt. Diese bleiben nur ehrlich, solange es sich um die gleichen Operationen handelt, auf die sich die Menschen bereits geeinigt haben.

Beginnen Sie mit dem Metrik, über das bereits Streitigkeiten entstehen, und formulieren Sie dazu die vier relevanten Fragen. Richten Sie ein Dashboard sowie einen Agent auf dieses Objekt aus und lassen Sie den Rest unberührt, bis sich die beiden Hilfsmittel einen Monat lang einigen. Erweitern Sie das Katalog anschließend.