Why the boundaries are moving
As long as building an intelligent system meant training a model, the split was legible: Data Engineers fed the pipelines, Data Scientists modelled, ML Engineers industrialised. General-purpose models available behind an interface moved part of the value towards assembly: designing around the model, evaluating it in a business context, running it at an acceptable cost.
The result is not the disappearance of the older roles but a wider overlap. Depending on the company, the same title can describe a job very close to the data or very close to the product. That is why reading the actual scope matters more than reading the title.
The three scopes as they are taking shape
AI Engineer
Centre of gravity: the application. Designing a system that uses one or more models to solve a business problem, evaluating it, shipping it and keeping it running. The work is about assembly — retrieval, tools, orchestration, guardrails — more than training. The dominant questions are user-perceived quality, latency, cost per request and failure behaviour.
ML Engineer
Centre of gravity: the model inside a system. Training or adaptation, experiment tracking, versioning, performance, drift over time. The role assumes a deeper statistical understanding and a closer relationship to training data. Where the AI Engineer picks an existing model, the ML Engineer is usually the one deciding whether to build one, and at what maintenance price.
AI-oriented Data Engineer
Centre of gravity: availability and quality of the data. Pipelines, data contracts, freshness, governance, lineage, storage and processing cost. It is the most stable of the three roles and often the most decisive: an AI system never durably exceeds the quality of the data feeding it.
Where the roles genuinely overlap
Overlaps are not anomalies: they are the places where teams expect shared competence, and therefore where interview questions tend to land.
- Evaluation: expected from all three, from a different angle — perceived quality, model performance, input data quality.
- Production and monitoring: shared between AI Engineer and ML Engineer, sometimes owned by a separate MLOps function.
- Retrieval and indexing: split between AI Engineer and Data Engineer, depending on who owns the corpus.
- Cost: model size and caching trade-offs on the AI side, processing and storage cost on the data side.
- Tool and agent orchestration: usually the AI Engineer's, though exposing internal systems belongs to data and architecture.
Reading a job ad to find the real scope
The title is the least reliable signal. These questions, asked of the ad and then in the interview, frame the role far more safely.
- 1
Who owns the data?
Question 1If the hiring team does not own its data, a significant part of the job will be negotiating access and making sources reliable. Real work, rarely described in the ad.
- 2
Is a system already live?
Question 2Running an existing system and starting from scratch are different jobs. The first rewards monitoring, reliability and regression handling; the second, framing and prototyping.
- 3
Are models trained here?
Question 3This is the main separator between AI Engineer and ML Engineer profiles. An ad mentioning training with no identified dataset deserves a follow-up question.
- 4
How is quality measured today?
Question 4A team that answers precisely is running a system. A team with no answer is still exploring, whatever the job title says.
- 5
Who sets the roadmap?
Question 5This tells you whether the role sits close to the product or strictly in technical execution — which changes the work far more than the title.
Choosing a direction without spreading thin
Faced with blurred boundaries, the temptation is to claim everything. It is the most common positioning mistake: a profile claiming all three scopes is hard to place, and therefore hard to shortlist.
Diluted positioning
“I do data engineering, machine learning, generative AI, MLOps and a bit of product. I adapt to whatever the team needs.”
Legible positioning
“My centre of gravity is shipping applications built on models: evaluation, reliability, cost. I can work with data pipelines because I have had to clean up corpora, but I am not the right person to design a data platform.”
The second version says both what you are and what you are not. It is the second half that makes a profile credible.
A legible trajectory is built around an owned centre of gravity plus one or two adjacent skills you have genuinely practised. The most natural moves today: from Data Engineer towards AI Engineering through retrieval and corpus quality; from Data Scientist towards AI Engineering through evaluation; from AI Engineer towards architecture through system design and cost trade-offs.
This analysis is deliberately qualitative. We publish no salaries, day rates or hiring volumes until we have verifiable sources or robust anonymised aggregates from engagements posted on Talent AI.
Placing a role before applying
Five checks that describe the real scope better than the title.
- I know who owns the data in the hiring team.
- I know whether a system is already live or everything is still to build.
- I know whether the role involves training or adapting models.
- I know how quality is measured today, and by whom.
- I can name my centre of gravity and what I do not claim.
Key takeaways
- The three roles differ by centre of gravity: application, model, data.
- Overlaps are expected: evaluation, production, indexing, cost.
- The title is the weakest signal; scope is read through data, production and quality measurement.
- A credible positioning also says what you do not cover.
- No market figures are quoted here, for lack of a verifiable source.
- AI Engineering
- MLOps
- AI agents