AI is the fifth transformation

In most large organisations, GenAI doesn’t arrive on a blank page. A cloud migration, a data platform rebuild, agile at scale and some regulatory programme are usually already running. AI comes fifth. Nobody in the business is waiting for another transformation story. They want things that work on Monday morning.

Building an AI Factory in that context taught me that the difficult part is rarely the technology. It is keeping a steady flow of useful results in an organisation that is already tired of change, while the tools move faster than any steering committee can meet.

Why this wave feels different

Cloud changed where systems run. Agile changed how teams plan. Neither changed how an analyst reads a contract or how an advisor writes to a client. GenAI does. It goes straight into professional judgement, the part of the job people protect most, and I think they’re right to protect it.

It also moves faster than governance does. The model you plan around in January has a successor by June. I gave up on detailed multi-year AI roadmaps fairly early. Today I’d commit to a direction for two years and to deliverables for one quarter, and revisit both often.

Where the real difficulty sits

Proofs of concept are easy to impress with and hard to industrialise. Between 2020 and 2024, my teams evaluated more than fifteen AI use cases and put five into production, meaning running on live data and used by business teams in their daily work. I think that ratio is healthy. What isn’t healthy is letting the other ten drift on for months because nobody wants to be the one who stops them.

Data debt also becomes visible very quickly, usually within the first weeks of a retrieval assistant. I’ve written about where that debt comes from in data maltreatment.

Then there are the constraints that are real: personal data, model risk, operational resilience. They deserve to be taken seriously. I’ve also seen them used, more than once, as a comfortable reason to wait.

And there’s the people side. Very few people understand both a business process and how a model behaves. Those profiles decide the outcome, and you can’t hire them in bulk. Meanwhile, staff are already using public AI tools, with or without a policy. The real question is whether they use them safely.

Battles I try to avoid

Some fights look important, cost a lot of energy and change very little.

The model and framework debate is the first one. Which LLM, which agent framework, which vector database. I’d rather put a gateway in front of the models, measure on our own cases and keep the freedom to switch. The rankings change every quarter anyway.

The big-bang platform is the second. Building the perfect platform before the first real use case gives you infrastructure designed for imaginary needs. I prefer to let the platform grow out of the use cases.

Then there is ROI theatre, counting pilots, demos and “use cases identified”. Usage in production and measured impact are the numbers I find worth reporting.

I also avoid trying to ban shadow AI. Bans push usage out of sight. A safe, approved path that is easier to use than the unofficial tools works better.

And I stay away from the replacement narrative. “AI will replace this team” is the fastest way to lose the experts you need to make AI reliable, and in most processes it simply isn’t true.

Battles I think are worth fighting

Other fights are slow and uncomfortable, and they decide whether anything lasts.

Data ownership. Every document an assistant reads needs someone accountable for its quality and its version. No amount of prompt engineering makes up for a missing owner.

Evaluation. Nothing goes to production without an evaluation suite and a named person who signs it off. The details are in agents that learn on the fly vs. agents you can govern.

Governance as a paved road. One approved path, with the model gateway, logging, data classification and the review checklist already built in. When the compliant route is also the fastest one, compliance stops being a negotiation.

The funding model. The approach I use is demo to budget: scope a use case with the business, build a working prototype on real data, show the result to the people who would pay for it, and only then ask for funding. It keeps the conversation about evidence. It also protects the team from projects that only one enthusiastic manager wanted, because those rarely survive a demo in front of their peers. It has a cost too. Prototypes take capacity before any money comes in, and teams that are less comfortable with demos can end up waiting longer.

Changing the process. Value appears only when the way the work is done changes: who does what, who validates, what happens when the assistant is wrong. A tool dropped into an unchanged process gives you a nice demo and little else.

Stopping projects. I try to make stopping normal and cheap: agree a stopping criterion with the sponsor at the start, and when it’s reached without the result, stop and say so openly. A project stopped early is a good portfolio decision, and the team that built it should hear that.

The people who make it work

Almost every difficulty above turns out to be a human one.

People’s fear is rational. They are being asked to trust a system that can be confidently wrong, in their own field. The least we can do is be explicit about what changes, for whom, and what stays the same.

Domain experts are the scarcest resource. Their judgement is what turns a model into something trustworthy. Reviewing AI output is real work, and I push for it to be recognised in their objectives instead of being asked as a favour.

Middle managers carry the change. They turn strategy into daily work and absorb most of the friction. In my experience, the ones who help define the success metrics defend the result, and the ones who have metrics imposed on them resist, often for good reasons.

A credible champion inside a business team, someone who has used the assistant and can say honestly what it’s good and bad at, does more for adoption than any internal campaign.

And then there’s my own team: AI engineers, data engineers, architects, people who understand the business. My job is to protect them from the hype cycle, give them time to do things properly, and make sure they can grow without having to leave the field.

What I’d tell someone starting now

Deliver something the business can see every quarter, even if it’s small. Trust comes from delivery. Every assistant that works makes the next one easier to adopt, and every public failure makes the next few harder.

Start where pain and data meet. A painful process with no usable data is a data project first. Good data with no pain is a solution looking for a problem.

Measure the baseline before you build, so the impact you report later is a fact and not an opinion. Then tell the story with production numbers.

Let each use case leave something reusable behind: a connector, a retrieval table, an evaluation set, a review workflow. That’s how a platform grows without a big-bang programme.

And leave room for people: training, time to adapt, and recognition for those who make it work.

None of the five transformations has an end date. The skill that has mattered most to me isn’t picking the right model. It’s keeping up a rhythm of delivery that people can feel in their daily work while everything around them keeps moving.