AI consultant: one title covering four different jobs
AI consultant is the least informative title in this field, and the reason is historical rather than sloppy. Strategy houses, systems integrators, software vendors and independent practitioners all adopted it at roughly the same moment, each attaching it to what they already sold. Nobody was wrong and no shared meaning ever settled. So the same words now cover four genuinely different jobs: deciding where AI is worth applying and in what order, choosing between vendors and building the business case, designing and running the delivery, and changing how an organisation operates once the technology is in. Some of these write code every day. Some never touch a keyboard. Before taking one of these roles, or hiring into one, the question worth asking is not what the title means. It is what this person produces, and whether they are still there when it does or does not work.
AI consultant, in short
Contested title| In one sentence | Advises an organisation on where AI is worth applying and in what order, usually without building it. |
|---|---|
| Judged on | Whether the advice survived contact with the organisation, which is rarely measured and should be. |
| Fails when | The recommendation is correct and nobody can execute it, because the constraint was never technical. |
| Most confused with | AI implementation consultant, which is the same word attached to a different half of the job. |
The title is used for several different jobs, or is being absorbed into neighbouring ones. No compensation figures: see methodology.
The four jobs under one heading
Opportunity work. Looking across an organisation and deciding where AI would pay, in what order, and where it would not. Largely analytical, produces a prioritised list and a business case, and it ends before anything is built. Done well, it removes more from the plan than it adds, which is its main value and the hardest part to sell.
Selection work. Choosing between build and buy, and between vendors. This is where independence matters most and is least common: a great deal of selection advice is given by firms with partner agreements on one side of the choice. Ask about that before taking the advice, and before taking the job.
Delivery work. Running the project that puts something in. This is the variant that overlaps with implementation consulting and with deployment engineering, and it is the one where the consultant is still present when the thing either works or does not.
Operating-model work. Changing who does what, and how they are measured, now that part of the process is automated. The least technical and frequently the most consequential, because a deployed system in an unchanged organisation produces very little.
The question that sorts a role in one conversation
Ask what the engagement produces and when it ends. Not what the role covers, which invites a list; what the final deliverable is, and what happens the week after.
If the answer is a document and the engagement ends there, it is advisory work. That is a real profession with real skill in it, and the thing to know going in is that you will rarely find out whether you were right.
If the answer is a running system, it is delivery work, and the skills required are much closer to engineering than the title suggests. If the answer is that the engagement ends when a team is operating differently, it is change work, and the constraint will be political rather than technical.
Hesitation in the answer is itself informative. Roles that cannot describe their own deliverable are usually roles whose scope is set by whatever the client asks for next.
The structural weakness of the title
Advisory work is paid for the recommendation, not the outcome. This is not a moral failing and it is a real incentive problem: a consultancy's next engagement is worth more than a client who no longer needs one, and nothing in the standard arrangement corrects for that.
The visible symptom is recommendations that are correct and unexecutable. A plan that assumes data access the organisation cannot grant, a target operating model no existing team has the authority to reach, a sequencing that requires two departments to agree about something they have disagreed about for five years. Each of these is defensible on paper and produces nothing.
The practitioners who avoid this do one thing consistently: they find out what the organisation can actually do before recommending what it should do. That means talking to the people who would have to execute, early, rather than to the sponsor who commissioned the work. It makes the recommendation smaller and much more likely to happen.
If you are moving into it from engineering
The transferable part is larger than it looks: knowing what is genuinely hard to build is the scarcest thing in advisory work, and it is precisely what an engineer has and most consultants do not.
The risk is specific and worth naming. Advisory work that never ships erodes technical credibility, and the erosion is invisible for about two years, after which returning to engineering becomes hard. If you make this move, keep building something, and prefer roles that stay through delivery over roles that end at the recommendation.
The alternative worth considering is forward deployed engineering, which is the same customer exposure with the build attached, and where the difference in who pays changes the incentive in your favour rather than against it.
