AI readiness assessment
Four areas decide whether a build reaches production. Only one of them is about technology.
What the report covers
4 things that decide this
- 01Readiness is decided by four things: your data, your ability to tell when a system is wrong, who operates it, and what you own at the end.
- 02The most common blocker is not model choice. It is that the data a model would need sits in three systems that disagree with each other.
- 03A team that cannot describe how it would notice a wrong answer is not ready, whatever the rest of the assessment says.
- 04Being unready is a schedule problem, not a verdict. Every gap in this report has a defined piece of work that closes it.
Most stalled projects were predictable before the first line of code
Every scoping call we run covers the same ground, because the same four things decide the outcome. We wrote them down so you can check yourself before anyone quotes you.
MIT's 2025 State of AI in Business report found a gap here. Pilots built with an outside partner were twice as likely to reach full deployment as ones built internally. Employee usage was nearly double for those tools too. Top performers moved from pilot to full implementation in about 90 days, where large enterprises took nine months or more.
That difference is rarely about engineering talent. It is about whether the four areas below were settled before the build started.
- DataDoes it exist, can you reach it, is it right
- EvaluationCould you tell if answers got worse
- OperationsWho watches it, who fixes it
- OwnershipCode, models and data at the end
A build stalls at whichever of these is weakest, not at the average of the four.
The assessment in full
One question per area, with the answers that predict what happens next. This is the whole rubric.
| Area | The question | Ready looks like | Stalls look like |
|---|---|---|---|
| Data | Where does the information a model needs live today? | One system of record, and someone can name who owns it | Three systems that disagree, reconciled by hand each month |
| Data quality | How often is that data wrong, and who finds out? | A known error rate, checked on a schedule | Nobody has measured it, because nobody has needed to |
| Evaluation | How would you know the system got worse this week? | A fixed set of real cases with known-correct answers | Someone would spot-check it, or a customer would complain |
| Operations | Who is paged when it breaks outside office hours? | A named person and an agreed service level | The team that built it, informally, until they move on |
| Ownership | What do you hold if the vendor relationship ends? | Source code, prompts, models and pipelines, in writing | Access to a hosted product and nothing underneath it |
| Scope | What is the system allowed to decide on its own? | A written boundary, with a person on the other side of it | Undecided, so it gets settled by whatever the demo did |
Data readiness is not a data volume question
Volume is not the test. The information a system will reason over has to be reachable, and correct often enough that a wrong answer stays rare and detectable.
Shift Link is the clearest version of this. A UK staffing firm was running worker compliance across spreadsheets, so eligibility could not be enforced automatically. The build joined onboarding, document validation and scheduling into one record, and only then could shifts be assigned by eligibility at all.
AI work follows the same order. If three systems hold conflicting versions of a customer, an agent reading them produces three confident answers. Fixing the record is usually the shorter job.
- 01Name the system of record for each piece of data before the build, not during it.
- 02Measure how often that record is wrong today. An unmeasured error rate becomes the model's error rate.
- 03Decide who is allowed to correct it, and how the correction reaches the system.
Fragmented records joined into one system of record
Related
- score yourself across the four areas →The same rubric as a ten-question assessment.
- why AI projects fail →The failure patterns behind the four areas.
- what to ask an AI vendor →The other side of the same conversation.
- getting a prototype into production →What the work looks like once the gaps are known.
