Kategorie: Erklärer

Drei Kollegen fragst du nach dem Umsatz des letzten Quartals. Einer schaut in eine Excel-Tabelle, ein anderer öffnet ein Dashboard, der dritte nutzt einen Chat-Bot. Du bekommst drei verschiedene Zahlen. Jeder hat eine andere Definition verwendet – vielleicht hat einer die Rabatte abgezogen, ein anderer nicht, einer hat nur bestimmte Regionen einbezogen. Dieses Szenario ist kein Einzelfall, es ist Alltag in vielen datengetriebenen Unternehmen. Sobald Menschen oder Tools unterschiedliche Verständnisse von „Umsatz“ haben, entsteht Chaos. Cube packt das Problem an der Wurzel: mit einer semantischen Schicht, die als gemeinsame Sprachbasis für alle Datenabfragen dient.

Die Grundidee ist einfach: Bevor du eine Frage an deine Daten stellst, legst du fest, was die Begriffe bedeuten. Cube nennt das ein semantisches Modell. Es funktioniert wie ein gemeinsames Wörterbuch: „Umsatz“ ist definiert als Nettoumsatz ohne Steuern und Rabatte, berechnet aus der Tabelle „orders“. Sobald dieses Modell steht, kann jedes Tool – Dashboard, Chat-Bot, Workbook oder eine externe KI wie ChatGPT – darauf zugreifen. Die Antworten sind identisch, weil sie auf derselben Definition beruhen. Das ist der Kern von Cube: eine einzige semantische Grundlage für jede Analyseoberfläche.

Warum eine semantische Schicht heute unverzichtbar ist

Wir leben in einer Welt, in der große Sprachmodelle wie ChatGPT oder Claude verbreitet sind. Sie verstehen Fragen in natürlicher Sprache und generieren daraus komplexe Datenabfragen. Aber sie kennen die firmenspezifischen Definitionen nicht. Sagst du einem LLM „Zeig mir den Umsatz der letzten Woche“, schätzt es, welche Spalten und Tabellen gemeint sind. Das Ergebnis ist oft ungenau oder falsch. Cube löst das, indem es dem LLM die semantische Schicht als Karte mitgibt. Der Chat-Bot bekommt nicht die rohen Datenbanken, sondern das bereinigte Modell. So wird aus einem Ratespiel eine präzise Abfrage. Das ist der Unterschied zwischen „Ich verstehe die Frage nicht“ und „Hier ist die korrekte Antwort mit Chart und Erklärung“.

Der Nutzen ist Konsistenz. Wenn dein Dashboard, dein Analyst und dein KI-Assistent dieselbe Frage stellen, bekommen sie dieselbe Antwort. Das schafft Vertrauen in die Daten. Und es reduziert den Aufwand. Statt für jede Abfrage eine eigene SQL-Query zu schreiben oder Definitionen in verschiedenen Tools zu pflegen, definierst du alles einmal im semantischen Modell. Cube nennt das „Governance flows from your model through to your customers‘ permissions“. Die Zugriffsrechte und Berechnungslogiken werden aus dem Modell direkt in die Analyseoberfläche durchgereicht – egal ob der Kunde ein internes Dashboard oder eine eingebettete Analytics-Funktion in einer SaaS-Anwendung nutzt.

Cube in der Praxis: Embedded Analytics und Multi-Tenancy

Ein Einsatzgebiet ist die eingebettete Analytik. Unternehmen wie Brex, Webflow oder Intuit binden Cube in ihre eigenen Produkte ein, sodass deren Kunden Analysen sehen können. Cube ist von Grund auf multi-tenant-fähig: Jeder Kunde bekommt nur die Daten und Definitionen, die für ihn freigegeben sind. Die semantische Schicht stellt sicher, dass die Berechnungen für alle Mieter korrekt sind, aber die Ergebnisse getrennt bleiben. Das ist für SaaS-Anbieter wertvoll – sie müssen sich nicht um die Governance jedes einzelnen Kunden kümmern, Cube erledigt das automatisch.

Brex hat sich bewusst für Cube entschieden – und gegen Alternativen wie dbt Semantic Layer oder LookML. Der Grund: Cube bietet eine native KI-Schnittstelle, die direkt auf dem semantischen Modell aufsetzt. Die LLMs werden so zu zuverlässigen Assistenten, die nicht nur Daten abrufen, sondern auch Zusammenhänge erklären können. Drata, ein Compliance-Unternehmen, berichtet, dass Cube zur „Single Source of Truth“ für Metrikdefinitionen geworden ist – CSMs sparen dadurch Dutzende von Stunden pro Quartal, die sie sonst für manuelle Datenaufbereitung aufgewendet hätten. Webflow lobt die Integration mit ClickHouse als Datenbank: Cube abstrahiert die Datenbankkomplexität, sodass Teams auf die Daten zugreifen können, ohne SQL-Schreibkenntnisse zu besitzen. Alcon hebt hervor, dass Cube die Anzahl der benötigten Queries deutlich reduziert – eine einzige Definition ersetzt 20 verschiedene Abfragen für dieselbe Metrik.

Die Analogie: Cube wie eine Stadtkarte für deine Daten

Denken Sie sich Ihr Unternehmen als eine große Stadt. Es gibt viele Stadtteile (Teams, Abteilungen), jeder mit eigenen Straßennamen und Adressen (Datenquellen und Tabellen). Fragt jemand nach dem Weg zum Hauptbahnhof („Wie hoch ist der Nettogewinn?“), bekommt er je nach Stadtteil eine andere Route. Cube ist die zentrale Karte, die eindeutige Straßennamen definiert. Egal, ob du im Norden oder Süden bist – du weißt, wo der Hauptbahnhof liegt. Du erhältst dieselbe Beschreibung. So wird aus einer chaotischen Ansammlung von Daten eine geordnete, verständliche Landschaft, in der sich jeder zurechtfindet – Mensch und Maschine gleichermaßen.

Cube bietet verschiedene Oberflächen, um auf diese Karte zuzugreifen. Der Analytics Chat arbeitet mit natürlicher Sprache: Du tippst eine Frage auf Deutsch, Cube übersetzt sie über die semantische Schicht in eine präzise Abfrage und zeigt das Ergebnis. Es gibt vorgefertigte iframes für Dashboards und Chats, die du schnell in deine App einbetten kannst. Der Creator Mode erlaubt es Nutzern, eigene Workbooks und Dashboards zu bauen – immer basierend auf dem zentralen Modell. Für Entwickler gibt es die Core Data APIs, die umfassende Kontrolle auf Datenebene bieten. Cube passt sich an deine Branding-Vorgaben an – deine Farben, dein Logo, dein Agentenname –, sodass die Analyseoberfläche als nahtloser Teil deiner Anwendung wirkt.

Warum Cube für die Zukunft der Datenanalyse relevant ist

Der Trend geht zu mehr KI in der Datenanalyse. KI ist nur so gut wie die Daten, die sie bekommt. Cube liefert die notwendige Struktur, damit LLMs nicht nur raten, sondern fundierte Antworten geben. Die semantische Schicht wird zum wichtigen Differenzierungsmerkmal: Wer sie hat, kann KI vertrauen; wer sie nicht hat, hat es mit inkonsistenten Ergebnissen und aufwändigen manuellen Korrekturen zu tun. Cube ist die Plattform, die diesen Schritt ermöglicht – nicht nur für große Konzerne, sondern auch für wachsende SaaS-Unternehmen, die ihren Kunden professionelle Analysefunktionen anbieten wollen.

Was bedeutet das konkret für dich? Wenn du Datenanalyse betreibst oder eine Anwendung entwickelst, die Daten auswertet, solltest du über eine semantische Schicht nachdenken. Cube zeigt, dass es möglich ist, eine einheitliche Definitionsbasis zu schaffen, die klassische BI-Tools und moderne KI-Assistenten bedient. Die Zukunft der Berichterstattung liegt nicht in statischen Charts, sondern in dynamischen, kontextbezogenen Einsichten – Cube liefert das Fundament dafür. Ob du intern deine Teams mit konsistenten Dashboards versorgst oder extern deinen Kunden eine vertrauenswürdige analytische Erfahrung bieten möchtest: Die semantische Schicht ist entscheidend. Cube hat das verstanden und setzt es um – ohne Hype, mit solidem Engineering und einem klaren Fokus auf Governance und Skalierbarkeit.

Quelle: cube.dev

Sie arbeiten in einem Unternehmen und nutzen einen KI-Assistenten mit Zugriff auf alle internen Dokumente. Sie fragen nach Kundenabwanderung. Der Assistent gibt eine kluge Antwort – Zahlen, Zusammenhänge, eine flüssige Erklärung. Doch wenn Sie nach der Quelle fragen, wird es vage. Der Assistent zitiert Passagen, aber gehören sie wirklich zusammen? Stammen sie aus demselben Bericht oder aus verschiedenen Kontexten? Dieses Gefühl der Unsicherheit ist kein Zufall. Viele Unternehmen erleben das mit KI-Agenten: plausible Antworten, aber keinen verlässlichen, nachvollziehbaren Kontext. Genau hier setzt eine Überlegung an, die über typische RAG-Ansätze hinausgeht.

Wenn der Agent Fakten vermischt

Amarnath Byakod beschreibt in seinem Artikel „Context Engineering and Knowledge Cataloging for AI Agents“ ein Experiment. Sein Team ließ einen Agenten aus klinischen Dokumenten Informationen abrufen. Das System fand semantisch ähnliche Textstellen und setzte sie zu einer Antwort zusammen. Auf den ersten Blick sah alles gut aus. Bei genauerer Prüfung zeigte sich: Der Agent hatte Daten von verschiedenen Patienten zu einem einzigen, erfundenen klinischen Profil vermischt. Die Antwort war sprachlich korrekt, aber fachlich falsch. Byakod zieht eine klare Schlussfolgerung: „Das ist kein Retrieval-Problem. Es ist ein Knowledge-Catalog-Problem.“ Es bringt wenig, wenn ein Agent beliebige Textfragmente findet, solange er nicht versteht, was sie bedeuten, wie sie zusammenhängen und ob sie gemeinsam verwendet werden dürfen.

Dieses Problem betrifft nicht nur die Medizin. Es ist relevant, wo immer Unternehmen KI-Agenten zur Entscheidungsunterstützung einsetzen: Finanzanalyse, Kundenbetreuung, Supply-Chain-Planung. Die meisten Initiativen beginnen mit dem Zugang. Teams verbinden den Agenten mit SharePoint, Confluence, Datenbanken oder APIs. Sie fügen Embeddings und Retrieval hinzu und testen, ob der Agent Fragen beantworten kann. Oft entsteht der Eindruck, der Agent verstehe das Unternehmen. In Wirklichkeit sind Zugang und Verständnis zwei verschiedene Dinge. Ein Agent muss wissen, welche Informationen zusammengehören, welche Quelle eine Tatsache belegt, welches Datenprodukt einen Geschäftsfall unterstützt und welche Begriffe eine vereinbarte Bedeutung haben. Auch Qualitätserwartungen, Service-Level, Zugriffsmethoden und Governance-Einschränkungen sind nötig. Das geht über reines Retrieval hinaus. Es betrifft die Struktur und den Kontext von Datenprodukten.

Stellen Sie sich vor, Sie suchen in einer Bibliothek nach Informationen zum Thema „Kundenbindung“. Ein klassischer Retrieval-Ansatz wäre ein Bibliothekar, der Ihnen die relevantesten Seiten aus verschiedenen Büchern bringt – ohne zu sagen, ob sie aus demselben Buch stammen, ob sie aktuell sind oder wer sie geschrieben hat. Sie erhalten viele Fragmente, aber keinen roten Faden. Was Sie brauchen, ist ein kuratiertes Dossier: genau die Informationen, die für Ihre Fragestellung relevant sind, mit klarer Herkunft, Zusammenhängen zwischen den Fakten und Hinweisen, unter welchen Bedingungen Sie sie verwenden dürfen. Genau das meint Byakod mit „Knowledge Cataloging“. Es geht nicht darum, mehr Daten abzurufen, sondern den richtigen Kontext zu kompilieren.

Ein Wissensmodell, viele Repräsentationen

Byakod schlägt eine Architektur vor, in der ein einziger Extraktionsprozess mehrere parallele Repräsentationen desselben Wissens erzeugt. Ein Graph unterstützt die Navigation über Beziehungen. Ein kompilierter Markdown-Wiki gibt dem Sprachmodell dichten, verbundenen Kontext. Ein portables Open-Knowledge-Format-Bündel ermöglicht lokale oder Offline-Nutzung. Eine Query-Engine wählt dann die Repräsentation aus, die am besten zur Frage passt. Dieses Prinzip lässt sich direkt auf Datenprodukte übertragen. Ein Datenprodukt – eine bereitgestellte, qualitätsgesicherte Dateneinheit für einen bestimmten Zweck – kann verschiedene Ansichten haben: eine grafische für das Portfoliomanagement, eine maschinenlesbare für die Plattform, eine vertragliche für die Governance und eine komprimierte für den Agenten. Wichtig ist nicht, alle Konsumenten in ein Format zu zwingen. Wichtig ist, ein einziges, gemanagtes Modell zu pflegen und dann die Repräsentation zu kompilieren, die jeder Anwendungsfall benötigt.

Eine der stärksten Empfehlungen in Byakods Artikel lautet: „Kompiliere Kontext, retriev ihn nicht nur.“ Dieses Prinzip sollte direkten Einfluss darauf haben, wie Agenten Datenprodukte konsumieren. Ein Agent, der das Kundenbindungsrisiko bewerten soll, sollte nicht den gesamten Unternehmenskatalog oder fünfzig Fragmente erhalten, die zufällig „Kundenabwanderung“ erwähnen. Er sollte ein vorbereitetes Kontextpaket bekommen: genau die Produkte, Definitionen, Beziehungen und Betriebsbedingungen, die für diese Aufgabe relevant sind. Dieses Paket könnte das Geschäftsziel, die Kennzahl, den genehmigten Anwendungsfall, die unterstützenden Produkte, die erforderlichen Qualitätsbedingungen, die verfügbaren Zugangsdienste und das im Unternehmen verwendete Vokabular umfassen. Auch Produktabhängigkeiten, Quellennachweise, erlaubte Zwecke und die aktuelle Produktversion sollten enthalten sein.

Maysano Studio als Kontext-Compiler

In der Praxis setzt Maysano Portfolio Studio dieses Modell bereits um. Das Studio beginnt mit Quelldokumenten – Strategieberichten, Präsentationen oder Tabellen – und extrahiert daraus Geschäftsziele, Signale, Anwendungsfälle und Datenproduktbedarfe. Diese werden in einem verbundenen Portfoliomodell organisiert. Die Quelldokumente bleiben am Portfolio haften, sodass der ursprüngliche Beleg stets in der Nähe des daraus erstellten Kontexts liegt. Das ist ein entscheidender Unterschied zu einem typischen Retrieval-Setup. Das System behandelt Quelldateien nicht als lose Sammlung von Textfragmenten, sondern wandelt sie in explizite Geschäftsobjekte um. Ein Ziel wird zu einem definierten Knoten. Ein Signal wird zu einem definierten Knoten. Ein Anwendungsfall wird zu einem definierten Knoten. Ein Datenprodukt wird zu einem definierten Knoten. Diese Objekte sind nicht isoliert gespeichert. Ihre Beziehungen erscheinen in einem Graphen, der zeigt, wie Geschäftsabsicht, Belege, Anwendungsfälle und Produktbedarfe miteinander verbunden sind. Jeder Knoten hat auch eine strukturierte YAML-Repräsentation. Dadurch hat dasselbe Portfolio mehrere nützliche Formen gleichzeitig. Geschäftsanwender sehen ein reichhaltiges, verständliches Portfolio. Der Graph offenbart die Beziehungen. Das YAML gibt Plattformen, Entwicklern und Agenten eine maschinenlesbare Definition. Das Quelldokument, das Geschäftsobjekt, die Graphbeziehung und der YAML-Knoten – sie alle beschreiben denselben zugrunde liegenden Kontext aus unterschiedlichen Perspektiven.

Das Studio fungiert als Business-Context-Compiler für Datenprodukte. Es bereitet den Kontext vor, bevor ein Agent ihn benötigt. Die Quelldokumente erklären, woher das Wissen stammt. Die Portfolio-Objekte erklären, was dieses Wissen bedeutet. Der Graph erklärt, wie die Objekte zusammenhängen. Das YAML bietet die Struktur, die Software und KI-Agenten benötigen. Das Data Product SDK kann diesen Kontext dann validieren, verpacken, traversieren, transformieren und über Schnittstellen wie ODPC, ODPG, ODPS, Sidecars, Workflows und Agenten-Interfaces verfügbar machen. Zusammen bilden Studio und SDK zwei Schichten desselben Systems: Das Studio ist die Business-Entwicklungs- und Portfolio-Bildungsschicht; das SDK ist die technische und operative Schicht, die dieses Modell in spezifikationskonforme, portierbare Kontextpakete für Agenten verwandelt.

Herkunft und drei Wissensebenen

Ein weiterer wichtiger Punkt ist die Herkunft der Informationen. Byakod stellt die Provenienz ins Zentrum der Architektur. Extrahierte Entitäten verweisen auf exakte Stellen im Quellmaterial. Das System überprüft diese Verweise unabhängig, anstatt der Ausgabe des Sprachmodells zu vertrauen. Dieses Prinzip ist auch für die Generierung von Datenproduktdefinitionen aus Geschäftsdokumenten entscheidend. Wenn das System ein Geschäftsziel, einen Produktbedarf, eine Kennzahl, einen Konsumenten, eine Einschränkung oder eine Beziehung extrahiert, sollte es den Beleg hinter dieser Extraktion bewahren. Eine Aussage wie „Das Kundenrisikoprodukt unterstützt das Ziel der Abwanderungsreduzierung“ sollte auf die Seite, die Folie, die Tabellenzelle oder den Textabschnitt verweisen, der diese Aussage stützt. Maysano Portfolio Studio hält die Quelldokumente bereits am Portfolio fest. Der nächste Schritt ist, diese Beziehung auf Knotenebene zu vertiefen: Jedes Ziel, jedes Signal, jeder Anwendungsfall und jedes Produkt sollte direkte Verweise auf den exakten Quellennachweis enthalten, aus dem es erstellt wurde.

Das System sollte außerdem drei Informationsebenen trennen. Die erste Ebene ist der Quellennachweis – also das, was das Originaldokument aussagt. Die zweite Ebene ist die maschinelle Interpretation – also das, was der Extraktionsprozess aus diesem Nachweis abgeleitet hat. Die dritte Ebene ist das genehmigte Portfoliowissen – also das, was ein Mensch in das aktive Modell übernommen hat. Diese Trennung verhindert, dass generierte Spezifikationen von ihrem Quellmaterial losgelöst werden. Ohne sie sehen Prüfer eine polierte Produktbeschreibung, können aber nicht feststellen, welche Teile direkt aus Belegen stammen, welche aus Interpretationen und welche während der Prüfung hinzugefügt wurden. Quellengestützte Generierung würde Portfolioentscheidungen leichter erklärbar, anfechtbar und prüfbar machen.

Schema-Validierung allein reicht nicht. Das Data Product SDK validiert bereits die Struktur von Spezifikationen, aber strukturelle Gültigkeit beweist nicht, dass der generierte Inhalt korrekt ist. Eine Produktdefinition kann perfekt dem ODPS-Schema entsprechen und trotzdem ein nicht unterstütztes Ziel, einen erfundenen Konsumenten oder eine falsche Beziehung enthalten. Die Datei ist technisch valide, aber das Produktwissen darin ist unzuverlässig. Byakod bietet hier einen wichtigen Hinweis: Das Sprachmodell schlägt Entitäten und Beziehungen vor, aber deterministischer Code überprüft, ob der Quellennachweis existiert. Das Modell assistiert bei der Interpretation, es fungiert nicht als letzte Autorität. Dasselbe Prinzip sollte auch für die Arbeit mit Maysano Portfolio Studio und dem Data Product SDK gelten. Das Sprachmodell kann bei der Extraktion und Zusammenfassung helfen, aber die finale Verantwortung für die Korrektheit liegt beim Menschen und bei nachvollziehbaren Belegen.

Was bedeutet das konkret für Unternehmen, die KI-Agenten einführen wollen? Der Fokus sollte nicht auf besseren Retrieval-Methoden liegen – nicht auf größeren Vektordatenbanken oder ausgefeilteren Embeddings. Der Fokus sollte auf der Strukturierung und Katalogisierung des Wissens liegen – auf der Schaffung von Datenprodukten mit klarem Kontext, klaren Beziehungen und klarer Herkunft. Ein KI-Agent, der auf solche Datenprodukte zugreift, kann nicht nur Texte abrufen, sondern auch verstehen, was sie bedeuten, wofür sie gelten und woher sie kommen. Er wird zu einem verlässlichen Werkzeug, statt zu einer Blackbox, die eloquent, aber unzuverlässig antwortet. Die Zukunft der Unternehmens-KI liegt nicht im Retrieval, sondern im Context Engineering. Dieser Kontext muss aus Datenprodukten kommen – nicht aus loser Textsammlung. Das ist der Schritt, um KI-Agenten von Demonstrationsobjekten zu ernsthaften Arbeitshilfen zu machen.

Quelle: blog.opendataproducts.org

Stell dir vor, du bist Detektiv, aber du darfst nur in einem Raum ermitteln. Du siehst Akten aus diesem Raum, hörst Zeugen aus diesem Raum – und ziehst deine Schlüsse. Was du nicht siehst: die Beweise im Nebenzimmer, die Protokolle im Keller, die Aussagen aus dem Nachbargebäude. Dein Urteil klingt trotzdem souverän, weil es auf dem basiert, was du hast. Nur: Es ist unvollständig. Genau das passiert, wenn wir KI-Agenten auf eine Datenplattform setzen, die nicht alle Quellen erreicht.

Vergangene Woche wurde bekannt, dass SAP Dremio übernimmt. Auf den ersten Blick wirkt das wie eine weitere Konsolidierung im Data-Engine-Markt. Genauer betrachtet zeigt sich: Die Ära der reinen Lakehouse-Engines ist mit dem Aufkommen von KI-Agenten vorbei. Wer nur im eigenen See fischt, wird für die neuen Workloads irrelevant.

Der Lakehouse-Kompromiss – und warum er für Analytics funktionierte

Um zu verstehen, was hier geschieht, müssen wir kurz ausholen. Ein Lakehouse ist im Kern ein Data Warehouse, das auf einem Data Lake aufsetzt. Die Idee: Statt Daten in teure, proprietäre Speicher zu kopieren, liegen sie in offenen Formaten wie Parquet auf einem Objektspeicher wie S3 oder ADLS. Eine Engine wie Dremio oder Trino (Presto) kann darauf direkt lesend zugreifen, optimiert durch Caching, Precomputing und intelligente Abfrageplanung. Für klassische Business Intelligence – Dashboards, Reports, feste Kennzahlen – war das ein Segen. Du materialisierst die häufigsten Abfragen als sogenannte „Reflections“ oder „Materialized Views“, planst nachts einen Refresh, und am Morgen läuft alles blitzschnell. Der Trade-off war klar: Du bringst die Daten in den See, baust dort dein Modell, und die Engine liefert Performance für die vorhersehbaren Fragen.

Dieses Modell hatte in den vergangenen Jahren enorme Erfolge. Viele Unternehmen haben ihre Data Warehouses abgelöst oder ergänzt. Die Kostenvorteile und die Flexibilität der offenen Formate waren überzeugend. Und für den Menschen, der einmal am Tag ein Dashboard öffnet, war die Latenz von Sekunden völlig ausreichend. Das Problem: KI-Agenten ticken fundamental anders.

Wie KI-Agenten das Modell zerbrechen

Ein KI-Agent ist kein menschlicher Analyst, der sich einen Kaffee holt, während ein Report rendert. Ein Agent ist eine automatisierte Einheit, die in Echtzeit Entscheidungen trifft – und dafür benötigt sie Zugriff auf das gesamte Datenökosystem, nicht nur auf einen vorbereiteten Ausschnitt. Der Artikel, den wir hier analysieren, macht einen entscheidenden Punkt: Die Reichweite einer Engine (Reach) ist keine Performance-Kennzahl mehr, sondern eine Vertrauenskennzahl.

Stell dir vor, ein Agent soll das Kündigungsrisiko eines Kunden bewerten. Er hat Zugriff auf das CRM, aber nicht auf das Ticketsystem. Er sieht: Der Kunde hat seit drei Monaten nichts gekauft. Er schlussfolgert: hohes Risiko. Was er nicht sieht: Der Kunde hat gestern einen Premium-Support-Fall eröffnet, der auf eine bevorstehende Verlängerung hindeutet. Der Agent liefert eine Antwort – aber sie ist nicht nur unvollständig, sie ist zuversichtlich falsch. Und anders als ein Mensch hat der Agent kein Bauchgefühl, das ihm sagt: „Moment, hier fehlt was.“ Er gibt die Antwort mit derselben Sicherheit, als hätte er alle Systeme abgefragt. Das ist ein gefährlicherer Fehlermodus als jede Latenz. Latenz sagt dir: Irgendwo hakt es. Eine zuversichtliche Fehlantwort tut das nicht.

Hinzu kommt ein zweites, subtileres Problem: die Unvorhersagbarkeit von Agenten-Workloads. Ein Dashboard fragt immer dieselben Dinge ab: „Umsatz letzte Woche“, „Top 10 Produkte“. Du kannst diese Abfragen vorberechnen. Ein Agent dagegen generiert seine Abfragen dynamisch. Er startet mit einer Frage, bekommt eine Antwort, und leitet daraus die nächste Frage ab – die du nie vorhergesehen hast. Du kannst keine Materialized Views bauen für Fragen, die erst fünf Sekunden vor Ausführung entstehen. Eine Engine, die auf Precomputing angewiesen ist, wird mit einem Agenten, der zur Laufzeit neue Pfade erkundet, strukturell nie mithalten können, egal wie gut sie optimiert ist.

Was KI wirklich von einer Datenplattform fordert

Aus diesen Beobachtungen leitet der Autor eine klare Anforderungsliste ab, die nichts mit Markennamen zu tun hat, sondern mit Architekturentscheidungen. Lass uns diese Anforderungen durchgehen, denn sie sind der Maßstab, an dem sich jede Plattform messen lassen muss.

Erstens: Reichweite muss nahezu vollständig sein. Nicht „die meisten unserer Daten“, sondern alle relevanten Quellen – relationale Datenbanken, Data Warehouses, Objektspeicher, SaaS-Systeme. Ein System, das ein Agent nicht erreicht, ist nicht etwa eine Lücke, die er umsichtig umgeht. Es ist eine stille Wissenslücke, die weder du noch der Agent bemerken, bis die falsche Entscheidung getroffen ist.

Zweitens: Parallelität muss skalieren, als wären tausend Analysten gleichzeitig am Werk. Ein Mensch öffnet ein Dashboard. Ein Agentenfleet feuert Dutzende parallele Abfragen ab – und die Plattform muss unter dieser Last genauso schnell sein wie im Leerlauf. Eine Engine, die für einen Benutzer schnell ist, aber unter realer Last einbricht, wird genau dann langsamer, wenn es am kritischsten ist.

Drittens: Kontext muss begrenzt und relevant sein. Ein Agent bekommt nicht das gesamte Schema einer Datenbank oder einen ganzen Dokumenten-Pool – das würde seinen Kontext aufblähen mit Rauschen und zu Fehlschlüssen führen. Stattdessen braucht er den spezifischen Ausschnitt: die richtigen Tabellen, die richtigen Spalten, die passenden Business-Definitionen, zugeschnitten auf die aktuelle Frage.

Viertens: Aktualität muss strukturell sein, nicht geplant. Die Frage eines Agenten entsteht 90 Sekunden vor der Antwort. Er braucht Daten von diesem Moment, nicht vom letzten nächtlichen Refresh. Die Frage „Wie aktuell darf es sein?“ war früher eine Business-Entscheidung. Für viele agentische Anwendungen liegt die Antwort heute bei null Sekunden.

Fünftens: Governance muss mit den Daten reisen, nicht daneben sitzen. Wenn zwei Agenten auf unterschiedliche Systeme zugreifen, die unterschiedliche Geschäftslogik anwenden, und sie kommen zu widersprüchlichen Ergebnissen – dann ist das nicht nur eine kleine Inkonsistenz. Es untergräbt das Vertrauen in den gesamten KI-Ansatz. Governance muss zur Abfragezeit durchgesetzt werden, nicht nachträglich.

Was das für die Branche bedeutet

Keine dieser Anforderungen ist neu, aber zusammen ergeben sie ein Profil, das reine Lakehouse-Engines strukturell nicht erfüllen können. Dremio ist kein Einzelfall – es steht exemplarisch für eine ganze Kategorie von Anbietern, die auf „Bring your data to the lake“ gesetzt haben. Der Verkauf an SAP ist der deutlichste Hinweis darauf, dass dieser Ansatz an seine Grenzen stößt.

Der Autor des zugrundeliegenden Artikels argumentiert, dass die Lösung in einer föderierten Architektur liegt: Daten dort lassen, wo sie sind, und über eine Engine abfragen, die alle Quellen gleichzeitig erreicht, ohne sie vorher zu bewegen. Das ist die Design-Philosophie hinter Starburst (dem Unternehmen, für das der Autor arbeitet) – aber es ist auch eine logische Schlussfolgerung aus den Anforderungen, die KI mitbringt. Ob man Starburst mag oder nicht: Die Fragen, die im Raum stehen, sind systemunabhängig. Kann meine Plattform alles erreichen, was meine Agenten brauchen? Hält sie unter der Last stand, die Agenten erzeugen? Kann sie Fragen beantworten, die vor fünf Sekunden noch nicht existierten?

Wenn ein Anbieter auf diese Fragen mit „arbeiten wir dran“ antwortet, ist das ehrlich. Aber dann solltest du sicherstellen, dass du die Fragen stellst, bevor du dich bindest – nicht hinterher, wenn der Agent bereits falsche Entscheidungen trifft.

Dremios Verkauf ist ein Datenpunkt. Er ist nicht die Geschichte selbst, sondern der Moment, in dem eine Verschiebung für einen Anbieter sichtbar wurde. Die Verschiebung ist größer und wird nicht mit einer Übernahme enden. Wer KI ernsthaft einsetzen will, muss Datenplattformen so bauen, dass sie dem Denken von Agenten folgen – nicht umgekehrt. Das ist kein Feature-Wettbewerb mehr. Es ist die neue Grundlage für Vertrauen in automatisierte Entscheidungen.

Quelle: starburst.io

Du gehst in eine Bäckerei, die ihr bestes Brot kostenlos auf die Straße stellt. Jeder bedient sich, ohne zu bezahlen. Gleichzeitig verdient die Bäckerei Millionen – mit Kaffee, Butter und dem Wissen, wie man Teigführung optimiert. Klingt widersprüchlich? Genau das tut das chinesische KI-Startup Z.ai (früher Zhipu). Laut Bloomberg ist das Unternehmen auf dem Weg, als erster unabhängiger chinesischer KI-Anbieter eine Milliarde Jahresumsatz zu knacken – und verschenkt seine leistungsfähigsten Modelle. Wie funktioniert das? Was sagt das über den Wettbewerb zwischen Ost und West?

Die Zahlen hinter dem Aufstieg

Die Nachricht kombiniert eine beeindruckende Zahl mit einer wichtigen Einschränkung. Z.ai erzielte 2025 einen Umsatz von umgerechnet 724 Millionen Yuan (etwa 100 Millionen Dollar) – ein Plus von 132 Prozent zum Vorjahr. Darauf basiert die Prognose: JPMorgan erwartet für 2026 rund 4,6 Milliarden Yuan, für 2028 dann 30,9 Milliarden Yuan – dann soll das Unternehmen profitabel sein. Die Milliardengrenze, von der Bloomberg spricht, ist vorsichtig: Sie stützt sich teilweise auf annualisierte wiederkehrende Umsätze, also eine Hochrechnung. Auch JPMorgans Schätzung für 2026 liegt in Dollar unter der Milliardenschwelle. Der Trend ist real.

Wie verdient Z.ai sein Geld? Der Mix ist stark unternehmensorientiert. Ein großer Teil stammt aus lokalen Installationen für Staatsbetriebe und Finanzinstitute – Modelle, die direkt auf den Servern der Kunden laufen. Dazu kommt ein schnell wachsendes Cloud-Geschäft. Die API-Sparte ist der Wachstumstreiber: Die annualisierten wiederkehrenden Einnahmen von der offenen Plattform liegen bei 1,7 Milliarden Yuan – ein Sechzigfaches innerhalb eines Jahres. Das klingt nach einem klassischen Plattform-Geschäftsmodell: Einmal aufgesetzt, skalieren die Einnahmen mit der Nutzung.

Warum das Verschenken funktioniert

Doch hier liegt der scheinbare Widerspruch: Z.ai gibt seine leistungsstärksten Modelle, darunter GLM-5.2, als Open Source frei. Jeder kann sie herunterladen und kostenlos nutzen. Das ist, als würde ein Autohersteller sein neuestes Elektroauto mit den Plänen im Internet veröffentlichen – und trotzdem Geld verdienen. In westlicher Logik müsste das die Monetarisierung zerstören. Z.ai setzt auf den gegenteiligen Effekt: Kostenlose Modelle treiben die Verbreitung voran. Wer die Software kennt, kauft die dazugehörige Cloud-Infrastruktur, bezahlt für Support oder bestellt eine maßgeschneiderte On-Premise-Lösung. Es ist das alte Modell „Rasiermesser verschenken, Klingen verkaufen“ – nur dass die Rasiermesser hier KI-Modelle mit Milliarden Parametern sind.

Gründer Tang Jie hat diese Philosophie öffentlich verteidigt. KI sollte der Menschheit gehören, nicht hinter Bezahlschranken verschwinden. Klingt idealistisch? Vielleicht. Aber die Umsatzzahlen liefern die kommerzielle Bestätigung. In China scheint das zu funktionieren, während westliche Labore wie OpenAI oder Google mit enormen Verlusten kämpfen. Im Westen ist das dominante Modell: teure Modelle über APIs verkaufen, leistungsschwächere Versionen sind kostenlos. Z.ai dreht den Spieß um: Die besten Modelle sind frei, die Bezahlung kommt aus dem Ökosystem drumherum.

Das führt zu einer grundsätzlichen Frage: Was ist ein „KI-Modell“? Stell dir ein großes Modell wie GLM-5.2 als eine Art superschnelles Gehirn vor, das aus Milliarden Beispielen gelernt hat, Texte zu verstehen und zu generieren. Dieses Gehirn kann man als Datei herunterladen – ähnlich wie ein Buch. Um es zu nutzen, braucht man einen leistungsstarken Computer, Speicherplatz, Daten und oft Hilfe bei der Anpassung. Genau das bietet Z.ai an: die Dienstleistung, das Modell für dich zu hosten, zu warten und zu optimieren. So wie ein Buch kostenlos im Internet stehen kann, während du für die Einführung in den Stoff bezahlst.

Haken und Risiken der Prognose

Die Zahlen von Z.ai sind beeindruckend, aber nicht ohne Haken. Die Milliardengrenze bleibt eine Prognose, und Prognosen in der KI-Welt haben eine kurze Haltbarkeit. Das Unternehmen macht immer noch Verluste – die Ausgaben steigen schneller als die Einnahmen. Ein großer Teil der Kunden sind staatliche Unternehmen, was die Grenze zwischen kommerzieller Nachfrage und politischer Unterstützung verschwimmen lässt. Die Bewertung liegt bei rund 112 Milliarden Dollar, nach einem Kursanstieg von über 1.000 Prozent seit dem Börsengang im Januar. Das ist viel Vertrauen in die Zukunft. Z.ai hat bereits Milliarden durch eine weitere Aktienplatzierung eingesammelt – der Preis spiegelt die Erwartung wider, dass die Prognosen wahr werden, nicht die aktuelle Realität.

Hinzu kommt der brutale Wettbewerb auf dem chinesischen Markt. Chinesische Modelle unterbieten sich gegenseitig bei den Preisen – auch die US-Labore müssen mitziehen. Die Margen sind knapp. Eine Milliarde Umsatz zu erreichen ist das eine, daraus Profit zu schlagen ein anderes. Aber genau das macht die Geschichte von Z.ai interessant: Sie zeigt, dass chinesische KI-Unternehmen nicht nur technisch aufholen, sondern gelernt haben, Technologie in Umsatz umzuwandeln. Die oft beschriebene „chinesische Art der Kommerzialisierung“ – schnell skalieren, effizient monetarisieren trotz niedriger Preise – findet hier ihre Anwendung auf große Sprachmodelle.

Die Lektion für den Westen

Für Beobachter bedeutet das: Der Wettlauf der KI-Supermächte wird nicht allein durch Rechenleistung oder Forschungserfolge entschieden. Es geht auch um Geschäftsmodelle. Z.ai zeigt, dass Open Source kein Hindernis für kommerziellen Erfolg sein muss. Im Gegenteil: Es kann der Hebel sein, der die Adoption so stark beschleunigt, dass die Nebeneinnahmen alles andere übertreffen. Vielleicht ist das die Lektion, die westliche Unternehmen lernen müssen: Nicht zu fragen, wie viel man für ein Modell verlangen kann, sondern wie man diejenigen bezahlt bekommt, die es nutzen – auch wenn das Modell selbst gratis ist.

Die nächsten Jahre werden zeigen, ob Z.ai die Profitabilität erreicht. Der Pfad ist vorgezeichnet: wachsende Cloud-Umsätze, steigende Zahl von Enterprise-Kunden, eine Community, die die Modelle weiterentwickelt. Die Gefahr lauert im Preisverfall: Wenn alle Modelle ähnlich gut sind und gratis, wird der Wettbewerb zum reinen Preiskampf auf den Dienstleistungen. Dann zählt nicht die Technologie allein, sondern die Servicequalität, die Kundenbindung und die Fähigkeit, das Ökosystem zu managen. Genau das ist die Herausforderung für Z.ai.

Bis dahin bleibt eine Erkenntnis: Die Idee, dass man sein bestes Produkt verschenken muss, um Geld zu verdienen, ist nicht neu. Z.ai zeigt, dass sie auch in der Welt der künstlichen Intelligenz funktioniert. Das reicht über China hinaus. Denn am Ende geht es nicht darum, ob KI teuer oder billig ist. Sondern darum, wie wir sie nutzbar machen – ohne den Zugang zu beschränken. Vielleicht ist das der Schlüssel zu einer KI, die allen dient.

Quelle: thenextweb.com

Ein Unternehmen kauft teure Grafikprozessoren, um damit bereits trainierte KI-Modelle auszuführen – Inference-Aufgaben. GPUs sind für das Training optimiert, einer rechenintensiven Phase, die hohe Parallelleistung braucht. Für die Inference zählen Effizienz und niedrige Betriebskosten, nicht maximale Rohleistung. Das Startup General Compute hat jetzt einen 400-Millionen-Dollar-Kredit von der Investmentfirma Upper90 erhalten – besichert durch spezialisierte Inference-Chips. Es könnte der erste Kredit dieser Art sein.

Das Geschäftsmodell von General Compute

General Compute wurde von CEO Finn Puklowski und CTO Jason Goodison gegründet. Im Mai startete es mit einer 15-Millionen-Dollar-Startkapitalrunde. Das Unternehmen baut eine Neocloud – eine Cloud speziell für KI-Workloads, anders als die Infrastruktur von AWS oder Azure. Die Basis bilden SN50-Chips von SambaNova, unterstützt von Intel. Diese Chips sind für Inference entwickelt: stromsparend, keine teuren Wasserkühlungen, flexibler einsetzbar als GPUs. General Compute verspricht eine 16-mal schnellere Inference als vergleichbare GPU-Clouds.

Wie kommt ein neues Unternehmen an genug dieser Chips? Upper90 hilft. Mitgründer und CEO Billy Libby, ehemaliger quantitativer Trader bei Goldman Sachs, erprobte diesen Ansatz 2021. Damals vergab Upper90 einen Kredit an das Startup Crusoe – besichert durch GPUs. Es war der erste Kredit, der den Wert fortschrittlicher Chips als Sicherheit nutzte. Traditionelle Banken mieden solche Deals wegen der Unsicherheit über GPU-Werte. Nachdem CoreWeave chip-besicherte Kredite zu einem Geschäftsmodell und später zu einem Börsengang machte, ist diese Finanzierungsform heute üblich.

Chips als neue Kreditsicherheit

„Als wir als erste Gruppe Nvidia-GPUs finanziert haben, war der Markt ineffizient“, sagte Libby. „Wir konnten als frühe Teilnehmer etwas aufbauen und für das Risiko entschädigt werden.“ GPUs sind heute gut verstanden, vielleicht überkauft. Upper90 richtet den Blick auf Inference-Chips. „Wir glauben, dass Open-Source-Modelle wichtig werden. Wir suchten nach einem Player im Inference-Bereich. Nicht jeder braucht einen Supercomputer, aber jeder braucht Inference und KI.“

Diese These gewinnt an Fahrt. Unternehmen wie OpenRouter und Fireworks erzielten hohe Bewertungen. Neue Modelle wie Kimis K3 zeigen in Codierungs-Benchmarks, dass sie mit Anthropic und OpenAI mithalten können. Chip-Hersteller wie Groq und Cerebras ziehen Interesse auf sich. General Computes Zugang zu Chips außerhalb des Nvidia-Ökosystems ist bedeutsam. TensorWave, ein weiteres KI-Infrastruktur-Unternehmen, setzt mit AMD auf eine ähnliche Strategie.

Inference wird zum Massengeschäft

„Es gibt Chips, die skalieren und eine bessere Gesamtbetriebskosten oder höhere Geschwindigkeit als Nvidia bieten – aber noch wenige Abnehmer“, sagte Puklowski. „Durch die Zusammenarbeit mit Upper90 geht es nicht nur um ein Startup, das Geld für Rechenleistung bekommt. Das ist das erste Signal: Kapital organisiert sich, Nvidias Monopolstellung bröckelt.“

Der 400-Millionen-Dollar-Kredit von Upper90 an General Compute ist mehr als eine Finanzierungsrunde. Er zeigt, wohin die Reise in der KI-Infrastruktur geht. Das Training großer Modelle erfordert teure GPUs. Die Ausführung dieser Modelle – Inference – wird zum Massengeschäft. Kosten pro Anfrage, Energieeffizienz und Skalierbarkeit zählen. Spezialisierte Inference-Chips wie der SambaNova SN50 bieten einen Vorteil, vor allem kombiniert mit Open-Source-Modellen ohne Lizenzgebühren. Die Finanzierung auf Basis dieser Chips zeigt: Der Markt investiert in diese Richtung, GPU-Finanzierer positionieren sich neu.

Die Analogie zum Supersportwagen und zum Kleinwagen passt. Für das Training braucht es die Kraft eines Supersportwagens – GPUs für tausende parallele Berechnungen. Für die alltägliche Nutzung reicht ein sparsamer Kleinwagen. Diese Alltagstauglichkeit wird den Großteil der KI-Kosten ausmachen. Unternehmen, die früh gehen, sichern sich einen Vorteil.

Offene Fragen und Risiken

Skepsis bleibt angebracht. Die Behauptung von General Compute, eine 16-mal schnellere Inference zu bieten, muss sich im Praxiseinsatz beweisen. Die Skalierbarkeit der SambaNova-Chips ist nicht im großen Maßstab erprobt. Upper90 geht ein Risiko ein. Sollte der Markt langsamer wachsen, könnten die Sicherheiten an Wert verlieren. Genau dieses Risiko bestand auch bei GPU-Krediten – und sie wurden zur Goldgrube.

Für Entwickler bedeutet dieser Deal: Günstigere Inference-Dienste könnten bald verfügbar sein. Open-Source-Modelle wie Llama 3 oder Mistral lassen sich zu einem Bruchteil der Kosten betreiben. Das senkt die Hürde für KI-Startups und ermöglicht neue Geschäftsmodelle. Rechenzentren können flexibler auf verschiedene Chip-Architekturen setzen, statt an Nvidia gebunden zu sein. Für die Chip-Industrie ist es ein Signal: Der Kampf um den Inference-Markt beginnt.

Bleibt die Frage, ob dieser Deal den Wendepunkt markiert oder eine Randnotiz bleibt. GPU-Finanzierung belohnte frühe Moves. Crusoe bekam 2021 seinen GPU-Kredit, viele zweifelten. Heute ist Crusoe ein Milliardenunternehmen. General Compute und Upper90 setzen auf die gleiche Dynamik – mit einer neuen Chip-Generation. Die kommenden Monate zeigen, ob die Rechnung aufgeht. Klar ist: Die Dominanz von Nvidia bekommt Risse, Kapital strömt in die Lücken.

Quelle: techcrunch.com