Sixty-six percent of professional services firms say they lack adequate AI skills internally. That's a Deloitte finding from this year, and when I first read it, my reaction was: yes, obviously - but what skills are we actually talking about?
Because when most managing partners or operations directors hear "AI skills gap," their brain immediately jumps to data scientists. Machine learning engineers. People with PhDs in computational linguistics who cost £150k a year and need a GPU cluster to be happy. So the internal conversation goes something like: We'd need to hire AI specialists to do this properly. We don't have the internal capability, and we can't afford to build it. Everyone nods, agrees it's a problem for next year, and moves on.
That reaction is understandable. It's also based on a capability model that doesn't apply to you.
The AI skills that matter for a mid-market professional services firm - a 200-person consultancy, a law firm with 80 partners, an accountancy practice with six offices - are not the same skills that matter for a company building AI products. The capability you actually need is much closer to what your existing fee earners and operations staff already have. And you can start developing it this week, not next financial year.
I've started using a simple four-level model when I talk to firms about AI capability. It's not original - bits of it exist in various frameworks - but I've found it useful because it maps capability to role in a way that makes the investment conversation more honest.
Level one: AI literacy. This is everyone. Understanding what AI tools do, what they don't do, how to recognise when output is unreliable, and what oversight responsibilities apply. If you're deploying any AI tool to staff who'll use it in client-facing work, this is the minimum. Not optional, not nice-to-have - it's the foundation everything else rests on.
Level two: prompt engineering. This is many people - your fee earners, your BD team, your operations staff who interact with natural language AI tools. The practical skill of directing AI to produce useful outputs. I slightly hate the term "prompt engineering" because it makes it sound more technical than it is. It's learnable by anyone who can write a clear email. Structured practice makes a real difference, and most people improve noticeably within two or three weeks of regular use.
Level three: tool configuration. This is some people - maybe two or three in the firm. Setting up, customising, and maintaining AI tools within their designed parameters. This is closer to advanced IT administration than to data science. If you've got someone who's comfortable configuring your CRM or building automations in your project management tool, they can probably do this with the right training.
Level four: custom development. This is few people, or - more often - it's outsourced. Building bespoke AI applications, fine-tuning models, creating custom integrations. This is the layer where the data scientists live. And for most mid-market professional services firms, it's the layer you'll access through an implementation partner rather than building internally.
Here's the thing that changes the conversation: most AI value in professional services is unlocked at levels one and two. Literacy and prompting. No new hires required. The Deloitte research backs this up - when they dug into which skills were actually missing, AI literacy and responsible use ranked as higher-priority gaps than technical implementation skills.
So when someone in your leadership team says "we can't do AI without specialists," what they're really saying is "we can't do level four without specialists." Which is true. But level four isn't where you start, and it's not where most of the early value comes from.
I sat with the COO of a 150-person consulting firm a few months back. She'd been quoted £45,000 by a training company for a two-day AI skills programme. Two days. For everyone. With a "certification" at the end. I asked her what she thought would actually change after those two days. She paused for a while - long enough that I thought I'd offended her - then said: "Honestly? Probably not much. But at least we'd have done something." Then she laughed, which I think meant she already knew it was a bad idea and just needed someone to say it out loud.
That's the trap. The impulse to formalise AI learning into a classroom event feels responsible, but the evidence consistently shows it's not how professional services staff develop usable AI capability. They develop it by doing things - trying, failing, adjusting, and sharing what they've learned with colleagues.
Three approaches that work far better than a training day:
First, nominate an AI champion in each team. Not a new role - just someone who's given slightly more tool access and slightly more time to experiment than their peers. Their job is to try things, figure out what's useful, and share it informally. In one firm we worked with, the champion in the tax team discovered that Claude could cut their first-draft research memo time by roughly 40% - specifically the initial pass at pulling together case precedents, which apparently nobody enjoyed doing anyway. That finding spread across the firm in about a fortnight. Not through a training session, but through a WhatsApp message and a lunchtime demo that ran twenty minutes over because people kept asking questions.
Second, curate a short resource list. Not every AI tutorial on the internet - a specific set of ten to fifteen resources that are relevant to your firm's actual use cases and appropriate for a non-technical professional audience. I've seen firms circulate 200-page reading lists that nobody opens. Ten good resources, updated quarterly, will do more.
Third - and this one is stupidly simple - run a fortnightly "what we've learned" session. Twenty minutes. People share what they tried, what worked, what went sideways. No slides. No prep. Just conversation. The compound effect of this over three months is remarkable. Deloitte's research on generative AI and the future of work cites 66% productivity gains among knowledge workers within six months of structured AI literacy development - that number sounds high to me, and honestly the firms I've seen do this haven't hit anything close to 66% in six months. But the direction is right, and the gains are real enough to justify twenty minutes a fortnight.
None of these costs a training budget. All three accelerate capability faster than a formal programme.
One of the things that frustrates me about the AI conversation in professional services is the assumption that "adopting AI" means buying new, expensive, complex systems. For most firms at the literacy and prompting stage, the entry point is much more accessible than that.
Start with what's already on your desk. If your firm runs Microsoft 365, you've probably got access to Copilot features that most of your team haven't touched. If you've got a CRM - HubSpot, Salesforce, Dynamics - there are AI features baked in that can be switched on without any integration work. Your project management tool, your document management system - many of them have shipped AI capabilities in the last twelve months that nobody in your firm has explored because nobody was told to.
Beyond what you've already got, the standalone tools that create the most immediate value at the literacy and prompting level are the ones your fee earners can use without technical support. Claude and ChatGPT for drafting, summarising, and research tasks. Microsoft Copilot for document and email work within the Microsoft ecosystem. For operations teams wanting to automate repetitive workflows, no-code platforms like Zapier AI and Make.com can handle document processing and task routing without a developer in sight.
I'm not suggesting you give everyone access to everything and hope for the best. But the gap between "we have no AI capability" and "we're using AI tools productively" is much smaller than most firms assume. The barrier isn't the technology. It's the permission.
This is the question I get asked most, so let me be direct.
At levels one and two - literacy and prompt engineering - you don't need a partner or a new hire. Development is internal and low-cost. The AI champions, the curated resources, the fortnightly sessions. That's it. Spending money on external support here is, candidly, a waste unless your firm has specific compliance or regulatory training requirements that need specialist input.
At level three - tool configuration - a technology-literate existing staff member with some specific AI tool training is typically enough. If they get stuck, a partner can help with specific configuration challenges. But you don't need someone on the payroll for this full-time unless you're running a complex multi-tool AI environment, and most mid-market firms aren't there yet.
Level four - custom development - is where the partner question gets real. And the honest answer depends on volume. If you anticipate more than three or four significant custom AI projects over a two-year horizon, a hire might be justified. Fewer than that, and a specialist implementation partner is almost always more cost-effective, because they've done it before across dozens of implementations and they're not learning on your specific project.
I should be transparent: we're an implementation partner, so I've got skin in this game. But I'd rather be honest with you than pretend otherwise. Most mid-market professional services firms are at levels one and two right now, and will stay there for the next eighteen months. Which means most firms don't need to hire anyone or engage a partner yet. They need to start building literacy and prompting skills internally - and only escalate when they've identified specific use cases that require configuration or custom work.
Right, here's where I'm going to push a bit. Because in every firm I've worked with on AI readiness, the most consistently cited barrier to capability development isn't a skills gap. It's a fear gap.
Fee earners who worry that using an AI tool poorly will make them look incompetent don't experiment. They wait. They watch. They say things like I'll have a proper look at it when things quieten down - which, as you know, means never.
Google's Project Aristotle research found that teams with high psychological safety are 3.2 times more likely to successfully adopt new technologies. I'll be honest - when I first saw that stat I thought it sounded like the kind of number that gets rounded up in a slide deck. But I've watched it play out enough times to believe the mechanism, even if the precise multiplier is debatable. Fear of visible failure directly inhibits the experimentation that builds capability. That's not a soft observation. It's what actually happens.
So what creates the conditions where people actually try things?
Three specific interventions. First - and this is non-negotiable - the managing partner or senior leadership team needs to use AI tools visibly and talk about what they're learning. Including what went wrong. I was with a managing partner last month who showed his team a proposal draft that Claude had produced which was, in his words, "absolute rubbish." He then showed them the revised prompt that produced something useful. That five-minute demonstration did more for the firm's AI adoption than three months of encouragement emails. What I didn't expect was the reaction - half the room immediately started asking whether they could try the same thing on their own proposals, and one partner admitted she'd been using ChatGPT for months but hadn't told anyone because she wasn't sure if it was "allowed." That's the fear gap, right there.
Second, make a clear, explicit statement that there is no expectation of perfection during a defined pilot period. Not a vague "it's okay to experiment" - a specific commitment. "For the next 90 days, we expect people to try AI tools on internal work. The outputs won't always be good. That's fine. That's the point."
Third, create a feedback mechanism that allows staff to report problems with AI tools without it reflecting badly on them personally. If someone discovers that an AI summary missed a critical clause in a contract, that's valuable information for the whole firm. But they'll only share it if the response is "thank you for catching that" rather than "why were you relying on AI for something that important?"
If you've read this far, you probably fall into one of two camps. Either you're thinking we're already doing some of this - in which case, the AI readiness checklist I've put together will help you assess where you actually are across all five dimensions, including skills readiness. Or you're thinking we haven't started, and this feels more achievable than I expected - and if that's you, there's a foundational piece on what using AI in your business actually means that's worth reading first.
Either way, the capability model is the same. Literacy first. Then prompting. Then configuration. Then - if and when you need it - custom development, probably through a partner.
Building AI capability across a firm is a change management programme as much as it is a skills programme. There's a separate piece on how to govern that kind of programme so it builds momentum rather than stalling - because the firms that treat this as a one-off initiative rather than an ongoing rhythm are the ones who end up back at square one six months later.
Most of the value is in the first two levels. Most of those skills already exist in embryonic form in your current team. The investment isn't in hiring a data scientist. It's in creating the conditions where your people feel safe enough to experiment, structured enough to learn from each other, and clear enough on what "good" looks like that they build real capability rather than just tick a box.
If you want to design a capability development plan for your firm - mapping the four skill levels to your current team, identifying which tools will create the most accessible entry points, and designing the internal champion structure that will accelerate adoption - book an AI capability planning session. We've also put together an AI capability development plan template that walks through each of the four levels with a current-state assessment and a development path. It's designed for an operations leader or HR director to fill in and share with a managing partner before the investment conversation happens.
You don't need a data scientist. You need a plan, some structure, and a managing partner who's willing to show their team a bad AI output and laugh about it. Start there.