Forward Deployed Engineer: Was das ist und wann Ihr Unternehmen einen solchen braucht

Jedes Unternehmen, das anspruchsvolle Software kauft, kennt diese Lücke. Der Vertrag ist unterzeichnet, die Demo war beeindruckend, und dann vergehen Monate, während das System konfiguriert, integriert und an die tatsächliche Arbeitsweise des Unternehmens angepasst wird. Manchmal wird es überhaupt nicht fertig. Die Demo lief mit sauberen Daten und einem vorbereiteten Skript. Ihr Unternehmen arbeitet mit unübersichtlichen Dokumenten, nur teilweise dokumentierten Abläufen und Zugriffsregeln, die niemand schriftlich festgehalten hat.

Der Forward Deployed Engineer, meist kurz FDE genannt, ist die Rolle, die diese Lücke schließen soll. Statt Software in einer Zentrale zu entwickeln und an ein Customer-Success-Team zu übergeben, arbeitet ein FDE direkt in der Organisation des Kunden: Er sitzt bei den Personen, die das System nutzen werden, beobachtet, wie die Arbeit tatsächlich abläuft, und schreibt den Code, der die Software passend macht. Dieser Artikel erklärt, was diese Rolle ist, woher sie kommt, was ein FDE im Alltag tut und woran Sie erkennen, ob Ihr Unternehmen einen solchen oder einen Partner benötigt, der nach demselben Prinzip arbeitet.

Was ein Forward Deployed Engineer tatsächlich ist

Ein Forward Deployed Engineer ist ein Softwareentwickler, der sich in die Organisation eines Kunden integriert, um auf der Plattform des Arbeitgebers funktionierende Software zu entwickeln, zu konfigurieren und bereitzustellen – innerhalb der eigenen Daten, Sicherheitsregeln und Arbeitsabläufe des Kunden. Die Arbeit wird an einer Frage gemessen: Läuft das System in der Produktion und leistet es nützliche Arbeit? Die Rolle liegt zwischen dem Produktteam des Anbieters und der internen IT-Abteilung des Kunden und gehört vollständig zu keiner der beiden Seiten.

Das Modell wurde um 2009 von Palantir bekannt gemacht. Die Plattform von Palantir war leistungsfähig, doch Kunden konnten daraus nicht eigenständig funktionierende Systeme machen: Die Daten waren unübersichtlich, die Arbeitsabläufe spezifisch, und genau die Lücke zwischen einem unterzeichneten Vertrag und einem produktiv eingesetzten System ließ Projekte ins Stocken geraten. Die Lösung bestand darin, Ingenieure in die Welt des Kunden zu entsenden. Palantir bezeichnet diese Ingenieure intern weiterhin als Deltas und teilt die Arbeit in zwei Bereiche: Devs entwickeln wiederverwendbare Plattformfunktionen für viele Kunden, während Deltas – die Forward-Deployed-Softwareentwickler – einen Kunden und viele Funktionen zusammenbringen und sie in der Umgebung dieses Kunden zum Funktionieren bringen. Ein Delta arbeitet üblicherweise mit einem Deployment Strategist zusammen, der Echo genannt wird. Dieser verantwortet den Missionskontext, die Stakeholder und die Einführung, während das Delta für die technische Umsetzung zuständig ist.

Ein Missverständnis sollte früh ausgeräumt werden: Die Rolle eines FDE geht über Beratung hinaus. Manche Beratungsprojekte enden mit einer Empfehlung, andere umfassen auch die praktische Umsetzung. Ein FDE schreibt produktiven Code, behebt Fehler in produktiven Systemen, konfiguriert das Plattformverhalten und bleibt, um das vereinbarte Ergebnis zu liefern. Die Arbeit ähnelt gewöhnlicher Softwareentwicklung. Der Druck entsteht durch den Ort, an dem sie stattfindet: vor Ort oder in einem Gespräch mit dem Team des Kunden, bei dem reale Probleme der Bereitstellung gemeinsam gelöst werden.

Was ein FDE im Alltag tut

Stellenausschreibungen und Berichte aus erster Hand beschreiben die Arbeit in drei ineinandergreifenden Bereichen: das Problem verstehen, die Lösung entwickeln und sicherstellen, dass sie sich dauerhaft bewährt.

Der erste Teil ist diagnostischer Natur. Der FDE nimmt an den täglichen Abstimmungen des Kunden teil, beobachtet Analysten und operative Mitarbeiter bei ihrer Arbeit und ermittelt, an welcher Stelle der Prozess tatsächlich scheitert: bei der Datenpipeline, die mit echten Datensätzen ausfällt, beim Dokumentensatz, der sich selbst widerspricht, oder beim Genehmigungsschritt, den niemand erklären kann. Ein Ticket bildet diesen Teil nur selten ab. Zu beobachten, wie ein Kunde mit einem Arbeitsablauf kämpft, vermittelt mehr, als darüber in einem Anforderungsdokument zu lesen.

Der zweite Teil ist die Umsetzung. Der FDE schreibt produktiven Code, typischerweise in Python, TypeScript oder Java, der die Plattform oder KI-Modelle des Arbeitgebers mit den bestehenden Systemen des Kunden verbindet. Dazu gehören Datenpipelines, die Datensätze aus Data Warehouses, ERPs, Ticketsystemen und Dokumentenspeichern abrufen, bereinigen und modellieren, sowie Abruf- und Agenten-Workflows die es Modellen ermöglichen, interne Daten zu lesen und über Kunden-APIs genehmigte Aktionen auszuführen. Wenn die Konfiguration einer bestehenden Funktion schneller ist als eine Neuentwicklung, konfiguriert der FDE sie. Ziel ist ein funktionierendes System, keine größere Codebasis.

Der dritte Teil besteht darin, die Lösung nachhaltig zu verankern. Der FDE schult die eigenen Mitarbeiter des Kunden darin, das Entwickelte zu nutzen und später zu warten, dokumentiert die wichtigen Entscheidungen und gibt Erkenntnisse an das Produktteam zurück, damit sich die Plattform selbst weiter verbessert. Ein Projekt, das mit einem System endet, das niemand auf Kundenseite versteht, ist keine abgeschlossene Bereitstellung. Es ist eine Abhängigkeit, die beim nächsten Ausfall auf Unterstützung wartet.

FDE im Vergleich zu den Rollen, mit denen er verwechselt wird

Die Bezeichnung ist für viele Menschen neu und wird mit mehreren benachbarten Rollen verwechselt. Die Unterschiede sind wichtig, denn die Einstellung der falschen Person lässt eine Bereitstellung ins Stocken geraten.

Betrachten Sie die Tabelle als Orientierung für typische Verantwortlichkeiten. Die Bezeichnungen überschneiden sich, doch die Verantwortung eines FDE besteht darin, dass ein System für diesen konkreten Kunden produktiv funktioniert – nicht lediglich darin, ein genehmigtes Design, eine gelieferte Empfehlung oder eine ausgefüllte Checkliste für den Rollout bereitzustellen.

Rolle	Typischer Schwerpunkt	Vergleich mit einem FDE
Forward Deployed Engineer	Anpassung und Bereitstellung von Software in der Umgebung eines Kunden	Verbindet Kundenerkundung, praktische Softwareentwicklung und Bereitstellung in der Produktion
Produktentwickler	Entwicklung wiederverwendbarer Funktionen für viele Kunden	Konzentriert sich in der Regel auf das gemeinsame Produkt und nicht auf die Bereitstellung für den Kunden
Solutions Architect	Entwurf des Zusammenspiels verschiedener Systeme	Kann ebenfalls entwickeln, legt aber häufig den Schwerpunkt auf Architektur und technische Beratung
Berater	Lösung eines geschäftlichen oder technischen Problems innerhalb eines vereinbarten Umfangs	Kann beraten, entwickeln oder beides; die Verantwortung für die Produktion hängt vom Auftrag ab
Implementierungsingenieur	Konfiguration, Integration und Einführung eines Produkts	Überschneidet sich mit der Arbeit eines FDE, erfolgt jedoch häufig innerhalb eines etablierteren Implementierungsprozesses
Interner Ingenieur	Entwicklung und Wartung der eigenen Systeme des Unternehmens	Kann ähnliche Aufgaben übernehmen und trägt innerhalb des Unternehmens fortlaufende Verantwortung

Warum sich das Modell jetzt verbreitet

Das Modell wurde lange mit Palantir in Verbindung gebracht und erhält nun größere Aufmerksamkeit. Es verbreitet sich derzeit, weil das von ihm gelöste Problem zum zentralen Problem von Geschäfts-KIgeworden ist. Modelle lassen sich leicht vorführen, aber nur schwer bereitstellen. Ein Sprachmodell beantwortet eine vorbereitete Frage gut. Es mit echten Dokumenten, echten Berechtigungen und echten Workflows zu verbinden und dabei korrekt zu halten, wenn sich diese ändern, ist der Punkt, an dem die meisten KI-Projekte ins Stocken geraten. Das ist Bereitstellungsarbeit – und genau dafür ist ein FDE zuständig.

KI-Labore und Anbieter von Unternehmenssoftware haben das Modell übernommen. Die FDE-Teams von Palantir sind das ursprüngliche Beispiel; ähnliche Rollen gibt es inzwischen unter anderem bei OpenAI, Anthropic, Databricks, Scale AI, Cohere, Ramp und Rippling. In einem Microsoft-Beitrag vom Oktober 2026schrieb Kevin Shatzkamer, Corporate Vice President of Forward Deployed Engineering, dass die FDE-Teams dort inzwischen durch Programmierassistenten und Bereitstellungsagenten ergänzt werden. Das sagt einiges darüber aus, wohin sich die Rolle entwickelt: Der Ingenieur ist weiterhin für die Bereitstellung verantwortlich, während KI-Tools mehr Routinecode übernehmen. Die Einstellungspraxis hat darauf reagiert. Planks Einstellungserhebung vom September 2026 zählte am 12. September 2026 1.333 offene FDE-Stellen bei 565 Unternehmen und veranschaulichte damit, wie weit sich die Bezeichnung verbreitet hat.

Bei der Nachfrage geht es nicht um die Bezeichnung. Es geht um das Muster: Software, die innerhalb eines bestimmten Unternehmens mit dessen Daten und Regeln funktionieren muss, braucht jemanden vor Ort, der sie dort entwickeln kann. Je mehr Unternehmen KI-Plattformen kaufen, statt alles selbst zu entwickeln, desto größer wird dieser Bedarf.

Wann Ihr Unternehmen einen braucht

Ein FDE oder ein Partner, der auf dieselbe Weise arbeitet, ist eine Überlegung wert, wenn mehrere dieser Punkte zutreffen.

Ihr Pilotprojekt steckt fest. Die Demo hat funktioniert, aber der Pilot hat nie den Produktivbetrieb erreicht. Die Hindernisse liegen bei der Integration, dem Datenzugriff, den Berechtigungen oder der Einbindung in die Workflows – nicht beim Modell selbst. Wenn Ihnen das bekannt vorkommt, liegt das Problem bei der Bereitstellung, und die Bereitstellung ist die Aufgabe des FDE. Das Handbuch für Pilotprojekte beschreibt dieselbe Falle aus Sicht des Käufers: Pilotprojekte, die nie zu Produktivsystemen werden.

Die Software des Anbieters lässt sich nicht erfolgreich einführen. Ihr Team hat eine Plattform gekauft, das Customer-Success-Team des Anbieters hat das Onboarding durchgeführt, und Monate später ist die Nutzung immer noch gering. Die Lücke kann über Schulungen hinausgehen: Das System muss möglicherweise angepasst werden, damit es zur tatsächlichen Arbeitsweise Ihrer Mitarbeiter passt. Ein FDE kann helfen, wenn das Schließen dieser Lücke praktische Entwicklungsarbeit gemeinsam mit Ihrem Team erfordert.

Ihre Daten- und Sicherheitsregeln sind streng. Einige Dokumente dürfen Ihre Infrastruktur nicht verlassen, bestimmte Branchen verlangen Prüfpfade, die der Anbieter nicht anbietet, und manche Zugriffsregeln sind zu spezifisch für eine Standardkonfiguration. Wenn die Bereitstellung diese Regeln im Code und nicht nur in einem Richtliniendokument berücksichtigen muss, brauchen Sie einen Ingenieur, der innerhalb dieser Vorgaben arbeitet.

Ihr KI-Anwendungsfall basiert auf echten Dokumenten. Retrieval, Agenten und Automatisierung funktionieren nur, wenn sie Ihre tatsächlichen Daten lesen und über Ihre tatsächlichen Systeme handeln. Diese Integrationsarbeit – die Verbindung von Modellen mit Data Warehouses, ERPs und Dokumentenspeichern – gehört zum Tagesgeschäft eines FDE. Genau hier scheitern allgemeine Implementierungen gewöhnlich.

Sie haben kein internes Team dafür. Ihre Ingenieure sind damit beschäftigt, die eigenen Systeme des Unternehmens zu betreiben. Sie für eine Bereitstellung einzusetzen bedeutet, dass die Bereitstellung mit allem anderen konkurriert – und in der Regel verliert. Ein FDE oder ein eingebettetes Partnerteam stellt die erforderliche Bereitstellungskapazität bereit, ohne dass Sie jemanden einstellen müssen.

Wann Sie keinen brauchen

Das Modell eignet sich nicht für jedes Projekt, und das zu erkennen, gehört zu seiner sinnvollen Anwendung.

Eine standardisierte Softwareeinführung mit klaren Anforderungen und einem Anbieter, der sie bereits hundertmal durchgeführt hat, braucht keinen eingebetteten Ingenieur. Das gilt ebenso wenig für eine einmalige Aufgabe mit klar definiertem Abschluss oder für ein Projekt, bei dem Ihr eigenes Team bereits über die nötigen Plattformkenntnisse und die erforderliche Zeit verfügt. Wenn der Workflow stabil, die Daten sauber und die Integration ein Standard-Connector ist, handelt es sich bei der Bereitstellung um eine Konfigurationsaufgabe. Für einen eingebetteten Ingenieur zu bezahlen hieße dann, Kapazität zu bezahlen, die Sie nicht benötigen.

Der Test ist einfach: Wenn der schwierige Teil darin besteht, Ihr Unternehmen zu verstehen und Software daran anzupassen, passt das Modell. Wenn der schwierige Teil darin besteht, zwischen zwei Produkten zu wählen oder ein Standardprodukt zu konfigurieren, passt es nicht.

Einen FDE einstellen oder mit einem Partner arbeiten?

Wenn der Bedarf real ist, stellt sich als Nächstes die Frage, ob Sie jemanden einstellen oder einen Partner hinzuziehen sollten. Beides sind legitime Optionen; die Antwort hängt davon ab, wie lange der Bedarf besteht und wie umfassend er ist.

Eine Einstellung ist sinnvoll, wenn die Bereitstellungsarbeit dauerhaft anfällt und Ihr Unternehmen jemanden braucht, der intern dafür verantwortlich ist. Wenn Ihr Unternehmen jahrelang auf der Plattform eines einzigen Anbieters läuft, wird ein interner FDE zur Person, die weiß, wie diese Plattform die Anforderungen Ihres Unternehmens erfüllt, und dieses Wissen bleibt im Unternehmen. Je nach Verantwortungsbereich kann es sich um einen Integrationsingenieur, einen KI-Ingenieur oder einen technischen Leiter mit umfassender Plattformexpertise handeln. Die Kosten bestehen in der Einstellung selbst, in der Zeit, jemanden mit technischer Tiefe und zugleich gutem Urteilsvermögen im Kundenkontakt zu finden, sowie in der Tatsache, dass eine Person nur einen begrenzten Umfang abdecken kann.

Ein Partner ist sinnvoll, wenn der Bedarf ein klar abgegrenztes Projekt darstellt oder mehrere Kompetenzbereiche umfasst. Ein Studio wie Ridiculous Engineering arbeitet in seinen KI-Entwicklungs- und Automatisierungsprojekten sowie in seinen Projekten für Softwareberatung und Unterstützung bei der Umsetzung auf diese Weise: Ingenieure arbeiten innerhalb der Umgebung des Kunden und gemeinsam mit dessen Team, um die Workflows zu verstehen, Integrationen und Automatisierungen zu entwickeln, die Lösung gemeinsam zu validieren und anschließend ein System zu übergeben, das das Team des Kunden selbst betreiben kann. Der Partner bringt ein Team statt nur einer Person mit und deckt einen größeren Teil des Technologie-Stacks ab. Wissenstransfer, Schulungen und Dokumentation erfolgen während des gesamten Projekts. Wenn der Partner das Projekt verlässt, verfügt das Team des Kunden über das Verständnis, die Fähigkeiten und die Dokumentation, um das System zu betreiben und zu warten.

Es gibt auch einen Mittelweg: Beginnen Sie mit einem Partnerprojekt, um das System in die Produktion zu bringen und zu erfahren, wie die laufende Arbeit tatsächlich aussieht. Stellen Sie dann mit fundiertem Wissen über die Rolle für den Regelbetrieb ein. Ein Pilotprojekt liefert die Zahlen, die die Einstellungsfrage klären: Wie viel Bereitstellungsarbeit das System tatsächlich erfordert und wie häufig.

Worauf Sie bei einem FDE-Projekt achten sollten

Unabhängig davon, ob Sie jemanden einstellen oder einen Partner beauftragen: Fünf Prüfungen unterscheiden ein gutes Projekt von einem weiteren System, das nicht vorankommt.

1. Verantwortung für den Produktionsbetrieb. Der Engineer oder das Team verantwortet ein funktionierendes System in der Produktion – kein Designdokument und keine Demo. Fragen Sie, was „fertig“ bedeutet. Die Antwort sollte ein System sein, das Ihre Mitarbeitenden nutzen, und kein Meilenstein auf einer Folie.

2. Übergabe und Schulung. Die Mitarbeitenden des Kunden können das System nach Abschluss des Projekts nutzen und warten. Schulung, Dokumentation und eine benannte verantwortliche Person auf Ihrer Seite gehören zum Leistungsumfang und sind keine Extras, die später ausgehandelt werden.

3. Evaluierung. Das System wird anhand realer Arbeit und klarer Erfolgskriterien getestet. Bei einer KI-Bereitstellung umfasst das repräsentative Fragen, Dokumente oder Aufgaben mit erwarteten Ergebnissen sowie Prüfungen auf unsicheres Verhalten. Wiederholen Sie die relevanten Tests nach Änderungen, damit nicht die Nutzer zuerst feststellen, dass die Qualität nachgelassen hat.

4. Sicherheit und Berechtigungen. Das System berücksichtigt, wer Informationen sehen und Aktionen ausführen darf. Diese Kontrollen werden mit echten Benutzerkonten getestet und nicht lediglich von einer Einstellungsseite abgeleitet. Wo relevant, sollte das Projekt Prüfprotokolle und Datenresidenz im Code abdecken, nicht nur im Vertrag. Der Governance-Aspekt ist hier wichtig; lesen Sie daher das Governance-Framework für LLMs bevor Sie den Umfang der Bereitstellung festlegen.

5. Ein Ausstiegsplan. Sie wissen, was nach Abschluss des Projekts geschieht: Wer das System verantwortet, wie die laufende Wartung aussieht und was erforderlich wäre, um zu einem anderen Partner zu wechseln oder die Arbeit intern zu übernehmen. Die günstigere Option für den Einstieg ist nicht immer auch die günstigere für den Ausstieg.

Häufig gestellte Fragen

Was ist ein Forward Deployed Engineer?

Ein Forward Deployed Engineer ist ein Softwareentwickler, der sich in die Organisation eines Kunden integriert, um funktionierende Software auf der Plattform des Arbeitgebers bereitzustellen, zu konfigurieren und auszuliefern – innerhalb der eigenen Daten, Sicherheitsregeln und Arbeitsabläufe des Kunden. Die Rolle wurde um 2009 von Palantir bekannt gemacht und ist inzwischen in KI-Laboren, bei Cloud-Anbietern und Beratungsunternehmen zu finden. Maßgeblich ist, ob das System in der Produktion läuft und nützliche Arbeit leistet.

Ist ein FDE ein Berater?

Die Rollen können sich überschneiden. Ein FDE verbindet kundenorientierte Problemlösung mit praktischer Softwareentwicklung, um funktionierende Software in der Umgebung eines Kunden bereitzustellen. Berater können Beratung, Implementierung oder beides anbieten. Der entscheidende Unterschied liegt in der vereinbarten Verantwortung: Umfasst das Projekt den Aufbau und die Bereitstellung eines funktionierenden Produktionssystems?

Arbeiten FDEs nur bei Palantir?

Nein. Palantir hat die Rolle bekannt gemacht, doch FDE-Positionen gibt es inzwischen auch bei anderen Unternehmen, darunter KI-Labore, Anbieter von Unternehmenssoftware und Beratungsunternehmen wie OpenAI, Anthropic, Databricks, Scale AI und Microsoft. Die Verantwortlichkeiten unterscheiden sich je nach Arbeitgeber. Achten Sie daher auf die Aufgaben und die mit dem Titel verbundene Verantwortung.

Welche Fähigkeiten benötigt ein FDE?

An erster Stelle steht das Engineering für den Produktionsbetrieb: die Sprachen und Systeme, auf denen die Plattform läuft, Datenpipelines, APIs und das Debugging in laufenden Umgebungen. Hinzu kommen die Fähigkeiten, die die Integration ermöglichen: den Arbeitsablauf eines Kunden schnell zu verstehen, ein unklar umrissenes Problem in ein lieferbares Ergebnis mit klaren Erfolgskriterien zu überführen, mit nichttechnischen Stakeholdern zu kommunizieren und das Team des Kunden zu schulen. Die seltene Kombination ist Tiefe in beiden Bereichen: ein Engineer, der ein Produktionsprotokoll lesen und eine Besprechung mit einem Vizepräsidenten leiten kann.

Wie lange dauert ein FDE-Projekt?

Das hängt vom Umfang, dem Zustand der Daten und der Klarheit der Erfolgskriterien ab. Ein eng umrissenes Pilotprojekt – ein Arbeitsablauf mit zugänglichen Dokumenten und einem festgelegten Erfolgskriterium – dauert typischerweise einige Wochen. Eine Produktionsbereitstellung, die mehrere Systeme, Sicherheitsprüfungen und organisatorische Änderungen umfasst, kann deutlich länger dauern. Zeitpläne verlängern sich, wenn Dokumente verstreut sind, Berechtigungen unklar bleiben oder der Umfang ständig wächst. Ein vor Arbeitsbeginn vereinbarter fester Pilotumfang, klare Erfolgskriterien und ein Entscheidungspunkt für die nächste Phase helfen, ein Projekt ohne festes Ende zu vermeiden.

Was kostet die Zusammenarbeit mit einem FDE?

Das hängt vom Arbeitsvolumen, der Komplexität der Integration und davon ab, ob Sie jemanden einstellen oder einen Partner beauftragen. Genau deshalb steht zunächst ein klar abgegrenztes Pilotprojekt: Es macht aus einer vagen Schätzung eine konkrete Zahl, die auf Ihren Systemen und Dokumenten basiert, bevor Sie sich zu etwas Größerem verpflichten. Betrachten Sie die Kosten als ein Modell, das Sie im Pilotprojekt verfeinern, und nicht als eine Zahl, die Sie einmalig berechnen.

Das Wichtigste in Kürze

Der Forward Deployed Engineer schließt eine reale Lücke: Er macht aus Software etwas, das innerhalb eines konkreten Unternehmens funktioniert. Der von Palantir bekannt gemachte Ansatz erhält zunehmend Aufmerksamkeit, da Unternehmen daran arbeiten, KI in die Produktion zu bringen. Der Wert entsteht durch die Verbindung eines Verständnisses der Arbeit des Kunden mit dem Engineering, das erforderlich ist, um die Bereitstellung nützlich zu machen. Modelle lassen sich leicht demonstrieren. Sie innerhalb eines Unternehmens zuverlässig zum Laufen zu bringen, ist schwieriger – und diese Lücke zu schließen, gehört zu den zentralen Aufgaben eines FDE.

Unabhängig davon, ob Sie jemanden einstellen oder mit einem Partner zusammenarbeiten, ist die Prüfung dieselbe. Benennen Sie das Produktionsergebnis, grenzen Sie ein messbares Pilotprojekt ab und machen Sie die Übergabe zu einem Bestandteil der Vereinbarung. Wenn das System in der Produktion funktioniert und Ihr Team es betreiben kann, hat das Modell seine Aufgabe erfüllt.

Wenn Sie Unterstützung bei dieser Entscheidung wünschen, sprechen Sie mit unserem Team über die Bereitstellung: über die Dokumente, die Integrationen und ein messbares Pilotprojekt, bevor Sie eine größere Verpflichtung eingehen.