
Interviews with candidates for the Forward Deployed AI Engineer role reveal a consistent pattern: business insight, technical execution, and AI expertise rarely come together in one person. Handing out a ChatGPT license buys access to a model, not the three skills that make an AI implementation actually work.
Over the past year I have spoken with dozens of candidates for the role of Forward Deployed AI Engineer. The full term is Forward Deployed Engineer (FDE) with AI specialisation: someone who builds alongside the client in production, rather than advising from the sidelines. The term originates from the military and was popularised around 2009 by Palantir (Wikipedia).
The trigger for these conversations is always the same pattern. A company hands out ChatGPT licenses to the team, a few people get excited, and something happens. Only the time saved stays with those few people. The process itself doesn't change, and leadership isn't sure who they should have hired to make that happen.
If you don't know the role: we wrote extensively before about what a Forward Deployed AI Engineer actually does. This piece isn't about that job description. It's about what I learned from actually talking to people who say they can fill that role, and why few of them really can.
What struck me after the first ten conversations wasn't the technology. Almost everyone could get a language model talking. Where it consistently broke down was the same every time: as soon as I pushed on a concrete business process, a production incident, or the question of when not to use AI, the conversation stalled or turned vague.
That pattern was consistent enough that I started writing it down. Not as a complaint about the job market, but as a vocabulary. If you know which three layers you're looking for, you can at least ask targeted questions instead of hoping "AI experience" on a resume means enough.
This piece contains no names and no identifiable candidates. Where I give examples, they describe patterns I saw repeated across multiple people, not one specific conversation.
What stands out after dozens of conversations is that three skills almost never come together in one person: business insight, technical execution, and AI expertise. Each layer is missing in its own recognisable way.
Most candidates are strong in one or two layers. A strong developer without business insight builds a technically beautiful system that solves the wrong problem. A strong process analyst without technical execution delivers a good plan that nobody builds. Only when all three layers come together does anything change structurally.

Whoever can't get to the bottom of the business process builds the wrong thing perfectly. That's not a marketing line, it's the pattern I run into most.
In a conversation I always ask about a process the candidate investigated before. Someone who just repeats the manager's version of events hasn't done the work. Someone who can explain where practice diverged from the official process, and why, has.
This is the difference between a demo and something that still works on Monday. A demo runs on a cleaned-up example case. Production gets the messy input of a real working week.
Most candidates drop out here, and it's also the layer where we spend the most time in our own build work. A working system recognises when something goes wrong, records what happened, and hands control back to a human at the right points instead of plowing ahead on its own.
Anthropic describes this as the core difference between a proof of concept and a working system: agents need extensive testing in a sandboxed environment, clear boundaries, and a human watching at the right points (Anthropic, 2024).

The candidates who reach for a model for everything drop out hardest here. Not every question is a prompting problem.
This is also the layer companies themselves underestimate most. You don't want someone who wants to push AI into everything, you want someone who says just as easily: this process is still better off as a fixed rule, or this stays better off as human work.
IBM points to exactly this risk: autonomous AI systems make decisions without fixed human oversight, and that is risky once the stakes are high. That's why IBM argues for controlled testing environments and people who oversee what an AI system does (IBM, 2025).
A license gives you access to a model. It doesn't add any of the three layers above. That's why "we have AI now" and "AI is delivering results now" are two different sentences.
A standalone proof of concept proves that something can be done. It doesn't prove that someone can make it work in your systems, with your data, on a Monday morning with a supplier outage.
The problem, moreover, isn't that your team isn't looking. According to Eurostat, lack of relevant expertise was the most-cited reason for EU enterprises not to use AI in 2025: 70.9 percent of the companies that had considered it named that as the reason (Eurostat, 2025). The market tells you that one AI consultant is the answer, while you're actually looking for three different things.
That also explains why two companies with the same license end up so differently. One company hires someone who masters all three layers for a single process, and sees that process change structurally within a few weeks. The other company buys more licenses, and gets the same result: a few enthusiastic users, no change in the process itself.
These are the questions I ask in a conversation, mapped exactly onto the three layers in this piece. No trick questions, just the questions where the answer shows whether someone can actually do it.
Pay less attention to the answer itself and more to how someone hesitates. The strong candidates regularly said "I don't know that yet, I'd want to find out first." The weak candidates had a confident answer ready for every question, immediately.

The same test applies to regulation. The EU AI Act classifies AI applications by risk, and requires human oversight exactly at the high-risk points (European Commission, 2026). Ask yourself the same question a regulator would: where in this process does a human need to keep watching, and has the candidate already thought about that.
You don't have to find this triangle in one person yourself. With a Fractional Chief AI Officer, we work embedded in your team, building in your own production environment, and leave the knowledge behind in your organisation.
That's also why we never split these three layers across one person on a project. An engagement always gets the combination of business insight, technical execution, and AI expertise, so you're never dependent on one individual's judgment of what works and what doesn't.
A Forward Deployed AI Engineer works embedded with a client and builds AI solutions that run directly in the production environment, instead of advising remotely. The term originally comes from Palantir. You can read more about the role in our earlier blog on what a Forward Deployed AI Engineer actually does.
A license gives you access to a model, not implementation in your processes and systems. Without someone who gets to the bottom of the process, builds it to be technically robust, and knows when AI isn't the solution, the time saved stays with a few enthusiastic individual users.
That depends on how much AI implementation you need on a structural basis. Most SMEs don't need a full-time hire, but they do need someone who masters all three layers from this piece. A fractional or interim arrangement gives you that expertise without a permanent commitment.
Test all three layers at once: can the person get to the bottom of a business process, can they build something that keeps working in production including exception handling and logging, and do they recognise when AI isn't the right solution. Pay less attention to confident answers and more to healthy hesitation. See the list of questions in this piece for the exact questions we ask ourselves.
That varies by organisation and by process, so we won't name a fixed amount here. The price depends mainly on scope: having one process built embedded is different from an ongoing Fractional Chief AI Officer role. Check the Fractional Chief AI Officer page for the setup.
Your IT team can often partly cover layer 2, the technical execution, especially if there's already development experience in house. Business insight into the specific process and AI expertise are usually missing there, simply because that isn't their day-to-day work and most IT teams don't have time to build that up structurally. That's why embedded, temporary reinforcement tends to work better than building everything in-house.
A consultant advises from the sidelines and delivers a report or a roadmap. An embedded engineer builds alongside you in your systems, in production, and leaves behind a working result instead of just advice.
That depends mainly on how messy the process and the data already are before you start, so we won't name a fixed timeline here. What we can say: a process that's already well documented and lives in one system moves noticeably faster than a process fragmented across five separate apps.
You don't have to find this triangle in one person yourself. We work embedded with your team, build in your own production environment, and leave the knowledge behind in your organisation.
View Fractional Chief AI Officer