An AI enablement operating model for People leaders

The question that lands in the CHRO's inbox after the board meeting is usually one line: "We rolled out AI to everyone. Where's the return?"

The honest answer is that you rolled out tools, not capability. An AI enablement operating model is not a training programme or a licence count. It is a system with three connected layers, each with an owner, a cadence and a budget line. Skip the model and you get exactly the picture the board is describing: a handful of power users, a majority who dabble then plateau, risk behaviours that vary team by team, and no leader able to say confidently what "great" looks like. The tools were the easy part. The operating model underneath them is the work.

Why AI enablement is an operating model, not a training programme

Most organisations have already bought the licences and stood up an "AI champions" programme. Adoption and return stay stubbornly uneven. The pattern repeats across enough engagements to write it down: a small group becomes genuinely good, the majority try it a few times and drift back to old habits, and every team invents its own idea of what is safe. Leaders cannot quantify the impact because there is nothing consistent to measure.

The gap sits one level up from the tools. Treat AI enablement the way you already treat leadership development, security awareness or management fundamentals: as a company capability with a backbone, not an event with a launch date. Those capabilities did not stick because someone ran a workshop. They stuck because there was a standard, a cadence, an owner and a set of incentives that carried the behaviour long after the training day. AI is no different, and it moves faster, so the absence of a backbone shows up sooner.

An AI enablement operating model gives you something to point at. It also gives you somewhere to put the money that is currently disappearing into scattered licences with no line of sight to a result.

The three layers, and why skipping one stalls the other two

The model has three layers. They are not a maturity ladder you climb one rung at a time. They are load-bearing walls: pull one out and the other two sag.

Org-wide is the layer almost everyone skips, because it is unglamorous and produces no launch moment. It is one page of standards in plain English (what is approved, what is forbidden, what needs review), a tooling strategy that says which models are licensed and where the data lives, capability expectations tied to the levelling framework rather than bolted on as a side project, governance that names who can deploy what with what oversight, monthly measurement reported openly, and incentives that make AI-fluent behaviour show up in promotion and performance conversations. It is boring, and it is the layer that decides whether everything above it compounds or evaporates.

Team-wide is where the value actually shows up. The unit is the team, not the individual. Each team picks its top three workflows and rebuilds them with AI in the loop. Take onboarding: instead of bolting a chatbot onto induction, you redesign the whole flow so AI sits at the moments that genuinely slow people down, day one, week two, first review. The before-and-after is visible enough that new hires notice it themselves. Then the team keeps the assets, prompts, agents and automations, versioned and owned, and runs a cadence that makes the work visible.

Individual is the human layer, and it is the one most companies do invest in, often the only one. Every employee needs a persistent AI workspace with reusable context, an understanding of what "good" looks like by task type, and the reflex to run a critique pass before shipping a first draft. It is necessary and, on its own, nowhere near sufficient. This is the whole territory of an AI workspace for People Ops: make the individual layer real, but never mistake it for the model.

Here is the same picture as a working matrix. It is the fastest way to see what each layer owns and, more usefully, what breaks the moment you leave one out.

Read the last column on its own and the interdependence is obvious. Rituals with no org backbone give you inconsistent standards team by team. Individual skill with no team cadence gives you isolated power users nobody else can learn from. Org standards with no individual capability give you a policy document that describes a behaviour nobody in the building can actually perform.

Where champions help, and where they can't

Champions are useful, and I would not run an enablement effort without them. They translate generic guidance into examples that make sense for Finance, People, Sales, Engineering and Legal. They create social proof. They surface friction early. A good champions programme genuinely accelerates adoption.

What a champions programme cannot do, on its own, is produce sustained capability. Champions rotate. Their priorities shift. The teams around them slide back to old habits the moment the champion is pulled onto something else. Without an underlying system, the wins evaporate, and the next champion starts again from zero. That is the whole case for building the backbone first and letting the champion model sit on top of it, distributing capability the system already supports rather than carrying the strategy by itself.

What to build in the first year

The temptation is to do all three layers at once. Do not. The order matters more than the ambition, and each layer has to earn the next.

The sequence is not arbitrary. Org-wide standards drafted in month one will be wrong by month four, because you will not yet know what the real workflows or the real risks look like. Team-wide rituals introduced before there is anything worth showing will get gamed before they produce value. Individual enablement that runs ahead of team cadence creates power users who feel unsupported and quietly stop bothering.

Two artefacts pay for themselves early. The first is the one-page policy: publish what is approved and what is forbidden before anyone asks, so the answer to a nervous manager is a page, not a Slack thread. The AI policy blueprint for People teams is the fastest version of that. The second is the move the whole model turns on, which is the shift from scattered prompting to owned systems. Enablement that never crosses from prompts to systems produces clever individuals and no institutional capability. Move in sequence, and let each layer buy the right to build the next.

The behaviours that decide whether it takes root

Underneath the three layers sits a small set of leadership behaviours. They are what actually decide whether the operating model roots or withers, and they cost nothing but attention.

• Context first. Translate every People decision into commercial terms, so AI work is judged on outcomes, not on activity.
• Speed with safety. Ship in slices, capture the learning, add the controls the slice revealed you need. Not a nine-month governance project before the first workflow moves.
• Show the work. Prompts, evaluations and outcomes are visible by default. Hidden good practice does not spread.
• Coaching over policing. Teach managers to think with AI, not just to monitor compliance. A manager who can only check a box will not lift their team.
• Transparency. Employees know what is automated, why, and how it is monitored. Trust is the substrate everything else runs on.

The signal that a leader is living this: they can explain any People decision in two sentences in commercial terms, and they volunteer examples of safe automation their team shipped this month. The anti-signal is the one to watch for: tool-first and problem-second, pilots that never end, and dashboards that produce no decisions.

What good looks like in 90 days, honestly

I would rather give you a testable bar than a comfortable one. Good, at the 90-day mark, is three to five use cases with a real number attached to each, one published policy page, and a weekly show-the-thing cadence that nobody has to be reminded about by month two. Measure adoption and capability separately, because both lag and both matter, and put a figure on the value rather than an adjective. The discipline of measuring AI value in People Ops is what stops the programme becoming a story you tell instead of a result you can defend.

Run this filter before you tell the board it landed.

For a sense of the ceiling, the mature version of this is not exotic. On one defence-tech engagement the reclaimed time reached 83 hours a week, roughly 70 per cent of routine queries were handled by systems the team owned, and there were no critical issues two months on. Across the wider practice, 37 champions trained and 11 functions reshaped is what the far end of the curve looks like. None of that came from a bigger tool budget. It came from the backbone holding the wins in place while the individuals and teams kept building on top.

Whose job this is

This is the CHRO's work, or the CPO's. Not because IT cannot help, but because AI enablement is a people system before it is a technical one: expectations, capability development, incentives, performance, progression, culture, trust and change. IT can deploy the tools and hold the security line. Only People leadership can standardise the behaviours and embed the capability into how work is done. Hand this to IT and you get tools with no adoption; hand it to a champions programme with no backbone and you get adoption with no memory.

Before you build the model, it is worth knowing where your function actually stands today, which is what the Readiness Assessment is for: sixteen questions, about ten minutes, a score across the four capability layers so you are building on a diagnosis rather than a hunch. Get the operating model right and the champions programme finally does the one job it was always meant for: distributing capability the system already supports.