Ein Forward Deployed AI Engineer trägt die Verantwortung für genau eine Sache, und zwar von Anfang bis Ende: Er bringt einen wertvollen, aber unscharf umrissenen Arbeitsablauf bis in den Produktivbetrieb und weist nach, dass sich dadurch etwas geändert hat. Darin liegt der ganze Unterschied. Wer als ML Engineer viel mit Kunden spricht, bleibt ML Engineer, und wer als Solutions Engineer Code schreibt, bleibt Solutions Engineer. Anders ist nur, wer am Ende für das Ergebnis verantwortlich ist.
Palantir hat diese Unterscheidung vor Jahren auf den Punkt gebracht, und sie gilt bis heute. Produktentwicklung heißt: eine Fähigkeit für viele Kunden. Forward Deployment dreht das um.
Ein Kunde, viele Fähigkeiten.
— Palantir über das Forward-Deployed-Modell
Genau deshalb ist der erste Monat so entscheidend. Discovery, Anwendungsentwicklung, Evaluierung, Integration, Sicherheitsprüfung und Change Management laufen parallel. Ziel ist dabei nicht möglichst viel Code, sondern der Abbau von Unsicherheit in der richtigen Reihenfolge.
Was in diesem Monat wirklich passiert
Rund 160 Stunden auf zwanzig Arbeitstage. Wer klassische Projektarbeit kennt, stolpert meist über dieselbe Zahl: Das eigentliche Bauen ist nur für knapp ein Drittel des Aufwands verantwortlich.
Die vier Wochen
- 01Woche eins
Verstehen und messen
- Aus „wir wollen einen KI-Agenten“ einen Arbeitsablauf mit einem Verantwortlichen machen
- Den Mitarbeitenden bei der Arbeit über die Schulter schauen, statt sich auf die Darstellung aus der Geschäftsleitung zu verlassen
- Daten, APIs, Identitäten, Aufbewahrungsfristen und Netzgrenzen erfassen
- Den Ist-Zustand messen, solange noch keine KI im Spiel ist: Durchlaufzeit, Nacharbeit, Kosten pro Vorgang
- 30 bis 100 repräsentative Fälle als Referenzmenge sammeln
- 02Woche zwei
Den Thin Slice bauen
- Service, CI/CD, Tracing und Prompt-Versionierung aufsetzen
- Zuerst den riskantesten Konnektor bauen, nicht den einfachsten
- Einen echten Anwender einmal komplett durch den Ablauf führen
- Die Evaluierung aufsetzen und Fehler nach Kategorien benennen
- Den Anwendern zeigen und alles streichen, was die Kennzahl nicht bewegt
- 03Woche drei
Härten und pilotieren
- Lese- und Schreibrechte trennen, keine Zugangsdaten im Code
- Telemetrie ergänzen: Latenz, Kosten, Ergebnis, manuelle Korrekturen
- Fehlerverhalten festlegen: Timeouts, Rückfallebene, Verweigerung, Eskalation
- Eine bewusst kleine Gruppe von 10 bis 30 Personen einbeziehen
- Echte Vorgänge laufen lassen und mit der Baseline vergleichen
- 04Woche vier
Produktion und Auswertung
- Die größten gemessenen Fehlerklassen beheben, nicht die interessantesten
- Canary- oder Shadow-Release mit geprobtem Rollback
- Verantwortliche für den Betrieb benennen und das Runbook übergeben
- Auswertung: was besser wurde, um wie viel, zu welchen Kosten
- Konnektor, Evaluierungsset und Muster für den nächsten Einsatz herauslösen
Warum Tag eins nicht zum Programmieren da ist
Der häufigste Fehlschlag ist die Proof-of-Concept-Falle: eine beeindruckende Demo ohne Baseline und ohne wirtschaftliche Annahme, die sich nicht skalieren lässt, weil niemand sagen kann, was sie verbessert hat. Wer den bestehenden Ablauf nicht gemessen hat, hat später nichts zum Vergleichen, und die Entscheidung am Monatsende beruht auf Begeisterung statt auf Belegen.
Die überzeugendsten dokumentierten Projekte haben diese Disziplin gemeinsam. NTT DATA hat zuerst den Ausgangswert festgehalten: eine Störungsanalyse, für die fünf erfahrene Engineers drei Tage brauchten. Dieselbe Analyse lief später in dreißig Minuten durch. Bei Rakuten lag die Zeit bis zur Auslieferung eines Features zunächst bei vierundzwanzig Arbeitstagen, danach bei fünf.
Entscheidend ist, was diese Zahlen messen: Ergebnisse eines Arbeitsablaufs, mit einem Vorher und einem Nachher. Token- oder Prompt-Zählungen würden hier nichts aussagen. Die Nutzung wird getrennt und bewusst erhoben, denn ein System, das seine Evaluierung besteht und dann ungenutzt bleibt, hat genau das verfehlt, worauf es ankam.
Die Fehlermuster, die man früh benennen sollte
| Risiko | Frühwarnzeichen | Was wir dagegen tun |
|---|---|---|
| Verzögerter Zugang | Prototyp steht, aber am Ende von Woche eins kein produktionsnaher Datenzugang | Sicherheit und IAM früh in die Discovery holen, in der Zwischenzeit mit anonymisierten Testdaten bauen |
| Proof-of-Concept-Falle | Begeisterung über die Demo, keine Baseline | Vor dem Bauen messen und die Entscheidung am Monatsende an den Vorher-Nachher-Vergleich binden |
| Ausufernder Umfang | Drei Abteilungen im ersten Sprint | Ein einziger Ablauf, bis sich die Kennzahl bewegt, mit einer ausdrücklichen „jetzt nicht“-Liste |
| Blinde Evaluierung | Qualität wird an ausgewählten Prompts beurteilt | Repräsentative Fälle in die Versionsverwaltung legen und bei jeder Änderung neu ausführen |
| Zu weite Werkzeugrechte | Der Agent kann wertvolle Systeme verändern | Minimale Rechte, eng definierte Tool-Schnittstellen, menschliche Freigabe für folgenreiche Schreibzugriffe |
| Kostenexplosion | Gute Demo, unwirtschaftliche Stückkosten | Kosten pro erfolgreichem Vorgang verfolgen, nicht pro Token |
| Gescheiterte Übergabe | Nur der Engineer kann das System betreiben | Verantwortliche früh benennen, Runbooks liefern, einen Störfall proben |
Was am zwanzigsten Tag „fertig“ heißt
Übergeben wird eine Sammlung von Belegen, die eine einzige Frage beantwortet: Lohnt es sich, dieses Betriebsmodell auszuweiten? Dazu gehören ein priorisierter Arbeitsablauf samt gemessenem Ausgangswert, ein repräsentatives Evaluierungsset, ein produktionsfähiger Thin Slice, Telemetrie zu Qualität, Kosten und Nutzung, eine echte Pilotgruppe, ein Nachweis der Produktionsreife, ein Runbook mit benannter Verantwortung und eine bezifferte Auswertung. Der Agent selbst ist davon der kleinste Teil.
Die Frage, die einen guten Einsatz von einer guten Demo trennt
Kann der Kunde das System ohne den Engineer betreiben, der es gebaut hat? Lautet die Antwort nein, hat der Monat eine Abhängigkeit erzeugt statt einer Fähigkeit, so gut die Kennzahlen auch aussehen.
Ein zweites Ergebnis übersieht man leicht, und später fehlt es schmerzhaft: das wiederverwendbare. Ein Konnektor, ein Evaluierungsgerüst, ein Integrationsmuster, ein Hinweis für das Produkt. Ohne das fängt jedes Projekt wieder bei null an, und aus dem Modell wird Individualentwicklung mit einem schöneren Titel.
So arbeiten wir: vor Ort verstehen, vor Ort bauen, vor Ort messen und anschließend das allgemeine Muster herauslösen, damit das nächste Projekt mit einem Vorsprung startet.