// in this post
I stumbled on two fascinating studies this week that highlight a striking paradox: AI upskilling is needed more than ever, yet consultants like me are the least trusted to actually deliver it.
First, UK hiring has dropped all year, job postings are down 11% since January, and graduate vacancies are at their lowest level for this time of year since 2020. Yet demand for AI skills just hit a record high, with AI tools appearing in 9.4% of UK job adverts. The message is clear: companies have less money for headcount, creating an urgent signal that existing teams need to adapt fast.
Second, there is a massive trust gap. A Source Global Research survey of nearly 3,900 companies found that 70% would not trust a report prepared using AI, and nearly a third said AI use would actively undermine their confidence in the firm. The catch? More than three-quarters of UK consulting firms are already using AI on client work.
So everyone needs to learn this tech, but the people selling the guidance are facing deep scepticism. As one of those people, that paradox is not lost on me, and honestly, having seen some of the guidance being offered I can see why.
The case for upskilling isn't broken
Sitting with that scepticism doesn't mean writing off the work entirely. This isn't a case against training everybody.
I'm a big fan of champion networks, I have watched them work. A baseline level of AI literacy across an entire workforce is invaluable, and not just as a box-checking exercise for an audit. It shifts peer expectations, redefines what is normal, and determines whether an employee trying something new gets encouragement or a raised eyebrow. That is culture and education, not compliance, and it is the part that lasts. If a business wants to invest in its people, building AI literacy delivers more immediate value right now than almost anything else.
None of that has changed for me. What has changed is my personal approach, and why.
Where AI training comes apart
Champion networks work because they ground AI in purpose. What destroys trust, and turns both employees and senior execs into cynics, is dropping software into people's laps and calling it transformation.
Broad enablement requires a complete ecosystem: sponsorship, clear use-cases, protected time for champions, supportive managers, and a meaningful outcome. Most organisations simply buy the licences and a one-day training webinar, the cheapest items on the list, and stop there.
That shortcut is actively creating sceptics at the top. A Source Global Research study found that clients who had actually used consultants' AI tools were more negative than those who hadn't: 77% think AI is a bubble about to burst, against 55% of those without that exposure.
That should alarm anyone planning a rollout. Standard adoption playbooks assume familiarity breeds confidence and resistance is just a training deficit. In reality, when you hand someone a licence and a sandbox with no specific job to do, they poke around for two weeks, hit a hallucination or a flawed output, and conclude the tech is overhyped.
You haven't built organisational capability. You have funded a group of key stakeholders to form a settled, negative opinion you will spend the next two years fighting.
How my own approach shifted
That realisation changed my own practice. My approach is now far narrower and more surgical. Instead of starting with the whole workforce, I work with specific teams to pinpoint where AI directly supports work they are already doing. We build targeted projects around those real workflows, always with a clear, named owner. If the business doesn't have someone ready to own the project yet, I step into that seat until they do.
We tackle these two or three at a time. Here are three examples from my recent work inside one manufacturing group:
Project one: automated design renders
The problem. Sales needs visual mockups to win work. Every request goes to the design team, who spend hours building renders by hand, so requests queue and customers wait days for something they treat as a formality. The design team's skilled time is consumed by the most repetitive work they do.
What I do on it. A vendor built the pipeline. I'm the technical owner of it, which means I watch the dashboard, re-run failed jobs and update credentials when a third party changes its API. The vendor offered a monthly maintenance retainer for that work and their own documentation concedes it takes a few hours a month. The work isn't difficult. The retainer exists because most clients have nobody whose job it is. I also capture the workflow it changes and write it up as procedures the design and sales teams can follow, so the knowledge stays in the building when the vendor's contract ends.
Project two: outbound lead generation
The problem. The sales team was chasing prospects who were never a fit, working from generic campaigns that produced curiosity rather than buyers. The previous agency billed a monthly retainer regardless of results and reported against metrics nobody could interrogate.
What I do on it. The agreement guarantees a number of qualified appointments and leaves the question of whether an appointment was genuinely qualified to the supplier's own judgement, with their decision final. That clause is common and there's nothing sinister in it, but it's impossible to argue with after the fact. So before anything launched I wrote a documented definition of what counts as a match for their ideal customer, had it agreed, and made it the standard every campaign is measured against. The discretion stays in the contract with very little left for it to decide. I also deploy the handoff automations, so leads reach the sales team in the tools they already use rather than sitting in a vendor's dashboard.
Project three: the procedures system
The problem. The group has roughly 260 standard operating procedures and no way of knowing who has read any of them, or which are still true. People ring a colleague instead of opening the document, so the documents get used less and maintained less, which makes them less worth opening. Some staff had gone further and deleted their own procedures, because an unreviewed procedure was a finding in an ISO audit and one that didn't exist wasn't.
What I do on it. This is the one I define and build. An owner records themselves doing a task, the system drafts the procedure from the recording, and a named human approves it before anything publishes. Procedures are assigned to the people they apply to, acknowledgement is recorded per person and per version, and managers see who on their team is outstanding. The design brief I work to is deliberately narrow: make non-compliance visible so a manager can act on it. The system doesn't make anyone comply. That remains a management job.
The risks, including the ones in my own approach
AI invents things, and its self-check will not catch it. We trialled the step that drafts a procedure from a recording. It produced clean, well-structured documents containing confident invented detail, steps that read perfectly well and that nobody at the company had ever carried out. When we asked the model to check its own output, it reported itself clean. It had made things up and its own quality check couldn't see it. Approval by a named human is a hard requirement in the design for that reason, and run as a demo rather than a trial it would have produced an impressive document and no discovery at all.
Anything you measure gets gamed. The deleted procedures weren't defiance, they were a rational response to an incentive. The measure produced exactly the behaviour it was designed to produce, and the documentation got worse because somebody decided to track it. So the system reports who is outstanding to that person's line manager, where a named person can act on it, and deliberately doesn't push completion percentages to a leadership dashboard, because the only thing anyone can do with a percentage is ask why it isn't higher.
Internal ownership creates key-person risk, and mine is the name on it. If I go and nothing is written down, the business has systems nobody understands and no support contract to fall back on. That's a real exposure and pretending otherwise would be dishonest. Two things reduce it. Everything I operate, I document as an operating procedure while I'm doing it, which is the same discipline the third project exists to enforce. And the procedures system is built so that owners create their own content, because if it depends on me to keep growing, it stops the day I leave.
So why doesn't anyone trust us
The contradiction at the top of this deserves an answer.
The easy explanation is that clients can tell. The people most negative in that survey were the ones who had used consultants' AI tools, which means they know what generated work looks like because they have been handed some.
The duller explanation is better. A client hiring a consultancy is buying judgement. If AI produced the deliverable, they have paid for judgement and received output, and they cannot tell which parts had a person behind them. What they object to is not knowing.
Which is a solvable problem, and solving it is most of why I work the way I do now. A project a team can see being built, that they end up owning and running themselves, does not have that problem. There is nothing to take on faith. They watched it happen.
Why build this internally instead of buying another platform
There is a SaaS product for every one of these problems. Buying one is faster and the invoice is easier to approve. I still think it's the wrong call for work that is specific to how your business runs, for four reasons.
A platform encodes the generic version of your problem. This group already had a register listing 120 procedures the business ought to have. It was written from what a company like theirs might plausibly need rather than from what they actually do, and it was never used. That's precisely what a SaaS product is: a well-built answer to the average version of your question. It fits the businesses closest to the average and quietly misfits everyone else.
You end up watching four screens. Two new systems already meant leadership checking data in three places. Adding a platform to solve that makes it four. The reporting for these projects sits in the SharePoint the group already pays for, because the useful thing is one place to look, not another good tool.
The subscription never ends and the build does. A retainer or licence is a permanent line in the budget priced at your dependency, not at the difficulty of the work. A build has a finish, after which the running cost is infrastructure and a few hours a month of somebody's attention.
What you keep at the end is different. When a SaaS contract ends you have an export file and a migration project. When you've built on tools you already own and documented the process while you did it, you keep people who understand how the work happens. That is the capability you were trying to buy in the first place, and no licence has ever delivered it.
I spent the last ten years working in HR, and in that time I watched the cost of procurement rise sharply. For smaller organisations that means being frozen out of the tech that would drive revenue, save on cost, or make a process work properly. This is where AI can make itself useful, not by writing dodgy LinkedIn posts, but by supporting projects that become bespoke solutions, built around how one business actually works, that make the job easier or better in some way. For me, that's how we build trust in AI capability.
FAQ
Should we train everyone in the company on AI?
Yes. A base level of understanding across a whole workforce is worth having, and not only for compliance. It changes what people expect of each other and whether someone trying something new gets encouragement or a raised eyebrow. Champion networks work too. The caution is that broad enablement is a large programme with a lot of moving parts, and access on its own, with no specific job attached to it, tends to produce sceptics rather than capability.
Why don't clients trust AI consultants?
Because a client hiring a consultancy is buying judgement, and if AI produced the deliverable they have paid for judgement and received output, with no way of telling which parts had a person behind them. Source Global Research found seventy per cent of clients wouldn't trust a report prepared using AI, and the people most negative were those who had used consultants' AI tools, because they know what generated work looks like.
What is a more targeted approach to AI adoption?
Work with specific teams to find where AI genuinely supports the work they already do, then build a project around that, with a named person owning it. Ownership means someone who runs the system day to day, documents the workflow it changes, builds reporting on tools you already have, and defines what a good outcome looks like before a vendor contract defines it for you.
Should we build AI systems internally or buy a SaaS platform?
Buy the platform when the problem is genuinely generic, like email or accounting. Build internally when the process is specific to how your business actually runs. A SaaS product encodes what a company like yours might plausibly need, which is not the same as what you do. The deciding question is what you still have when the contract ends: an export file, or people who understand the process.
Can AI check its own work?
Not reliably. On one project an AI-generated procedure contained confident invented detail, and when the model was asked to check its own output it reported itself clean. Human approval by someone who actually does the job belongs in the design as a hard requirement, not as a step you automate away later.
What are the risks of owning AI systems internally?
Key-person dependency is the main one. If the person who runs it leaves and nothing is written down, you have an orphaned system and no support contract. The mitigations are documenting the operating procedure as you build, and building on platforms that have their own vendor support underneath, so the thing you own is the configuration rather than the whole stack.