What an AI readiness assessment actually covers

A readiness assessment should end with a decision you could not have made on Monday. If it ends with a maturity score and a recommendation to talk further, you have bought a sales process with a diagnostic costume on.

Here is what one should actually examine.

1. Whether the use cases are AI at all

This comes first because it is the cheapest thing to get wrong. Before anything else: would a rule, a database query or a lookup table do this job better? Not adequately — better.

Running that question across forty proposals inside a regulated European enterprise, roughly one in ten failed it. Those were not bad projects. Several were sensible automation that would have paid back quickly. They were automation with an AI label, and the label was buying them a governance process they did not need.

2. Whether success has been defined

This is the one that produces MIT's 95% figure — the share of generative AI pilots that delivered no measurable profit-and-loss impact across 300 disclosed deployments.

An assessment should force the sentence nobody has written: this number, currently at X, should be at Y by date Z. If the team cannot name the number, the assessment has found something more valuable than a score.

3. Whether the data is production-ready or demo-ready

Pilots run on curated subsets: cleaned, selected, owned by the team running the pilot. Production consumes real data governed by compliance rules and owned by several teams who were not consulted.

You will see 85% attributed to Gartner here. It is worth knowing what that number actually says: Gartner’s 2018 press release predicted that “through 2022, 85 percent of AI projects will deliver erroneous outcomes due to bias in data, algorithms or the teams responsible for managing them.” A forecast about wrong answers, not a measurement of failure, and the window closed in 2022. It gets quoted as a data-quality failure rate because that is a more useful shape for whoever is quoting it.

The test that does not require a statistic: did anyone prepare this data by hand? If so, the thing that was tested is not the thing that will run.

4. Where it lands in someone's day

A capability that requires leaving the tool where work happens does not get used, however good it is. This is invisible in a demo, because in a demo somebody opens the tool deliberately.

The assessment should be able to say which screen this appears on, and what the person was doing immediately before.

5. What it costs to run, not to build

A depressing share of AI business cases use sticker-price API costs with no allowance for evaluation, observability, governance, model updates, drift management, security review or human quality assurance.

When the real run cost surfaces, the return does not evaporate — it was never there. The business case contained an arithmetic error from the start.

What you should get at the end

A score is not a deliverable. What makes an assessment worth its fee is that every judgement is written down beside the reasoning that produced it, so it survives a room containing security, risk and someone whose job is to disagree with you.

A score you can audit holds up. A score you cannot is an opinion with a number attached, and it will be challenged by the first person who has a reason to.

How long it should take

Days, not months. If a readiness assessment is quoted as a quarter of work, what is being sold is the engagement rather than the answer. My own is a fixed-scope week — €1,500 for up to ten use cases, €3,500 for up to twenty — and the point of publishing the price is that the scope has to be real for the number to hold.

Common questions