Most of the enterprise AI initiatives I'm asked to look at had decided what to build before anyone asked whether the organisation was ready to build it. The proof of concept goes well, the production rollout stalls, and I get called in to find out why.

Nine times out of ten it's the same answer: a readiness gap that should have been caught at the start. The framework below is how I try to catch it before the budget is committed.

Five pillars

A useful readiness assessment covers five areas. Most organisations are strong in two or three and weak in the rest, and the weak ones are where AI projects fail.

1. Data

Data derails more projects than anything else. AI systems need data that's accessible, accurate and well described, and three questions cut through most of the noise.

If I asked a new employee to find the definitive record for customer X, how long would it take them? How sure are you that two teams pulling the same metric would get the same number? And for the systems you'd want an agent to read from, who owns the schema and how often does it change?

If the first answer is "ask Jane, she knows" and the second is "we'd have to check", you have a data maturity problem that no AI project can work around. Fix that first.

2. Infrastructure

This is the easiest pillar to assess and usually the least likely to block you. Cloud AI services have removed most of the heavy lifting. The questions that matter are narrower.

Is there an approved way to use AI APIs (Azure OpenAI, Anthropic, Google) that meets your security and compliance rules? Can your applications call AI providers at all, or is everything locked to private networks? And if you had to run a private model behind your firewall, could you get the GPUs?

For most enterprises in 2026 the first answer is "yes, through Azure OpenAI", and that's enough. The other two only matter in particular scenarios.

3. Skills

An AI project needs a different team from a typical software project. You want someone who's good at prompt engineering, which is a real skill that takes a few months to build. You want someone who can evaluate AI output systematically rather than spot-check it, and someone who understands what model choices do to cost and latency. And you need a product owner who can trade off accuracy, cost and user experience.

You don't need PhDs. You do need people who've shipped AI features before, or who get the time and budget to learn. Handing AI projects to teams that have only ever built CRUD apps usually goes badly.

4. Governance

AI brings kinds of risk that ordinary software doesn't, so ask yourself a few questions:

  • Is there a written policy on which data can go to which AI providers?
  • Is there a process for assessing AI risks such as bias, hallucination and prompt injection in any new system?
  • If a customer challenges a decision an AI system made, who's accountable, and how do you investigate?
  • How would you know if a model update from your provider changed your system's behaviour?

Most large enterprises have at least started on this. Most mid-sized ones haven't. Either way, get the answers in place before AI goes in front of customers, not after the first incident.

5. Use cases

I weight this pillar highest. AI pointed at the wrong problem fails for reasons that have nothing to do with the technology.

A good use case has a baseline you're trying to beat, such as current process time, error rate or cost per transaction. It has users who'll really use it, which is harder than it sounds. It can tolerate the occasional mistake, because AI is rarely the right choice where 100% accuracy is required with no human review. And there's enough volume for the build cost to make sense against doing it the old way.

The baseline is the best single filter. If you can't measure what the AI is meant to improve, you'll never know whether it worked.

How I run the assessment

A typical assessment takes me two to three weeks.

The first week is interviews across business, IT, data and security, plus a read through the data dictionaries, policies and architecture diagrams, and one workshop to surface candidate use cases. In the second week I go deep on the top two or three use cases, pull together baseline metrics and talk to the people who'd use the system. The third week is writing up, presenting and agreeing on a way forward.

The report has two parts: a readiness score across the five pillars with the specific gaps, and a recommended order for which use cases to try first, based on readiness and value.

What "ready" looks like

You don't need to be strong on all five pillars to start. You do need to be honest about where you're weak and have a plan for it.

The organisations that get the most from AI tend to pick one or two use cases and get them right instead of launching ten at once. They put money into the dull groundwork of data quality, governance and evaluation tooling before the flashy capabilities. And their executive sponsorship survives the first failure.

That last point matters more than people expect. The first AI project rarely lands as well as hoped. Organisations that give up after one disappointment never see the compounding value, while the ones treating it as a multi-year capability pull ahead.

Where most people land

AI readiness has less to do with how modern your tech stack is than with clean data, real skills, working governance and well-chosen first use cases. Most enterprises I assess are stronger on the tech than on those four. The fix is usually rebalancing the investment, not buying more tools.

Want a readiness assessment for your own organisation, or a second opinion on where you stand? Let's talk.