Not one AI programme, but three

Most AI programmes stall for the same reason: they are three different kinds of change pretending to be one.

Organisations tend to describe their AI plans as a single thing: "our AI programme", "our AI strategy", "rolling out AI". In practice, there are three quite different types of change hiding inside that phrase. They need different leadership, different ways of working and different measures of success. When an organisation treats one type as if it were another, the work usually stalls, and it is rarely the technology's fault.

1. AI adoption: a people change

The first type is helping people across the organisation use AI safely, confidently and productively in their daily work.

The common mistake is treating this as a technology rollout. Licences are bought, a launch email goes out, and six months later usage is flat. Issuing licences is the easy part. The hard part is changing habits, building trust and keeping use safe.

What works is a staged approach. Start by building comfort, with an introduction to AI for everyone, so people know what it can and cannot do. Put governance in place early, because clear rules give people permission to experiment rather than a reason to hold back. Then work with small groups on their own tasks, not generic demos, and grow the ambition as confidence builds: from chat tools, to workflows, to people building their own tools.

In one business I worked with, that approach took around 85% of staff to using AI every week, and over half built their own AI tool that they now use every day. None of that came from the licences. It came from the sessions.

How to measure it: whether AI has become part of how work gets done, not how many licences have been issued.

2. Agentic workflows: a process change

The second type is redesigning a business process so AI takes on some of the steps, with people handling the rest.

The common mistake here is the opposite one: treating a process change like an adoption pilot. Someone builds a clever prototype, a team starts using it, and there is no baseline, no owner, no change control and no support. Then the underlying model is updated, the output quietly changes, and nobody notices until something goes wrong.

The prototype is not the problem. It is usually the right way to start. Someone close to the work sees how a task could be done faster, builds a proof of concept, and shows it working. That is how the best workflow ideas are found. The problem is stopping there.

Once a prototype has proved it is a better way of working, it needs to be productionised. That means mapping the full process it sits in, deciding where a person must review or approve, rebuilding it to the organisation's own engineering standards, and hosting it securely so the data and the system are protected. Then it needs monitoring and measurement, so everyone can see whether it is delivering. From then on, every change to a model, prompt or rule is treated as a release, with testing, versioning and rollback, and the workflow is wrapped in proper service management so the lights stay on.

A good example started with one member of staff. Using an AI assistant, she built a customer insights dashboard that gave client account teams a clear view of the market insights behind each of their clients. People liked it, but it had no way to connect to the tools and data it needed. She handed it to the technology team, who rebuilt it to the organisation's coding standards, connected it securely to the approved AI tools and hosted it securely, with access protected. It is now a critical tool that all the client account teams use. Only 10 to 12 people use it, but the impact is significant. That is the full journey, from a proof of concept built by the person who saw the need to a production system the business relies on.

How to measure it: against a baseline of the old process, on dashboards that show quality, human review rates and benefits over time.

3. AI products: a business model change

The third type is turning what a business does for its customers into an AI-powered product, so expertise that once depended on people's time becomes a service that scales.

This is the most ambitious type, and the common mistake is treating it as a bigger workflow: taking the old way of working and automating it step by step. That produces a faster version of yesterday's service, not a new product.

What is needed is a blank sheet of paper. Start with the output, the customer and the knowledge the service depends on, then design a new, agentic way of producing that output. AI does the work it is good at, and people oversee the system and its output. The key is capturing what those people do: every review, correction and judgement becomes part of the product's knowledge. As the process is fully measured, that knowledge lets people shift from producing the output to overseeing it, focused where their judgement adds most. The result is a fully agentic AI product, not a replacement for the old way of working.

I led a project that tested exactly this: an agentic pipeline that took a creative brief and produced localised assets for multiple markets, guided by expert rules and human sign-off. The working prototype produced 96 files across six markets in about 30 minutes. It worked, and it proved the blank-sheet approach technically. What was missing was organisational readiness. The business decided its future lay in premium, bespoke service rather than a software product, so the prototype was archived.

The lessons were not about the AI. They were about what has to be in place before an AI product is built:

• Design and fully cost the whole system before building. A proof of concept that grows step by step can become a platform without anyone deciding to fund one.
• Test the organisation, not just the idea. That means checking it is ready for both the investment and the pivot to a new product or service, not just whether the technology works.
• Put the engineering team in place before you start. A product needs a team to build it and run it, not a few people fitting it around other work.
• Know who will buy it, and how. Do the market research before building: is there a market for this kind of product, who will you sell it to, how will you reach them, and what will you charge? Agree the pricing before the build, not after.

All four need to be in place before the project starts, not sorted out along the way. Do not start building too early: the excitement of a good design needs to be tempered by reality.

How to measure it: like any product, on whether customers will pay for it and whether it fits the business that has to sell it.

Why the distinction matters

Each type fails in a predictable way when it is mistaken for another:

• Adoption run as a technology rollout produces licences without habits.
• A workflow run as an adoption pilot produces prototypes nobody can support.
• A product built by automating the old process produces a faster version of yesterday's service.

The types also build on each other. Adoption builds the confidence and the ideas. People who use AI every day are the best source of processes worth redesigning. Well-run workflows prove what AI can reliably do inside the business, and the strongest of them sometimes point to something bigger that customers would pay for.

Three questions to ask before you start

Before starting any AI initiative, it is worth asking:

1. Are we changing how people work, how a process runs, or what we sell?
2. Who owns the outcome? A people leader, a process owner, or a product owner?
3. How will we know it worked? Use, measured process performance, or customer value?

If the answers are unclear, or if they point to more than one type, that is the signal to split the work up, and give each part the approach it needs.