Enterprise-AI-Ontologie: Warum Definition und Runtime offen sein sollten

Kurz gesagt: Dieser Beitrag argumentierte im Juni 2026, dass sowohl die typisierte App-Definition als auch die Runtime, die sie ausführt, offen sein sollten. Seitdem hat die Branche Teile dieses Arguments von sich aus eingeräumt. Palantirs Ontology MCP wurde in der Woche des 16. Juni 2026 allgemein verfügbar – vier Tage nach Erscheinen dieses Textes – und machte die Objekte und Aktionen einer Ontologie über ein offenes Protokoll für jeden Agent aufrufbar; im August begann Palantir, Ontologie-Definitionen in ein versioniertes Repository zu verlegen. Über Portabilität entscheiden drei Schichten – Schnittstelle, Definition, Runtime –, und 2026 öffnete die erste, begann die zweite zu öffnen und ließ die dritte genau dort, wo sie war. Die Runtime ist die letzte geschlossene Schicht, und sie ist die Hälfte dieses Arguments, über die es sich noch zu streiten lohnt.

Beginnen wir mit einer Geschichte, die Sie vermutlich selbst schon miterlebt haben.

Ein Unternehmen startet ein Projekt „KI-Assistent”. Woche eins: Die Demo ist beeindruckend. Jemand exportiert eine Kopie der Kundendaten, füttert ein Modell damit – und es kann tatsächlich beantworten, „welche Kunden in der Region Ost ein hohes Abwanderungsrisiko haben”. Die Geschäftsführung sieht es und genehmigt sofort einen größeren Pilot.

Monat drei: Die Produktionsdaten sollen angebunden werden. Das Security-Team kommt herein und stellt drei Fragen:

• Welche Daten kann die KI sehen? Wenn Vertriebler A nach dem „unternehmensweiten Leistungsranking” fragt – liest sie dann auch die Provisionen aller anderen vor?
• Sie soll Aktionen ausführen – Rabatte ändern, Verträge versenden. Mit wessen Berechtigungen? Und wer haftet, wenn etwas schiefgeht?
• Wenn die Revision fragt, „wer diesen Rabatt genehmigt hat” – wo ist das Protokoll für den Teil, den die KI erledigt hat?

Das Projektteam hat keine Antworten. Nicht aus Nachlässigkeit – sondern weil die Architektur schlicht keine Schicht enthält, die diese Fragen beantworten könnte. Die Daten sind über ein Dutzend Systeme verstreut. Berechtigungen stecken im Code der einzelnen Anwendungen. Die Regel für „Rabattfreigabe” existiert vor allem im Kopf eines erfahrenen Mitarbeiters. Die KI starrt auf rohe Tabellen und rohe Schnittstellen – und keine Intelligenz der Welt kann Unternehmensregeln von einem Ort lesen, an dem sie nie niedergeschrieben wurden.

Monat neun: Der Pilot endet still. Das Modell hat nicht an Fähigkeit verloren. Es hat verloren, weil niemand bereit war zu unterschreiben.

Die Branche hat einen Namen für das, was fehlte: eine Ontologie – eine strukturierte, maschinenlesbare semantische Schicht, die explizit definiert, welche Geschäftsobjekte existieren, wie sie zusammenhängen, wer was mit ihnen tun darf und wo jede Aktion protokolliert wird.

Was Palantir richtig gesehen hat

Das Unternehmen, das die Ontologie vom Forschungskonzept zur kommerziellen Tatsache gemacht hat, ist Palantir. Es lohnt sich, ehrlich hinzusehen, warum es erfolgreich war – je fairer der Blick, desto schärfer die Frage, die folgt.

Palantir Foundry tut im Kern zwei Dinge. Erstens: Es integriert die verstreuten Daten eines Unternehmens in eine einheitliche Ontologie-Schicht. Kunden, Anlagen und Aufträge sind keine Dutzenden Tabellen mehr, sondern typisierte Geschäftsobjekte mit Beziehungen und Eigenschaften. Zweitens: Es bündelt jede Schreiboperation in governte Actions – jede validiert, berechtigt und vollständig auditiert. Seit 2023 richtet AIP diese Architektur direkt auf große Sprachmodelle: Das LLM berührt nie die Datenbank; es kann nur governte Werkzeuge aufrufen, die die Ontologie-Schicht bereitstellt. Modelle sind austauschbar. Die Grenze bleibt.

Warum ist das teuer? Weil das Problem, das es löst, wirklich teuer ist. Zwanzig Jahre gewachsener Altsysteme in eine saubere Ontologie zu entwirren, erfordert Palantirs Forward Deployed Engineers, die sich System für System vorarbeiten und Begriff für Begriff abgleichen – Arbeitsintensität im wörtlichsten Sinn. Die Kunden sind Regierungen, Verteidigung, Banken und Energiekonzerne, für die „jeder KI-Schritt innerhalb der Berechtigungen, jeder Schritt protokolliert” eine harte Anforderung mit passendem Budget ist. Verträge beginnen im Millionenbereich – und werden verlängert, weil sie tatsächlich die drei Fragen beantworten, die einem CISO am wichtigsten sind. Dieselben drei Fragen aus der Eingangsgeschichte.

Palantirs Börsenwert beweist also keine Vertriebsmaschine. Er beweist ein Architekturoteil: Damit KI ins Unternehmen kommt, muss zuerst eine governte semantische Geschäftsschicht existieren. Dieses Urteil muss niemand mehr verteidigen.

Neu durchdacht werden muss die nächste Frage: Welche Form soll diese Schicht haben? Denn einige Dinge ändern sich gerade.

Software wird zunehmend von KI geschrieben

Die erste Veränderung ist die sichtbarste: Anwendungen selbst werden zunehmend von KI geschrieben.

„Ein maßgeschneidertes Spesenfreigabe-System für ein 50-Personen-Team bauen” war früher ökonomisch absurd – die Entwicklungskosten überstiegen den Schmerz. Heute liefert ein KI-Agent es an einem Nachmittag. Individuelle Unternehmenssoftware wandelt sich vom knappen Gut zur Massenware, und die Gesamtnachfrage wird explodieren.

Beachten Sie, wo sie explodiert: im Long Tail. In Teams, die auf keiner Interessentenliste eines Enterprise-Anbieters je auftauchen werden – kein Beschaffungsprozess, kein Implementierungsbudget, keine POC-Gremien. Sie sagen einem Agent einfach „bau etwas, das funktioniert” – und nutzen es noch am selben Tag.

Ein Modell, das auf Forward Deployed Engineers und Millionenverträgen beruht, erreicht diesen Markt strukturell nicht. Das ist keine Kritik; es sind schlicht zwei verschiedene Märkte. Aber jedes System in diesem neuen Markt wird gegen dieselben drei Sicherheitsfragen vom Anfang prallen – nur steht dann kein Forward Deployed Engineer daneben.

Der Nächste, der Technologie auswählt, ist ein Agent

Die zweite Veränderung ist leiser, geht aber tiefer: Der Akt der Technologieauswahl selbst wandert vom Menschen zur KI.

Bitten Sie heute einen Agent, „ein Kundenverwaltungssystem zu bauen”, greift er höchstwahrscheinlich zu Next.js und Postgres. Warum? Niemand hat Werbung in seinem Kopf geschaltet. Diese Technologien sind offen, umfassend dokumentiert und massiv in seinen Trainingsdaten vertreten. Der Agent hat Hunderttausende Verwendungen gesehen und kennt jedes Schlagloch.

Das erzeugt etwas, das es vorher nicht gab: Für Entwicklertechnologie sind öffentlicher Protokolltext und Open-Source-Code jetzt selbst der Vertriebskanal. Je offener ein Protokoll ist – je mehr darüber diskutiert wird, je mehr Code zum Lernen existiert –, desto besser versteht es die nächste Modellgeneration, und desto eher wählen Agents es als Standard. Die Schleife verstärkt sich selbst.

Eine geschlossene Plattform hat daraus zwei Auswege. Der teure: das Format selbst öffnen, damit Modelle es lernen und Agents ungefragt danach greifen. Der billige: das Format geschlossen halten und am Rand ein offenes Protokoll übernehmen – Agents können die Plattform dann aufrufen, obwohl sie sie weiterhin nicht lernen können.

Als dieser Beitrag zuerst erschien, behauptete er, eine geschlossene Plattform könne diese Schleife schlicht nicht betreten. Binnen einer Woche war das zu stark: Die etablierten Anbieter nahmen den billigen Ausweg, und er funktionierte. Was bleibt, ist die engere und wichtigere Aussage: Eine Schnittstelle, die ein Agent aufrufen kann, ist keine Definition, aus der ein Agent lernen kann – und keines von beidem ist eine Runtime, die Sie mitnehmen können. Was die Etablierten daraufhin taten – und das eine, was sie nicht taten – steht weiter unten.

Moment – haben geschlossene Plattformen nicht schon oft gewonnen?

Spätestens jetzt sollte ein kluger Einwand auftauchen: Offenheit gewinnt nicht immer. Die Cloud-Ära hat AWS gewonnen. Mobile hat das iPhone gewonnen. Beide geschlossen.

Der Einwand verdient eine ernsthafte Antwort – denn sie legt das eigentliche Muster frei.

Sehen Sie sich an, womit AWS Geld verdient: Es hostet Linux, Kubernetes, Postgres – offene Standards, durch und durch. Das iPhone ist geschlossen, aber jedes Paket, das es sendet, fährt auf TCP/IP und HTTP. Noch weiter zurück: Datenbankanbieter bekämpften sich erbittert, während SQL – die Sprache selbst – öffentlich blieb; die Container-Orchestrierungskriege endeten damit, dass alle dasselbe offene OCI-Image-Format nutzen.

Das Muster ist bemerkenswert konsistent: Das portable Fundament, von dem ein ganzes Ökosystem abhängt, wird am Ende offen – sowohl die Definition als auch die grundlegende Runtime, die sie interpretiert. Anbieter erzielen weiterhin wiederkehrende Umsätze, aber mit der betriebenen Produktionserfahrung: Hosting, Upgrades, Sicherheitspakete, Performance, Support und Verantwortung. AWS ist der beste Beweis. Linux, Kubernetes und Postgres bleiben offen; AWS verdient am zuverlässigen Betrieb.

Eine semantische Geschäftsschicht ist genau ein solches Fundament. Von Ihrem Objektmodell, Ihren Berechtigungsregeln, Freigabeprozessen und der Runtime-Semantik, die sie durchsetzt, werden Anwendungen, Agents und Audit-Systeme abhängen. Je mehr davon abhängt, desto weniger gehört eine der beiden Hälften in die Plattform eines Anbieters. Definitionen sollten als lesbare, versionierte Dateien in Ihrem Repository liegen; eine kompatible Runtime sollte selbst hostbar und austauschbar sein. Eine offene Datei, die nur eine kostenpflichtige Engine ausführen kann, ist nicht wirklich portabel.

Unternehmen haben zwanzig Jahre damit verbracht, ihre Daten aus einem geschlossenen System nach dem anderen zu befreien. Sie sollten das KI-Zeitalter nicht damit verbringen, etwas noch Grundlegenderes – die Definition des Geschäfts selbst – erneut einzusperren.

Ontology MCP öffnete die Schnittstelle. Die Runtime blieb zu.

Dieses Muster wurde fast sofort auf die Probe gestellt, und das Ergebnis ist ein besserer Beleg, als die Vorhersage einer war.

Vier Tage nach Erscheinen dieses Beitrags wurde Palantirs Ontology MCP für Foundry-Enrollments allgemein verfügbar, beginnend mit der Woche des 16. Juni 2026 (Palantirs Dokumentation). Objekttypen, Aktionstypen und Funktionen werden in Werkzeuge des Model Context Protocol projiziert, sodass jeder MCP-fähige Agent die Ontologie lesen und ihre Abläufe in Gang setzen kann – ohne Integrationscode pro Agent-Framework. Microsoft zeigt dieselbe Schnittstelle als Preview in Fabric IQ.

Im August legte Palantir dann Ontologie-als-Code in Beta nach: Objekttypen, Links, Interfaces und Aktionen in TypeScript in einem Monorepo deklariert, wobei diese Code-Definitionen die Quelle der Wahrheit sind.

Nimmt man beide Schritte zusammen, hält das Substrat-Argument des vorigen Abschnitts – aber nicht aus dem Grund, aus dem es geschrieben wurde. Das Substrat öffnet sich. Es öffnet sich, weil die Etablierten es selbst geöffnet haben, in der Reihenfolge, die sie am wenigsten kostete:

Schicht	Was sie ist	Wo 2026 sie zurückließ
Schnittstelle	Wie ein Agent die Ontologie aufruft	Offen. MCP, von den Plattformanbietern selbst übernommen
Definition	Die Objekte, Aktionen und Berechtigungen	Öffnet sich der Form nach. Als Code im Repository – landet weiterhin auf der Plattform eines Anbieters
Runtime	Was eine Aktion ausführt und die Regeln durchsetzt	Unverändert. Kein Anbieter lieferte eine, die anderswo läuft

Lesen Sie die dritte Zeile langsam, denn dort steckt das ganze Argument.

Eine offene Schnittstelle macht eine Ontologie aufrufbar. Definitionen im Repository machen sie lesbar und prüfbar. Keines von beiden macht sie anderswo lauffähig. Portabilität der Definition ist nicht Portabilität des Systems – ein Monorepo voller Ontologie-Code materialisiert sich am Ende doch auf einem Foundry-Enrollment. Und weil die Werkzeugfläche aus der Definition projiziert wird, entscheidet derjenige, der die Projektion betreibt, was die Werkzeuge sind. Eine Definitionsdatei führt von sich aus nichts aus.

Das ist die Zahl, um die es bei dieser Aktualisierung geht. Wendet man Palantirs dokumentierte Projektionsregel auf eine mittelgroße Anwendung an – 12 Objekttypen, 30 Aktionstypen, 6 veröffentlichte Funktionen –, erhält man 37 MCP-Werkzeuge, die ein offenes Protokoll sprechen, und darunter genau eine Engine, die auf irgendeines davon antworten kann. Die Schnittstelle wurde portabel. Die Abhängigkeit bewegte sich keinen Zentimeter.

Der stärkste Einwand, fair formuliert: Das meiste, was ein Team von Portabilität will, liegt inzwischen auf dem Tisch. Sie können Ihr Modell lesen, es als Diff prüfen, jeden Agent darauf richten – und analytische Semantik über eine anbieterneutrale Spezifikation austauschen, die 2026 den Apache Incubator erreichte. Wenn Ihre Ontologie nur jemals Fragen beantwortet, ist das nah genug an genug, und dieser Beitrag täte unredlich, etwas anderes zu behaupten.

Die Antwort ist dieselbe Linie, die eine Semantikschicht überhaupt erst von einer Ontologie trennt: Sie hält genau so lange, bis etwas geschehen muss. In dem Moment, in dem eine exponierte Aktion einen Datensatz ändert, ist alles, worauf es Ihnen ankommt – die Berechtigungsprüfung, die Transaktion, die Freigabe oberhalb eines Schwellwerts, die Audit-Zeile –, eine Eigenschaft der Engine, nicht der Datei und nicht des Protokolls. Den Satz können Sie exportieren. Die Durchsetzung nicht.

Nennen wir diese Lücke die letzte geschlossene Schicht. Das ist kein Vorwurf, sondern eine Beschreibung, wo die Kategorie stehen blieb. Zwei der drei Schichten öffneten sich in neun Monaten, größtenteils aus eigenem Antrieb. Die dritte bewegte sich gar nicht – weil sie die eine Schicht ist, die ein Plattformgeschäft nicht öffnen kann, ohne zu ändern, was es verkauft.

Wie diese „Definition” konkret aussieht

Genug Abstraktion. Hier ist ein Verkaufschancen-Objekt in der typisierten ObjectStack-App-Definition, gekürzt aus einem echten Beispiel:

export const Opportunity = ObjectSchema.create({
  name: 'crm_opportunity',
  label: 'Verkaufschance',
  fields: {
    name: Field.text({ label: 'Name', required: true }),
    account: Field.lookup('crm_account', { label: 'Kunde', required: true }),
    amount: Field.currency({ label: 'Betrag', min: 0 }),
    probability: Field.percent({ label: 'Wahrscheinlichkeit', defaultValue: 50 }),
    expected_revenue: Field.formula({
      label: 'Erwarteter Umsatz',
      expression: cel`amount * probability / 100`,
    }),
    discount_percent: Field.percent({ label: 'Rabatt %', max: 100 }),
  },
});

// Berechtigungen werden genauso deklariert: Vertrieb darf lesen und schreiben, nie löschen
export const SalesUser: Security.PermissionSet = {
  name: 'crm_sales_user',
  objects: {
    crm_opportunity: { allowRead: true, allowCreate: true, allowEdit: true, allowDelete: false },
  },
};

Es geht nicht um die Syntax. Es geht darum, dass diese wenigen Dutzend Zeilen das System sind. Die Open-Source-Runtime von ObjectStack liest die Definition und leitet daraus Datenbanktabellen, REST-API, Verwaltungsoberfläche und MCP-Werkzeuge ab; Berechtigungen und Audit werden dabei durchgesetzt. Rabatte über 30 % brauchen eine Finanzfreigabe? Das ist eine Prozessdefinition an diesem Objekt: ebenso deklarativ, ebenso versioniert. ObjectOS ergänzt um dieselbe App die kommerzielle Produktionserfahrung – Build und Ask im Browser, Team-Review und Freigaben, verwaltete Cloud- oder private Bereitstellung, SSO, Betrieb und Support – ohne Definition oder Engine wieder proprietär zu machen.

Daraus folgen unmittelbar drei Konsequenzen:

1. Die drei Sicherheitsfragen vom Anfang bekommen strukturelle Antworten. Was die KI sehen darf – steht im Berechtigungsset. Mit wessen Rechten sie handelt – sie handelt als der angemeldete Benutzer, von der ObjectStack-Runtime erzwungen, nicht im Prompt erbeten. Wo das Audit-Protokoll liegt – Menschen und Agents schreiben in dasselbe Journal: wer, was, wann, warum. Compliance liest ein Protokoll, nicht zwei.
2. Geschäftsänderungen werden zu Code-Reviews. Die KI will eine Verlängerungs-Erinnerung ergänzen? Was sie einreicht, ist ein Metadaten-Diff – welche Felder sich ändern, welche Berechtigungen sich bewegen, alles auf einen Blick. Und weil Definitionen versioniert sind, lassen sich Fehler zurückrollen.
3. Das ganze System passt in das Kontextfenster eines Agents. Ein typisches Enterprise-Modul schrumpft von Zehntausenden Zeilen CRUD und Klebecode auf einige Hundert Zeilen Deklarationen – klein genug, dass eine KI jede Abhängigkeit von Anfang bis Ende liest und dann sicher über Daten, API, UI und Berechtigungen hinweg in einer einzigen Änderung refaktoriert. Das ist die Grenze zwischen „KI als Mit-Maintainer” und „KI als Autovervollständigung”.

Definition und portable Runtime gehören der Community; Betrieb ist das Geschäft

Jetzt schließt sich das Argument.

Das Ontologie-Urteil ist richtig – Palantir hat es für die ganze Branche bewiesen. Als dieser Beitrag zuerst erschien, war „offene Definition, exklusive bezahlte Engine” ein Fehlermuster, vor dem zu warnen sich lohnte. Neun Monate später ist es keine Warnung mehr. Es ist eine faire Beschreibung dessen, wo die Kategorie gelandet ist – erreicht über je eine vernünftige Entscheidung von Anbietern, die alles öffneten außer dem, was sie verkaufen. Das macht die Alternative leichter auszusprechen, nicht schwerer: Typisierte Geschäftsdefinition und portable governte Runtime gehören zum offenen Ökosystem; bezahlt wird die betriebene Produktionserfahrung darum herum.

Genau das ist die Arbeitsteilung zwischen ObjectStack und ObjectOS:

• ObjectStack ist eine offene Geschäftsontologie (open business ontology): die typisierte App-Definition zusammen mit der Open-Source-Runtime, die sie ausführt (Apache 2.0). Objekte, Beziehungen, Berechtigungen, Prozesse, APIs, UI und KI-Werkzeuge werden einmal im Repository definiert; die Runtime leitet Datenbank, REST-API, gerenderte UI und MCP-Server ab und erzwingt bei jedem Aufruf Berechtigungen und Audit. Definition und Engine sind diffbar, selbst hostbar und portabel – wobei die zweite Hälfte genau jene ist, die der Rest der Kategorie geschlossen ließ.
• ObjectOS ist die kommerzielle Produktionsplattform um dieselben ObjectStack-Apps. Sie verkauft Build und Ask im Browser, Team-Review und Freigaben, den Betrieb verwalteter Cloud- oder privater Bereitstellungen, SSO, Enterprise-Kontrollen und Support. Sie ist keine geschlossene Ausführungs-Engine, die Ihnen die Ontologie wieder entzieht.

Auf der einen Seite: App-Definition und portable Runtime, die jedes Team und jeder Agent verstehen, selbst hosten und mitnehmen kann. Auf der anderen: die Produktionserfahrung, für die Unternehmen wirklich zahlen – gemeinsames Authoring, Freigaben, Hosting, private Bereitstellung, SSO, Support, Upgrades und Betriebsverantwortung. Anwendung und Basis-Runtime gehören Ihnen. Der zuverlässige Betrieb für ein Team ist das Geschäft.

Schluss

Jener KI-Pilot, der im neunten Monat starb, hat nie gegen Modellfähigkeiten verloren. Er verlor gegen das Fehlen einer semantischen Schicht, die ein Security-Team hätte abzeichnen können. Das teuerste Unternehmen der Branche hat ein Jahrzehnt lang bewiesen, wie viel diese Schicht wert ist – und 2026 hat in neun Monaten etwas Engeres und Nützlicheres bewiesen: Die Teile davon, die billig zu öffnen waren, sind jetzt offen. Die Schnittstelle ist ein öffentliches Protokoll. Die Definition ist eine Datei, die Sie lesen können. Übrig bleibt die Engine, die aus dem Zweiten das Erste macht und dabei die Regeln durchsetzt – und auf dieser Schicht öffnete sich nichts.

Damit hat die Frage vom Juni eine schärfere Form. Nicht mehr „sollte die Ontologie offen sein?” – das ist entschieden, und die Anbieter haben es entschieden. Sondern: Wenn die letzte geschlossene Schicht ausgerechnet die ist, die Ihre Geschäftsregeln ausführt – wessen Engine soll das sein?

Wenn Sie prüfen wollen, ob davon etwas wahr ist:

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

In fünf Minuten definieren Sie Ihr erstes Geschäftsobjekt – und sehen zu, wie die offene ObjectStack-Runtime daraus Datenbanktabelle, API, Verwaltungsoberfläche und ein Werkzeug macht, das eine KI sicher aufrufen kann. Jeder Aufruf trägt Berechtigungen und schreibt ins Journal. Braucht Ihr Team Build und Ask im Browser, gemeinsame Reviews und Freigaben, verwaltete Cloud- oder private Bereitstellung, SSO und Support, betreibt ObjectOS dieselbe ObjectStack-App; sie wird nicht durch ein proprietäres Format oder eine exklusive Engine ersetzt.