GenAI and AI/ML are two different hires. Most JDs miss it.

Under “AI/ML engineer” sit at least three roles that share almost nothing day to day. The ML and platform engineer builds and runs the machinery: feature pipelines, model training, serving infrastructure, MLOps. The applied-GenAI builder wires foundation models into a live workflow and owns the messy last mile: retrieval, evaluation, guardrails, the cost of a wrong answer at scale. The researcher advances the model itself, closer to the paper than to the product.

These are different skills drawn from different pools, and they clear at different prices. The platform engineer comes from a deep, decade-old analytics and data-science bench. The production-GenAI builder comes from a pool that barely existed 2 years ago. The researcher comes from a small academic and frontier-lab world with its own currency, where publications and citations carry more weight than a shipped feature.

Write all three into one requisition and the shortlist inherits the confusion. A hiring manager screens a strong researcher for a seat that needed a product builder. Everyone leaves the loop vaguely dissatisfied, the offer gets benchmarked against an average that describes none of the three, and the mis-hire rate climbs in a way that looks like bad luck. It was decided the moment the JD priced and pitched three roles as one.

Most reqs give the profile away in the responsibilities section, if you read it for what the seat actually owns rather than the keywords stacked in it. The tell is the verb attached to the outcome. “Build and maintain training pipelines,” “own model serving and monitoring,” “improve inference latency” describe an ML and platform engineer. The scarce skill is reliability at scale, and the deep pool supplies it.

“Integrate an LLM into the product,” “stand up retrieval and evaluation,” “own the quality of generated output in front of users” describe an applied-GenAI builder. The scarce skill here is production judgment about systems that fail in soft, expensive ways. “Investigate novel architectures,” “publish,” “push benchmark performance” describe a researcher, and if those words are in the JD by accident, you’ll interview people the rest of the panel can’t evaluate.

A useful discipline is to ask which sentence in the req, if deleted, would change who applies. Usually it’s one. When a description tries to keep all three sets of verbs, it’s hiding a decision the hiring manager hasn’t made yet. The clean reqs read as though someone already knew which of the three they needed and wrote only for that person.

The platform engineer keeps AI in production working. Their output is uptime, throughput and a pipeline that retrains without drama. Hire this profile when the model already earns its keep and the risk is operational: latency, cost, reliability, the plumbing that a demo never has to survive. Their value compounds quietly over quarters, and it’s straightforward to benchmark because the market has priced this work for years.

The applied-GenAI builder turns a capable model into something a customer can trust. Their output is a feature that behaves under real inputs, an evaluation harness that catches regressions before users do, and a considered answer to what happens when the model is confidently wrong. This is the profile most enterprises actually mean when they say they’re “hiring for GenAI,” and it’s the one the market is racing to build. India’s AI-talent demand will exceed 1.25 million by 2027, up from roughly 600,000–650,000 in 2022, against a shortfall of about 50% in 2024, according to Deloitte and Nasscom. The proven production subset of that pool is a fraction of a fraction.

The researcher moves the frontier. Their output is a method, a result, a paper, and on most enterprise teams, hiring one is a category error dressed as ambition. A researcher on a delivery team is expensive, under-used and quick to leave, because the work you have isn’t the work they came to do. Reserve the profile for the rare mandate that genuinely needs new capability rather than applied capability, and price it against named peers rather than a salary band.

The umbrella label does two kinds of damage, and they compound. The first is the mis-hire: a shortlist assembled from three incompatible pools, screened against a rubric that fits none of them, closing on whoever interviewed best rather than whoever the seat needed. The second is the money. A single AI/ML benchmark averages three populations with different economics, so its midpoint describes no one. You over-pay the platform engineer, who finds the offer generous and settles in comfortably. You under-pay the production-GenAI builder, who has quietly read the gap on their own req and stopped replying.

That asymmetry has a market behind it, not a hunch. Naukri’s JobSpeak Index recorded AI/ML roles growing around 45% over the year, far ahead of the roughly 8% for white-collar hiring overall, while the senior 20-plus-LPA band rose about 16%. Postings surge fastest exactly where the proven pool is thinnest. An offer built on the blended average lands wrong twice in the same requisition: too high for the abundant profile, too low for the scarce one.

The cost isn’t only the closed role. It’s the strong mid-level engineer who watches production-GenAI offers clear above the band you quoted them and reads the ceiling before you do. Price three profiles as one and you lose the person you most needed to win while over-paying for capability you could have sourced at a fair rate.

Make one decision before the req exists: which of the three profiles this seat needs, tied to the outcome it owns. That single choice sharpens the JD, the screen, the comp benchmark and the assessment at the same time. It’s a small act of specificity that most teams skip, because “AI/ML engineer” is a comfortable label that defers the hard question to the interview loop, where it’s far more expensive to answer.

With the profile named, write the req to it and nothing else. Lead with the outcome the seat owns: “own the quality of our generated summaries in production” screens harder than “experience with LLMs, RAG, Python.” State the proof you will interview for: systems in production for the platform engineer, a live generative feature with owned failure modes for the builder, a research portfolio for the researcher. Cut the verbs that belong to the other two profiles, because each one you leave in widens the shortlist toward people the panel can’t fairly assess.

Then benchmark the profile itself. Price the platform seat against a published market average, because the deep pool holds that rate. Price the production-GenAI seat case by case against demonstrated experience. Price the researcher against named peers and the frontier. One req, one profile, one benchmark, and the shortlist stops being three people who could never have been right for the same job.