Forward Deployed Engineer: Warum KI-Piloten an den Daten scheitern

Constantin, Pexon Consulting | 10 Min. Lesezeit | 03.08.2026

TL;DR

Zwischen 2024 und 2026 hat fast jedes Industrieunternehmen bewiesen, dass KI funktioniert. Der Demo hat die Frage beantwortet, dann kam der Stillstand – an den Daten. Ein Forward Deployed Engineer dreht die Reihenfolge um: nicht das Modell zuerst, sondern die Datenschicht. Genau diesen Weg geht der Pexon AI Engineering Hub.

Fast alle haben den Piloten gebaut. Kaum jemand hat ausgeliefert.

Das Muster ist in fast jedem Industrieunternehmen dasselbe. Zwischen 2024 und 2026 lief der Proof of Concept, das Modell beantwortete die Beispielfrage, und alle im Raum waren beeindruckt. Dann passierte nichts mehr. Der Pilot blieb Pilot, das Budget für die Produktivsetzung wurde vertagt, und ein Jahr später steht dieselbe Demo im nächsten Steering-Meeting.

Der Grund ist selten das Modell. Die Modelle sind gut genug, seit Jahren. Der Grund ist die Schicht darunter: die Daten, an die kein Prompt heranreicht. Warum ein Agentensystem im Unternehmen mehr braucht als einen guten Prompt, ist ein eigenes Thema (siehe Verwandte Themen). Hier geht es um die Stufe davor: warum es meist gar nicht so weit kommt.

Wo der Pilot stehen bleibt: an den Daten

Drei Wände stehen zwischen dem funktionierenden Demo und dem produktiven System. Alle drei sind kein Modellproblem.

1. Die Daten sind nicht erreichbar. SAP, MES, PLM, dreißig Jahre SharePoint, SQL, das seit einer Dekade niemand angefasst hat. Kein Prompt greift dort hinein. Das schaffen nur Engineers, die Ihr Schema lesen und die Systeme anbinden.
2. Berechtigungen lassen sich nicht ausdrücken. Ein System, das jedem alles zeigt, geht nicht in Produktion. Ihr echtes Rechtemodell muss mit dem Kontext mitwandern, von der Quelle bis zur Antwort. Genau daran scheitern die meisten RAG-Prototypen.
3. Der Mensch, der es könnte, ist gebunden. Der eine Engineer, der es durchziehen würde, sitzt in einem anderen Projekt. Und am Markt ist dieses Profil in Monaten nicht einzustellen.

Diese drei Wände sind der Grund, warum so viele KI-Initiativen bei 80 Prozent hängenbleiben. Nicht weil die Technik fehlt, sondern weil niemand die Datenschicht sauber aufräumt und das Rechtemodell durchzieht.

Der Konsens der Frontier-Labs: nicht das Modell ist der Engpass

Das stärkste verfügbare Argument für diesen Befund kommt von den Unternehmen mit den besten Modellen der Welt. Sie sind im vergangenen Jahr fast gleichzeitig zu demselben Schluss gekommen: Das Modell ist nicht der Engpass, die Auslieferung ist es. Und sie haben Kapital genau dorthin verschoben.

Der rote Faden: Wer die Wahl zwischen besseren Modellen und besserer Auslieferung hatte, hat in die Auslieferung investiert. Das ist kein Marketing-Trend, das ist die Kapitalallokation der Firmen, die es am besten wissen müssten.

Der Haken: All das zielt auf die größten Konzerne der Welt. Der Mittelstand mit 50 Mio. bis 2 Mrd. Euro Umsatz hat exakt dieselbe Auslieferungslücke – nur niemanden, der sie schließt. Genau dort setzt der Pexon AI Engineering Hub an.

Was ein Forward Deployed Engineer wirklich macht

Ein Forward Deployed Engineer ist kein Berater, der von außen ein Projekt steuert, und kein Body, der eine Stelle füllt. Er arbeitet eingebettet in Ihrer Umgebung, mit Ihren Werkzeugen, Ihrem Code und Ihren Daten. Der Unterschied zur klassischen Projektvergabe ist die Nähe: Ihr Team behält die Kontrolle und lernt mit, statt eine Blackbox geliefert zu bekommen. Wie sich so ein Engineer in ein bestehendes Plattform-Team einfügt, behandeln wir separat (siehe Verwandte Themen).

Entscheidend ist, wo er anfängt: nicht beim Workflow, sondern bei den Systemen, von denen der Workflow abhängt.

# Data-to-AI: die Reihenfolge, die einen Piloten produktiv macht
pipeline:
  - extract:  source: sap-ecc          # read-only, no write access
  - mask:     pii: on                   # PII removed before indexing
  - join:     mes: batch-history        # machine context to quality results
  - index:    rbac: inherit             # real permission model carried through
  - deploy:   target: customer-tenant   # runs inside your own cloud

Drei Prinzipien machen den Unterschied:

• Start an der Datenschicht. SAP, MES, PLM, SharePoint, Ticketsysteme, Mainframes werden extrahiert, bereinigt, maskiert und strukturiert – und Ihr echtes Rechtemodell wird durchgezogen. So kann ein System in Produktion gehen, statt Demo zu bleiben.
• Neutral bei Modellen und Clouds. Frontier-Modelle, wo sie ihre Kosten verdienen, Open-Weight-Modelle, wo die Datenklasse es verlangt, vollständig on-premise, wo das Gesetz es verlangt. Keine Lizenz, die verteidigt werden muss.
• Das Wissen bleibt Ihres. Alles läuft im eigenen Tenant. Ihre Daten verlassen ihn nicht, trainieren kein fremdes Modell und werden nicht zum Vorteil eines anderen. Das Ziel ist Ihr Team, das das System am Ende ohne uns betreibt.

Dass dieses Modell trägt, zeigt ein anonymisiertes Enterprise-RAG-Projekt (siehe Verwandte Themen): ein Engineer, der ein bestehendes Team vom Prototyp zum produktiven System geführt hat. Denselben Ansatz bündelt unsere KI-Beratung.

Die fünfte Infrastruktur-Schicht: das Company Brain

Jedes Unternehmen betreibt vier Infrastruktur-Schichten: ERP für den Betrieb, CRM für die Kunden, Identity für Zugriff und Sicherheit, Cloud für Compute. Gerade entsteht eine fünfte – und anders als die anderen vier lässt sie sich nicht von der Stange kaufen, weil sie aus Ihrem eigenen Wissen besteht.

Der Punkt ist die Determinismus-Frage, die die meisten Company-Brain-Produkte umgehen: Sie optimieren auf Retrieval über unstrukturiertem Text. Wenn ein Agent und der CFO „Umsatz“ unterschiedlich berechnen, landen falsche Zahlen lautlos in der Vorstandsvorlage. Für regulierte und industrielle Kunden schlägt Nachvollziehbarkeit die reine Antwortabdeckung: definierte Quellen mit definierten Definitionen, nicht Freitext-Ähnlichkeitssuche.

Häufig gestellte Fragen

Was ist ein Forward Deployed Engineer?

Ein Forward Deployed Engineer ist ein Ingenieur, der eingebettet in der Umgebung des Kunden arbeitet, nicht als externes Projektteam. Er bindet die realen Systeme an, zieht das Berechtigungsmodell durch und bringt ein KI-System bis in den Produktivbetrieb – mit den Werkzeugen, dem Code und den Daten des Kunden.

Warum scheitern so viele KI-Piloten?

Nicht am Modell, sondern an der Datenschicht. Die Daten in SAP, MES, PLM oder altem SQL sind für einen Prompt nicht erreichbar, und das echte Rechtemodell lässt sich im Prototyp nicht ausdrücken. Ohne diese beiden Bausteine bleibt jeder Demo eine Demo.

Ist Forward Deployed Engineering nur etwas für Großkonzerne? forward deployed engineer

Die großen Deployment-Teams von OpenAI, Microsoft und Palantir zielen auf die größten Konzerne der Welt. Der Mittelstand mit 50 Mio. bis 2 Mrd. Euro Umsatz hat dieselbe Auslieferungslücke, aber niemanden eingebettet, der sie schließt. Genau dieses Segment adressiert der Pexon AI Engineering Hub.

Bleiben unsere Daten dabei im Haus?

Ja. Alles läuft im eigenen Cloud-Tenant, die Daten verlassen ihn nicht und trainieren kein fremdes Modell. Modell- und Cloud-Entscheidungen fallen nach Ihrer Datenklassifizierung – inklusive der Antwort, dass nichts das Haus verlässt, wenn die Regulatorik das verlangt.

Wie fängt man an, ohne ein Zwölf-Monats-Programm freizugeben?

Über einen abgegrenzten Zwei-Wochen-Blueprint ab 4.900 Euro: eine echte Datenquelle, ein echter Anwendungsfall, End-to-End bis zu etwas, das ein Mensch nutzt. Kein breiter Pilot, der alles anfasst und nichts ausliefert, sondern ein Faden bis in die Produktion.

Nächster Schritt

Wenn Ihr Pilot immer noch ein Pilot ist, liegt das Problem wahrscheinlich an einer erreichbaren Stelle: den Daten. Ein Architecture-Fit-Call klärt in 30 Minuten mit dem Architekten, der die Umsetzung tatsächlich verantworten würde, ob das passt und welche Datenquelle die erste sein sollte.

Verwandte Themen