Job boards use 'AI engineer,' 'ML engineer' and 'data scientist' as if they were synonyms with different pay bands attached. They aren't. Each role sits at a different point in the path from raw data to a shipped product, and hiring the wrong one is the single most common reason a first AI hire quietly fails to move the roadmap for two quarters.
What each role actually does, day to day
Strip away the titles and look at the artifact each role is accountable for shipping. A data scientist's artifact is usually an analysis or a notebook that answers a business question: will this pricing change increase churn, does this segment behave differently, is there signal in this data at all. An ML engineer's artifact is a trained, versioned model with a defined accuracy target, deployed behind an API, with a retraining pipeline behind it. An AI engineer's artifact is a working product feature, a chatbot, an extraction pipeline, an agent, built by orchestrating existing foundation models (via API or self-hosted) with prompts, retrieval, tool calls and evaluation harnesses, and rarely training a model from scratch.
- Data scientist: statistical analysis, experiment design, exploratory modeling, answering 'is there a signal here.'
- ML engineer: feature pipelines, model training and tuning, deployment infra, retraining and monitoring for a model the company owns.
- AI engineer: prompt and retrieval design, orchestration between models and tools, evals, latency and cost tuning, shipping a feature end to end on top of a foundation model.
- Overlap zone: all three can write Python, all three can be asked to 'look at the data,' which is exactly why the titles get confused in job postings.
A decision table for your first hire
| Your situation | Hire this | Why |
|---|---|---|
| Adding an AI feature (chat, summarization, extraction) to an existing product | AI engineer | The model already exists; the work is integration, prompting, retrieval and evals |
| Building a proprietary model on your own data (fraud, forecasting, recommendations) | ML engineer | You need training pipelines, feature stores and deployment, not prompt orchestration |
| You don't know yet whether your data supports any AI use case | Data scientist (often fractional) | The question is exploratory; committing to a build is premature |
| Scaling an AI feature that already works to more use cases company-wide | AI engineer, then a platform-minded senior AI engineer | You need reusable infrastructure, not a new model per use case |
| Regulated, high-stakes predictions (credit, medical, safety) | ML engineer with a data scientist partner | You need rigor on model validation that pure product engineering skips |
Read the last project, not the title
Because the taxonomy is fuzzy in the market, the title on a resume tells you less than the last two projects a candidate actually shipped. Someone titled 'data scientist' who spent the last year building a RAG pipeline and tuning prompts is functionally an AI engineer now, and someone titled 'AI engineer' who has never touched an eval or a retrieval pipeline may really be a backend engineer who added an API call to GPT.
- Ask what they shipped, when it shipped, and what happened to its accuracy or cost after launch.
- Ask whether they trained a model or called one. Both are valid, but they are different jobs.
- Ask how they know their AI feature is working today, not just at launch.
- Weight recent, shipped work over certificates, courses or Kaggle competitions.
When you need more than one, and when you don't
Past a certain point, roles specialize because generalists can't hold both a training pipeline and a product roadmap in their head at once. But most companies reach for a three-person hybrid team long before they need one. If you're shipping your first one or two AI features, one strong AI engineer, ideally someone who has done this before at another company, will outperform a committee of specialists arguing about ownership.
- Under 3 AI use cases in production: one AI engineer is almost always enough.
- 3-8 use cases, some proprietary models: add an ML engineer once training and retraining become a weekly cost, not a one-time project.
- 8+ use cases across teams: you now have a platform problem, see our piece on feature vs. platform hires below.
- Data science stays a fractional or fixed-term engagement unless you have a genuinely recurring stream of open-ended analytical questions.
