What Should an AI Readiness Assessment Actually Cover?

Before a business commits real money to an AI project, somebody should be able to answer three questions: what exactly will the AI decide or produce, does the data it needs actually exist in usable form, and what will it cost to run at real volume rather than in a demo? An AI readiness assessment exists to answer those questions before the build starts, when changing the answer is cheap.

Here is the definition worth holding onto: an AI readiness assessment is a structured, fixed-scope examination of your use cases, data, systems, governance and team that ends in a decision you can act on: build now, fix specific things first, or do not build this. If what you are being offered cannot end in "do not build this", it is a sales document, not an assessment.

Why readiness is usually about data and access, not the model

The models are the mature part of the stack. In the projects we see, what actually stalls an AI initiative is almost never model capability. It is that the facts the AI needs live in six places and disagree with each other, that the CRM has years of duplicate and half-complete records, that nobody can say who is allowed to approve an AI-drafted email, or that the pilot's running costs were never projected at production volume.

Every one of those problems is discoverable in advance. That is the entire argument for assessing before building: the failure causes are visible up front to anyone who goes looking with engineering discipline.

The six areas a proper assessment covers

1. Use cases, sized and testable

Not "we want AI in customer service" but a specific, bounded statement per use case: what the AI decides or produces, at what volume, with what an error costs and how you would detect one. A good assessor pushes vague ambitions into testable shape and is willing to conclude that a fashionable use case is a poor first project. The strongest first candidates are usually high-volume, interpretive and reversible; the worst are rare, high-stakes and irreversible.

2. Data readiness

Where do the facts live, and are they true? An AI system answering from your CRM inherits every duplicate, stale field and inconsistent convention in it. The assessment should examine the actual records the use case depends on (not a schema diagram) and state plainly what needs cleaning, deduplicating or connecting before the AI's answers can be trusted. "Fix the data first" is one of the most valuable verdicts an assessment can return, and one a model vendor will rarely give you.

3. Systems and integration surface

Which systems must the AI read from and write to, what do their APIs actually expose, and what breaks if one of them is down? If the answer to "how does the AI get the order status?" is "someone pastes it in", there is engineering to do before there is AI to deploy. This is also where live-data questions get settled: information that changes minute to minute must come from the system of record at the moment of asking, not from a copy made last week.

4. Security, governance and sign-off

Three concrete artefacts, not a policy essay. First, a data classification: what may enter an AI system freely, what needs review, what must never leave your estate. Second, named decision rights: who approves what the AI sends, changes or spends, and at what threshold. Third, the audit answer: when someone asks why the AI did something in March, what record will exist? If your organisation already has unsanctioned AI use in the wild, an assessment should surface that too; our guide to running a shadow AI audit covers that exercise on its own.

5. Cost at production volume

A pilot handling 30 requests a week tells you nothing about the bill at 3,000. The assessment should model realistic volumes against realistic per-request costs, including the expensive tail (long documents, retries, peak periods), and state the monthly figure the business is signing up to before anyone signs up to it. If the number only works with the cheapest model on the happy path, the business case is not real yet.

6. Team readiness and adoption

Who will actually use this, what changes in their working day, and who owns the system after launch? Tools that are technically sound still fail commercially when they are handed to a team that was never brought along. The assessment should name an internal owner and a realistic adoption plan, because software with no owner decays, and AI systems decay faster than most.

What the output should look like

A verdict per use case (build, fix first, or drop), a prioritised list of the fixes with effort attached, an architecture sketch for anything worth building, and the cost model. Short enough to be read, specific enough to act on. The test of a good assessment is that it would still be useful if you hired a different firm to do the build, because it describes your business's readiness rather than the assessor's product. It should also map where each use case sits on the wider journey; our AI transformation ladder describes those stages in more detail.

Red flags that you are reading a pitch, not an assessment

• Every use case comes back green. Real businesses have at least one "not yet" in them.
• Nobody technical examined your systems. A questionnaire about your ambitions is not an engineering assessment of your estate.
• The data section is missing or generic. If nobody looked at actual records, nobody knows whether your data can support the use case.
• There is no running-cost model. An assessment that prices the build but not the operation has answered the easier half of the question.
• The recommendation is always the assessor's biggest product. The verdict should sometimes be small, boring and cheap.

Where to start

We run this as a fixed-scope diagnostic: the AI and Data Readiness Assessment on our AI implementation page. Most of our clients start there rather than with a build, because the assessment either de-risks the project or saves them from it, and both outcomes pay for the exercise. If you would rather begin with a broader conversation about where AI fits in your systems, book a diagnostic and an engineer will look at it with you.

Frequently asked questions

What is an AI readiness assessment?

A structured, fixed-scope examination of your use cases, data quality, system access, governance and team, ending in an actionable verdict for each use case: build now, fix specific things first, or do not build. It exists to surface the problems that sink AI projects while they are still cheap to fix.

How is it different from a data audit?

A data audit is one component. A readiness assessment also covers use-case feasibility, integration surface, security and sign-off design, running costs at production volume, and adoption. Clean data feeding an unworkable use case is still an unworkable project.

Do we need one if we have already run a pilot?

Usually yes, because a pilot answers "can this work on a small scale with someone nursing it?" and an assessment answers "will this work at real volume, at a knowable cost, with real governance?" Those are different questions, and the gap between them is where most AI projects fail.

What should it conclude?

A decision you can act on. If every use case is approved and the recommendation is the assessor's flagship product, you have been sold to, not assessed. Expect at least one "fix this first" and be suspicious of a clean sheet.

John Kelleher is a Claude Certified Architect (Foundations and Professional) and leads SpotDev, a Claude Registered Partner and OpenAI Select Partner.