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

Kurz gesagt: Palantir hat bewiesen, dass KI eine governte geschäftliche Semantikschicht braucht, um ins Unternehmen zu gelangen. Diese Schicht sollte jedoch aus einer offenen, typisierten App-Definition und einer portablen Open-Source-Runtime bestehen – nicht aus einer „offenen Datei”, die weiter von der Engine eines einzelnen Anbieters abhängt. Definition und Ausführungsbasis bleiben offen; bezahlt wird die betriebene Produktionserfahrung.

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 kommt in diese Schleife nicht hinein. Ihr Ontologie-Format, ihre Aktionssemantik, ihr Berechtigungsmodell liegen hinter Dokumentationsmauern und Verträgen. Modelle können sie nicht lernen; Agents können nicht im Selbstbedienungsmodus einsteigen. Sie kann von einem Beschaffungsprozess ausgewählt werden – aber nicht von einem Agent gewählt werden. Je mehr Software von Agents geschrieben wird, desto weniger ist das ein Marketingproblem. Es ist Abwesenheit vom Kanal.

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.

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. Die gesunde Form dieser Schicht im KI-Zeitalter lautet aber nicht „offene Definition, exklusive bezahlte Engine”. Sie lautet: 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 die offene, typisierte App-Definition und Open-Source-Runtime (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.
• 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. Die nächste Aufgabe ist, dafür zu sorgen, dass sie kein Luxus der größten Konzerne bleibt.

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.