Palantir sagt, Sie brauchen 12 Monate, bevor KI-Agenten eingesetzt werden. Die Daten sprechen jedoch eine andere Sprache.

Die meisten Enterprise-AI-Strategien beginnen mit derselben Annahme: erst die Daten richtig machen, dann die Technologie einsetzen. Das klingt verantwortungsvoll. Das klingt gründlich. Und in vielen Fällen ist es genau der Grund, warum KI-Projekte es nie bis in die Produktion schaffen.

Palantir hat eine der ehrgeizigsten Versionen dieser Philosophie aufgebaut. Ihre 12-Schichten-Agentenarchitektur stellt die Ontology, ein strukturiertes semantisches Modell der gesamten Organisation, in den Mittelpunkt von allem. KI-Agenten fragen Objekte ab, lösen freigegebene Aktionen aus und arbeiten innerhalb einer zentralisierten Datenebene, die jede Beziehung und jeden Workflow im Unternehmen abbildet.

Es ist beeindruckende Ingenieurskunst. Es ist aber auch eine Philosophie, die Unternehmen auffordert, Monate, manchmal ein ganzes Jahr, in den Aufbau ihrer Datenbasis zu investieren, bevor ein einziger Agent einen echten Prozess berührt. Für die meisten Unternehmen ist genau dieser Zeitrahmen der Ort, an dem KI-Strategien sterben.

Was Palantir richtig erkennt

Die Diagnose ist größtenteils richtig.

Die meisten Unternehmen sind nicht datenbereit. Eine Gartner-Umfrage unter 183 Finanzverantwortlichen ergab, dass zwar 59 % angeben, KI in ihrer Finanzfunktion einzusetzen, die Verbreitung jedoch stagniert ist, nachdem sie von 37 % im Jahr 2023 auf 58 % im Jahr 2024 gestiegen war. Die Lücke zwischen „wir haben KI“ und „KI liefert Wert“ wird immer größer. Laut dem Journal of Accountancy berichten nur 7 % der CFOs von starken Auswirkungen ihrer KI-Investitionen.

Die Gründe sind genau die, die Palantir benennt. Daten liegen in Silos. Geschäftslogik existiert in den Köpfen der Menschen, nicht in Systemen. Niemand hat die Sonderregel dokumentiert, wie Rechnungen in Spanien im Vergleich zu Deutschland funktionieren. Die KI stößt auf reale Komplexität und scheitert.

Palantirs Lösung besteht darin, all diese Komplexität im Voraus zu modellieren. Die Ontology aufbauen. Jedes Objekt, jede Beziehung, jede Berechtigung abbilden. Dann Agenten agieren lassen.

Die Logik ist stimmig. Das Problem ist der Zeitrahmen.

Die 12-Monats-Falle

Hier ist, was tatsächlich passiert, wenn ein Unternehmen sich vor dem Einsatz von Agenten auf monatelange Datenvorbereitung festlegt.

Monat eins bis drei: Workshops, Daten-Audits, Abstimmung mit Stakeholdern. Monat vier bis acht: Aufbau der semantischen Schicht, Anbindung von Systemen, Auflösen von Konflikten darüber, wie verschiedene Abteilungen dieselben Daten definieren. Monat neun bis elf: Tests, Governance-Prüfungen, Compliance-Checks. Monat zwölf: Der erste Agent berührt endlich einen echten Prozess.

Bis dahin haben sich drei Dinge verändert. Die KI-Modelle sind eine Generation weiter als das, wofür Sie geplant hatten. Ihre Wettbewerber haben vor neun Monaten etwas mit 80 % Genauigkeit ausgeliefert und seither die Produktionserkenntnisse genutzt, um es kontinuierlich zu verbessern. Und der Executive Sponsor, der das Budget genehmigt hat, fragt, warum es keine Ergebnisse gibt.

Das ist keine Hypothese. Gartner prognostiziert, dass bis Ende 2027 über 40 % der Agentic-AI-Projekte eingestellt werden, größtenteils wegen steigender Kosten und weil es nicht gelingt, innerhalb der Geduldsfenster des Managements Wert zu liefern. Die meisten davon sind keine technischen Fehler. Es sind Timing-Fehler.

Der ontology-first-Ansatz scheitert nicht, weil er falsch ist. Er scheitert, weil den meisten Organisationen die Zeit, das Budget oder die Unterstützung des Managements ausgeht, bevor der erste Agent überhaupt Wert schafft.

Die produktionsorientierte Alternative

Es gibt einen anderen Weg, sich der Enterprise-AI-Reife zu nähern. Statt die gesamte Organisation zu modellieren, bevor Agenten ausgerollt werden, beginnen Sie mit einem schmerzhaften Prozess. Bauen Sie etwas, das besser ist als manuelle Arbeit. Bringen Sie es mit menschlicher Aufsicht in die Produktion. Lassen Sie es herausfinden, welche Daten es tatsächlich braucht.

Dieser Ansatz funktioniert wegen einer kontraintuitiven Wahrheit: Man kann nicht wissen, welche Daten wichtig sind, bevor ein Agent auf echte Workflows trifft. Die Ausnahme für Spanien, die niemand dokumentiert hat? Sie finden sie erst, wenn der Agent Rechnungen verarbeitet und bei einer spanischen Rechnung einen Fehler macht. Die Geschäftslogik, die im Kopf einer Person steckt? Sie wird sichtbar, wenn die Ausgabe des Agents nicht dem entspricht, was diese Person erwartet.

Die Hälfte der Sonderfälle, die produktionsreife Agenten heute handhaben, wurde in der Produktion entdeckt, nicht in der Planung. Kein noch so aufwendiges Data Modeling im Vorfeld hätte sie ans Licht gebracht.

Dell CFO David Kennedy beschrieb diese Realität im März 2026: „Sie sind nur so gut wie die Daten, die Sie haben, also müssen Sie sicherstellen, dass sie sauber sind. Und dann müssen Sie den Agenten in das richtige Format lenken, weil ein Agent 24/7 arbeiten will.“ Er setzt Agenten jetzt für Abstimmungen und Buchungssätze ein, nicht erst nach einem Jahr Datenvorbereitung.

Goldman Sachs verfolgte einen ähnlichen Weg und setzte von Claude angetriebene Agenten ein für Transaktionsabstimmung, Handelsbuchhaltung und Kunden-Onboarding. Das Unternehmen verbrachte sechs Monate damit, Anthropic-Ingenieure in spezifische Workflows mit strengen Zugriffskontrollen einzubetten. Sie bauten nicht zuerst eine 12-monatige Ontology. Sie begannen mit gezielten Prozessen und lernten unterwegs dazu.

Warum Einfachheit schlägt Komplexität

Palantirs Architektur hat 12 Ebenen. Viele der selbstlernenden Systeme, die heute in Unternehmen produktiv laufen, nutzen etwas viel Einfacheres: einfache Textkorrekturdateien.

Wenn ein Agent einen Fehler macht, korrigiert ihn ein Mensch. Diese Korrektur wird gespeichert. Der Agent liest sie beim nächsten Mal und macht denselben Fehler nicht noch einmal. Das Format ist oft so schlicht wie eine Markdown-Datei. Kein Wissensgraph. Keine Ontology. Text, den jede nicht-technische Person öffnen und verstehen kann.

Das klingt naiv, bis man bedenkt, was es ermöglicht. Wenn ein Kunde fragt „warum hat der Agent das getan?“, öffnen Sie die Datei und zeigen es ihm. Wenn etwas schiefgeht, können Sie genau sehen, was der Agent wann gelernt hat. Wenn Sie ein Verhalten zurücksetzen müssen, löschen Sie eine Zeile Text.

Erklärbarkeit ist keine Funktion, die man nach dem Aufbau einer ausgefeilten Architektur einfach ergänzt. Sie ist eine Eigenschaft davon, Dinge so einfach zu halten, dass Menschen sie tatsächlich prüfen können.

Die 80-%-Schwelle, die die meisten Unternehmen verpassen

Es gibt ein verwandtes Missverständnis, das in der ontology-first-Philosophie steckt: dass man nahezu perfekte Genauigkeit braucht, bevor man einen Agenten einsetzt.

Das brauchen Sie nicht. Sie brauchen nur, dass der Agent besser ist als das, was jetzt passiert.

Eine typische Erfahrung bei Enterprise-AI-Implementierungen: Ein HR-Agent wird für Recruiting gebaut, und die anfängliche Genauigkeit liegt bei rund 80 %. Der Reflex ist, ihn aus der Produktion zu nehmen und die Datenpipeline zu verbessern. Aber dann prüft jemand den menschlichen Ausgangswert und stellt fest, dass die Menschen Fehler in einer ähnlichen oder höheren Rate machten. Der Agent war bereits besser als der Prozess, den er ersetzen sollte.

Nicht alle Fehler sind gleich. Einige Variablen brauchen 99 % Genauigkeit. Andere sind mit 85 % völlig in Ordnung. Entscheidend ist zu verstehen, welche welche sind, und das lernt man in der Produktion, nicht in der Planung.

Mittelständische Unternehmen, die KI-Agenten im Finanzwesen einsetzen, haben die Finanzabschlusszyklen laut den Benchmarks der Hackett Group 2026 von 6,2 Tagen auf 1,8 Tage verkürzt. Sie haben nicht auf perfekte Daten gewartet. Sie sind mit dem gestartet, was sie hatten, und haben von dort aus verbessert.

Wann die Ontology sinnvoll ist – und wann nicht

Das ist kein Argument dafür, dass Dateninfrastruktur keine Rolle spielt. Doch, sie spielt eine Rolle. Schlecht verbundene Systeme, undokumentierte Geschäftslogik und inkonsistente Datenformate sind echte Probleme, die gelöst werden müssen.

Die Frage ist das Timing.

Palantirs Ansatz löst Datenprobleme, bevor ein Agent überhaupt eingesetzt wird. Der produktionsorientierte Ansatz löst sie, während Agenten sichtbar machen, was tatsächlich zählt. Der erste liefert Ihnen ein vollständiges Modell. Der zweite ein gezieltes Modell, das auf realen operativen Anforderungen basiert.

Für Organisationen mit unbegrenztem Budget, erstklassigen Engineering-Teams und geduldigen Executive-Sponsoren kann der ontology-first-Ansatz funktionieren. Palantirs 571 Enterprise-Kunden und das kommerzielle Wachstum von 137 % im Jahresvergleich beweisen, dass das Modell einen Markt hat.

Aber für die überwältigende Mehrheit der Unternehmen ist die Rechnung einfacher. Fast 60 % der Finanzteams pilotieren oder implementieren KI, und die meisten werden weder das Budget noch den Zeitrahmen für ein einjähriges Datenvorbereitungsprojekt haben. Sie brauchen Agenten, die mit unvollständigen Daten arbeiten, aus Korrekturen lernen und in Wochen statt in Quartalen Wert liefern können.

Beginnen Sie mit dem Chaos

Palantir fragt: „Sind Ihre Daten bereit für KI-Agenten?“

Eine bessere Frage: Welcher Prozess ist schmerzhaft genug, dass selbst ein Agent mit 80 % Genauigkeit eine Verbesserung wäre?

Beginnen Sie dort. Setzen Sie ihn mit menschlicher Aufsicht ein. Lernen Sie, was bricht. Beheben Sie es. Nach 30 Tagen wissen Sie, ob es funktioniert. Nach 90 Tagen haben Sie etwas, das skaliert. Nach 12 Monaten haben Sie ein produktionsgetestetes System, das auf echten operativen Daten basiert, nicht auf einem theoretischen Modell davon, wie Ihre Organisation arbeiten sollte.

Die Datenebene kann später kommen, gestützt auf das, was Sie tatsächlich gelernt haben. Die Agenten sollten jetzt starten.