Zum Hauptinhalt springen

Talk · data2day 2026

Agentic Analytics: From Hype to Real Value

Fabian Biberger (Founding Engineer, Entropy Data) ·

Fabian Bibergers Talk auf der data2day 2026 in Köln, gehalten auf Deutsch als Agentic Analytics: Wie aus Hype echter Mehrwert wird. Er zeichnet den Weg von Entropy Data nach: von einem MCP-Server zu einem Chatbot mit Governance, welchen Kontext ein Agent braucht, um verlässlich auf Daten zu arbeiten, und Apache Ossie für Ontologien und Semantic Models.

Titelfolie: Agentic Analytics, Wie aus Hype echter Mehrwert wird, Fabian Biberger, data2day, 07.10.2026, daneben ein Screenshot des Entropy-Data-Chatbots, der das Datenprodukt Orders empfiehlt

Eine redigierte Zusammenfassung des Talks.

TL;DR

Die fünf wichtigsten Punkte und Learnings aus dem Talk.

  1. Governance entscheidet über die Nutzung. Der MCP-Server beeindruckte, war für Kunden aber nicht nutzbar: Er führte Daten auf einem persönlichen Rechner außerhalb der Governance zusammen, und viele Unternehmen hatten keinen freigegebenen Chat-Client. Die Lehre: Hol den Agenten in den kontrollierten Marktplatz, deshalb hat Entropy Data einen eigenen Chatbot gebaut.

  2. Kläre, unter wessen Identität die Query läuft. Mit einem einzigen Service Account sieht Databricks nur einen User, und das Audit-Log zeigt nicht mehr, wer worauf zugegriffen hat. Wird jede Identität über OIDC weitergegeben, prüft die Plattform wieder jeden Zugriff einzeln.

  3. Kontext macht Agenten verlässlich. Der Talk nennt sieben Faktoren: Daten in Silver-Qualität, ein dokumentiertes Datenmodell, Unternehmensstruktur, Lineage, Beispieldaten, Semantic Models und Ontologien. Fang mit den Basics an und setz die Boosts obendrauf.

  4. Semantik schließt die Lücke. Data Contracts, Contract-Tests, Lineage und Teams decken bereits fünf Faktoren ab, Semantic Models und Ontologien waren noch offen. Apache Ossie verankert die Ontologie in den Semantic Models, und mit dieser Verknüpfung baut der Agent bessere Queries.

  5. Agenten brauchen Identität und Purpose. Autonome Agenten handeln entweder im Namen eines Users oder als Service mit eigener Identität. Als Nächstes kommt Purpose-based Access: Der angegebene Purpose wird gegen die Nutzungsbedingungen im Data Contract und die Semantik geprüft.

Ausgangspunkt, was wir bei Entropy Data machen: ein Marktplatz für Datenprodukte (Data Contracts, Multi-Platform, Self-Service), offene Metadaten-Standards (portable Metadaten, Metadaten-Sync nach Git, Open-Source-Tooling, ODCS, ODPS, Apache Ossie) und Automatisierung (automatisierte Contract-Tests, Data Quality Scoring, KI-gestützte Governance, Data Contract CLI)

Wo Entropy Data startet

  • Marktplatz für Datenprodukte mit Data Contracts, Multi-Platform und Self-Service.
  • Offene Standards: ODCS, ODPS und Apache Ossie.
  • Automatisierung: Contract-Tests mit der Data Contract CLI, Data Quality Scoring, KI-gestützte Governance.
Motivation: 01 die Suche im Datenmarktplatz verbessern, 02 analytische KI mit Governance ermöglichen, 03 einen Spielplatz für neue Datenprodukte schaffen, 04 agentengestützte Entwicklung von Datenprodukten ermöglichen

Vier Gründe für den agentischen Weg

  1. Bessere Suche im Datenmarktplatz.
  2. Analytische KI mit Governance.
  3. Ein Spielplatz für neue Datenprodukte.
  4. Agentengestützte Entwicklung von Datenprodukten.
MCP: Ein KI-Client mit einer Frage oder einem Agenten-Task ruft Entropy Data auf, das MCP-Tools wie Search, Fetch und Execute Query hinter einer Data-Governance-Schicht anbietet, verbunden mit dem Marktplatz (Metadaten der Datenprodukte) und der Datenplattform (die eigentlichen Daten). Verschiedene Tools, mit Unterstützung für Governance-Checks und Access Requests

Schritt eins: ein MCP-Server

  • KI-Clients wie Claude oder ChatGPT verbinden sich über MCP mit dem Marktplatz.
  • Tools: Datenprodukte suchen, Data Contracts abrufen, Queries ausführen.
  • Governance-Checks und Access Requests liegen dazwischen.
Sprechblase über einem unscharfen Chat-Screenshot: Wow, das sieht super aus. Aber nutzen werden wir das nie.

„Wow, das sieht super aus. Aber nutzen werden wir das nie.“

  • Governance: MCP führt Daten auf einem persönlichen Rechner zusammen, außerhalb der Governance.
  • Verfügbarkeit: Viele Unternehmen haben keinen freigegebenen Chat-Client, oder nur Copilot.
  • Entscheidung: einen eigenen Chatbot bauen.
Wir bauen einen Chatbot: Der Entropy-Intelligence-Chat im Entropy-Data-Marktplatz beantwortet, welches Datenprodukt für das Kaufverhalten der Kunden passt, und empfiehlt Orders. Eine Seitenleiste zeigt Fortschritt, Purpose, Governance, Datenprodukt, Semantik, Datenmodell, Verbindung und SQL

Also haben wir einen Chatbot gebaut

  • Entropy Intelligence sitzt im Marktplatz, unter der bestehenden Governance.
  • Der System-Prompt lässt sich auf die Use Cases von Entropy Data zuschneiden.
  • MCP-Tools sind direkt eingebaut, und die Governance lässt sich nicht umgehen.
User Interface, Kontrolle über das Interface: eine Seitenleiste mit dem Datenprodukt Customers und seinen vier Output Ports mit Contracts sowie zwölf semantischen Konzepten wie Order, Order ID, Customer ID, Customer Email und Billing Address
Der Chatbot antwortet auf ‚gib mir Zugriff auf Customers‘: Er empfiehlt den Databricks-Port ohne PII auf Basis der AI Instructions des Data Product Owners, weist darauf hin, dass der User noch keinen Zugriff hat, und zeigt einen Request-Access-Button mit dem Hinweis, dass der Zugriff freigegeben wurde

„Neue Features lassen sich einfach kommunizieren“: Wer das Interface kontrolliert, kann neue Features leicht vermitteln.

User Interface

  • Bessere Nachvollziehbarkeit durch die Kontext-Sidebar: Datenprodukt, Output Ports, semantische Konzepte und Purpose auf einen Blick.
  • Neue Features direkt integriert, zum Beispiel ein Request-Access-Button mitten im Gespräch.
  • Wiederverwendete Interface-Elemente wie die Chips und Icons aus dem Marktplatz helfen Usern bei der Orientierung.
Verbindung zur Datenplattform, ein Account pro Organisation: JD (Marketing), Turk (Controlling), Elliot (Sales) und Carla (Data Engineering) laufen alle über Entropy Data und einen einzigen Service Account entropy-data zu Databricks, das nur einen User sieht. Das Audit-Log zeigt entropy-data SELECT orders, customers, revenue

Wer fragt die Daten eigentlich ab?

  • Ein Service Account für die ganze Organisation.
  • Databricks sieht nur einen User: entropy-data.
  • Das Audit-Log zeigt nicht mehr, wer worauf zugegriffen hat.
Ein Account pro User mit OIDC: Die gleichen vier User laufen über Entropy Data, das ihre Identität von einem Identity Provider wie Entra ID bezieht, und jeder User verbindet sich mit eigenen Credentials zu Databricks. Databricks sieht und prüft jeden User einzeln. Das Audit-Log zeigt jd, turk, elliot und carla
  • OIDC: Der Identity Provider, zum Beispiel Entra ID, gibt jede Identität an die Plattform weiter.
  • Databricks prüft jeden Zugriff einzeln, und das Audit-Log ist wieder aussagekräftig.
  • Prinzip: Entscheide zuerst, unter wessen Identität der Datenzugriff läuft.
Der richtige Kontext: Was braucht ein Agent, um erfolgreich auf Daten zu arbeiten?
Der richtige Kontext: Sieben Faktoren speisen die Leistung von KI-Analytics (Verlässlichkeit, Qualität, Konsistenz): Ontologien, Semantic Models (Metriken und Dimensionen), dokumentiertes Datenmodell, Unternehmensstruktur, Lineage, Beispieldaten und Daten mindestens in Silver-Qualität

Der richtige Kontext: sieben Faktoren

  • Basics: Daten mindestens in Silver-Qualität und ein dokumentiertes Datenmodell.
  • Boosts: Unternehmensstruktur, Lineage und Beispieldaten.
  • Semantik: Semantic Models (Metriken, Dimensionen) und Ontologien (gemeinsame Konzepte).
Die gleichen sieben Faktoren, jetzt mit den Standards und Tools, die sie abdecken: ODCS für das dokumentierte Datenmodell, die Data Contract CLI für Silver-Qualität, OpenLineage für Lineage, Entropy Data für Unternehmensstruktur und Beispieldaten. Ontologien und Semantic Models sind mit Fragezeichen markiert

Fünf abgedeckt, zwei offen

  • Datenmodell und Silver-Qualität: abgedeckt durch Data Contracts und Contract-Tests.
  • Lineage über Verknüpfungen von Datenprodukten und OpenLineage, Beispieldaten teils in den Data Contracts, Unternehmensstruktur als Teams und Domains.
  • Noch offen: Semantic Models und Ontologien.
Der richtige Kontext: Wie stellen wir Ontologien und Semantic Models für Agenten dar?
Apache Ossie (incubating), der universelle Standard für semantische Daten: eine branchenweite Spezifikationsinitiative, die vereinheitlicht, wie semantische Metadaten zwischen Analytics-, KI- und BI-Plattformen ausgetauscht werden, früher bekannt als Open Semantic Interchange. 100 % herstellerneutral, YAML-Konfiguration, Apache 2.0, AI ready

Apache Ossie

  • Früher Open Semantic Interchange (OSI), heute Apache Ossie.
  • Ein Apache-Projekt im Incubator für Semantic Models und Ontologien.
  • Entropy Data unterstützt es als Format für Semantik.
Ontologie und Semantic Model: Die Ontologie deckt Business-Konzepte, Beziehungen und Regeln ab, das Semantic Model Dimensionen, Metriken und Aggregationen
Ontologie, Konzepte und Beziehungen: ein Graph mit Order, Line Item, Article, Product, Shipment, Shipping Address, Billing Address, Postal Address und B2B Customer, verbunden durch Beziehungen wie places, contains, ships_to, bills_to, fulfilled_by, references, has_variant, is a und subsidiary_of

Ontologie und Semantic Model

  • Ontologie: Konzepte wie Order, mit Eigenschaften.
  • Beziehungen tragen Bedeutung: Eine Order ships to eine Lieferadresse.
  • Mehr Bedeutung heißt mehr Kontext für den Agenten.
Semantic Models, Metriken, Dimensionen, Aggregationen: Semantic Models aus dbt, Power BI, Tableau, Looker und anderen Quellen speisen ein Semantic Model
  • Semantic Model: Metriken, Dimensionen und Aggregationen über den Daten.
  • Bekannt aus dbt MetricFlow, Power BI, Tableau und Looker.
  • Rechenlogik, etwa der Bestellwert, ist an einer Stelle definiert.
Ontologie-Mapping: Business-Konzepte werden durch ein Mapping von der Ontologie zum Semantic Model im Semantik-Layer verankert
  • Ossie verankert die Ontologie in den Semantic Models.
  • Eine Mapping-Ebene verknüpft jedes Konzept mit seinem Vorkommen.
  • Mit dieser Verknüpfung baut der Agent bessere Queries.
Der richtige Kontext, vollständig: Alle sieben Faktoren sind jetzt abgedeckt, mit Apache Ossie für Ontologien und Semantic Models

Wo du anfängst

  • Fang mit den Basics an: einem dokumentierten Datenmodell und Daten in Silver-Qualität.
  • Unternehmensstruktur, Lineage und Beispieldaten kommen als Boost obendrauf.
  • Semantic Models und Ontologien bringen bessere Ergebnisse und mehr Nachvollziehbarkeit.
Identität von Agenten: On behalf of the user, die Identität kommt aus dem Kontext des Users und der Agent handelt in seinem Namen. Agent as a service: Der Agent bekommt eine eigene Identität, und es braucht zusätzliche Metadaten

Die Agenten kommen

  • Autonome Agenten brauchen auch eine Identität.
  • On behalf of the user: Die Identität kommt vom User, wie heute im Chatbot.
  • Agent as a service: eine eigene Identität, plus Metadaten wie den Betreiber.
Ausblick, Purpose-based Access: Ein Analyst oder Agent fragt Zugriff an. Purpose-based Access Control fragt: warum, zu welchem Zweck? Der Agent nennt als Purpose Direktmarketing. PBAC vergleicht den genannten Purpose mit den Nutzungsbedingungen im Data Contract und der Semantik und gibt erst dann Zugriff auf die Daten

Ausblick: Purpose-based Access

  • Analysten und Agenten müssen angeben, wozu sie die Daten brauchen.
  • Der Purpose wird gegen die Nutzungsbedingungen im Data Contract und die Semantik geprüft.
  • Eine Idee aus der Q&A: Zugriff zeitlich begrenzen, etwa auf die Session des Agenten.
Danke! Fragen? Komm an unseren Stand, wir zeigen dir alles gerne live. Schreib an fabian.biberger@entropy-data.com. Probier Entropy Intelligence aus: Starte die 1-Click-Demo auf www.entropy-data.com

Probier es selbst aus

Verwandte Artikel

A Data Marketplace is What Your Agent Needs

Warum KI-Agenten einen Datenmarktplatz brauchen, um Daten über kontrollierte Tools zu lesen und neue Datenprodukte zu bauen, mit zwei Live-Demos.

Was ist Apache Ossie?

Der offene Standard für Ontologien und Semantic Models, früher bekannt als Open Semantic Interchange.

Was ist Purpose-based Access Control?

KI-Agenten entscheiden zur Laufzeit, welche Daten sie brauchen. Purpose-based Access Control prüft jede Query gegen die Nutzungsbedingungen im Data Contract.