AI Engineer vs ML Engineer

The starting point is the difference

An ML engineer starts with data and produces a model. An AI engineer starts with a model and produces a system.

That single sentence does most of the sorting, and what is an AI engineer establishes it. Everything below is what follows from it when a real problem lands and somebody has to pick it up.

The roles are not a hierarchy and not a replacement. A team shipping a support assistant on a hosted model may never need an ML engineer. A team whose product is a fraud classifier over their own transaction data needs one and cannot substitute prompt engineering for them.

Sorting real problems to a role

The useful exercise is problems that look like they belong to the other role.

"Our assistant gives wrong answers about our own products." Reads like a model problem. It is a retrieval problem. The model was never going to know your catalogue, and no amount of training would fix a corpus it cannot see. AI engineer.

"The classifier is three points worse this quarter than last." Reads like an application problem, since nothing in the application changed. It is usually a data problem: the input distribution moved and the training set did not. ML engineer.

"Responses are too slow." Either. If the fix is streaming, a smaller model, or sending less context, AI engineer. If the fix is a distilled model or a quantized deployment of your own weights, ML engineer.

"We need this to work in Portuguese." AI engineer first, because the hosted model may already handle it and the answer is an evaluation rather than a project. ML engineer if the answer turns out to be no and you own the model.

"The model leaks customer data between accounts." Neither, in the sense that matters. That is an application boundary problem, covered in RAG with dynamic filters, and treating it as a model question is how it stays unfixed.

The pattern: symptoms present at the surface and causes sit in a layer. Naming the layer names the role.

Where the two roles overlap

Evaluation is the honest overlap, and it is where the two roles talk past each other most often.

An ML engineer evaluates a model: accuracy, precision and recall against a held-out set drawn from the same distribution as training. The question is whether the model generalises.

An AI engineer evaluates a system: does this feature still do what it did last week, across a set of real cases that must keep passing. LLM evaluations and regression testing cover that shape, and it is deliberately not a held-out sample. It is a fixed set, and it stays fixed precisely so that changes to the prompt, the retrieval or the model show up as movement.

Both are called evaluation. One measures a model against a distribution, the other measures a system against a specification. A conversation where one person means each is a conversation where nobody understands why the other's numbers look wrong.

The other real overlap is data quality, arrived at from opposite ends. The ML engineer cares because it is training input. The AI engineer cares because it is retrieval corpus. Same documents, same problems, different reason to fix them.

What goes wrong when a team assumes one covers the other

Both directions fail, and they fail differently.

Assuming an ML engineer covers the application work. You get a team that can tell you the model is performing to specification while the feature is unusable, because the failures are in retrieval, prompt assembly, output handling and latency budget. These are systems problems, and the instinct to reach for training as the lever produces expensive projects that address the wrong layer.

Assuming an AI engineer covers the modelling work. You get prompt changes and retrieval tweaks applied to a problem that is about a model trained on the wrong data. This fails more slowly and looks like progress for longer, because each change produces a small improvement and none of them reach the cause.

The tell for both is a fix that keeps almost working. If three rounds of prompt changes each helped slightly and none solved it, the lever may be in another layer, and pre-trained models covers how to work out which one.

Where the boundary blurs

Titles do not map cleanly onto work. Plenty of people do both, plenty of teams use one title for both, and the boundary moves with team size. A five-person company has one person doing everything and the distinction is about which hat is on. A large organisation may have a whole function on each side.

There is also no claim here about which is harder, better paid, or more senior. The question worth answering is which problems you have, and that is answered by looking at whether your work starts from data or from a model somebody else trained.

Further reading

• What is an AI engineer?: the role itself, worked through a single support feature.
• What AI engineers actually do all day: the daily work, and the prerequisite that carries the weight.
• Pre-trained models: what training produced, and which problems it can reach.
• LLM evaluations: the systems side of the word both roles use.