FDE-Einsätze bei ellamind beginnen meistens auf dieselbe Weise. Ein Kunde führt eine ernsthafte Evaluation an einem produktiven KI-System durch und möchte das ellamind-Team im Raum haben, während er sie aufsetzt. Nehmen wir einen Kundenservice-Chatbot bei einem großen gesetzlichen Krankenversicherer in Deutschland, der in einer neuen Abteilung ausgerollt werden soll. Das Team will vor dem Go-live wissen, wie sich der Bot verhalten wird. Solche Evaluationen passen in kein Template. Die Testdaten liegen in mehreren Systemen verteilt. Die Qualitätskriterien sind in regulatorischer Sprache formuliert und müssen erst in Ja/Nein-Fragen übersetzt werden. Die Compliance-Prüfer müssen mitreden können, ohne Code zu schreiben. Das sind normale Rahmenbedingungen in regulierter KI-Arbeit, und die Plattform genau darauf zuzuschneiden ist die Aufgabe eines FDE.
Die Arbeit der nächsten Wochen sieht ungefähr so aus: definieren, was evaluiert werden muss, die Daten des Teams in die Plattform importieren, mit den Fachexperten den ersten Satz Kriterien schreiben und Experimente nebeneinander durchführen. Am Ende hat das Team laufende Evaluationen, denen es vertraut, Kriterien, die seine Compliance-Prüfer abgesegnet haben, und einen klaren Blick darauf, wo der Bot scheitert und warum, ohne dass jemand eine Zeile Code schreibt.
Mein Titel ist Forward Deployed Engineer. Die Aufgabe besteht darin, elluminate auf die konkrete Realität jedes Kunden zuzuschneiden, damit er echten Wert daraus zieht.
Dieser Beitrag handelt davon, was ein FDE bei ellamind wirklich macht, und warum elluminate einen hat.
Was ist ein Forward Deployed Engineer?
Bekannt gemacht hat den Begriff Palantir, und inzwischen ist er Standard bei Enterprise-Software-Unternehmen mit enger Kundenbetreuung. Kurz gesagt: ein Entwickler, der nah am Kunden arbeitet. Wir helfen dabei, das Produkt zu integrieren und zu justieren, führen Hands-on-Workshops durch, schneiden Use Cases zu und tragen das, was wir sehen, zurück in die Produktorganisation.
Es ist eine hybride Rolle. Teils Entwickler, teils Product Manager, teils Sales Engineer, teils Diplomat. Die meiste Zeit schreibe ich keinen Produktivcode, sondern helfe dem Fachexperten eines Kunden, Evaluationen für sein KI-System aufzusetzen, reproduziere einen Bug, für den ihm das Vokabular zum Melden fehlt, oder sitze in einem Workshop, in dem der Kunde noch herausfindet, was er überhaupt evaluieren will.
Wenn die Rolle funktioniert, schrumpfen zwei Distanzen, die normalerweise weit auseinanderliegen: die Distanz von der Realität eines Kunden zu unserem Backlog und die Distanz von unserem Backlog zurück in seine Hände.
Warum elluminate diese Rolle braucht
elluminate ist die Entscheidungsebene für verlässliche KI. Wir helfen Teams, ihre KI-Entwicklung von Intuition auf Evidenz umzustellen: Kriterien definieren, Experimente durchführen, Modelle vergleichen und Quality Gates vor die Produktion setzen.
Auf einer Folie klingt das sauber. In der Praxis ist KI-Evaluation von Natur aus domänenspezifisch. Es gibt keine fertige Eval-Suite für den Erstattungs-Agenten eines privaten Krankenversicherers in Deutschland, für einen RAG-Bot im öffentlichen Sektor, der Fragen zu Sozialleistungen beantwortet, oder für einen industriellen Reasoning-Agenten, der regulierte Gebührenordnungen interpretieren muss. Jeder Kunde kommt mit demselben allgemeinen Problem (“wir müssen wissen, ob unsere KI funktioniert”) und einem völlig anderen konkreten (“…an diesen 80 Fällen, anhand dieser Kriterien, bewertet von diesem Modell, unter diesen Compliance-Vorgaben”).
Genau in dieser Lücke zwischen “die Plattform kann das” und “dieser Kunde zieht jetzt Wert daraus” stirbt die Adoption meistens. 46 % der KI-Proof-of-Concepts erreichen nie die Produktion (Gartner, 2024). 70 % der Organisationen haben weniger als 30 % ihrer GenAI-Experimente über das Experimentierstadium hinausgebracht (Deloitte, 2024). Diese Lücke zu überbrücken ist kein Dokumentationsproblem. Es ist ein Beziehungsproblem im Gewand eines technischen.
In dieser Lücke arbeite ich. Die Arbeit teilt sich in drei Bereiche. Den größten Teil meiner Zeit verbringe ich damit, Kunden beim Onboarding auf die Plattform zu begleiten und sie für ihren Use Case einzurichten. Während ich neben ihnen sitze und ihnen bei der Arbeit zusehe, entstehen die Feature-Anforderungen, die ich zurück ins Engineering trage. Und sobald die Plattform aktiv genutzt wird, führe ich Workshops durch, um sichtbar zu machen, was bereits läuft, und neue Möglichkeiten für die nächste Runde zu finden.
1. Onboarding: von “Plattform deployt” zu “Erkenntnisse gewonnen”
Der schwierigste Teil jeder Plattform ist nicht die Installation. Es ist, sie zu einem festen Teil des Arbeitsalltags zu machen. Adoption scheitert selten auf der technischen Ebene, sondern in der Lücke zwischen “wir haben Zugang zu elluminate” und “unsere Fachexperten öffnen es Montagmorgen, ohne dass man sie darum bitten muss.”
Dort fließt ein Großteil meiner Stunden hin. Ich sitze mit einem KI-Entwickler im Screenshare, während er seinen ersten Datensatz importiert, mal aus einem Langfuse-Export, mal aus einer CSV mit produktiven Traces, mal aus einer Notion-Seite mit Testfällen, die sein Compliance-Team in Prosa geschrieben hat. Gemeinsam definieren wir den ersten Satz binärer Ja/Nein-Kriterien, binden das passende Judge-Modell für seine Domäne ein, führen sein erstes Experiment durch und lesen die Vergleichsansicht nebeneinander.
Der entscheidende Moment ist nicht der Import oder der erste Lauf. Es ist, wenn ein nicht-technischer Prüfer (ein Compliance-Verantwortlicher, ein klinischer Gutachter, eine Teamleitung im Kundenservice) elluminate zum ersten Mal öffnet und etwas sagt wie “jetzt sehe ich, warum Version zwei bei diesen Fällen scheitert.” Das ist der Moment, in dem Evaluation zur Gewohnheit wird statt zum Projekt. Es ist auch der Moment, in dem ein Kunde aufhört, ein Logo auf unserer Folie zu sein, und anfängt, ein Partner zu werden.
Die andere Hälfte des Onboardings besteht darin, Kunden dort abzuholen, wo sie bereits stehen. Sie kommen mit vorhandenem Tooling zu elluminate: einer Langfuse-Instanz, einem MLflow-Setup, einer selbstgebauten Logging-Pipeline, einer Chatbot-Plattform ihrer Wahl. Teil der FDE-Aufgabe ist es, elluminate an diese Systeme anzubinden, statt zu verlangen, dass sie sie wegwerfen. Wir importieren Daten, die sie ohnehin gesammelt haben, konfigurieren Connectors zu Plattformen, die sie ohnehin betreiben, und sorgen dafür, dass ihre ersten Wochen mit elluminate sich anfühlen wie “die Tools, die wir hatten, plus Evaluation obendrauf” und nicht wie “bauen Sie Ihren Stack neu”. Je schneller sie Wert erhalten, ohne neu zu bauen, desto schneller vertrauen sie der Plattform den nächsten Use Case an.
2. Anforderungen zurück ins Produkt tragen
Die meisten Feature-Anforderungen, die die Roadmap von elluminate prägen, entstehen daraus, dass ich während des Onboardings neben einem Kunden sitze. Manche kommen als ausdrückliche Anfrage. Die meisten nicht. Sie zeigen sich als ein Moment der Reibung, den ich in Echtzeit beobachte, oder als beiläufige Frage, die sich als dritte Variante derselben Frage von einem anderen Kunden herausstellt.
Persona- und Multi-Turn-Evaluation
Die folgenreichste Feature-Anforderung, die ich dieses Jahr zurückgetragen habe, begann in einem Vier-Augen-Gespräch mit einem Entwickler bei einem großen gesetzlichen Krankenversicherer in Deutschland. Er nutzte elluminate auf eine Weise, mit der ich nicht gerechnet hatte: Er behandelte es so, als könnte es vollständige Gespräche simulieren, obwohl die Plattform damals nur Single-Turn-Evaluation unterstützte. Statt ihn zu korrigieren, fragte ich so lange nach, bis ich verstanden hatte, was er eigentlich vorhatte.
Was er brauchte, war eine Möglichkeit, einen Kundenservice-Chatbot so zu evaluieren, wie er sich im Produktivbetrieb tatsächlich verhält: nicht als Reihe isolierter Single-Turn-Antworten, sondern als Gespräche. Ein Nutzer präzisiert, widerspricht, stellt eine Rückfrage. Ein Bot, der bei einzelnen Fragen glänzt, kann ein ganzes Gespräch trotzdem entgleisen lassen.
Ich nahm das mit ins Team und iterierte mit unserem Entwicklerteam und den Fachexperten des Kunden, um die Anforderungen für ein Feature zur Persona- und Multi-Turn-Evaluation zu schreiben. Wir schnitten zu, wie eine gute “simulierte Persona” aussieht: der genervte Nutzer, der verwirrte Nutzer, der Nutzer, der ständig das Thema wechselt, der böswillige Nutzer. So konnten die Fachexperten Personas beisteuern, ohne Code zu schreiben. Dann baute ich den Proof of Concept, führte ihn dem Kunden vor, brachte ihn auf seiner elluminate-Instanz live und leitete den Onboarding-Call.
Der ganze Bogen, von einem einzelnen Gespräch darüber, wie ein Nutzer die Plattform tatsächlich verwendete, bis zu einem Live-Feature auf seiner Instanz, schrumpfte auf eine Handvoll Zyklen, weil dieselbe Person ihn von Anfang bis Ende verantwortete. Der Kunde musste seine Anforderung nicht erst einem Product Manager übersetzen, der sie an einen Entwickler weiterreicht, der sie später jemandem vorführt, der nie im ursprünglichen Raum war. Persona-getriebene Multi-Turn-Evaluation ist heute eine vollwertige Fähigkeit in elluminate, und das Design begann mit der tatsächlichen Nutzung eines Kunden, nicht mit einem Roadmap-Brainstorming.
Frontend-Verbesserungen, beim Onboarding entdeckt
Die andere Kategorie von Anforderung kommt überhaupt nicht als Feature-Anfrage. Sie kommt als Moment der Reibung, den ich in Echtzeit beobachte, während ich in einem Screenshare bei einer Onboarding-Session sitze.
Ich leitete eine Onboarding-Session mit einem Entwickler bei einem unserer Kunden. Er versuchte, seine Experimente aufzusetzen, und stieß immer wieder an Grenzen im elluminate-Frontend, die den Workflow mühsamer machten als nötig. Er meldete kein einziges Ticket. Er arbeitete einfach weiter darum herum. Ich machte mir während der Session Notizen und nutzte sie als Grundlage für die nächste Runde Frontend-Verbesserungen, um den Ablauf zum Aufsetzen von Experimenten für genau die Arbeit nutzbarer zu machen, die er tatsächlich tat.
Das wertvollste Feedback ist das, von dem ein Kunde nicht weiß, dass er es Ihnen geben sollte.
Dieses Prinzip fällt mir immer wieder auf. Zwei große Krankenversicherer fragten unabhängig voneinander, ob das Judge-Modell seine Begründung auf Deutsch statt auf Englisch schreiben könne, teils zur Prüfung durch nicht-technische Gutachter, teils für eine Dokumentation im Sinne von EU AI Act Artikel 17. Nach der zweiten Anfrage wurde daraus ein nachverfolgtes Produkt-Item statt einer Slack-Nachricht, die in einem Thread verfällt. Eine Berechtigungslücke beim Organisations-Admin, durch die Admins ihre Einstellungsseite nur sehen konnten, wenn sie auch einem Projekt zugeordnet waren: am Freitag gemeldet, bis Montag behoben. Eine Fehlermeldung für Projekt-Admins, die technisch korrekt, aber für den Nutzer nutzlos war: innerhalb eines Tages geschlossen. Ein Connector zur bestehenden Chatbot-Plattform eines Kunden, der einen Schalter brauchte, damit Evaluations-Aufrufe seine produktiven Monitoring-Statistiken nicht verfälschten: in zwei Tagen ausgeliefert.
Keines davon ist ein großes Feature. Alle zusammen sind der Unterschied zwischen einem Kunden, der verlängert, und einem Kunden, der sich still nicht mehr einloggt. Und keines davon wäre überhaupt gemeldet worden, wenn ich nicht neben der Person gesessen hätte, die darauf gestoßen ist. Kunden melden keine Tickets für die Reibung, mit der sie zu leben gelernt haben. Man fängt sie nur ein, indem man ihnen bei der Arbeit zusieht, und genau das ist Onboarding.
3. Workshops: bestehende Use Cases sichtbar machen, neue finden
Sobald ein Kunde elluminate aktiv nutzt, verschiebt sich die Arbeit. Workshops werden zum Format, in dem wir einen Schritt zurücktreten und auf den gesamten Einsatz schauen statt auf ein Experiment nach dem anderen. Ich setze mich mit dem KI-Team des Kunden und seinen Fachexperten zusammen und versuche zweierlei zugleich.
Ihre bestehenden Use Cases sichtbar machen. Überraschend viele Evaluationsprojekte innerhalb eines Unternehmens sind für den Rest des Unternehmens unsichtbar. Ein Team hat ein sorgfältiges Testset für seinen Chatbot aufgebaut. Ein anderes Team ringt mit demselben Problem an einem anderen Bot und weiß nicht, dass es das erste Team gibt. Der Workshop ist manchmal das erste Mal, dass diese beiden Teams tatsächlich miteinander reden. Wir gehen durch, was bereits auf der Plattform liegt, welche Experimente, welche Kriterien, welche Ergebnisse, und machen daraus ein gemeinsames Bild: “Hier nutzen wir das schon, hier funktioniert es, hier sind wir hängengeblieben.”
Gemeinsam neue Möglichkeiten finden. Sobald die bestehende Arbeit im Raum steht, öffnet sich die nächste Frage: “Wo tut es sonst noch weh?” Bei einem großen Healthcare-IT-Anbieter hatte der Einsatz rund um einen Knowledge-Base-Assistenten für Pflegekräfte begonnen. Der Workshop brachte eine andere Frage zum Vorschein, über die sich die Führung still Sorgen gemacht hatte: Sollte das LLM-as-a-Service-Angebot, das sie an ihre eigenen Kunden weiterverkaufen, mit einer eingebauten Evaluationsebene kommen? Aus diesem Gespräch wurde eine eigene Chance, zugeschnitten Wochen nachdem wir hereingekommen waren, um über etwas anderes zu sprechen.
Workshops sind keine Vertriebstermine. Sie sind der Ort, an dem der Kunde erkennt, wie viel mehr er mit der Plattform tun könnte, und an dem ich lerne, was wir als Nächstes bauen sollten.
Was das skaliert: die Forward Deployment Engine
All das für einen Kunden zu tun, ist machbar. Es für zehn parallel zu tun, ohne Signale zu verlieren, nicht. Deshalb haben wir unsere eigene interne Forward Deployment Engine gebaut, ein hauseigenes Framework, das die kundennahe Arbeit über Slack, Notion, Linear und unsere Codebasis hinweg strafft. Kunden-E-Mails laufen zu Handlern, die das Signal triagieren, die Interaktion festhalten, zwischen Feature-Anfrage und Bug unterscheiden, sie dem Kunden in unserem CRM zuordnen und das Linear-Issue mit den richtigen Labels und dem richtigen Kontext anlegen. Die Rolle ist der Mensch im Loop; die Engine ist das, was den Loop schnell macht.
Was ich in der Rolle gelernt habe
Ein paar Dinge, die ich jedem mitgeben würde, der diese Art von Arbeit übernimmt.
Die Integration in den Use Case des Kunden ist die Aufgabe, nicht die Feature-Liste.
Das Wertvollste, das ich für einen Kunden tue, ist nicht, eine Demo zu zeigen oder eine neue Funktion auszuliefern. Es ist, elluminate so gut in seinen tatsächlichen Workflow einzupassen, dass das Team beginnt, sich darauf zu verlassen. Die Beziehung und die Vertragsverlängerungen folgen daraus, nicht aus der Feature-Liste.
Die Maßeinheit für Fortschritt ist nicht “Feature ausgeliefert”. Sie ist “Kunde erfolgreich”. Ein Feature, das landet, aber nichts daran ändert, wie ein Kunde arbeitet, ist eine Kennzahl, kein Ergebnis. Kalibrieren Sie an Letzterem.
Die Fragen, von denen ein Kunde nicht weiß, dass er sie stellen müsste, sind die wichtigsten. Die sichtbaren Anfragen sind einfach; sie kommen per E-Mail. Die unsichtbaren entstehen, wenn man neben dem Kunden sitzt, während er arbeitet. Planen Sie den Screenshare ein.
Übersetzen, nicht abtippen. Ein Kunde sagt “das Judge-Modell ist zu streng mit unserem Chatbot.” Das ist keine Feature-Anfrage. Der eigentliche Wunsch könnte lauten: “wir wollen Bewertungskriterien, die dazu passen, wie ein menschlicher Prüfer in unserer Abteilung das tatsächlich bewerten würde.” Formulieren Sie das Problem in der Fachsprache des Kunden um, bevor daraus überhaupt ein Ticket wird. Wie Gerriet geschrieben hat, müssen Fachexperte und Entwickler am selben Tisch sitzen, wenn Kriterien definiert werden; der FDE ist oft die Person, die sie dorthin bringt.
Der größte Teil des Ergebnisses ist kein Code. Das Wirksamste, das ich in einer Woche schreibe, ist meist kein Pull Request. Es ist das umformulierte Problem-Statement, die Workshop-Zusammenfassung oder das One-Pager, das sagt: “zwei Kunden haben diesen Monat nach X gefragt, das ist jetzt ein Thema.”
Warum das für elluminate zählt
elluminate ist die Entscheidungsebene für verlässliche KI. Diese Positionierung ist bedeutungslos, solange sie nicht für diesen Kunden gilt, mit dieser Domäne, unter diesem Compliance-Regime. Die FDE-Rolle existiert, weil der einzige Weg, sie wahr zu machen, darin besteht, jemanden in die Realität des Kunden zu schicken und ihn mit dem zurückkommen zu lassen, was das Produkt als Nächstes können muss.
Wenn dieser Loop schnell schließt, hören Kunden auf, uns wie einen weiteren Anbieter zu behandeln, und fangen an, uns als Teil ihres Teams zu sehen. Nur diese Art von Beziehung wächst auf Dauer.
Es ist auch die ehrlichste Version von “wir hören auf unsere Kunden”, die ein Softwareunternehmen anbieten kann. Keine Umfrage. Kein Roadmap-Webinar. Dieselbe Person bei der Demo, in der Onboarding-Session und im Pull Request.
Möchten Sie sehen, wie ein FDE-geführter Einsatz aussieht? Wir helfen Teams, von “wir haben elluminate” zu “elluminate ist Teil davon, wie wir KI ausliefern” zu kommen. Wenn Sie in Ihrem Unternehmen Evaluation ausrollen und dabei jemanden im Raum haben möchten, sprechen Sie uns an. Vielleicht bin ich derjenige, der ihn leitet.
