Data Engineer, Data Scientist, ML Engineer: what GenAI actually changes

Data roles have been redrawn several times in a few years, and GenAI restarts the exercise. Public debate swings between two caricatures: data roles disappearing into a single GenAI Engineer, and the opposite claim that nothing moves because calling an API is not a job.

This analysis takes another angle. It starts from the responsibilities people actually hold, shows where LLM, RAG and agent systems add, shift or change none of them, and leaves readers to locate their own position.

Start with responsibilities, not titles

The same title covers very different scopes depending on company size, platform maturity and team structure. A list of responsibilities, by contrast, can be compared across organisations.

• Collection, transformation, quality and availability of data.
• Experimentation and modelling: hypotheses, protocols, comparison of approaches.
• ML engineering: industrialisation, reproducibility, packaging, testing.
• Serving: exposing the system, latency, scaling.
• Evaluation: defining what a good result is and measuring it defensibly.
• Observability: knowing what happens in production and detecting degradation.
• Application integration: fitting the system into a product and its journeys.
• LLM / RAG / agent systems: orchestration, retrieval, tools, guardrails.

These responsibilities are not distributed the same way everywhere. In a small company one person may hold six of them; in a large group a single one may be split across three teams.

Data Engineer

GenAI adds one family of data to a role that already handled plenty: document corpora. They come with their own difficulties, usually underestimated by those who discover the topic through the model.

• Heterogeneous document sources: formats, versions, duplicates, scanned files.
• Ingestion and parsing: text extraction, structure, tables, attachments.
• Metadata: origin, date, scope, validity status, language.
• Quality: spotting outdated versions, truncated documents, duplicated content.
• Permissions: who may see what — central once a system answers from internal documents.
• Freshness: what must be reindexed, how often, with what acceptable delay.
• Retrieval pipelines: chunking, indexing, incremental updates.
• Data observability: knowing what entered the index and what was excluded.

It would be wrong to conclude that the Data Engineer becomes "the person who prepares data for an LLM". Warehouses, analytics pipelines, data contracts and the reliability of existing flows do not disappear: they remain the base everything else rests on, GenAI use cases included.

Data Scientist

This is the role whose value is most often misread in GenAI projects, because it is associated with training models when most of its skill lies in method.

• Experimentation: comparing two approaches under conditions where comparison means something.
• Hypotheses: stating what you believe and how you would know you were wrong.
• Metrics: choosing what must be measured and what the measure does not say.
• Evaluation: building a representative test set, difficult cases included.
• Error analysis: sorting failures by cause rather than by symptom.
• Test data: building it with domain experts and maintaining it over time.
• Understanding system behaviour: where it is stable and where it is not.

These skills transfer well: a RAG system or an agent is judged exactly like a model, with a protocol, a test set and error analysis. The difference is that the output is text or an action, which makes "a good result" harder to formalise — and makes someone who can do it more valuable, not less.

That does not mean every Data Scientist should become an AI Engineer. Staying on modelling, analysis and decision support is a complete path, and many problems have no reason to be solved with an LLM.

ML Engineer

The ML Engineer works where a system stops being a demo. GenAI barely changes the nature of that scope, but it extends it to new objects.

• Integration into an application and an existing chain.
• Serving, latency, scaling, behaviour under peak load.
• Deployment, versioning, rollback.
• Monitoring and alerting on signals that mean something for this system.
• Reproducibility: being able to redo, explain and retrieve a result.
• Reliability: graceful degradation, error handling, external dependencies.
• Cost: trading off quality, latency and spend per request.
• Infrastructure and production evaluation, distinct from offline evaluation.

The GenAI extensions are concrete: external model calls subject to quotas and behavioural drift, retrieval chains to monitor, agents whose actions must be bounded and traced, hybrid systems where a classical model and an LLM coexist. The underlying skill — keeping a system alive in production — is unchanged.

AI / GenAI Engineer

This is the hardest role to describe, because it has no settled definition. Depending on the organisation, it overlaps existing responsibilities, complements them, or specialises on one object.

• Overlap: in a small team, it is ML engineering work applied to GenAI systems.
• Complement: alongside an existing data team, it takes application integration, orchestration and evaluation of LLM-based systems.
• Specialisation: retrieval, agents, tooling, guardrails, output quality, cost.

Looking for a universal definition of this job is wasted effort. Reading a job ad for the responsibilities it describes is far more informative than trusting the title.

A qualitative comparison of responsibilities

The list below is deliberately hedged: it shows tendencies, not closed boxes. In a given organisation the split may differ without being abnormal.

• Data ingestion and quality — Data Engineer: often central. Data Scientist: frequent collaboration. ML Engineer: depends on context. AI/GenAI Engineer: depends on context.
• Corpus permissions and freshness — Data Engineer: often central. Data Scientist: rare. ML Engineer: frequent collaboration. AI/GenAI Engineer: frequent.
• Experimentation and hypotheses — Data Engineer: rare. Data Scientist: often central. ML Engineer: frequent. AI/GenAI Engineer: frequent.
• Metrics and test sets — Data Engineer: frequent collaboration. Data Scientist: often central. ML Engineer: frequent. AI/GenAI Engineer: frequent.
• Serving, latency, scaling — Data Engineer: depends on context. Data Scientist: rare. ML Engineer: often central. AI/GenAI Engineer: frequent.
• Observability and production evaluation — Data Engineer: frequent collaboration. Data Scientist: frequent collaboration. ML Engineer: often central. AI/GenAI Engineer: frequent.
• LLM, RAG and agent orchestration — Data Engineer: depends on context. Data Scientist: depends on context. ML Engineer: frequent. AI/GenAI Engineer: often central.
• Product integration and user journeys — Data Engineer: rare. Data Scientist: depends on context. ML Engineer: frequent. AI/GenAI Engineer: often central.
• Cost per request and technical trade-offs — Data Engineer: depends on context. Data Scientist: frequent collaboration. ML Engineer: often central. AI/GenAI Engineer: often central.

One person may sit in several columns depending on the project. The point is not to file people away, but to make visible what somebody has to cover.

How to work out where you fit

"Which role should I choose" is the wrong question. A better one is: which responsibilities do I want to hold, and at what depth?

1. 1

   What you enjoy solving

   starting point

   A reliability problem, a measurement problem, a modelling problem and an integration problem do not feel the same. This is the most stable criterion over time.

2. 2

   Software depth

   requirement

   Keeping a system in production demands software: tests, versions, dependencies, incidents. Some people thrive there, others endure it.

3. 3

   Data depth

   requirement

   Understanding where data comes from, what it is worth and what it does not cover stays decisive, GenAI systems included.

4. 4

   Experimentation or production

   trade-off

   Finding what works and making what works hold up are adjacent but distinct jobs, with different rhythms.

5. 5

   Product interaction

   orientation

   Some roles live close to users and product trade-offs; others work upstream, on the platform.

6. 6

   Level of responsibility

   commitment

   Contributing, deciding, operating in production or arbitrating architecture are not the same commitments.

None of these axes designates a best role. They only help you recognise, in a job ad or in your current position, what will suit you over time.

• LLM
• RAG
• AI engineering