A freelancer who introduces themselves as an "AI expert" is asking the other person to do work they will not do: guess which problem to hand over. A readable positioning puts that effort where it belongs — on the person who knows the subject — and leaves the client with a simple decision.
This guide is about positioning: making expertise understandable and addressable. It does not cover pricing, legal status or tax, which depend on country, regime and personal situation, and deserve qualified advice rather than a general rule.
A positioning answers a problem, not a technology
A skill describes what you can do. A positioning describes what you solve, for whom, and under which conditions. The difference is not cosmetic: it decides whether someone can spontaneously associate you with a situation they are facing.
A list of skills
"AI freelancer: LLM, RAG, agents, Python, evaluation, cloud." Nothing tells a reader when to call you rather than someone else.
A named problem
"I help product teams move a promising LLM prototype into a feature whose quality is measured and sustainable in production." The reader immediately knows whether this concerns them.
The second statement does not narrow the range of possible engagements. It only makes the first contact possible.
The same shift applies to other families of profiles, and it does not take the same form depending on what you sell.
A technical stack
"Data Scientist / ML / MLOps / Python / Cloud." The statement describes tooling, not a responsibility: nothing says at which point of a project you come in.
A problem and a scope
"I work on models already in service whose results are degrading: rebuilding monitoring, validation sets and retraining rules, until the team can hold them without me."
The second statement names almost no technology. It names a precise moment in a system's life, which is enough to know when to call you.
A consulting title
"AI Consultant / Product / GenAI / Transformation." Four words that can mean an awareness workshop just as easily as an eighteen-month programme.
A context and a deliverable
"I work with business units that have several AI ideas and no way to choose between them: framing the cases, checking feasibility with the data teams, and a test plan they keep ownership of. I do not take responsibility for the technical build."
Here it is the stated limit that makes the offer credible: it says what is covered and what is not.
Building a positioning in five decisions
- 1
The recurring problem
1Which difficulty have you already solved several times, including in-house? Repetition is the best indicator of what you can genuinely hold.
- 2
The type of client
2A scale-up product team, an IT department, a consultancy, a large group's data team: context entirely changes expectations, pace and vocabulary.
- 3
The moment of intervention
3Upfront framing, exploration, industrialisation, repairing an existing system. Many excellent freelancers lose engagements because they arrive at the wrong phase.
- 4
The scope you own
4What you take on, and above all what you do not. An explicit scope protects the engagement as much as the relationship.
- 5
The evidence
5What makes the claim checkable: a case described with its constraint, a defended decision, an observable outcome. One solid piece of evidence is enough.
Specialising without closing doors
The fear is constant: "if I position myself, I lose the other engagements." A precise positioning does not narrow what you are allowed to accept: it makes the offer easier to understand for the person in front of you, and therefore easier to describe to someone else. Specialising forces you neither to stick to a single technology nor to turn down an adjacent topic when the problem falls under the same skill.
Useful specialisation does not have to be about technology either. It can be about a sector and its constraints, a project phase, a type of organisation, or a combination. Expertise in the documentary constraints of a regulated sector is a stronger position than one more framework.
Phrasing the offer
The statement holds three elements: for whom, which problem, with what outcome. What follows are shapes, not promised results — the outcome you state must match what you have already done.
- For product teams with a prototype and no quality criterion yet: setting up an evaluation protocol and the go-live decisions.
- For IT departments opening an internal document corpus: framing retrieval, access rights and data freshness.
- For non-technical business teams: turning a need into instructed use cases, including the conditions for dropping them.
- For data teams moving from model to service: structuring the lifecycle, monitoring and recovery paths.
- For organisations in exploration: instructing several options and giving an argued recommendation, including a negative one.
An offer that never lets someone conclude "this is not for me" is not an offer. A positioning is recognised by what it rules out.
What makes a positioning credible
Credibility does not come from the number of technologies listed, but from the precision of the account. An experienced client looks for three things: that you have met the difficulty before, that you can say what was hard, and that you can name the limits of what you claim.
- Describe an engagement with its real constraint, not only its outcome.
- Name an approach you ruled out, and why.
- Separate your contribution from the team's, without minimising or appropriating.
- Acknowledge a domain you do not cover, and know where to point instead.
- Avoid any numeric claim you could not document.
A positioning gets revised
The initial positioning is almost always too broad, because it is built before there are enough engagements to observe a pattern. After a few of them, one emerges: the type of problem you are actually called back for. That pattern, not the original intention, should become the statement.
Revising does not mean changing discipline; it means tightening. Freelancers often move from "AI projects" to "making existing AI features reliable" without changing a single skill — only the way they name what they already do.
Test how readable your offer is
Run this before publishing a profile or replying to a first introduction.
- I can say in one sentence which problem I solve and for whom.
- An outside reader could decide in ten seconds whether I am relevant to them.
- I have at least one piece of evidence described with its constraint and decision.
- I state what I do not take on.
- My positioning is recognisable independently of the technologies listed.
- I can name an approach I ruled out and the reason.
- None of my numeric claims is undocumentable.
Key points
- A positioning names a problem solved, not a list of technologies.
- Five decisions build it: problem, client, moment, scope, evidence.
- A readable specialisation makes third-party recommendation possible.
- The axis can be sectoral or methodological, not only technical.
- An offer that rules nobody out is not an offer.
- Positioning is revised after a few engagements, by tightening the statement.
- Freelance
- Positioning
- Offer