Most AI readiness assessments measure enthusiasm. They ask whether leadership is committed, whether the team has explored use cases, whether a budget exists. All of that can be true while the first project still fails in month three, because none of it touches the conditions that actually determine whether a system reaches production and stays there.
Readiness is not a mood or a maturity score. It is a set of concrete conditions that either hold or do not. When they hold, a project has a path to production. When one is missing, the project usually still starts - and then stalls at exactly the point the missing condition would have covered.
This article sets out five conditions worth checking before committing budget, how to test each one honestly, and what to do when the answer is no.
1. The Decision Is Named
The first condition is not a use case. It is a decision that a specific person currently makes, that the system is meant to improve.
"Improve customer experience with AI" is not a decision. "Reduce the time an agent spends finding the correct warranty clause before answering" is. The second names who acts, what they do today, and what would change.
Test it by asking three questions and requiring specific answers. Who makes this decision now? What information do they use? What does a good outcome look like in numbers they already track?
If the answer to the third question is a metric nobody currently measures, that is not disqualifying, but it becomes the first task. You cannot demonstrate improvement against a baseline that does not exist, and projects without a baseline get judged on impressions.
The failure this prevents is the most common one in enterprise AI: a technically successful system that nobody can prove was worth building, quietly defunded at the next budget cycle.
If the answer is no: run a short scoping exercise before anything else. This is cheap and it is the highest-leverage work available.
2. The Data Is Reachable, Not Merely Existing
Teams routinely confirm that data exists and treat the question as settled. Existing and reachable are different states.
Data is reachable when you can get it programmatically, at the frequency the system needs, with the fields the task requires, and with permission to use it for this purpose.
Test it by trying. Pull a real sample through the actual access path you would use in production - not an export a colleague prepared, which hides every problem you are trying to find. A week spent doing this reveals more than a month of meetings about data strategy.
Watch for the specific blockers that appear at this step. The system holding the data has no API and the vendor charges for one. The fields exist but half are free text where a category was expected. The records are complete from 2024 onward and inconsistent before that. Access requires approval from a team with no reason to prioritize you. Legal has not established whether this data can be used for this purpose.
None of these are fatal. All of them extend the timeline, and all are cheaper to discover now than after a build has started.
If the answer is no: the data work is the project. Sequence it explicitly rather than treating it as preparation, and expect it to take longer than the model work.
3. Someone Owns the Outcome
A project needs someone who can make decisions during the build and who remains responsible after launch. These are frequently different people, and the second one is frequently unnamed.
During the build, the owner resolves the questions that stop progress: is this edge case in scope, is this error rate acceptable, do we ship without the third integration. Without that person, decisions escalate to a committee and the timeline doubles.
After launch, the owner is who notices when quality degrades and who has authority to act on it. This is the condition most often missing, and its absence is invisible until the system has been running for a quarter and nobody can say whether it is still working.
Test it by asking one question: when this system produces a wrong result in six months, who finds out, and what are they empowered to do? If the answer is "the vendor" or "the project team, but that project will have ended," the system is unowned.
If the answer is no: do not start. An unowned system degrades until a customer notices, and the reputational cost of that usually exceeds the value of the automation.
4. There Is a Path Into Production
A model that cannot reach the workflow it is meant to improve is an experiment. The path has to exist before the model does.
That path has four parts, and each can independently block deployment. The system it must connect to needs an interface that accepts what you will send. Users need somewhere to see the output inside the tool they already use rather than in a separate dashboard nobody opens. Someone needs the authority to change the process the system is meant to alter. And the organization needs a way to deploy and update software of this kind at all.
The fourth is easy to overlook in companies where most software is bought rather than built. If there is no deployment pipeline, no environment, and no on-call arrangement, then production is not a technical step at the end - it is an organizational capability that has to be created.
Test it by describing precisely where the output lands and who acts on it. If the honest description is "we will produce a report and share it," the project is analysis, not a production system - which may be fine, but it should be planned and budgeted as analysis.
If the answer is no: scope the first project around a path that already exists, even if it is a less interesting use case. A smaller system that reaches users beats a better one that does not.
5. The Failure Mode Is Acceptable
Every AI system will be wrong sometimes. Readiness includes knowing what happens then.
Ask what the cost of a wrong output is, and whether it differs by direction. A missed defect and an unnecessary rejection do not cost the same. A wrongly approved refund and a wrongly declined one do not cost the same. That asymmetry sets the operating threshold, and it is a business decision that has to be made by someone with authority - not a default left at 0.5 by whoever wrote the code.
Then ask what catches the error. Human review before the action, an audit sample afterwards, a downstream check, or nothing. "Nothing" is an answer, and it is acceptable for genuinely low-stakes outputs - but it should be a decision rather than an oversight.
Finally, ask what happens when the system is unavailable. If the previous manual process has been dismantled, the fallback is that work stops. That is a real operational risk and it belongs in the plan.
If the answer is no: narrow the scope until it is yes. A system that acts only on high-confidence cases and routes the rest to a human is usually deployable when a fully automated version is not.
Reading the Result
These conditions are not a score to average. They behave more like a chain.
If all five hold, the project has a credible path and the remaining risk is execution.
If one is missing, that gap is the first piece of work, and it should be sequenced before the build rather than in parallel with it. Building while the data access question is unresolved produces a system that demos on a sample and cannot run on reality.
If three or more are missing, the honest conclusion is that this is not yet an AI project. It is an operations and data project that will later enable one. Teams that accept this and spend a quarter on the foundation reach production faster than teams that start building and discover the same gaps one at a time.
The pattern worth avoiding is the one where readiness is assessed as a percentage, the number comes out at seventy, and everyone treats that as a passing grade. Seventy percent ready with no named owner is not seventy percent of a working system. It is a system that will run unattended until it quietly stops being right.