The real problem is not a lack of skills
A large share of professionals who hesitate to mention AI on their CV have in fact done something real: identified a use case, tested a tool on their own domain's data, written acceptance criteria, run a pilot, or explained to a team why a generated answer should not be sent as is. That work exists. It is simply described in a way that makes it invisible.
So this guide is not about projecting expertise. It is the opposite: making a real contribution visible and verifiable, phrased with the precision you would use for any other part of your job.
A recruiter or technical manager is not checking whether you know the vocabulary. They want to know what you did, under which conditions, and what remains true once the enthusiasm is removed.
Seven levels of experience worth separating
"AI skills" covers wildly uneven realities. Separating them lets you place yourself honestly — avoiding both undersell and overclaim.
- Having used a conversational assistant: individual usage, with no demonstrable organisational effect. A starting point, not a claim on its own.
- Having automated a task or a chain of tasks: a concrete outcome exists, but its scale and robustness determine what you can say about it.
- Having framed a use case: problem, users, scope, data, risks, criteria. A transferable professional skill, and a scarce one.
- Having contributed to a product with an AI component: specification, trade-offs, follow-up, participation in product decisions.
- Having defined or tested evaluation criteria: case set, what counts as a good answer, thresholds, output review. Often the most sought-after and least claimed contribution.
- Having taken part in adoption or governance: usage rules, training, compliance framing, monitoring of real usage.
- Having worked with a Data or AI Engineering team: regular collaboration, shared language, shared decisions, without stepping into the engineers' role.
These levels are not a linear value scale: framing a difficult use case is often worth more, in a product or consulting role, than having stitched together an automation. What they mainly provide is precision. Saying which one you actually occupy is already a signal of seriousness.
From a weak statement to a demonstrable one
The method holds six elements. A good statement does not always carry all of them, but a weak statement usually carries none.
- 1
The context
Where, with whom, under which constraints. "In a fifteen-person legal department, on unstructured contract documents" immediately establishes the difficulty.
- 2
The problem
What did not work before, expressed from the angle of real work: time lost, decisions delayed, information nobody could find, repetitive low-value tasks.
- 3
Your personal responsibility
What you did, as distinct from what the team did. This is the most commonly blurred point, and the one interviewers systematically dig into.
- 4
The approach
How you went about it: framing, collecting real cases, defining criteria, testing, piloting, supporting adoption. Describe the method, not the technology.
- 5
The outcome
What changed, observably. A modest verifiable result beats an impressive percentage you cannot justify.
- 6
The limits
What the solution did not cover, what was dropped, what remains open. This is what separates someone who actually worked on the subject from someone who read about it.
If you have no reliable figure, do not invent one. "Preparation time dropped noticeably, though we never measured it formally" is an acceptable sentence, and nobody can use it against you.
Three before / after examples
The "before" lines below are deliberately typical: they appear verbatim on many CVs. The situations described are teaching scenarios, to be adapted to your own experience.
Product / Product Owner
Before
"Led an AI project. Daily use of ChatGPT and AI tools."
After
"On a drafting-assistance feature for a thirty-person support team, I framed the scope with the engineering team: three request types handled, permitted sources, expected behaviour under doubt (offer an empty template rather than an uncertain answer) and a ban on any commercial commitment in the suggestion. I built the eighty-case anonymised set used to validate each version. The feature is used daily within that narrow scope; extending it to complex requests was dropped after testing, for lack of reliable sources."
Business Analyst / consultant
Before
"Generative AI expertise. Supported the client's AI transformation."
After
"For a finance department, I assessed four candidate use cases and recommended keeping only one. For each, I documented the data actually available, the access rights, the refresh frequency and the consequence of an error. Two were dropped because the data was not usable as it stood, a third because the expected gain did not justify the control effort. The remaining one was specified with evaluable acceptance criteria, tested on real files with the business teams."
UX / project & transformation
Before
"Designed AI experiences. Raised team awareness of AI tools."
After
"I ran eight interviews with users of an internal assistant to understand why usage collapsed after two weeks. The problem was not answer quality but the absence of any way to check where an answer came from. I designed and tested a source display and a reporting mechanism, then agreed with the product team on what the system should do when it was unsure. I also wrote the usage rules circulated to teams, distinguishing the tasks where human review remained mandatory."
In all three, the "after" version claims no technical skill. Yet it is far harder to write for someone who did not do the work — which is exactly what makes it credible.
Adapting the message to the medium
The substance stays the same; format and level of detail change.
CV
Two to four lines per experience, focused on responsibility and outcome. No "AI skills" section listing tools: a tool list proves nothing and invites questions you will not want to answer. If you insist on a skills line, phrase it as capabilities: "AI use-case framing, evaluation criteria definition, pilot management".
TalentAI profile
There is more room than on a CV: describe the kind of problems you can handle, the context you operate in and the real level of your practice. A profile that plainly says "I do not build; I frame, I test and I drive adoption" is more useful to companies than one that leaves doubt hanging.
Public professional profile
On a public profile, the issue is consistency between headline and content. A headline announcing technical expertise above an experience section describing framing creates an immediate negative impression. An honest headline — your role, with the AI area you work in — reads far better. Avoid copying a fashionable phrasing verbatim too: it ages quickly and makes you interchangeable.
Interview
This is where precision pays. Prepare two situations you can narrate for five minutes with concrete detail: what you discovered along the way, the hard decision, what was abandoned. Also prepare the sentence that bounds your scope: "I did not design the system; I defined what it had to do, on which data, and how we would check that it did". That sentence closes the subject instead of opening it.
Portfolio or practical case
A portfolio is only relevant if you can show something without breaching confidentiality: an anonymised, reconstructed framing document, an evaluation criteria grid, a test protocol, a structured retrospective. It is not mandatory for a non-technical profile, and a poor portfolio hurts more than it helps. A framing exercise handled cleanly during an interview, on the other hand, beats any document.
What is better left unclaimed
Some phrasings produce the opposite of the intended effect. They attract precise technical questions, and the gap shows immediately.
- "AI Engineer" after a few automations: the title commits you to an engineering practice you will have to demonstrate not once, but in every conversation.
- "LLM expert" after regular assistant use: expertise on models means being able to discuss evaluation, cost and limits, not usage.
- "RAG expert" or "agents specialist" without demonstrable experience: these are engineering topics; claiming them without having built or evaluated anything invites a one-question rebuttal.
- Unverifiable technical mastery — tools named without context, technologies listed with no associated deliverable.
- A figure you cannot explain: where it comes from, how it was measured, over what period.
- A collective contribution presented in the first person singular: the most easily detected mistake, and the most costly.
One rule simplifies everything: claim nothing you could not defend for ten minutes in front of someone who does that work daily.
Owning a non-technical positioning
There is a legitimate worry behind the hesitation: that without technical skill, an application carries no weight. In practice, organisations deploying AI systems rarely lack people who can build; they lack people who can say what should be built, for whom, on which data, and under what conditions the result will be acceptable.
Stating that positioning clearly — what you can do, what you do not do, and who you work well with — is more effective than inflating a technical veneer. It is also what lets you join a team without having to hold a role you cannot hold.
Evidence worth gathering
Before rewriting your CV or profile, collect what you could genuinely show or narrate in detail.
- The precise context of at least two situations: organisation, users, main constraint.
- What you personally produced: framing document, case set, criteria, test protocol, adoption plan.
- The decisions you contributed to, and the ones you did not make.
- One or two edge cases you had identified.
- The observable outcome, however modest, and how it was established.
- What did not work, and what you took from it.
- The people you worked with and what they could confirm.
- What you cannot do, stated without embarrassment.
Key points
- The goal is not to look like an expert but to make what you can actually do verifiable.
- "Using an assistant" and "framing a use case" are very different levels; name them separately.
- A solid statement carries context, problem, personal responsibility, approach, outcome and limits.
- Saying what did not work strengthens credibility instead of weakening it.
- Undemonstrable technical titles — AI Engineer, LLM expert, RAG expert — turn against whoever uses them.
- Evidence is gathered before the interview: cases, criteria, documents, decisions, user feedback.
- AI literacy
- AI Product
- Adoption