Enterprise-AI-Ontology: Warum die semantische Geschäftsschicht offen sein sollte
KI im Unternehmen braucht eine governte semantische Schicht. Entscheidend ist, diese Definition offen, prüfbar und portabel zu halten, während die Runtime Verantwortung für Ausführung, Rechte und Audit übernimmt.
Kurz gesagt: Palantir hat bewiesen, dass KI eine governte geschäftliche Semantikschicht braucht, um ins Unternehmen zu gelangen – doch diese Schicht sollte ein offenes Protokoll sein, das Ihnen gehört, wie Linux, und nicht in einer geschlossenen Plattform eingesperrt. Öffnen Sie die Definitionsschicht; verdienen Sie an der Runtime.
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: Die „Definitionsschicht”, von der ein ganzes Ökosystem abhängt, wird am Ende offen – weil niemand es wagt, sein Vermögen auf der Grammatik eines einzelnen Anbieters zu errichten. Die „Ausführungsschicht” darf geschlossen bleiben und Geld kosten – weil Betrieb laufende Wartung, Performance und Verantwortung bedeutet, also echte, wiederkehrende Kosten. AWS selbst ist der größte Beweis: Definitionen gehören der Community; sie zu betreiben ist das Geschäft.
Eine semantische Geschäftsschicht ist eine Definitionsschicht wie aus dem Lehrbuch. Von Ihrem Objektmodell, Ihren Berechtigungsregeln und Freigabeprozessen werden Ihre Anwendungen, Ihre Agents und Ihre Audit-Systeme abhängen. Je mehr davon abhängt, desto weniger gehört es in die Plattform-Datenbank eines Anbieters – und desto mehr gehört es als Dateien in Ihr eigenes Repository: lesbar, versioniert, 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 im ObjectStack-Protokoll, 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 Runtime (ObjectOS) liest diese Definition und erzeugt die Datenbanktabellen, die REST-API, die Verwaltungsoberfläche – und die governten Werkzeuge, die ein KI-Agent direkt aufrufen kann. Rabatte über 30 % brauchen eine Finanzfreigabe? Das ist eine Prozessdefinition an diesem Objekt: ebenso deklarativ, ebenso in der Versionskontrolle.
Daraus folgen unmittelbar drei Konsequenzen:
- 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 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.
- 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.
- 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”.
Das Protokoll gehört der Community; die Runtime ist das Geschäft
Jetzt schließt sich das Argument.
Das Ontologie-Urteil ist richtig – Palantir hat es für die ganze Branche bewiesen. Aber nach dem Muster „offene Definitionen, bezahlte Runtime” ist die gesunde Form dieser Schicht im KI-Zeitalter: Das semantische Geschäftsprotokoll gehört dem offenen Ökosystem, wie Linux – und eine governte Runtime führt es in Ihrer eigenen Umgebung aus.
Genau das ist die Arbeitsteilung zwischen ObjectStack und ObjectOS:
- ObjectStack ist das offene Protokoll zur Beschreibung von Geschäftsanwendungen (Apache 2.0): Objekte, Beziehungen, Berechtigungen, Prozesse, APIs, UI und KI-Werkzeuge, einmal definiert. Es lebt in Ihrem Repository – diffbar, portabel, von jedem Agent lesbar – und damit im öffentlichen Internet, in den Trainingsdaten jedes künftigen Modells.
- ObjectOS ist die Runtime für diese Definitionen: Sie führt alles auf Ihren Servern, gegen Ihre Datenbank aus, erzwingt Berechtigungen zur Laufzeit und schreibt das Audit-Protokoll. Governance steht nicht im Prompt, sondern in der Ausführungs-Engine.
Auf der einen Seite: ein Protokoll, das sich jedes Team und jeder Agent leisten, verstehen und mitnehmen kann – heute. Auf der anderen: das, wofür Unternehmen wirklich zahlen – Hosting, Compliance, Multi-Umgebungs-Releases, jemand, der für den Betrieb geradesteht. Die Definitionen gehören Ihnen. Die Mühe, sie zu betreiben, ist unser 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 es zur Datenbanktabelle, zur API, zur Verwaltungsoberfläche und zu einem Werkzeug wird, das eine KI sicher aufrufen kann. Jeder Aufruf trägt Berechtigungen. Jeder Aufruf schreibt ins Journal.