What you need to know

  • This guide assumes you have already settled comp. Benchmarking and countering on money are covered in the India and UK pay benchmark guide and in the two-tier market negotiation guide. Everything below starts after the number is agreed.
  • Seven terms decide whether the role produces work. Compute and API budget, evaluation time, model and data access, publication and open-source rights, on-call load, scope and decision rights, and learning budget. Each is negotiable. Almost nobody negotiates any of them.
  • The leverage exists and is being spent on one line. Aggregator data compiled in 2026 suggests demand for AI engineers is rising roughly 40% year on year while the skilled talent pool grows only 15–20%. That gap is a bargaining position, and candidates convert nearly all of it into base pay.
  • The senior salary bands disagree with each other, and that is the useful part. When aggregators cannot agree what a senior AI engineer is worth, the market has no settled price — which is exactly the condition under which non-cash terms are winnable.
  • Frame every ask as a delivery requirement, never a perk. State the outcome you are being hired for, name the resource it needs, and ask what is currently available. That sentence pattern is most of the technique.

There is a particular kind of professional disappointment that arrives about a year into a well-paid AI role. The money landed. The title was right. And when someone asks what you have built, the honest answer is a set of internal dashboards nobody outside the company will see, a fine-tune cancelled because the GPU allocation never came through, and a retrieval pipeline nobody gave you time to evaluate, so nobody — including you — can say whether it works.

None of that was in the offer letter. It was all decided in the weeks after you signed, by people making budget and rota decisions you were not part of, according to constraints nobody thought to mention during the interview because nobody asked.

The offer is a bundle and you are negotiating one item in it

Compensation gets negotiated because it is legible. One number, both sides know it matters, and there is a well-worn script for going back and forth on it. Everything else in the bundle is invisible by default: no line on the offer letter, no market benchmark, no ritual attached to it. It passes unexamined into the category of things you will simply discover.

Consider the arithmetic of getting the money right and the conditions wrong. Suppose you negotiate a ten per cent uplift on base — a genuinely good outcome, and the thing most negotiation advice exists to produce. Now suppose the role has no dedicated inference budget, so every experiment competes with a product team's spend and loses; no allocated evaluation time, so you ship on intuition and cannot defend a claim about quality; and a publication policy that means nothing you build is ever visible outside the company. Eighteen months later you are ten per cent better off with no portfolio and no defensible story about what you can do. The next negotiation — the one that actually compounds — starts from a much weaker position.

That is the trade almost everybody makes, and it is not made deliberately. It is made by omission.

Pro tip

Before the offer conversation, write down the single sentence you want to be able to say about this job in two years' time. Then work backwards to what that sentence requires: compute, time, access, permission to show it. Those are your asks. Everything else on this page is a way of phrasing them.

Where the leverage comes from, and why it is real

Two things make this a negotiation rather than a request, and both are visible in the public pay data even though the pay data is not what we are negotiating over.

The first is the supply gap. Aggregator figures compiled in 2026 put year-on-year growth in demand for AI engineers at roughly 40%, against growth in the skilled talent pool of only 15–20%. In India, around 11.7% of all job postings now explicitly require AI skills, up from 8.2% a year earlier. Reported salary growth is averaging 15–20% annually in top talent segments. Treat these as indicative rather than authoritative: they are secondary aggregations, not primary survey data, and they compress very different roles into one label. The direction is what matters — employers are competing for a thin pool, and a candidate at offer stage has more room than they use.

The second is more interesting, and it is the disagreement in the data rather than the data itself. As of May 2026, Glassdoor put the average base for an AI engineer in India at approximately ₹10 LPA, with typical salaries falling between ₹6 and ₹16 LPA; entry level is commonly cited at ₹2–7 LPA and four to six years' experience at ₹10–15 LPA. Those junior and mid figures are broadly consistent across sources. At the senior end, the consistency collapses. One set of aggregators cites ₹25–50L and above for senior AI architects and specialists. Another cites ₹40L to ₹95L for comparable roles. Those are not small variations around a shared centre; they are different accounts of the market.

Resist the urge to pick one. The spread is the finding. When the aggregators cannot agree what a senior AI engineer is worth to within a factor of two, there is no settled price — employers are pricing these roles case by case, from a mixture of internal bands, competitor panic and whatever the last hire cost them. The UK figures are tighter, with senior AI engineers commonly quoted at £90,000–£150,000 base as of 2026, but the same condition holds: nobody is working from a rate card anybody else agrees with.

An unsettled market is precisely where non-cash terms are winnable. A hiring manager who cannot confidently defend a salary number against a competing offer often has considerable latitude over the things that never appear on the compensation spreadsheet — the GPU allocation, the sprint time, the access tier, the permission to publish. They come out of different budgets and are frequently easier to grant than another five per cent on base.

The seven terms that decide whether you can do the job

Be clear about what follows. There is no public dataset on compute budgets for AI engineering roles: nobody surveys it, no aggregator tracks it, and any figure quoted for a "normal" monthly inference allowance has been invented. So this section contains no benchmarks. It contains the questions worth asking and a way of reading the answers, which is the part that transfers between markets.

1. Compute and API budget

Ask for a stated monthly figure, in currency, that you can spend on inference, training and experimentation without seeking permission. Then ask three follow-ups that matter more than the number: who approves an overspend and how long that takes; whether experimentation is charged against the same budget as production serving; and what happens when you need a much larger allocation for a fortnight to run a fine-tune or a sweep.

The second follow-up is the one that quietly kills research work. When experiments and product traffic draw on a single pool, every experiment becomes an argument about degrading the product's margin, and that is an argument the experiment loses. A separate line, even a small one, changes the default from "justify this" to "spend it".

2. Evaluation time

This is the single strongest predictor of whether a role produces defensible work, and the one almost never discussed at offer stage. Ask for explicit allocation — a proportion of each sprint, or a named phase before each release — for building and maintaining evaluations, not merely running them.

The distinction is load-bearing. Running an existing eval suite is cheap and everybody agrees it should happen. Building one is slow, unglamorous, produces no demo, and is the first thing cut in a tight quarter. An organisation that has not allocated time to build evals is shipping on intuition, and you inherit the consequences: no way to prove a change improved anything, and no evidence to point at in your next interview.

3. Model and data access

Establish which models you can reach and through what. Direct API access to frontier models is a different job from read-only access through a locked internal gateway where somebody else chooses the model, sets the temperature, caps the context and logs everything. Both are legitimate architectures. Only one lets you evaluate a new release the week it lands.

On data, ask whether you will work against production data, a governed sample or synthetic data only — and crucially, how long an access request takes end to end. A four-week turnaround is not an inconvenience; it is a hard cap on how many ideas you can test in a year. In UK regulated sectors and in Indian centres handling client data under contract, long turnarounds are often unavoidable, which is exactly why you want the number before you sign rather than in your second month.

4. Publication, open-source and portfolio rights

Ask what you may write about, what you may open-source, and whether anything you build will be visible to anyone outside the company. Then ask who decides and how long the review takes, because a policy that permits publication in principle and requires four sign-offs in practice is a policy of no.

This is where the career arithmetic gets sharpest. Work nobody can see does not compound. It cannot be cited, evaluated or used to open the next conversation, and after a few years of it your record consists of job titles and your own account of what happened inside them. A Verified Builder profile on AI Tech Connect is where the work you are permitted to show actually lives — the deployed system you can describe in outline, the internal tool you can characterise without breaching anything, the open-source contribution the policy allowed. It is what lets a hiring team see proof before the first call, which is precisely what makes this negotiation worth winning. If most of your best work sits behind a confidentiality wall, the guide to proof of work under NDA covers what can legitimately be shown and the portfolio guide covers how to structure it.

5. On-call and interruption load

Agent systems fail loudly, expensively and at inconvenient hours. Ask for the rota size, the frequency of your rotation, what counts as an incident, and what compensation or time off in lieu attaches to a night call. Then ask the question underneath: what protects deep work during the weeks you are not on call.

A rota of four means a week in four, indefinitely. Combined with an interrupt-driven support channel, it can leave no contiguous block long enough to build anything substantial. That is not a lifestyle complaint; it is a capacity constraint on the output the role was created to produce, and it should be discussed as one.

6. Scope and decision rights

Establish whether you choose the architecture or implement someone else's. Both are real jobs with real seniority attached — but they are different roles carrying the same title, and only one accumulates the judgement that gets you the next one.

The sharpest version of the question, and the one that most reliably reveals how an organisation operates: who can override an evaluation result? If a benchmark says a change makes the system worse and a senior stakeholder wants it shipped anyway, what happens? The answer tells you whether your evaluations will function as a decision mechanism or as decoration.

7. Learning and conference budget

Small money, disproportionate signal. An organisation with no line for conferences, courses or paper-reading time has not internalised that the field moves faster than its staff can absorb by osmosis. The amount matters less than whether the line exists and whether the time to use it is protected: a generous allowance nobody is free enough to spend is a line item, not a benefit.

What a good answer sounds like

Below is the compressed version, usable as a checklist during a call. Read the right-hand columns carefully: the bad answer is rarely a refusal, it is a vagueness — and vagueness at offer stage reliably becomes a constraint after it.

Dimension What to ask for A good answer sounds like A bad answer sounds like
Compute and API budget A stated monthly figure, a named approver for overage, and experiments on a separate line from product spend "Roughly this much a month, the platform lead approves anything above it within a day, and research spend is tracked separately." "We've never really capped it." Or: "That comes out of the product budget, so you'd square it with the PM."
Evaluation time Explicit allocation per sprint or per release for building and maintaining evals, not just running them "Every release has an eval phase before sign-off, and the eval suite is owned work with a name against it." "Quality is everyone's responsibility." Or: "We evaluate as we go."
Model and data access Named models, the gateway or direct route, the data tier, and the turnaround on an access request "Direct API keys for these providers; production data via a governed sample, approved in about a week." "You'll have everything you need." Or an inability to say who owns the gateway.
Publication and open-source What you may write about, what you may open-source, who approves, and how long approval takes "Engineering blog posts go through one review; personal open-source outside working hours is carved out in the contract." "We'd have to look at that case by case." Silence on personal projects is not permission.
On-call and interruptions Rota size, rotation frequency, incident definition, compensation, and what protects non-on-call weeks "Rota of eight, one week in eight, night calls carry time off in lieu, and support requests are triaged by a duty engineer." "It's pretty quiet, honestly." Or: "We all just pitch in when something breaks."
Scope and decision rights Whether you set the architecture, and who can override an eval result "You own the design; a failing eval blocks the release, and overriding it needs a written rationale." "The architecture's mostly settled." Or an override path that runs through whoever is most senior in the room.
Learning budget An annual figure, and protected time to use it "There's an annual allowance and a standing half-day; people actually take it." "We're flexible about that sort of thing."

Every article here is written by a Verified Builder. Want your name on the next one?

AI Tech Connect lists AI engineers, founders and researchers across India and the UK — and the people hiring browse it to find them. Adding your profile is free.

Become a Verified Builder →

How to ask

Timing first. Raise all of this after compensation is agreed and before you sign. Raise it while the number is still open and you invite a trade you do not want, in which a compute allowance quietly substitutes for base pay. Raise it after you sign and a negotiation becomes a request, and requests are answered on convenience.

Then framing. Every ask here can be phrased as a perk or as a delivery requirement, and the phrasing determines the answer. "Do you offer a learning budget?" is a benefits question and gets a benefits answer. "I want to evaluate new model releases within a week of launch — what does the access path for that look like?" is a delivery question, and it gets an engineering answer from an engineer.

The pattern underneath is three beats: state the outcome you are being hired for, name the resource it requires, ask what is currently available. It works because it is not adversarial. You are not asking for something for yourself; you are asking how the thing they have just agreed to pay you for is supposed to happen.

Copy and adapt — send after comp is agreed, before you sign.

Subject: Two things before I sign — how the first six months work

Hi [name],

Delighted we've landed on the package. Before I sign I'd like to
understand how the day-to-day will actually run, so that what I've
committed to delivering is something we both think is achievable.

  1. COMPUTE — You've described the first six months as getting
     [outcome] into production. That means a fair amount of
     experimentation before anything ships. What's the monthly
     inference and training budget for the team, who approves
     going over it, and is experiment spend tracked separately
     from product serving?

  2. EVALUATION — I'd want to build a proper eval suite for
     [system] rather than inherit one, since that's what makes
     the quality claims defensible later. How is that time
     allocated at the moment — a phase in each release, a share
     of each sprint, or something else?

  3. ACCESS — Which models can the team call directly, and which
     go through an internal gateway? And roughly how long does a
     production-data access request take end to end?

  4. ON-CALL — How large is the rota, how often would I be on it,
     and what's the arrangement for night incidents?

  5. WRITING — I write publicly about engineering work. What's
     the process for an engineering blog post, and how does the
     contract treat personal open-source done outside work?

Happy to talk any of these through on a call if that's easier.

[your name]

Five questions is the practical ceiling for one message. If you need to cut, keep compute and evaluation — they are the two that most directly determine whether the role produces anything.

Watch out

Do not send this to a recruiter and expect a useful answer. Recruiters are measured on closing offers and rarely know the team's inference budget or eval practice. Send it to your future manager, or ask for a short call with them specifically. If a company will not put you in front of the person you would report to before you sign, you have learned something more important than the answers.

Reading the answer

The answers are more informative than the commitments, because they are unrehearsed. Nobody prepares for these questions the way they prepare for salary negotiation, so what you get is close to how the organisation actually thinks.

Take the evaluation question, the most diagnostic of the set. A manager who answers with a mechanism — a phase, an owner, a gate — is describing a team that has been burned by shipping something unmeasurable and built a habit in response. A manager who answers with a principle ("quality matters to us") is describing an aspiration. A manager mildly puzzled by the question is telling you the team does not build evaluations, and that if you want them you will be doing it as unfunded work alongside the roadmap.

Distinguish carefully between "I don't know the number" and "I don't know that a number exists". The first is common and fine; budgets often sit with a platform team, and a manager who goes and finds the figure has answered well. The second is the warning: experiments have never been costed, so the first time your spend is noticed will be when finance asks what it is for.

Vagueness deserves one clarifying attempt and no more. Ask again, specifically — "I appreciate it varies; what did it look like last quarter?" A second vague answer is an answer. It usually means the thing does not exist, and that you would be creating it yourself with no mandate.

Avoid

Accepting a role on an enthusiastic promise with no mechanism behind it. "We absolutely want you publishing" is worth nothing without an answer to who approves it and how long that takes — and the same holds for compute without an approver, eval time without an owner, and decision rights without an override rule. Enthusiasm is not a process, and the person promising may not be your manager in a year.

Sometimes the right move is to decline. If a role is described as building production AI systems and there is no compute budget, no eval time and no path to publish anything, the organisation wants the title without the function. That is a legitimate thing for a business to want and a poor place to spend two years during which the field will move considerably. The due-diligence guide to vetting an AI team covers the wider assessment, including the questions worth putting to engineers rather than the hiring manager.

India and the UK: the same terms, different signatories

The seven dimensions travel. What changes across the two markets is who holds the authority to grant them, and getting that wrong wastes a negotiation on somebody who was never able to say yes.

Structural factor India — GCC and services UK — startup and enterprise
Who owns the compute budget In a global capability centre, frequently a parent-company platform function abroad; the local manager consumes an allocation rather than setting one. In services firms, it is charged to a client engagement. In a startup, the founder or engineering lead, who can usually commit immediately. In an enterprise, a central platform team with an annual planning cycle.
What that means for your ask Ask about the escalation path and the turnaround, not just the figure. A GCC manager who explains how allocation requests work has given you a more useful answer than a number they cannot guarantee. In a startup, get the commitment but note that it is only as durable as the runway. In an enterprise, ask when the planning cycle closes and whether your requirement is in it.
Data access Often governed by client contract as well as by the DPDP framework; in services work, the client's rules bind you and can differ per engagement. Information security and data protection review own it, particularly in financial services and health. Review cycles are the constraint, more than permission itself.
Publication and open-source Client confidentiality frequently prohibits naming the work at all. A carve-out for personal projects done outside working hours is the realistic ask. Startups are usually permissive and sometimes actively want the visibility. Enterprises route through communications and legal, and the timeline is the real question.
On-call Follow-the-sun coverage can mean your rota is shaped by another region's business hours. Establish which time zone's incidents you carry. Startups often have small rotas and no formal compensation. Enterprises usually have both a policy and an allowance; ask to see the policy.
Where the leverage sits Bands are frequently rigid and set centrally, which is precisely why non-cash terms are the negotiable surface. See the guide to AI roles in global capability centres. Startups trade cash for scope and autonomy and will often grant both generously. Enterprises trade the reverse; expect process, negotiate for access.

Get it in writing — and know what cannot be

Not everything here is enforceable, and pretending otherwise leads people to over-invest in an offer letter that was never going to carry the weight. Sort your asks into three tiers.

Tier What belongs there How to secure it
In the offer letter or contract Title, level, reporting line, location and hybrid pattern, on-call eligibility and any allowance, annual learning budget, and any amendment to the intellectual property clause covering personal open-source work. Ask explicitly and expect a redraft. An IP carve-out for personal projects is a routine amendment at many employers and is the single most valuable contractual ask on this page.
In a documented email Compute and API budget, evaluation time allocation, model and data access tiers, scope and decision rights, override rules on eval results. Summarise the call in an email to your future manager and ask them to confirm you have understood correctly. No legal weight; considerable practical weight, especially when a reorganisation later makes the record useful.
Trust only Protection of deep-work time, the culture around interrupting people, whether the eval gate is respected when a deadline is close. Unenforceable by construction. Judge it by asking two engineers already on the team the same questions and comparing their answers with the manager's.

The middle tier is where most of the value sits and where most people do nothing. A short email — "to confirm my understanding: the monthly budget is X, overage goes through Y, and each release includes an eval phase" — costs five minutes and creates a shared record. It will not survive a court. It will comfortably survive a change of manager, which is the failure mode worth planning for.

Recommended

Ask to speak to one or two engineers on the team, not just the manager, and put the same questions to them. Discrepancies are the finding. If the manager describes a dedicated eval phase and an engineer describes writing tests at the weekend before a launch, believe the engineer.

What you are actually negotiating for

None of this is about comfort. Every term on this page maps to a specific way that AI work fails: experiments that never run because nobody costed them, systems that ship unmeasured because evaluation was somebody's spare time, capability that goes stale because access sits behind a queue, and eighteen months of genuine effort that produces nothing anybody outside the building can verify.

The conditions that make this winnable will not last indefinitely. As of 2026, demand is outrunning supply by a wide margin and the senior end of the market has no agreed price — and an employer who cannot confidently price you has room to move on everything that is not price. Settle the money using the benchmarking method in the pay guide. Then spend the leverage you have left on the seven things that determine whether, two years from now, you have a body of work or just a longer CV.