Moving from your current job to an AI-oriented role

The question arrives in many forms depending on the job someone holds today, but it usually hides the same worry: do I have to start over to work on artificial intelligence? In most cases, no. A credible move rarely looks like a full career change. It looks like a shift, where part of the professional foundation stays valid and new depth is added exactly where the target role demands it.

This guide offers a general method that works from several starting points. It is not one specific trajectory, and it is not about jobs that simply gain an AI layer without changing role. It is about the path between an identified professional starting point and a destination precise enough to be credible.

1. Identify your starting point honestly

The starting point decides what is already acquired, and therefore what remains to be built. Two people aiming at the same job title do not face the same work. Placing yourself in a family is useful, not to stay locked in it, but to make the gap measurable.

• Software / engineering: design, integration and shipping are acquired; what is usually missing is the probabilistic behaviour of models and how to evaluate it.
• Data / analytics: rigour on data, measurement and bias is acquired; the gap often sits in software engineering and operations.
• Product / project: framing, trade-offs and user relationships are acquired; the gap sits in technical constraints and in reasoning about uncertainty.
• BA / consulting: process analysis, stakeholders and exceptions are acquired; the gap sits in what an AI solution can and cannot take over.
• UX / design: user research and interaction design are acquired; the gap sits in designing for behaviour that varies from one run to the next.
• Functional roles: domain knowledge is a scarce asset; the gap sits in technical vocabulary and in expressing a need in terms a team can act on.

A starting point is not a handicap to compensate for. It is half of the case you are making: the half nobody will have to verify, because it is already evidenced.

2. Choose a realistic destination

"Working in AI" is not a destination. It names an industry, not a role, and that imprecision shows immediately in an application: it makes it impossible to know which skills to check, what level to expect, and what evidence to ask for. A useful destination names a responsibility.

Some common shifts, to read as examples of phrasing rather than mandatory paths: developer towards AI/GenAI engineering; data scientist towards a practice closer to ML engineering; PO or PM towards a product with an AI component; BA or consultant towards framing and transformation work; UX towards research and design on AI products; a functional role towards the same job enriched, with no change of title.

3. Take stock of what actually transfers

This step is often rushed because it looks obvious. It is not: what transfers is not what you know how to do, it is what you can evidence and what stays useful in the destination. Framing ability, a habit of measurement, domain knowledge, and comfort with production constraints count for more than a list of tools you have encountered.

A move almost always rests on three combined pieces: existing skills that are genuinely evidenced, AI depth proportionate to the role, and one piece of proof that connects the two. One brick alone is not enough — which is usually why an application goes unanswered.

4. Measure the real gap, not the felt one

The perceived gap is usually overstated on concepts and understated on practice. To measure it without inventing yet another scale, reuse the progression described in the dedicated guide on the depth of AI skills — understand, use, build, evaluate, then design and decide when the role requires it — and apply it to your target destination.

1. 1

   Understand

   reading

   Being able to explain what a technique does, what it is for and what it does not solve. Enough to take part in a conversation, not enough to decide.

2. 2

   Use

   practice

   Being able to apply it correctly in a defined context, and to recognise the cases where the output is not reliable.

3. 3

   Build / apply

   building

   Being able to produce something reproducible within the scope of the role, and to justify your choices, including the ones you ruled out.

4. 4

   Evaluate / diagnose

   evaluation

   Being able to say whether a result is good enough, on which population of cases and against which criterion, then trace an observed failure back to its likely cause.

5. 5

   Design, decide, operate

   when the role requires it

   Arbitrating between quality, cost, latency, risk and time, then keeping the system alive over time and correcting its drift. Not every role asks for this.

The exercise is to place, for each skill the destination expects, the level the role requires and the level you can evidence today. The gaps that appear are rarely numerous: two or three, usually, and not all of them are technical.

5. Build a first piece of evidence that fits the destination

Generic advice — "build a chatbot" — produces interchangeable evidence that demonstrates nothing about the responsibility you are targeting. Useful evidence is chosen against the gap identified in the previous step, and it shows a decision, not only a result that runs.

• Towards engineering: a narrow but complete component, with failure cases handled and a stated reason behind each architectural choice.
• Towards product: a framed use case, with acceptance criteria, a quality bar you consider sufficient, and an explicit value hypothesis.
• Towards framing work: an existing process described with its exceptions, dependencies, and the points where automation would be risky.
• Towards UX: a research protocol or a design that deals explicitly with error, uncertainty and handing control back to a human.
• Towards evaluation or adoption: a qualitative measurement protocol applied to a small scope, whose limits you can explain.

A modest piece of work you fully control beats an ambitious demo whose behaviour you cannot explain in an interview.

6. Test the move before changing your title

Changing job title is the last step, not the first. There is almost always intermediate ground, inside the current job, where the target responsibility can be exercised partially and observed by others. That ground produces two rare things: evidence situated in a professional context, and honest information about whether the role suits you.

• An internal project where the AI component already exists and is short of contributors.
• An adjacent responsibility taken deliberately: evaluation, framing, documentation, adoption.
• A scoped prototype, with an explicit boundary and an end date.
• Regular collaboration with a team that builds these systems.
• A contribution to an acceptance protocol or to change management.
• A short engagement or a credible personal project, when the internal context offers no opening.

None of these guarantees a transition. They reduce uncertainty for you and for the organisation, which is already a lot in a hiring or mobility decision.

Seniority: the nuance that avoids two symmetrical mistakes

Changing roles does not mean becoming junior again across all your skills. Ten years of delivery experience do not evaporate because the subject becomes AI, and presenting yourself as a beginner for lack of technical vocabulary hurts as much as the opposite.

But tenure does not automatically transfer the same level of seniority to every responsibility in the new role. You can be senior on framing and trade-offs, and a beginner at assessing a probabilistic system. Naming that asymmetry yourself, rather than letting it be discovered, usually reads as maturity — and it is also what makes a learning path credible.

• Transition
• Career path
• Transferable skills