Skip to content
Zurück zu Technik
GenAI · 15 Min. Lesezeit

SaaS ist nicht tot - es nimmt Forward Deployed AI Engineers an Bord

Palantirs Behauptung, SaaS sei tot, ist provokativ falsch. Die nützliche Lesart ist, dass KI die Grenze zwischen Custom- und Packaged-Software verwischt - und die SaaS-Unternehmen, die das nächste Jahrzehnt gewinnen, kombinieren einen starken Plattformkern mit Forward Deployed AI Engineers und speisen jede Kundenengagement-Erfahrung zurück in die Plattform.

Teilen
Auf dieser Seite

Steve Bankers Forbes-Stück vom 16. Mai ist die zitierfähigste Enterprise-Software-Schlagzeile des Jahres bisher. Danny Lukus, Deployment-Stratege bei Palantir, erklärte dem Saal, dass SaaS tot sei - und verwies auf jedes Fortune-500-Finance-Team, das seine Operationen aus Excel heraus betreibt, als Beweisstück A. “We have humans doing manual data integration and creating their own logic. There are a lot of bad things that happen as a result of that.” Im selben Takt behauptete CTO Shyam Sankar, AI FDE - Palantirs KI-gestützter Forward Deployed Engineer - treibe SAP-ECC-zu-S/4HANA-Migrationen jetzt “in as little as 2 weeks.”

Der Markt nimmt es ernst. Software-Aktien verloren während des jüngsten “SaaSpocalypse”-Sell-offs in zwei Tagen über 300 Mrd. USD. Palantirs Q1-Umsatz wuchs um 85% auf über 6,5 Mrd. USD ARR. Sales und Marketing als Prozentsatz des Umsatzes brachen von 60% auf 23% ein. Die Net Dollar Retention liegt bei 139%. Die Zahlen sind ungewöhnlich genug, um den Rest der Branche zu zwingen, die These ernst zu nehmen, auch wenn sie halbgar ist.

Hier ist, was ich für die nützliche Lesart halte. “SaaS is dead” ist die falsche Schlagzeile. Die akkurate Schlagzeile ist, dass KI die Grenze zwischen Custom- und Packaged-Software verwischt und die SaaS-Unternehmen, die das nächste Jahrzehnt gewinnen, diejenigen sein werden, die einen starken Plattformkern mit Forward Deployed AI Engineers kombinieren - und entscheidend, jede Kundenengagement-Erfahrung zurück in die Plattform speisen. Dieser letzte Halbsatz ist der Teil, den alle übersehen, und er ist der Teil, der entscheidet, ob du als Plattform oder als Beratung endest.

Dieses Stück ist, was klassische SaaS-Unternehmen meiner Ansicht nach tatsächlich tun müssen.

Was Palantir tatsächlich anders macht

Um irgendein nützliches Argument darüber zu führen, ob SaaS tot ist, musst du zuerst präzise sein darüber, was Palantir tut, das fast kein anderes Softwareunternehmen tut. Die drei Teile zählen einzeln und zählen mehr zusammen.

1. Die Ontology

Die Ontology ist Palantirs struktureller Moat. Sie ist kein Data Lake. Sie ist eine semantische, ausführbare Repräsentation der Logik, Assets und Prozesse eines Unternehmens - ein digitaler Zwilling, gegen den KI-Agenten und Menschen operieren. Während ein traditionelles Data Warehouse unter der Applikationsschicht sitzt, sitzt die Ontology darüber und bildet die Daten aus SAP, Oracle, Custom-Systemen und operativen Quellen in ein einheitliches Geschäftsmodell ab, das weiß, was ein Contract, ein Plant, ein Part oder ein Customer in den spezifischen Begriffen deines Unternehmens bedeutet.

Das ist der Teil, den Wettbewerber am langsamsten begreifen. Die Ontology kompoundiert. Jeder Workflow, den du darauf baust, macht den nächsten günstiger. Jeder KI-Agent, den du darauf richtest, macht die Geschäftslogik haltbarer. Deshalb ist Palantirs 139% Net Dollar Retention strukturell anders als die 110% NDR eines typischen SaaS. Kunden geben jedes Jahr 39% mehr aus, nicht weil sie mehr Seats gekauft haben, sondern weil die Ontology mehr davon geworden ist, wie sie operieren.

2. Der Forward Deployed Engineer

Palantir liefert kein Produkt aus und lässt die Kunden zusehen, wie sie zurechtkommen. Sie betten Engineers in Kundenumgebungen ein und lassen sie die Produktions-Workflows auf der Plattform bauen. Das strukturierte Team ist scharf:

  • Delta (Engineer) schreibt Produktionscode, navigiert kaputte Daten, implementiert das System.
  • Echo (Stratege) versteht die politische und Workflow-Realität des Kunden und stellt sicher, dass die Arbeit tatsächlich adoptiert wird.

Die Spannung zwischen den beiden ist Design. Was von außen wie Beratung aussieht, ist die bewusste Konstruktion von Pattern-Daten: Jedes Deployment lehrt Palantir, was an diesem Kunden bespoke ist und was generalisierbar ist. Der Grund, warum das Modell keine Services-Falle ist - das ist der Teil, den die meisten Analysten übersehen - ist die explizite Pattern-Recognition-Funktion. Der eigentliche Job des FDE ist, Abstraktionen zu identifizieren, die wiederholt auftauchen, und sie zurück in die Plattform zu ziehen.

3. AI FDE: Forward Deployed Engineers als Agenten

Ende 2025 und über 2026 hinweg hat Palantir das FDE-Modell auf die KI selbst erweitert. AI FDE ist ein Agent, der Foundry über natürliche Sprache bedient: Datenpipelines bauen, Repositories managen, Ontology-Objekte konstruieren, Transformationen ausführen. Sankars Behauptung über zweiwöchige SAP-Migrationen ist davon nachgelagert - was früher ein Jahr menschlicher FDE-Arbeit plus Kundenteams brauchte, braucht jetzt Wochen AI-FDE-Arbeit plus eine viel kleinere menschliche Brücke.

Das ist der Teil, auf den die “SaaS is dead”-Rahmung tatsächlich zeigt, auch wenn sie ihn unter Wert verkauft. Die echte Veränderung ist nicht, dass KI SaaS ersetzt. Die echte Veränderung ist, dass KI die Kosten der Custom-Schicht, die schon immer über SaaS gesessen hat, kollabiert, und dieser Kollaps verändert die Mathematik jedes Enterprise-Software-Deals.

Warum “SaaS ist tot” provokativ falsch ist

Der Slogan ist gutes Marketing und schlechte Analyse. Drei Dinge sind gleichzeitig wahr, und der Slogan würdigt nur eines davon.

Wahr: Reines Packaged SaaS, ohne Integrationsschicht und ohne kundenspezifische Logik, stößt an eine strukturelle Wand. Der Punkt im Forbes-Stück, dass jedes Finance-Team Excel oben auf seinem SaaS laufen lässt, ist das Symptom, nicht die Diagnose. Packaged-Software hat schon immer einen kundenseitigen Build gebraucht, um tatsächlich zu passen. Dieser Build wurde historisch von Beratern, internen Engineering-Teams oder, im schlimmsten Fall, von Excel erledigt. KI eliminiert diese Schicht nicht. Sie kollabiert deren Kosten, und das verändert, wer den geschaffenen Wert gewinnt.

Wahr: Reine Custom-Software skaliert nicht. Jeder Dollar, den Palantir für ein FDE-Engagement berechnet, ist ein Dollar, den ein Wettbewerber für seine eigenen Engineers, eine Big-Four-Firma, eine Beratung oder interne Teams ausgeben könnte. Der Grund, warum Palantir gewinnt, ist nicht, dass ihre FDEs günstiger sind. Sind sie nicht. Der Grund, warum Palantir gewinnt, ist, dass die Arbeit, die der FDE produziert, zu einem Plattform-Asset kompoundiert (die Ontology und die Plattform-Level-Abstraktionen). Würdest du den Plattform-Feedback-Loop herausnehmen, wäre Palantir Accenture mit Hoodies.

Wahr: Die Grenze zwischen Custom und Packaged wird fließend, nicht verschwindend. Das richtige Mental Model für die nächste Dekade Enterprise-Software ist eine Plattform plus ein Service, der zu Plattform wird, wobei KI beide Hälften komprimiert. SaaS stirbt in dieser Welt nicht. Es entwickelt sich zur Package-plus-Deployment-plus-Feedback-Loop-Struktur, deren lautestes Beispiel Palantir ist.

Wenn du ein SaaS-CEO bist und die “SaaS is dead”-Schlagzeile beim Wort nimmst, überreagierst du. Wenn du den darunterliegenden Shift ernst nimmst, beginnst du, dein Geschäftsmodell um eine Struktur herum umzubauen, gegen die sich klassisches SaaS seit fünfzehn Jahren wehrt.

Die drei Dinge, die klassisches SaaS tun muss

Hier ist das Operating-Playbook, das ich jedem klassischen SaaS-Leadership-Team in die Hand drücken würde, das herauszufinden versucht, was es dieses Jahr und nächstes Jahr tun soll. Es gibt drei Moves, in Reihenfolge, und jeder funktioniert nur, wenn der vorherige steht.

Move 1: Halte die Plattform stark - und mache sie würdig zu kompoundieren

Der erste Instinkt eines SaaS-CEO, der die Palantir-Geschichte liest, wird falsch sein. Der Instinkt wird sein: “wir brauchen einen AI-Tab und einen Chatbot.” Das ist genau der Move, der nicht funktioniert.

Was funktioniert, ist in das Substrat der Plattform zu investieren, damit sie zunehmend komplexe kundenspezifische Logik absorbieren kann, ohne den Kern aufzublähen. Drei Eigenschaften zählen am meisten:

  • Ein echtes Datenmodell, keine CRUD-förmige Datenbank. Die meisten SaaS-Datenschichten sind für den kanonischen Use Case designt und widersetzen sich Abweichungen. Eine Plattform, die zu kompoundieren gebaut ist, hat ein semantisches Modell - Objekttypen, Beziehungen, abgeleitete Properties, Änderungshistorie - das den Edge Case des nächsten Kunden absorbieren kann, ohne das Schema zu forken. Du musst es nicht Ontology nennen. Du musst eines bauen.
  • API-first Komponierbarkeit. Jede Aktion, die die Plattform ausführt, muss durch Code adressierbar sein, nicht nur durch UI. Das ist Table Stakes für Agenten, um sie zu nutzen, und es ist auch die Vorbedingung dafür, dass Forward Deployed AI Engineers irgendetwas tun, das kompoundiert.
  • Ehrliche Erweiterbarkeit. Kundenspezifische Erweiterungen brauchen einen First-Class-Pfad, der den Kern nicht forkt. Die meisten SaaS-Architekturen erlauben “Customisation” nur über einen Feature-Toggle oder eine Konfigurationstabelle. Das ist nicht, was die agentische Ära braucht. Du brauchst eine Sandbox, in der Kundenlogik geschrieben, ausgeführt, gesteuert und - kritisch - in die Plattform promoted werden kann, wenn sie sich ihren Weg dorthin verdient.

Wenn du Move 1 nicht hinkriegst, wird dich kein Maß an Move 2 retten. Du wirst zu einem Services-Geschäft mit SaaS-Haut.

Move 2: Füge Forward Deployed AI Engineers als Service-Schicht hinzu

Das ist der Move, gegen den klassisches SaaS am meisten Widerstand leisten wird, weil er wie Services-Umsatz aussieht. Investoren hassen Services-Umsatz. Boards hassen Services-Umsatz. Senior Manager haben zwanzig Jahre damit verbracht, Services-Umsatz aus ihrer P&L herauszuholen, auf dem Weg, Pure-Play-SaaS zu werden.

Dieser Instinkt ist jetzt falsch, und der Grund, warum er falsch ist, ist, dass die Kostenstruktur von Services kollabiert ist. Ein Forward Deployed AI Engineer ist kein abrechenbarer menschlicher Berater. Es ist ein menschlicher Engineer, der mit Agenten mit fünf- bis zehnfachem Durchsatz arbeitet - in einigen Workflows viel mehr. Die Ökonomie von “FDE-style Engagement plus AIP-level Agenten plus Plattform-Leverage” sieht nicht aus wie ein Services-Geschäft mit 30% Bruttomarge. Sie sieht aus wie ein hochmargiges Plattformgeschäft mit einer eingebetteten Delivery-Abteilung.

Konkret bedeutet das für ein klassisches SaaS-Unternehmen:

  1. Stelle (oder baue) eine Forward Deployed AI Engineering-Funktion ein. Klein, senior, darf in Kundenumgebungen leben. Die Stellenbeschreibung ist näher an Staff Engineer als an Solutions Architect. Sie schreiben Produktionscode, sie implementieren Workflows in der Plattform, sie instrumentieren Outcomes, sie pairen mit Kundenteams.
  2. Statte sie ab Tag eins mit Agenten aus. AI-FDE-style Automatisierung ist der einzige Weg, wie die Mathematik aufgeht. Ohne Agenten mit relevantem Leverage erzeugst du erneut eine Beratung mit 30% Bruttomarge. Mit Agenten behältst du Plattform-Klasse-Margen.
  3. Verkaufe das Engagement nicht. Bündle es. Backe das FDE-Engagement in Onboarding und Expansion ein. Kunden wollen keine Software kaufen und dann einen Services-SOW unterschreiben. Sie wollen eine funktionierende Capability kaufen. Wenn du das FDE-Engagement wie einen SOW anfühlen lässt, kollabiert deine Sales-Velocity. Wenn du es sich wie die ersten neunzig Tage Value Delivery anfühlen lässt, beschleunigt sich die Expansion.

Das Modell aus No Rules Rules und aus meinem Stück über Empowered Teams gilt hier genauso wie innerhalb deiner eigenen Organisation. Forward Deployed AI Engineers empowern Kunden auf die gleiche Weise, wie Empowered Product Teams innerhalb deiner Organisation empowert sind. Du gibst ihnen Kontext - das Geschäftsproblem, die Daten des Kunden, die zu transformierenden Workflows - und lässt sie es lösen. Was du nicht tust, ist, die Entscheidungsfindung in irgendeinem Produktkomitee zu zentralisieren, das die Daten des Kunden nicht hat.

Move 3: Speise alles zurück in die Plattform

Das ist der Move, der entscheidet, ob du eine Plattform oder eine Beratung wirst. Es ist auch der Teil, den Palantir genagelt hat, der Teil, den die meisten services-lastigen Enterprise-Anbieter verfehlen, und der Teil, zu dem klassisches SaaS die engste kulturelle Passung in der Branche hat - wenn sie den Move bewusst machen.

Die Disziplin ist diese: Jedes Forward-Deployed-AI-Engineering-Engagement produziert drei Artefakte. Eines ist ein funktionierendes Kunden-Deployment. Das zweite ist ein dokumentiertes Set an Patterns - Abstraktionen, Primitiven, Edge Cases - die während der Arbeit auftauchten. Das dritte und wichtigste ist die Promotion-Entscheidung: Welche dieser Patterns gehören in die Plattform, und welche bleiben bespoke?

Die Promotion-Entscheidung braucht ein explizites Forum. Bei Palantir, so verstehe ich, passiert das durch einen engen Loop zwischen Deployment-Teams und Plattform-Engineering. Bei einem klassischen SaaS-Unternehmen würde ich genau diesen Loop einrichten, wöchentliche Kadenz, keine Ausnahmen:

  • Was haben unsere FDEs diese Woche in Kundenumgebungen gebaut?
  • Welches dieser Patterns wird bei den nächsten fünf Kunden auftauchen?
  • Wer besitzt das Promoten dieser Patterns in die Plattform?

Das Schwungrad ist identisch mit dem, was Kief Morris als agentisches Flywheel in meinem früheren Stück beschrieben hat, nur auf die Anbieter-Kunden-Beziehung angewendet statt auf den internen Engineering-Loop. Das Kundenengagement ist die Datenquelle. Die Plattform ist das Harness. Der Promotion-Prozess ist der Agent, der das Harness aus den Daten verbessert. Der kompoundierende Moat ist die Plattform selbst, die mit jedem Engagement reicher wird.

Wenn du Move 3 gut machst, verbessert sich deine Plattform schneller als die der Wettbewerber, die nur Telemetrie sammeln. Wenn du Move 3 schlecht machst, baust du ein Services-Geschäft auf, das Wettbewerber in achtzehn Monaten kopieren werden.

Was das in der Praxis bedeutet

Lass mich das Abstrakte mit drei Vorhersagen und drei Fallen konkret machen.

Drei Vorhersagen für SaaS über die nächsten 24 Monate

  1. Jedes kategorieführende SaaS fügt eine Forward-Deployed-AI-Engineering-Funktion hinzu. Es wird nicht immer so heißen. Salesforce wird es umbenennen. SAP wird es in einen neuen Tier drehen. Die Form wird die gleiche sein: Senior Engineers, plus Agenten, bei Kunden eingebettet, innerhalb des Plattformvertrags bezahlt statt als separater SOW. Diejenigen, die es als Plattforminvestition statt als Services-Linie ausführen, werden gewinnen.
  2. Das Ontology-Pattern wird der neue Differenzierer. Wer die semantische Schicht der operativen Daten eines Kunden besitzt, besitzt den Moat der KI-Ära. Beobachte genau SaaS-Anbieter, die leise objektorientierte Datenmodelle, ausführbare Geschäftslogik-Oberflächen und Agent-adressierbare APIs veröffentlichen. Das sind diejenigen, die den Moat bauen, auch wenn sie es nicht so vermarkten.
  3. Reines horizontales Punkt-Lösungs-SaaS wird zerquetscht. Die Anbieter, die ein Feature verkaufen - Spesenreports, E-Signaturen, Single-Purpose-CRM-Module - sind diejenigen mit dem meisten zu verlieren. Ihre Kunden können jetzt äquivalente Funktionalität mit einem kompetenten KI-Engineer in zwei Wochen generieren. Die Anbieter, die überleben, sind diejenigen mit tiefer Datengravitation, semantischen Modellen und Integrationsmoats. Alle anderen werden zu einem Feature innerhalb der Plattform von jemand anderem.

Drei zu vermeidende Fallen

  1. Die AI-Tab-Falle. Claude oder GPT in deine bestehende App schrauben und es KI-aktiviertes SaaS nennen. Das ändert deine Ökonomie nicht. Kunden wissen es.
  2. Die Services-Creep-Falle. FDEs zu einer abrechenbaren Beratung werden lassen. In dem Moment, in dem deine FDE-Organisation eine separate P&L mit Services-style Margen hat, stirbt der Plattform-Feedback-Loop, weil niemand einen Anreiz hat, Bespoke-Arbeit zurück in die Plattform zu ziehen. Halte die FDE-Funktion innerhalb von Plattform-Engineering, mit Plattform-Ökonomie-Ownership.
  3. Die Fork-the-Product-Falle. Den Bespoke-Build eines großen Kunden für immer als Special Branch leben lassen. So sind SaaS-Unternehmen in den 1990ern gestorben, und so werden sie in den 2030ern sterben. Die Disziplin, Patterns zurück in die Plattform zu ziehen, ist das, was die Architektur kohärent hält.

Wie das alles andere zusammenpasst, worüber ich geschrieben habe

Ich finde es auffällig, wie viele der Stränge der agentischen Serie auf diesen Artikel zulaufen. Schnelle Übersicht:

Das Pattern über alle hinweg ist dasselbe: Die menschliche Rolle konzentriert sich auf Architektur, Kontext und Urteilsvermögen; die agentische Schicht komprimiert die Kosten von allem anderen; und die gewinnende Struktur ist diejenige, die die Kompression als kompoundierenden Plattformwert einfängt statt als einmalige Services-Marge.

Palantir hat das früher als jeder andere erkannt und das Unternehmen darum herum gebaut. Klassisches SaaS kann das Pattern kopieren. Das Fenster dafür ist schmal.

Das Fazit

SaaS ist nicht tot. Der Slogan ist falsch, die Analyse ist unvollständig, und die Schlagzeile wird in fünf Jahren albern aussehen. Aber der darunterliegende Shift, auf den sie zeigt, ist real. Die Kosten, Packaged-Software anzupassen, kollabieren. Die Grenze zwischen Plattform und Service verwischt. Die Unternehmen, die das nächste Jahrzehnt Enterprise-Software gewinnen, werden diejenigen sein, die eine starke Plattform mit Forward Deployed AI Engineers kombinieren - und die jedes Engagement zurück in die Plattform speisen.

Wenn du ein klassisches SaaS-Unternehmen leitest, ist deine Arbeit klar. Stärke das Plattform-Substrat. Baue eine kleine, seniorige, mit Agenten ausgerüstete Forward-Deployed-AI-Engineering-Funktion auf. Backe das Engagement in die Kundenbeziehung ein statt in einen separaten SOW. Am wichtigsten: Baue das wöchentliche Forum, das jedes Kundenengagement in Plattform-IP verwandelt.

Die Unternehmen, die das 2026 tun, werden ihre Kategorien 2030 besitzen. Die Unternehmen, die “SaaS is dead” beim Wort nehmen, in Panik geraten und einen AI-Tab hinzufügen, werden von denen akquiriert oder gefressen, die das nicht taten.

Referenzen

palantir saas forward-deployed-engineers ai-engineering platform-strategy agentic-flywheel ontology enterprise-software business-model

Verwandte Artikel

·GenAI

On the Loop - KI zu führen ist ein Empowerment-Problem

Kief Morris' agentisches Flywheel, veröffentlicht auf Martin Fowlers Seite, landet fast wortwörtlich auf denselben Prinzipien, die Marty Cagan und Reed Hastings seit Jahrzehnten predigen. KI-Agenten zu führen ist keine neue Disziplin. Es ist Empowered Product Management mit einer neuen Art von Teammitglied.

·GenAI

Die perfekte CLAUDE.md für Enterprise Software Engineering

Wie ich CLAUDE.md-Dateien nutze, um Engineering-Excellence-Standards zu kodieren - Stammwissen in durchsetzbare, KI-gestützte Leitplanken für den Bau von Enterprise-SaaS.

·GenAI

KI in Kürze

Von KI-Modellen über grundlegende Konzepte bis hin zur Entwicklung von KI Anwendungen.