From data science to applied AI: which skills transfer first

You are not starting from a blank page

A lot of writing on this topic assumes a data scientist must reinvent themselves entirely. That is neither accurate nor useful. The role exists, it continues to exist, and nothing obliges anyone to leave it. This piece is for people who want to move closer to applied AI or GenAI roles and want to know what carries over, what is missing, and which direction to aim for.

The key point is that there is no single transition. "Moving into AI" covers at least three very different directions, which do not require the same learning and do not lead to the same interviews. Choosing the direction before choosing the learning saves several months.

What carries over, and is often underrated

The skills below are not secondary assets: profiles coming from software engineering frequently lack them, and they are hard to pick up on the job.

• Statistical reasoning: knowing that an observed gap may only be a sampling effect, and judging what is worth concluding.
• Experimental culture: forming a hypothesis, defining the measure before looking at the result, telling an effect from a coincidence.
• Data understanding: where data comes from, how it is produced, what is missing, what is biased, and why a column does not mean what its name suggests.
• Metric design: choosing what to measure, seeing what a metric does not say, and spotting cases where optimising it degrades the service.
• Validation: clean test sets, no leakage, comparison against a simple baseline, suspicion towards a result that looks too good.
• Communicating results: explaining uncertainty to someone who has to decide, without hiding it and without turning it into a refusal to conclude.
• Python, depending on the profile: a real foundation for some, thinner for others — notebooks and production code do not call for the same practices.

On GenAI systems this foundation pays off immediately. The central question of those projects — how do we know this system works, and on what evidence? — is an evaluation question. Many teams build demo-convincing systems with nobody able to ask it properly.

Not every data scientist has all of these: profiles vary enormously between analysis, modelling, data engineering and product-adjacent work. The first step is an honest inventory, rather than borrowing the average profile from a job description.

The gaps depend on the direction

What is missing is not the same in each case. Here are three common trajectories, described by what they additionally require, not by supposed prestige.

Towards ML Engineer

The emphasis moves from an analytical result to a running system. What becomes central: writing code meant to be read, tested and maintained by others; exposing a model behind a stable interface; managing versions and dependencies; holding performance and cost constraints; knowing what happens when the service goes down. The difficulty is almost never mathematical, it is software and operational.

Towards AI / GenAI Engineer

The model is often external and most of the work sits around it: building a retrieval chain, deciding what the model receives, constraining outputs, measuring quality through case sets, instrumenting, trading cost against latency. The evaluation reflex transfers directly; what is missing is mostly software engineering and operations, plus a fine understanding of behaviours specific to generative models.

Towards an AI Product or cross-functional role

Here the emphasis moves to framing: which problem deserves solving, what a model-based solution can and cannot guarantee, how to define an acceptable quality level with users, how to trade value against risk and cost, and how to explain a limitation to non-technical people. Communication and metric skills are a major asset; what is missing belongs to product leadership, stakeholder work and deciding under uncertainty.

These three are not ranked. They match different tastes: building durable systems, solving open problems with models, or deciding what should be built.

A four-step method

The goal is to move from "I should learn a lot of things" to a direction and a first piece of evidence.

1. 1

   Inventory what you can already do

   step 1

   Write down what you actually delivered: which problems, which data, which decisions, which results, how much code, how much production exposure. Separate what you did alone from what you did within a team. This inventory is also the raw material for your CV and your interview pitch.

2. 2

   Identify gaps against a direction, not in the abstract

   step 2

   Take several job ads matching the direction and note what recurs. Separate genuine requirements from decorative tool lists. You usually end up with two or three structural gaps, not fifteen.

3. 3

   Choose a direction that matches what you enjoy

   step 3

   System, open problem, or product decision. A useful test: on past projects, which part interested you most, and which did you endure? A transition you can sustain is chosen on that basis rather than on the most visible title of the moment.

4. 4

   Build one piece of evidence you can defend deeply

   step 4

   A real case, ideally inside your current job: an internal search assistant, an evaluation of an existing tool, the industrialisation of a model that lived in a notebook. One case you can describe in detail — problem, constraints, decisions, what failed — beats three standard demo projects.

The shortest path often runs through your current employer

The most solid transition frequently happens without changing company. You already know the data, the users and the constraints, which is exactly what an external candidate lacks. Taking on the evaluation side of an existing GenAI project, or industrialising a model stuck at prototype stage, produces real experience rather than a side project.

That intermediate step has another benefit: it tells you whether the direction suits you before you commit to a job search. Some people discover at that point that they prefer analysis and modelling problems, and that conclusion is a result, not a failure.

Presenting the transition without underselling yourself

Two symmetrical mistakes. The first is presenting yourself as a beginner, erasing valuable experience. The second is claiming production experience you do not have, which surfaces on the second technical question.

The framing that works ties the existing to the target: what you have been doing for years, what you have recently built towards the direction, and what you are currently acquiring. Naming what you still lack, along with how you are closing it, reads as clear-sightedness far more than as weakness.

• Career path
• Evaluation
• AI Engineering