The gap between a board asking about AI and a project that actually ships is almost never the AI. It is the data underneath it, and the manual processes nobody has fixed yet. This is how to work out where you stand before spending anything.
AI readiness is an honest assessment of whether your data, processes and security can support AI before you spend on it. Most organizations are not ready, and knowing precisely why is worth more than a pilot that quietly dies.
Data, automation and reporting are not preconditions in theory, they are the whole project in practice. Skip them and the model gets built on top of the same mess, just faster and harder to audit.
The fourth piece is the one teams skip on purpose: a specific decision the answer would actually change, not a category of work to point AI at.
One version of the numbers the business runs on, with the conflicts between source systems resolved rather than papered over.
Automation is the step before AI, not a lesser version of it. Organizations that skip it end up applying AI to a broken process and scaling the breakage.
If the report is stale when it is opened, no model on top of it will help.
Specific, measurable, and attached to something the business would do differently. Not a category like customer service.
If you cannot answer most of these, that is the finding. It is more useful than a pilot that fails eighteen months from now.
If the answer involves more than three systems and a person who reconciles them, that reconciliation is the first problem.
Conflicting definitions break AI faster than bad models do.
If the answer is measured in weeks, decisions are being made on history.
Compliance reporting, approvals, document and procedure management. These automate before anything else.
If an auditor asked, could you show the lineage? Regulated environments need this before AI, not after.
If the honest answer is nobody, that role has to exist before tooling helps.
A use case that does not change a decision is a demonstration, not a project.
This determines how much validation the use case needs, and whether it belongs anywhere near a regulated process.
We start with a conversation about what leadership needs to see and cannot currently get, then work backwards into the systems. Frequently the conclusion is that an automation and data project delivers most of the value, and the AI layer becomes a smaller and much safer piece of work than expected. We would rather tell you that early than sell you the larger version.
Two published engagements where the automation and data work came first:
Bring us your answers to the eight questions. We will tell you honestly what has to be true before AI is worth spending on.
Start an AI readiness conversationData quality and accessibility, process documentation, security and access control, and which business cases are actually worth pursuing.
Usually because the data underneath was not ready, or the process being automated was never documented. The tool is rarely the problem.
Not necessarily. Part of the value of an assessment is ruling things out and pointing you toward automation that pays back sooner.
The assessment itself is short. Remediation depends on what it finds, and it is sequenced so the earliest work carries its own payback.
A prioritized roadmap, then implementation of the highest-value use cases with the data foundation actually in place underneath them.