Offene Unternehmens-Ontologie: Wem sollte die semantische Geschäftsschicht gehören?

Kurz gesagt: Die Schicht der Geschäftsdefinitionen, auf die Ihre Anwendungen, Agents, Prüfer – und mittlerweile auch mehrere Anbieter – allesamt angewiesen sind, sollte keiner einzelnen Plattform gehören. Sie sollte eine neutrale Schicht sein, die Sie in Ihrem eigenen Repository selbst in der Hand halten.

Beginnen wir mit der Geschichte, wie ein Unternehmen genau deswegen einen Kunden verlor. Die Details sind anonymisiert, aber jeden einzelnen Schritt davon haben Sie vermutlich schon erlebt.

Yuanfeng ist ein Hersteller von Industrieanlagen, mit einem Jahresumsatz im Milliardenbereich und mehreren tausend Kunden. 2024 setzte das Unternehmen sein Datenfundament voll auf Microsoft, baute in Fabric eine saubere Ontologie auf: Was ein „Kunde” ist, welche „Anlagen” an einem Kunden hängen, welche „Serviceaufträge” an einer „Anlage” hängen – alles glasklar definiert. In jenem Jahr war Yuanfeng das Vorzeigebeispiel, das auf jeder Anbieterkonferenz immer wieder genannt wurde.

2026 trafen Yuanfeng drei Dinge fast gleichzeitig:

Das Data-Science-Team wollte eine Reihe von Verlängerungsprognosen mit Gemini rechnen, weil es in genau diesem Szenario tatsächlich präziser war;
die Compliance-Abteilung erhielt die Auflage, dass die Daten von EU-Kunden in der EU bleiben müssen und nicht mehr in eine US-Cloud dürfen;
eine Übernahme wurde abgeschlossen und brachte eine komplette, auf Salesforce laufende Vertriebsorganisation mit mehreren tausend Kunden mit.

Damit hatte Yuanfeng plötzlich drei „Kunden”: einen in Fabric, einen in Salesforce und noch einen in der compliance-isolierten EU-Umgebung.

Die Wendung der Geschichte ereignete sich bei einem zentralen Großkunden namens „H-Gruppe”. Eines Tages fragte der Vertriebsleiter den Agent: „Wie hoch ist das Verlängerungsrisiko der H-Gruppe für nächstes Jahr?” Der Agent antwortete: „Niedrig.” – Er war an die Fabric-Ontologie angebunden, und dort sahen die jüngsten Aufträge der H-Gruppe gesund aus, die Zahlen waren schön.

Was der Agent aber nicht sah: In jenem Salesforce-Datensatz (aus der Übernahme) hatte die H-Gruppe innerhalb eines halben Jahres zweimal eine Beschwerde bis auf Vorstandsebene eskaliert; in der isolierten EU-Umgebung hing zudem ein seit 90 Tagen schwelender Zahlungsstreit. Drei Datensätze gehörten zu drei „Kunden”, die einander nicht kannten, und keine einzige Schicht wusste, dass sie in Wahrheit ein und dieselbe H-Gruppe waren.

Ein Quartal später war die H-Gruppe abgewandert, der Jahresverlust ging in die Millionen. Das Fazit der Aufarbeitung war so schmerzhaft, dass es im Raum still wurde: Der Agent hatte technisch keinen Fehler gemacht – jene eine Datenmenge, die er sah, zeigte tatsächlich ein niedriges Risiko. Falsch war nicht das Modell, sondern die Definition des „Kunden” unter seinen Füßen, die in drei Stücke zerschnitten war.

Das war kein Versäumnis von Yuanfeng. Es ist die zwangsläufige Folge davon, die „Definition des Geschäfts” einer Plattform zur Verwahrung zu überlassen – und jede Plattform verwahrt nur ihren eigenen Teil davon.

Kein Einzelfall: Alle wetteifern um diese Schicht

Yuanfengs Lage ist deshalb so verbreitet, weil die ganze Branche gemeinsam auf dieselbe Schicht zustürmt.

Vor kurzem klang „Business-Semantikschicht / Ontology” noch wie ein Spezialbegriff einzelner Datenplattformen. Inzwischen bewegen sich große Clouds, Datenplattformen und KI-Plattformen in dieselbe Richtung. Der Grund ist einfach: Agents verstehen Unternehmen nicht zuverlässig, wenn sie nur auf Tabellen und APIs schauen.

Warum gerade jetzt? Weil Agents dieses Loch aufgerissen haben. Die Datenpipelines des vergangenen Jahrzehnts kümmerten sich nur darum, „wohin die Daten fließen”, kaum darum, „was diese Daten bedeuten” – am Ende fing es ja ohnehin ein Mensch auf. Ein Agent hat diesen auffangenden Menschen nicht: Er steht vor Dutzenden Tabellen mit „Kunden”-Feldern uneinheitlicher Definition und antwortet entweder falsch (wie bei der H-Gruppe) oder wagt gar keine Antwort. Die augenfälligen Zahlen der Branche – 88 % der Agent-Piloten schaffen es nicht in die Produktion – sterben zu einem großen Teil genau an dieser fehlenden Schicht.

Das Urteil der drei Konzerne ist also richtig und zudem hochgradig deckungsgleich: Damit KI zuverlässig in Unternehmen Einzug hält, braucht es zuerst eine maschinenlesbare, governte Schicht von Geschäftsdefinitionen. Das muss man nicht mehr diskutieren. Worüber man wirklich streiten sollte, ist die nächste Frage – wem diese Schicht gehören soll.

Drei richtige Richtungen, drei verschiedene Schlösser

Legt man die Ansätze der drei Anbieter nebeneinander, stößt man auf eine peinliche Gemeinsamkeit.

	Wo liegt die Ontologie	Wer kann sie verstehen	Können Sie sie mitnehmen
Palantir Foundry	Innerhalb der Palantir-Plattform	Vor-Ort-Ingenieure + Plattform-Tools	An die Plattform gebunden, Migration = Neuaufbau
Microsoft Fabric IQ	Innerhalb von OneLake / Fabric	365- und Fabric-Ökosystem	An den Microsoft-Stack gebunden
Googles Enterprise-Wissensgraph	Innerhalb der Google Cloud	Vertex- und GCP-Ökosystem	An den Google-Stack gebunden

Fairerweise gesagt: Jeder der drei macht auf seinem eigenen Terrain einen sehr guten Job. Palantirs Ontologie-Modellierung ist wirklich hochwertig; Microsoft schweißt die semantische Schicht so eng an OneLake und 365, dass es für ein durch und durch auf Microsoft setzendes Unternehmen fast reibungslos abläuft; und Google hat bei Datenmaßstab und Graphenschlussfolgerung ebenfalls echtes Können. Sie alle helfen Ihnen, Ihr Geschäft klar zu ordnen – und sperren diese Klarheit dann in ihre eigene Plattform ein.

Ein IT-Veteran der alten Schule sagt an dieser Stelle reflexartig: Schon wieder Anbieter-Lock-in, das alte Problem.

Aber diesmal ist nicht der Lock-in das, was man am meisten fürchten sollte. Diesmal gibt es ein schlimmeres, neues Problem. Bevor wir es auseinandernehmen, müssen wir erst ehrlich das Drehbuch durchgehen, mit dem geschlossene Plattformen gewinnen – denn das ist keineswegs schwach.

Zuerst das Gewinner-Drehbuch der geschlossenen Plattformen

Wer nur „offen ist gut” ruft, betreibt Verkündigung, keine Analyse. Geschlossene Plattformen halten vier echte Trümpfe in der Hand:

Erstens: Modellierungsqualität. Die über zwanzig Jahre angesammelte Altlast eines Großunternehmens zu einer sauberen, in sich stimmigen Ontologie zu verarbeiten, ist extrem schwere Ingenieursarbeit. Palantir richtet mit Vor-Ort-Ingenieuren Konzept für Konzept aus, eine Qualität, mit der eine Open-Source-Community kurzfristig nicht mithalten kann. Eine Ontologie schlecht zu bauen, ist schlimmer, als gar keine zu bauen.

Zweitens: ein Verantwortlicher, der einsteht. Wenn etwas schiefgeht, hebt jemand ab, es gibt ein SLA, einen Vertrag, der absichert. Für einen CIO ist „ein Anbieter trägt für mich die Verantwortung über die gesamte Schicht” an sich schon Geld wert – das nennt man one throat to choke.

Drittens: Viele Unternehmen sind tatsächlich „im Wesentlichen bei einem einzigen”. Wenn 80 % Ihres Geschäfts in einem Ökosystem liegen, dann ist „das Beste innerhalb des Ökosystems” für Sie buchstäblich das Beste, und die Vorteile der Offenheit nützen Ihnen schlicht nichts.

Viertens: Integrationstiefe. Innerhalb desselben Ökosystems sind Daten, Identität und Berechtigungen schon vorhanden, und die eingesparte Drecksarbeit zählt nach Personenmonaten.

Diese vier Trümpfe sind alle echt. Das Fazit lautet also nicht „geschlossene Plattformen sind alle eine Falle” – für Unternehmen, die unter ihren Prämissen leben, sind sie oft die richtige Antwort. Das Problem entsteht bei Unternehmen wie Yuanfeng: deren Prämissen gerade ungültig werden.

Diesmal hat das Drehbuch ein neues Leck: Fragmentierung

Beim Lock-in eines einzelnen Anbieters ist Ihre Geschäftsdefinition wenigstens noch ein vollständiges Ganzes, nur eben nicht transportierbar. Schmerzhaft, aber vollständig.

Wenn drei Konzerne gleichzeitig geschlossene Ontologien bauen, entsteht etwas anderes: Fragmentierung. Yuanfengs „Kunde” ist nicht eingesperrt, er ist in drei Teile zerschnitten, die jeweils in drei Plattformen liegen, die einander nicht kennen. Das ist weit unangenehmer als Lock-in, und zwar aus gutem Grund – zwei Mechanismen sorgen dafür, dass es nicht von selbst heilt:

Die erste Schicht sind die Interessen. Sie denken vielleicht: Dann lasse ich doch einfach die Microsoft-Ontologie den „Kunden” aus Salesforce verstehen? Geht nicht, denn kein einziger Anbieter hat einen Anreiz, das zu tun. Die Ontologie jedes Einzelnen ist sein Burggraben. Würde Microsoft von sich aus die „Kunden”-Semantik mit Salesforce vereinheitlichen, hülfe es eigenhändig dem Konkurrenten, die Daten reibungsloser zu transportieren, und würde sich selbst zur austauschbaren Ware machen. Vereinheitlichung ist für jeden Teilnehmer des Rennens Selbstverstümmelung. Das ist keine technische Nachlässigkeit, sondern eine rationale Entscheidung – darauf zu hoffen, dass einer von ihnen die Fragmentierung aufräumt, ist vergeblich.

Die zweite Schicht ist die Technik. Selbst wenn man die Interessen beiseitelässt, ist die ontologieübergreifende semantische Ausrichtung an sich ein ungelöstes Problem: Ist der „Kunde” aus System A gleich dem „Account” aus System B? Felddefinitionen, Lebenszyklen, Deduplizierungsregeln und was als „dieselbe Entität” gilt – auf beiden Seiten ist alles unterschiedlich. Auch KI kann das nicht zuverlässig automatisch erledigen – ganz im Gegenteil: Agents machen gerade deshalb Fehler, weil ihnen diese eindeutige Definitionsschicht fehlt. Zurück zur H-Gruppe: Lässt man den Agent selbst raten, „ob diese drei Datensätze dieselbe Firma sind”, kostet ein Fehlschluss genau jene Millionen.

In einem Satz zusammengefasst: Sie glauben, drei Werkzeuge gekauft zu haben, in Wahrheit haben Sie drei einander unbekannte „Quellen der Wahrheit” gekauft. Je mehr Systeme, je mehr Übernahmen, je mehr Compliance-Isolation, desto schwerer die Fragmentierung – und ausgerechnet das Agent-Zeitalter verstärkt ihre Kosten, denn ein menschliches Gehirn kann zur Not noch händisch über drei Systeme hinweg ausrichten, ein Agent kann das nicht; er braucht eine eindeutige, systemübergreifend konsistente Definitionsschicht, um überhaupt schlussfolgern zu können.

Damit Fragmentierung nicht entsteht, gibt es logisch nur einen Ausweg: Die Definition des Geschäfts darf keiner der am Rennen teilnehmenden Plattformen gehören, sie muss eine neutrale Schicht sein – eine Definition, die Sie selbst besitzen und die die Werkzeuge aller drei Anbieter lesen können. Geschlossene Plattformen können das strukturell nicht liefern: Sie sind Teilnehmer des Rennens und können nicht zugleich der Schiedsrichter sein.

Wie Sie erkennen, dass Sie gerade fragmentiert werden

Das ist nicht abstrakt, es gibt sehr konkrete Frühsymptome. Prüfen Sie sich an den folgenden Punkten: Treffen mehr als drei zu, hat die Fragmentierung in Ihrem Unternehmen bereits stattgefunden:

Derselbe „Kunde / Auftrag / Anlage” hat in verschiedenen Systemen unterschiedliche Definitionen und passt nicht zusammen, sodass jeder Bericht manuell zusammengeführt werden muss.
Lässt man einen Agent eine systemübergreifende Frage beantworten, drückt er sich entweder vage aus oder beantwortet sie nur halb richtig (er sieht ein System, das andere nicht).
Bei jedem neu angebundenen System müssen Sie der KI von Neuem beibringen, „was das ist und was die Felder bedeuten”.
Eine Übernahme liegt über ein Jahr zurück, aber die Stammdaten beider Seiten sind noch immer nicht wirklich zusammengeführt, jeder berichtet für sich.
Compliance verlangt, eine bestimmte Datenkategorie zu isolieren, sodass dieselbe Entität gezwungenermaßen in mehreren Kopien gespeichert wird, von denen keine die andere kennt.

Bevor Yuanfeng die H-Gruppe verlor, trafen vier dieser fünf Punkte zu. Sie wurden damals alle als „offene Punkte der Daten-Governance” behandelt, und niemandem war bewusst, dass es sich in Wahrheit um eine Mine handelte, auf die ein Agent früher oder später treten würde.

Erst eine kalte Dusche: Offenheit ist keine Wunderwaffe

Hier muss man ehrlich innehalten, sonst wird daraus Quacksalberei.

Erstens: Die Definition durch ein offenes Protokoll zu ersetzen, führt nicht automatisch dazu, dass Yuanfengs drei „Kunden” zu einem verschmelzen. Die fällige semantische Modellierung, Deduplizierung und Definitionsausrichtung muss man genauso machen – für diesen Teil gibt es keine Wunderwaffe, glauben Sie niemandem, der so etwas anpreist. Was Offenheit wirklich verändert, ist die Zugehörigkeit dieser Mühe: Die Definition, die Sie sich heute mühsam ausgerichtet haben, steht in Ihrem eigenen Repository, statt im Backend irgendeiner Plattform zu versickern. Wechseln Sie nächstes Jahr das Modell, die Cloud, oder werden Sie übernommen, müssen Sie die Anbindungen neu machen, nicht die Definition selbst.

Zweitens: „Offenheit” allein garantiert auch keinen Sieg. Damit ein offener Standard sich historisch wirklich durchsetzt, braucht es meist zusätzlich eine ausreichend gute Referenzimplementierung plus ein aktives Ökosystem – ein bloß veröffentlichtes Protokoll, das niemand gut nutzbar macht, scheitert genauso. Sich für Offenheit zu entscheiden, ist also eine Wette darauf, „dass jemand es solide umsetzt”; das ist eine Einschätzung mit Ausführungsrisiko, kein sicherer Gewinn.

Aber beachten Sie das Gewicht dieser zwei kalten Duschen: Sie besagen „Offenheit kostet auch Mühe und hat auch Risiken”, nicht „geschlossen ist besser”. Im Vergleich dazu ist das Abwärtsrisiko, die Geschäftsdefinition in eine einzige Plattform einzusperren – also Yuanfengs Art von Fragmentierung – weit größer und schwerer umkehrbar. Keine der beiden Seiten ist kostenlos; nur hält bei einer von beiden das wichtigste Gut Ihre eigene Hand fest.

Schichten, auf die sich alle verlassen, wurden am Ende stets neutral

Diese Gesetzmäßigkeit selbst ist nicht neu, aber sie verdient es, an neuen Beispielen erzählt zu werden, weil sie sich gerade wieder und wieder ereignet.

Die „Definitionsschicht”, auf die sich ein ganzes Ökosystem gemeinsam verlässt, wird am Ende immer neutral. Das älteste Beispiel ist SQL: Die Datenbankanbieter haben sich in einem roten Ozean gegenseitig zerfleischt, doch die Abfragesprache selbst ist Allgemeingut. Aktueller und aussagekräftiger sind diese beiden: OpenTelemetry – die Datendefinition im Bereich Observability, an die sich alle Monitoring-Anbieter anbinden, gehostet von der neutralen CNCF, von niemandem monopolisierbar; und LSP (Language Server Protocol) – von Microsoft selbst eröffnet, doch gerade weil es offen war, von allen Editoren übernommen und zum De-facto-Standard geworden.

Gerade das LSP-Beispiel ist bemerkenswert, denn es ist etwas, das Microsoft eigenhändig bewiesen hat: Die Definitionsschicht zu öffnen und selbst über die beste Implementierung Geld zu verdienen, gewinnt mehr, als sie zuzusperren. Die Business-Semantikschicht ist von derselben Art – sie wird künftig von Ihren Anwendungen, Ihren Agents, Ihrem Audit-System sowie den Werkzeugen dreier Anbieter gleichzeitig abhängen. Eine Schicht, von der so viele Parteien abhängen, kann logisch nicht auf Dauer einer einzigen privat gehören. Sie wird entweder neutral, oder sie produziert weiterhin Fragmentierung wie bei Yuanfeng.

Wie diese neutrale Schicht aussieht

Nach all dem ein Blick auf das konkrete Stück. Der Schwerpunkt liegt nicht auf der Syntax, sondern darauf, wo es liegt, ob man es mitnehmen kann und ob man die Fragmentierung zurückholen kann.

Hätte Yuanfeng den „Kunden” damals als eine neutrale Definition gebaut, hätte das Unternehmen jedes der drei Systeme als Datenquelle anbinden, jeweils als Objekte modellieren und sie über einen gemeinsamen Schlüssel – die USt-IdNr. – zu einem einzigen, mit Berechtigungen und Audit versehenen „Kunden” zur Deckung bringen können:

export const Customer = ObjectSchema.create({
  name: 'crm_customer',
  label: 'Kunde',
  fields: {
    name: Field.text({ label: 'Kundenname', required: true }),
    tax_id: Field.text({ label: 'USt-IdNr.' }), // gemeinsamer Schlüssel, um systemübergreifend „denselben Kunden" zur Deckung zu bringen
  },
});

Diese Definition liegt in Ihrem Git-Repository, ist diffbar, prüfbar, migrierbar. Was sie als Nächstes leisten kann, ist das Entscheidende – „mitnehmbar” wird zu einer vorführbaren Handlung statt zu einem Versprechen:

git add crm/*.ts          # Die Definition liegt nun in Ihrem Versionsverzeichnis, prüfbar und zurückrollbar
os start   # Dieselbe Definition läuft auf Ihrer eigenen Infrastruktur
# Dann richten Sie ein beliebiges Modell darauf aus – Claude, GPT, Gemini, egal; die Runtime bleibt gleich

Stellen Sie nun erneut die brennende Frage: „Wie hoch ist das Verlängerungsrisiko der H-Gruppe für nächstes Jahr?” Der Agent steht einem vereinheitlichten „Kunden” mit Berechtigungen und Audit gegenüber: Aufträge gesund, aber überlagert von zwei Beschwerden auf Vorstandsebene und einem 90-Tage-Zahlungsstreit – er wird antworten: „Hohes Risiko, frühzeitiges Eingreifen empfohlen.” Dasselbe Modell, dieselbe Frage; allein weil die Definition unter seinen Füßen nicht mehr fragmentiert ist, wird aus „mehrere Millionen verloren” ein „ein Quartal früher gewarnt”.

Genau das ist die Arbeitsteilung von ObjectStack und ObjectOS und zugleich ihre Antwort auf dieses Rennen:

ObjectStack – das offene Protokoll zur Beschreibung des Geschäfts (Apache 2.0), liegt in Ihrem Repository, von den Agents aller drei Anbieter lesbar;
ObjectOS – die Runtime dieser Definition, läuft auf Ihrer eigenen Infrastruktur, erzwingt Berechtigungen, zeichnet Audits auf.

Die Definitionsschicht ist neutral, die Laufzeitschicht macht das Geschäft. Es ist dieselbe Beziehung wie zwischen SQL und Datenbankanbietern, wie zwischen LSP und Editor-Anbietern.

Schlusswort

Das ist keine ideologische Frage von „offen gut oder geschlossen gut”. Es ist eine nüchternere Rechenaufgabe: Wenn Ihre Anbieterkombination sich früher oder später ändern wird – Multi-Modell, Multi-Cloud, Übernahmen, Compliance-Isolation, sie wird sich ganz sicher ändern – wer hält in diesem Moment die Definition Ihres Geschäfts in der Hand?

Die drei Konzerne haben mit hartem Geld für die Branche bewiesen, dass diese Schicht es wert ist, gebaut zu werden. Aber sie haben damit zugleich diese Rechenaufgabe jedem Unternehmen auf den Tisch gelegt. Yuanfengs drei „Kunden” waren kein technischer Unfall, sondern der zwangsläufige Preis dafür, die Definition aus der Hand zu geben; und jene als „niedriges Risiko” fehleingeschätzte H-Gruppe war nur die erste Rechnung.

Eine Schicht, auf die sich alle verlassen, hat historisch nie dauerhaft einem Einzigen gehört. Diesmal gibt es keinen Grund, dass es anders wäre.

npm i -g @objectstack/cli && os start

Definieren Sie Ihr erstes Geschäftsobjekt, lassen Sie seine Daten aus Ihren beiden bestehenden Systemen kommen und machen Sie dann git commit in Ihr eigenes Repository – in diesem Moment ist die Definition des Geschäfts in Ihre Hand zurückgekehrt, statt im Backend irgendeines Anbieters zu liegen.