
Interviews met kandidaten voor de rol van Forward Deployed AI Engineer laten een vast patroon zien: zakelijk inzicht, technische executie en AI-expertise komen zelden in één persoon samen. Wie een ChatGPT-licentie uitdeelt, koopt toegang tot een model, niet de drie vaardigheden die een AI-implementatie laten werken.
Ik heb het afgelopen jaar tientallen kandidaten gesproken voor de rol van Forward Deployed AI Engineer. In het Engels heet die rol voluit een Forward Deployed Engineer (FDE) met AI-specialisatie: iemand die bij de klant meebouwt in productie, niet vanaf de zijkant adviseert. De term komt oorspronkelijk uit het leger en werd rond 2009 populair gemaakt door Palantir (Wikipedia).
De aanleiding voor die gesprekken is steeds hetzelfde patroon. Een bedrijf deelt ChatGPT-licenties uit aan het team, een paar mensen raken enthousiast en er gebeurt iets. Alleen blijft de tijdwinst hangen bij die paar mensen. Het proces zelf verandert niet, en de directie weet niet goed wie ze had moeten aannemen om dat wel te laten gebeuren.
Wie de rol niet kent: we schreven eerder uitgebreid over wat een Forward Deployed AI Engineer precies doet. Dit stuk gaat niet over die functieomschrijving. Het gaat over wat ik leerde van het daadwerkelijk spreken met mensen die zeggen dat ze die rol kunnen vervullen, en waarom dat weinigen echt kunnen.
Wat me opviel na de eerste tien gesprekken was niet de techniek. Bijna iedereen kon een taalmodel aan de praat krijgen. Waar het op vastliep was steeds hetzelfde: zodra ik doorvroeg op een concreet bedrijfsproces, een storing in productie, of de vraag wanneer je AI juist niet moet inzetten, viel het gesprek stil of werd het vaag.
Dat patroon was zo consistent dat ik het ben gaan opschrijven. Niet als klacht over de arbeidsmarkt, maar als vocabulaire. Als je weet welke drie lagen je zoekt, kun je tenminste gericht doorvragen in plaats van te hopen dat "AI-ervaring" op een cv genoeg zegt.
Dit stuk bevat geen namen en geen herleidbare kandidaten. Waar ik voorbeelden geef, gaat het om patronen die ik bij meerdere mensen terugzag, niet om één specifiek gesprek.
Wat opvalt na tientallen gesprekken is dat drie vaardigheden bijna nooit in één persoon samenkomen: zakelijk inzicht, technische executie en AI-expertise. Elke laag ontbreekt op een andere, herkenbare manier.
De meeste kandidaten zijn sterk op een of twee lagen. Een sterke developer zonder zakelijk inzicht bouwt een technisch mooi systeem dat het verkeerde probleem oplost. Een sterke procesanalist zonder technische executie levert een goed plan dat niemand bouwt. Pas als alle drie de lagen samenkomen, verandert er iets structureel.

Wie het bedrijfsproces niet kan doorgronden, bouwt het verkeerde ding perfect. Dat is geen reclamezin, het is het patroon dat ik het meest tegenkom.
In een gesprek vraag ik altijd naar een proces dat de kandidaat eerder heeft onderzocht. Wie alleen het verhaal van de manager navertelt, heeft het werk niet gedaan. Wie vertelt waar de praktijk afweek van het officiële proces, en waarom, heeft het wel gedaan.
Dit is het verschil tussen een demo en iets dat maandag nog werkt. Een demo draait op een schoongemaakte voorbeeldcase. Productie krijgt de rommelige invoer van een echte werkweek.
Hier vallen de meeste kandidaten af, en het is ook de laag waar wij in onze eigen bouw het meeste tijd in steken. Een werkend systeem herkent wanneer iets misgaat, legt vast wat er is gebeurd, en geeft op de juiste plekken de controle terug aan een mens in plaats van zelf door te denderen.
Anthropic beschrijft dit zelf als de kern van het verschil tussen een proof of concept en een werkend systeem: agents hebben uitgebreide tests in een afgeschermde omgeving nodig, duidelijke grenzen, en op de juiste plekken een mens die meekijkt (Anthropic, 2024).

De kandidaten die overal met een model voor komen, vallen hier het hardst af. Niet elke vraag is een promptprobleem.
Dit is ook de laag die het meest wordt onderschat door bedrijven zelf. Je wilt niet iemand die AI overal naartoe wil duwen, je wilt iemand die net zo makkelijk zegt: dit proces blijft beter een vaste regel, of dit blijft beter mensenwerk.
IBM wijst op precies dit risico: autonome AI-systemen nemen beslissingen zonder vast menselijk toezicht, en dat is riskant zodra de inzet hoog is. Daarom pleit IBM voor gecontroleerde testomgevingen en mensen die toezicht houden op wat een AI-systeem onderneemt (IBM, 2025).
Een licentie geeft toegang tot een model. Het geeft geen van de drie lagen hierboven erbij. Dat is waarom "we hebben nu AI" en "AI levert ons nu iets op" twee verschillende zinnen zijn.
Een los proof of concept bewijst dat iets kan. Het bewijst niet dat iemand het kan laten werken in jouw systemen, met jouw data, op een maandagochtend met een storing bij een leverancier.
Het probleem is bovendien niet dat jouw team niet zoekt. Volgens Eurostat was gebrek aan relevante expertise in 2025 de meestgenoemde reden voor EU-bedrijven om geen AI te gebruiken: 70,9 procent van de bedrijven die het wel hadden overwogen, noemde dat als reden (Eurostat, 2025). De markt praat je aan dat één AI-consultant het antwoord is, terwijl je drie verschillende dingen zoekt.
Dat verklaart ook waarom twee bedrijven met dezelfde licentie zo verschillend uitkomen. Het ene bedrijf huurt voor één proces iemand in die alle drie de lagen beheerst, en ziet binnen een paar weken dat proces structureel veranderen. Het andere bedrijf koopt meer licenties, en houdt hetzelfde resultaat: een paar enthousiaste gebruikers, geen verandering in het proces zelf.
Dit zijn de vragen die ik in een gesprek stel, precies op de drie lagen uit dit stuk. Geen trucvragen, gewoon de vragen waarop het antwoord laat zien of iemand het echt kan.
Let minder op het antwoord zelf en meer op hoe iemand twijfelt. De kandidaten die goed waren, zeiden regelmatig "dat weet ik hier nog niet, dat zou ik eerst uitzoeken". De kandidaten die zwak waren, hadden op elke vraag meteen een stellig antwoord.
Dezelfde toets geldt voor regelgeving. De EU AI Act deelt AI-toepassingen in naar risico, en vraagt precies op de risicovolle plekken om menselijk toezicht (Europese Commissie, 2026). Stel jezelf dezelfde vraag als een toezichthouder: waar in dit proces moet een mens blijven meekijken, en heeft de kandidaat daar al over nagedacht.
Je hoeft deze driehoek niet zelf in één persoon te vinden. Bij een Fractional Chief AI Officer werken wij embedded bij je team, bouwend in je eigen productieomgeving, en laten we de kennis achter in je organisatie.
Dat is ook de reden dat wij deze drie lagen nooit over één persoon verdelen op een project. Een opdracht krijgt altijd de combinatie van zakelijk inzicht, technische executie en AI-expertise, zodat je niet afhankelijk bent van één individuele inschatting van wat wel en niet werkt.
Een Forward Deployed AI Engineer werkt embedded bij een klant en bouwt AI-oplossingen die direct in de productieomgeving draaien, in plaats van op afstand te adviseren. De term komt oorspronkelijk van Palantir. Meer over de rol staat in onze eerdere blog over wat een Forward Deployed AI Engineer precies doet.
Een licentie geeft toegang tot een model, geen implementatie in jouw processen en systemen. Zonder iemand die het proces doorgrondt, het technisch robuust bouwt en weet wanneer AI niet de oplossing is, blijft de tijdwinst hangen bij een paar enthousiaste individuele gebruikers.
Dat hangt af van hoeveel AI-implementatie je structureel nodig hebt. De meeste MKB-bedrijven hebben geen volledige fte nodig, maar wel iemand die alle drie de lagen uit dit stuk beheerst. Een fractional of interim-constructie geeft die expertise zonder een vaste aanname.
Test op alle drie de lagen tegelijk: kan de persoon een bedrijfsproces doorgronden, kan hij of zij iets bouwen dat in productie blijft werken inclusief foutafhandeling en logging, en herkent de persoon wanneer AI niet de juiste oplossing is. Let daarbij minder op stellige antwoorden en meer op gezonde twijfel. Zie het vragenlijstje in dit stuk voor de exacte vragen die wij zelf stellen.
Dat verschilt per organisatie en per proces, dus we noemen hier geen vast bedrag. De prijs hangt vooral af van de scope: één proces embedded laten bouwen is iets anders dan een doorlopende Fractional Chief AI Officer-rol. Bekijk de Fractional Chief AI Officer-pagina voor de opzet.
Je IT-team kan vaak laag 2, de technische executie, deels invullen, vooral als er al ontwikkelervaring in huis is. Zakelijk inzicht in het specifieke proces en AI-expertise ontbreken daar meestal, simpelweg omdat dat niet hun dagelijkse werk is en de meeste IT-teams geen tijd hebben om daar structureel in te verdiepen. Vandaar dat embedded, tijdelijke versterking vaker werkt dan alles intern optuigen.
Een consultant adviseert vanaf de zijkant en levert een rapport of een roadmap. Een embedded engineer bouwt mee in jouw systemen, in productie, en laat een werkend resultaat achter in plaats van alleen een advies.
Dat hangt vooral af van hoe rommelig het proces en de data al zijn voordat je begint, dus we noemen hier geen vaste doorlooptijd. Wat we wel kunnen zeggen: een proces dat al goed gedocumenteerd is en in één systeem leeft, gaat merkbaar sneller dan een proces dat over vijf losse apps versnipperd zit.
Je hoeft deze driehoek niet zelf in één persoon te vinden. Wij werken embedded bij je team, bouwen in je eigen productieomgeving en laten de kennis achter in je organisatie.
Bekijk Fractional Chief AI Officer