AI Strategy & Transformation: Charter

Most AI transformation functions fail the same way: they become an internal marketing department for AI. They count pilots, publish adoption dashboards, and cannot answer the only question that matters: did the work get cheaper, faster or better, and by how much?

This charter exists to prevent that. The function owns the portfolio of changes, not the technology, and it is judged on realised benefit rather than deployment count.

The question this function asks#

The difference between a transformation function that works and one that does not shows up in the question it puts on the table.

It does not ask "should we use AI?" That question has no answer, because it has no subject. It invites opinion, it is settled by whoever is most senior in the room, and it produces pilots.

It asks:

Which twenty processes consume the most human hours, and which of those can be automated or augmented?

That question has an answer, and the answer is a list. It can be wrong, which means it can be corrected. It ranks by something the company already pays for rather than by enthusiasm. And it splits cleanly into work that a machine should do, work a machine should assist with, and work that should stay exactly as it is.

Everything else in this charter is machinery for answering it honestly: measure the hours rather than ask for them, score each candidate for reversibility before volume, freeze a baseline before anything changes, and have someone other than the delivery team publish the result.

What this function is responsible for#

The last one is the one most often left off a list like this, and it is the one that decides whether the rest is adopted or resisted.

What this function owns#

The application map. Which processes are candidates for AI, ranked by value at risk and reversibility. A process that is high value and easily reversed is a first candidate; one that is low value and irreversible is never a candidate, however technically attractive.

Sequencing. What changes first, and what deliberately waits. Sequencing is where transformation programmes are won: three functions changed properly beats twelve changed superficially.

The refusal list. Written, published, and revisited quarterly. Where the company will not apply AI, and why. Without this, every request becomes a negotiation.

Benefit realisation. A baseline measured before the change, and the same measure taken after. No baseline, no claim.

Capability versus purchase decisions. Whether a given capability is built, bought or rented, and what the switching cost is if that answer changes.

What is NOT delegated to an agent#

• Choosing which processes change. Agents can score candidates; the ranking encodes risk appetite, and risk appetite is an ownership question.
• Signing off a benefit claim. An agent that measures its own programme's success has an obvious conflict.
• Deciding to stop a programme. Kill decisions are political before they are analytical.
• Anything touching headcount. Where automation changes what people do, a person decides.

KPIs#

Deliberately absent: number of pilots, number of agents deployed, adoption percentage. Each is easy to grow while delivering nothing.

AI agents in this function#

Process-mining agent. Reads event logs and proposes where time and rework actually go. It is frequently the first thing to contradict the organisation's own account of itself. Read-only.

Candidate-scoring agent. Applies the ranking model to a proposed change and returns the score with its inputs shown, so the score can be argued with.

Benefit-tracking agent. Holds the before-baseline and reports the after-measure on schedule. It reports the number even when the number is bad; that is the entire point of separating measurement from delivery.

Vendor and capability scanning agent. Watches the build-buy landscape and flags when a previously sound build decision has been overtaken. Read-only.

Every one of these prepares evidence. None of them approves a change, signs a benefit claim or alters a baseline once set.

SOPs#

• Quarterly portfolio review. Every live change against its forecast, with kill decisions taken in the meeting rather than deferred.
• Baseline protocol. No change starts without a measured baseline and a named measure. This is the rule most often skipped and most expensive to skip.
• Refusal review. The do-not-automate list, re-read quarterly and dated.
• Post-implementation review at 90 days, comparing claim to outcome, published internally whichever way it lands.
• Reversal drill. For any irreversible-looking change, the rollback path is written and tested before go-live.

Templates#

Project Charter, Business Requirements, SOP, benefit baseline record, candidate scoring sheet.

Workflows#

In: process pain reported by any function, cost and cycle-time data from Finance and Data & Analytics, capability signals from Research & Innovation, regulatory constraints from Compliance.

Out: the ranked application map, sequenced programme, benefit reports, the refusal list.

Handoffs: PMO delivers the change, AI Engineering & Product builds it, Data & Analytics supplies the measurement, CEO holds the capital decision.

The loop that makes it work: baseline → change → same measure → published result. Break any link and the function reverts to counting pilots.

FAQ#

Why not just automate everything that can be automated?#

Because capability is not the test. Reversibility and accountability are. A process that is cheap to automate but expensive to unwind, or where someone must answer for the outcome, belongs to a human regardless of what the technology can do.

How do you know the benefit is real rather than a reallocation?#

By measuring the same thing before and after, and by separating measurement from delivery. If the team claiming the saving is also the team measuring it, the number is an opinion.

What is the right size for a first change?#

Small enough to reverse in a day, large enough that someone notices it worked. Programmes that open with a flagship process usually spend their credibility before they have earned any.

Where does this function most often go wrong?#

Owning the technology instead of the portfolio. The moment this team is judged on tools deployed rather than benefit realised, its incentives invert and it stops being able to say no.

What else is coming for AI Strategy & Transformation