What is AI enablement, and who should lead it?

Most organisations we talk to have already bought the licences. Claude, ChatGPT, Copilot or Gemini is on every laptop, and in our experience it's most often Claude. A few people get real value from it, and most teams don't know where to start. Then someone is asked to lead AI enablement. Sometimes that's a new hire. More often it's a line added to an existing job, which we think is the first mistake. Either way, the title tends to arrive before anyone has decided what it means. This post is for both people in that conversation: the leader who has to define the role, and the person who has just been given it. There's a one-page role brief at the end that you can fill in together. ## What AI enablement is to us To us, AI enablement is the work of getting real value from the AI tools an organisation already pays for. Not buying more of them, and not just teaching people to use them, but finding the work they should take on and proving that they do it well. The person who leads it is the AI enablement lead. You'll also hear AI champion, AI lead or, in larger organisations, head of AI. The job is the same: find out where AI actually helps the organisation, and prove it. They sit between two groups. Leadership is asking what AI has delivered so far. Teams are doing the work and know where the time goes. The lead's job is to connect the two: find the work that AI should take on, test whether it does, and come back with a recommendation that leadership can fund or drop. So the output of the role is evidence. It looks like a short list of candidate work, the results of a few small tests, and one page saying what to do next. Some organisations also run a network of AI champions: volunteers in each team, each giving a few hours a week to help colleagues with the tools. A network like that is useful, and the lead often runs it. A few hours a week works for a champion. It doesn't work for the person leading them. This post is about that person.  ## What we say it shouldn't be The role is easy to confuse with work that sits next to it. Here's where we draw the lines. - **Not a part-time role.** Adoption is the hardest part of AI. Getting people to change how they work takes attention every day, and it doesn't happen in the gaps between someone's other responsibilities. If you're serious about it, make it the job, not a side of the desk. - **Not IT.** IT keeps systems secure and running. The lead decides what's worth trying, and IT decides how it can be done safely. They need each other, and neither can do the other's job. - **Not the AI strategy.** A strategy says what to try. The lead finds out what works. - **Not a trainer.** Training helps people use the tools. It doesn't tell you which work the tools should take on. - **Not the office enthusiast.** The keen person who builds automations on the side is often the right person for the job. But enthusiasm isn't the job. Enthusiasm is not the same as demand. ## Evidence, not evangelism The easiest way to fill the role is with activity: lunch-and-learns, a prompt library, a monthly newsletter, a usage dashboard. A lot of AI enablement stops there. None of it is wrong. But together it answers "are people using AI?", and the question the CEO is asking is "what has AI done for us?" A lead who can only answer the first question will find it hard to get budget for anything bigger. A lead who can answer the second gets asked what to do next. That's the case for making the role about small, live tests. Pick a real piece of work. Try AI on it with the people who do it. Measure what changed. Report it plainly, including what didn't work. One test like that carries more weight with leadership than a full room at a lunch-and-learn. ## For leaders: setting the role up Five decisions, ideally made before the role is announced. 1. **Time.** Make it their whole job. A lead squeezing this in alongside their old role has a hobby, not a role. If you're moving someone internally, decide who takes on their previous work, and put it in writing. 2. **Reporting line.** They should report to someone who can approve spend and clear blockers across teams. If the lead reports into one function, their remit will drift to that function. 3. **A small budget.** Enough for licences, API usage and the odd tool, spent without asking each time. Needing approval for every £20 is how momentum stops. 4. **Access.** A named contact in IT, and agreed rules on which data can go into which tools. Settle this in the first fortnight. Unsettled, it is often why a good idea stalls. 5. **What good looks like at 90 days.** Not adoption figures. Something like: "Two or three ideas tested on real work, with results, and a recommendation on which one to fund." Who should it be? Look for someone who knows how the work is actually done, is trusted by the teams, and can write a clear one-page case for leadership. Technical skill helps, but it can be borrowed. Trust from the teams can't.  ## For the lead: your first 90 days If you've just been given the role, this plan is a reasonable place to start. If you've been given it on top of your current job, start with the role brief below and have that conversation first. **Weeks 1 to 3: map the work.** Talk to the teams. Ask what they do each week, not what they want from AI. Look for work that is repetitive, follows rules, comes in volume or involves a lot of documents. Note what's already been built on the side, and by whom. Those people are your first allies. **Weeks 4 to 6: rank it.** Score each candidate on three things. How much it's worth: the time it takes, how often it happens, and what a mistake costs. Whether it's possible: the data exists and the tools are allowed. Whether you can measure it: you know how long it takes today. Pick two or three. **Weeks 7 to 11: test them live.** Use real work, real users and a small scale. Measure before and after. Write down what goes wrong as well as what goes right. A test that shows an idea doesn't work is still a result, and it saves money later. **Weeks 12 and 13: report.** One page to leadership. What you tested, what happened, and what you recommend: fund it, stop it, or try something next. Write it so it still makes sense when it's forwarded to someone who wasn't in the room. Throughout, keep a log of every idea people bring you, including the ones you don't take forward. It shows teams they were heard, and it becomes your list for the next round.  ## The role brief We've put the decisions above onto one page. It covers the role's purpose, time, reporting line, budget, access, what good looks like at 90 days and a date to review it. Leaders, fill it in before you announce the role. Leads, if you weren't given one, fill it in yourself and take it to your manager. It is much easier to agree a role on paper than to discover its edges six months in. [Download the AI enablement lead role brief (PDF)](/share/3e9LJXX) ## Where we fit Mapping, ranking and testing is the work we do with AI enablement leads. [AI Opportunities](/#offers) is the mapping and ranking: two to four weeks, ending in a ranked shortlist of five to eight opportunities. The [AI Evidence Sprint](/#offers) is the testing: live automations built with your team over six to eight weeks, a readout every week, and an evidence-backed recommendation on what to build next. If you're setting up the role, or you've just been given it, [we're happy to talk it through](/contact-us).