AI Engineer vs ML Engineer vs Data Scientist: What Each Actually Does
5 min read · updated August 3, 2026
These three titles are used interchangeably by companies who have not thought about it and precisely by companies who have. Comparing the titles is therefore useless. Comparing what the person does all day is not, and the distinctions turn out to be sharp.
Titles are unreliable; the work is not
The same title means different jobs at two companies on the same street, and the same job carries different titles depending on which decade the organisation’s job architecture was written in. A “data scientist” at one place builds dashboards; at another it is the person who trains the ranking model. This is not sloppiness that will be fixed — job titles are a compensation and organisational artefact, not a description.
What is stable is the work. There are three recognisably different jobs here even where the labels are scrambled, and they differ on one axis more than any other: what you are on the hook for when it goes wrong. Hold that axis and everything else falls out of it.
Three Tuesdays
Composite days, written from the work rather than from anyone in particular. Read them for the texture of the decisions rather than the specific tasks.
The AI engineer
Morning: a support ticket says the assistant cited a document that does not contain the claim. You pull the trace, find that the reranker put a near-duplicate chunk at the top, and spend an hour deciding whether to fix the chunking or add a grounding check after generation. Midday: review a colleague’s PR that adds a fourth tool to an agent, and push back because the tool list is already long enough to hurt selection accuracy. Afternoon: the evaluation suite went red on a provider-side model update you did not ask for, so you pin a version and write the incident note. End of day: a product manager asks whether a feature is possible; you say yes but it needs a human review step, and explain why.
The through-line: you are integrating models you did not train into a system that has to behave, and almost every decision is about failure modes and cost rather than about modelling. Nothing in that day required knowing how a transformer works; all of it required knowing what the system does when a component is wrong rather than down.
The ML engineer
Morning: the recommendation model’s offline metric improved but the online one did not, so you go looking for training-serving skew and find a feature computed differently in the batch job than in the serving path. Midday: a training run has been sitting in a queue for six hours; you shrink the batch size to fit different hardware and restart it. Afternoon: work on the feature pipeline so a new signal becomes available with the right time semantics — no leakage from the future. End of day: review the model card and the rollback plan before the canary.
The through-line: you own a model in production, including how it is trained, what it is trained on, and what happens when the data moves under it. The infrastructure is a large fraction of the job.
The data scientist
Morning: a stakeholder claims a feature increased retention; you check and find the change coincided with a pricing change, so the two are confounded and the claim cannot be supported by that data. Midday: design the experiment that could support it — units, metric, minimum detectable effect, duration. Afternoon: an analysis of why a segment of users churns, which ends in a chart and three sentences that change someone’s roadmap. End of day: push back on a proposed metric because it is gameable in an obvious way.
The through-line: you are producing decisions, not systems. The deliverable is usually an argument supported by evidence, and the hardest part is inference from imperfect data rather than engineering.
What each one is on the hook for
| Role | Description |
|---|---|
| AI engineer | A running service that calls models. On the hook for its latency, its cost per request, its failure rate against a defined evaluation, and its behaviour when a provider misbehaves. Produces: prompts under version control, schemas, retrieval pipelines, evaluation harnesses, fallback and retry logic, traces. |
| ML engineer | A model in production, end to end. On the hook for the training pipeline being reproducible, the features being the same online and offline, and the model not degrading silently as the data shifts. Produces: training pipelines, feature definitions, serving code, model cards, retraining schedules, rollback plans. |
| Data scientist | A conclusion somebody will act on. On the hook for the conclusion being supportable — the right comparison, the right units, an honest account of what the data cannot tell you. Produces: experiment designs, analyses, metric definitions, forecasts, and the occasional model that is an input to a decision rather than a service. |
| Research engineer / scientist | Included because adverts confuse it with the others. On the hook for a result that is new, not for a system that is up. Produces: experiments, ablations, papers, and models that somebody else productionises. Different literature, different day, different hiring bar. |
The AI engineer row is the newest of the four and the one whose contents are still moving, which is why it is worth describing by its responsibilities rather than by a tool list. Every item in it existed before the title did; what is new is that one person owns all of them for a system built on a model they did not train.
Where they blur, and where they collide
- Evaluation is shared and defined differently. A data scientist’s instinct is a statistically defensible comparison; an AI engineer’s is a regression gate that runs in CI. Both are right, and teams that have only one of them either ship unmeasured changes or measure everything and ship nothing.
- Fine-tuning sits on the boundary. The question of whether to fine-tune at all is usually an AI engineering decision; doing it well, with a dataset that is not accidentally leaking your evaluation set, is ML engineering.
- Retrieval quality is where the collision happens. It looks like an engineering problem and is measured like a search relevance problem, which is a data science skill. Teams that treat it as pure engineering plateau at “the demo works”.
- Nobody owns cost by default. Unit economics falls between all three roles and lands on whoever notices, which is a reason to name an owner explicitly.
Reading an advert for the work underneath
Ignore the title in the header and read the responsibilities for four things. The answers tell you which of the Tuesdays above you would be having.
- Does the role train anything? If the pipeline, the dataset and the retraining cadence are mentioned, it is ML engineering however it is titled. If the only models are ones the company calls over an API, it is AI engineering.
- Is there a service with an on-call rotation? Being paged is the sharpest single indicator of which side of the engineering line the job sits on.
- Who consumes the output — a system or a human? A deliverable that is a deck or a document is analysis work, whatever the tooling.
- What is the interview loop? Ask. A loop with a take-home analysis is hiring for judgement about data; one with a system design round is hiring for systems. The loop is the most honest description of the job any company produces, because it is the one they designed with the actual work in mind.
One last thing worth saying plainly, because the comparison invites the question and the honest answer is not satisfying: there is no ranking here. These are three different jobs that suit different people, and none of them is the senior version of another. Choose by which Tuesday you would rather have.