Vet the AI Team Before You Sign: Due Diligence for AI Roles

What you need to know

• You have more leverage than you are using. The supply gap is structural, not a moment, and it applies in both Indian and British markets.
• One question predicts most of the rest: how does this team know the AI feature is working? Everything downstream follows from whether an answer exists.
• Five things determine whether an AI role is real: evaluation practice, data rights, inference budget ownership, on-call reality, and vendor exit path.
• The worst outcome is not a bad job, it is two years of unshowable work. Roles where you cannot describe what you built are career-expensive in a field this fast-moving.
• Ask the questions as curiosity, not challenge. Good teams enjoy them. Bad teams reveal themselves. Both outcomes are useful.

Why the lens should flip

The numbers underneath this are worth stating because they are what justifies asking.

As of mid-2026, reporting on the Indian market puts demand for AI engineers growing at roughly 40% year on year against a skilled talent pool growing 15 to 20% — and around 11.7% of Indian job postings now explicitly require AI skills, up from 8.2% a year earlier. Deel's global hiring data counted a 283% increase in AI roles over the preceding year. In the UK, senior AI engineers sit in a £90,000 to £150,000 base band against a general average nearer £55,500, a spread that tells you the market is paying a large premium for demonstrated capability rather than a title.

These figures come from recruitment and market-data publishers rather than official statistics, and they should be read as directional. But the direction is unambiguous and consistent across sources: there are more AI-branded roles than there are people who can do them.

That gap has a second-order effect nobody warns candidates about. When a company needs an AI capability it does not have, and cannot hire the people who would build it properly, it hires someone and calls the role AI engineering anyway. The result is a category of job that has the title, the salary band and the LinkedIn announcement, and no actual AI engineering in it. Distinguishing those roles is the skill this guide is about.

The five things that determine whether the role is real

1. Does an evaluation practice exist?

This is the load-bearing question. A team that measures its AI system has, by necessity, also thought about what good output means, has data to measure against, has a feedback loop, and has had at least one argument about quality that was resolved with evidence. A team that has not built evals has usually not done any of those things.

It is also the question hiring managers themselves report as most diagnostic in the other direction — evaluation literacy is now a standard probe in senior AI interviews precisely because it separates people who have shipped from people who have demoed. If they are testing you on it, you are entitled to test them.

2. Whose data is it, and can you actually use it?

An AI role without data access is a prompt-engineering role with a better title. Ask specifically: is there production data, who owns it, what is the process to get access, and how long does it take. In regulated Indian and UK contexts — financial services, health, anything touching personal data under DPDP or UK GDPR — the honest answer is sometimes "six weeks and a DPIA", which is fine. The concerning answer is that nobody knows.

3. Who owns the inference budget?

Follow the money, because it tells you whether the AI work is a real product line or an experiment on someone's discretionary spend. A team with its own inference budget can make decisions. A team spending from an innovation fund is on a clock nobody has told you about.

Ask what the monthly spend is and whether anyone tracks cost per task. A team that can answer immediately has a functioning unit-economics practice of the kind we set out in our guide to LLM unit economics and cost per task. A team that cannot has not yet met the moment when finance asks.

4. What happens when it goes wrong, and who is on call?

Every AI system in production fails in ways the team did not anticipate. What varies is whether there is a process. Ask about the last incident: what happened, how was it detected, who was woken up, what changed afterwards. A team that has a story here has been in production. A team that says nothing has gone wrong has either not launched or is not watching.

This question has become more pointed over the past year as agent deployments have widened. Security surveys published in 2026 report that a large majority of organisations — one widely cited figure is 88% — experienced a confirmed or suspected AI agent security incident within the previous year. Take the specific number with appropriate scepticism given it comes from a vendor survey; take the pattern seriously.

5. Is there a path off the current vendor?

Not because you should avoid teams with a single vendor — most sensible teams have one. But because the answer tells you how deeply anyone has thought about the architecture. A team that has considered what a forced migration would cost has abstracted its prompts, has an eval suite that can score a replacement, and knows which behaviours are model-specific. Our guide to building an LLM vendor exit plan covers what that looks like in practice. A team that has never thought about it has probably coupled application logic to one provider's quirks.

The questions, by interview stage

Do not ask all twenty-two. Pick the ones that fit the stage and the person in front of you.

Recruiter screen — cheap questions, high information

1. Is this a new role or a backfill? If a backfill, how long was the previous person in it?
2. How long has the role been open?
3. How many people are on the team today, and how many were there a year ago?
4. Is the AI work a product the company sells, or an internal capability?
5. What is the interview process, and does it include anything hands-on with their actual system?

Question two does a surprising amount of work. A specialist role open for six months usually means either a specification nobody can satisfy or a job people leave.

Hiring manager — the substance

6. How do you know the AI feature is working? Walk me through the measurement.
7. What did your evaluation suite catch most recently, and what happened next?
8. What is in production today, how long has it been there, and how many users touch it?
9. What is the monthly inference spend, and whose budget is it?
10. Do you track cost per task or per user?
11. Tell me about your last incident.
12. What would I have shipped by the end of my first quarter?
13. What is the hardest technical problem the team has open right now?
14. Who makes the call when the model and the product manager disagree about quality?

Question thirteen is underrated. A manager who lights up describing a genuinely hard open problem is running a team with real work. A manager who cannot name one is running an integration project.

Peer round — where the truth lives

15. What surprised you about this codebase when you joined?
16. How long does it take to get from an idea to something running against real data?
17. How much of your week is building versus reviewing versus meetings?
18. What is the thing about working here you would change tomorrow if you could?
19. When was the last time a model or prompt change went out and something broke?

Ask question eighteen of everyone and compare. Consistent answers mean a team with shared understanding of its problems. Wildly different answers mean people are experiencing different companies.

Offer stage — the commitments

20. Can I publish or speak about the work, in general terms, with approval?
21. What is the policy on open-source contribution during employment?
22. Is there a training or compute budget, and who approves it?

Question twenty matters more than people realise, and it is the reason many strong engineers in this field are invisible. If everything you do for two years is unpublishable, your evidence base stops growing at your joining date. Our guide to building proof of work under an NDA covers the workarounds, but it is far better to negotiate the permission upfront while you still have leverage.

Reading the answers

What the answers to the five core areas tend to sound like across the range.

Area	Green	Amber	Red
Evaluation	Names the suite, how it was built, a regression it caught	"We're building that out this quarter"	"Users tell us if it's wrong"
Data	Production data, defined access process, known timeline	Synthetic or sampled data, access "usually a few weeks"	No one can say who owns it
Budget	Knows the monthly number and the cost per task	Knows the number, not the unit economics	Spend sits under an innovation fund with an end date
Incidents	Specific story, detection method, concrete change afterwards	"We've had a few things, nothing major"	"Nothing has gone wrong" — with a year in production
Vendor	Abstracted, eval suite can score a swap, knows the cost	Single vendor, has thought about it, not done it	Has not considered it; provider quirks are in the app logic

A row of amber is completely normal and is often a good sign — it describes a team that is building the practice honestly. A single red is worth probing rather than walking away from. Three reds is a pattern.

What to check before you apply

Half of this diligence can be done before you spend an hour on an application.

• Read the advert for artefacts, not adjectives. A real role names a stack, a scale and a problem. A vague one lists twelve technologies and the word "cutting-edge".
• Look for public evidence of engineering. An engineering blog with real content, conference talks, open-source contributions, papers. Absence is not disqualifying for a small team; presence is strong positive evidence.
• Check tenure patterns. If the AI team's engineers consistently leave at fourteen months, that is data.
• For startups, check the funding date. A team that raised eighteen months ago and has not raised since is on a different clock from one that closed a round last quarter, and it changes what "we're investing heavily in AI" means.
• Search for the company plus "incident" or "outage". Cheap, occasionally very informative.

The market-specific bits

Global capability centres in India

GCC roles have become one of the largest sources of AI engineering employment in India, and they range from genuinely excellent to purely executional. The question that separates them is not about technology, it is about decision rights: does your team own a system end to end, or implement specifications written elsewhere?

Ask who decides what gets built, where the product manager sits, and whether anyone in the India team has shipped something that originated as their idea. We covered the wider picture in our guide to AI roles at global capability centres. The pay can be excellent at both ends of that range; the career trajectory is very different.

UK startups and the funding cycle

British AI startups raised strongly through the first half of 2026, which means a large number of teams are currently between eighteen and thirty months from their last round. That is the window in which "we're hiring aggressively" and "we need to show revenue by Q2" are simultaneously true. Ask directly about runway. Good founders answer; the reaction to being asked is informative either way.

Consultancies and services firms

An AI role at a services firm can be superb for exposure — you will see fifteen client architectures in two years, which no product company can offer. The risk is depth: shipping a pilot repeatedly is not the same as operating a system. Ask what proportion of engagements go to production and how many the firm still runs a year later.

If you are already somewhere that fails this test

Do not resign on Monday. Extract evidence first, because that is what actually changes your options.

Build the thing nobody asked for. If there is no evaluation suite, build one — our guide to testing agent reliability is a reasonable starting point and the work is measurable within a fortnight. If nobody knows the cost per task, work it out and write it down. If an incident happened and was never documented, document it.

Three things follow from this. The artefacts are portable and are exactly what your next interviewer will probe. The work often improves the current job enough to change the calculation entirely — teams without evaluation practice frequently just lack someone who has built one. And you convert a period you would otherwise describe vaguely into something specific, which is the difference between a strong application and an unconvincing one. Our guide to writing a hiring-ready case study covers how to turn it into a page someone will actually read.

Give it two quarters. If nothing shifts, leave with the evidence rather than without it.

Next steps

Concretely, three things this week. Write your own version of the five core questions — the ones that matter to you may differ from the ones here, and phrasing them in advance means you will actually ask them. Check the public signals for the two or three companies currently on your list. And make sure the work you already have is visible, because the whole leverage argument in this guide depends on inbound interest, and inbound interest depends on being findable.

That last point is the one candidates most often skip. Vetting employers only works when you have options to compare, and options come from being discoverable before you need to be. A profile that already lists what you have built puts you in the searches that produce the conversations where these questions become useful. If you are in India or the UK, adding one takes about two minutes, and the Founding Builder cohort is still open.

Related reading: the question clusters AI interviewers use, the rubric hiring managers score you against, and benchmarking and negotiating AI engineer pay in India and the UK. Market figures cited are as of August 2026.