Run an AI readiness assessment covering data, systems, skills, governance, and process maturity, and turn the findings into a sequenced plan rather than a score.
An AI readiness assessment determines whether an organization can deploy AI successfully before it commits budget to doing so. Its value is in identifying the specific blockers that would otherwise be discovered mid-project, usually at the point where they are most expensive.
Assessments that produce a maturity score and little else are of limited use. The output should be a sequenced list of what must be fixed and in what order.
Data readiness
Most stalled AI projects stall on data, so examine it first and in detail.
Determine whether the data required for your intended use cases exists, where it lives, who owns it, and whether it is accurate enough for the decision it will inform. Sample it rather than trusting documentation.
Check access. Data that exists but requires a quarterly manual export is not available for a production system. Note where integration work is required and how long it realistically takes.
Check classification and permissions. If you cannot determine who is allowed to see a record, you cannot build permission-aware retrieval over it, and that becomes a blocking dependency.
Check history. Supervised approaches and evaluation both need labeled examples of past decisions and outcomes. Organizations that discarded this find themselves unable to measure anything.
Systems readiness
Assess whether the systems the AI must read from and write to have usable interfaces. Documented APIs with authentication are workable; screen scraping and database access through a shared credential are warning signs.
Check whether those systems can support the load, whether they have test environments, and whether change to them requires a vendor engagement with its own timeline.
Identify authorization architecture. Agent systems must act with the requesting user's permissions, which requires a way to determine what those permissions are. Where that does not exist, it becomes a prerequisite project.
Process readiness
Document the workflow you intend to automate as it actually operates, not as the process documentation describes it. The gap between the two is where most requirements hide.
Determine whether success is measurable. If nobody can define what a correct outcome looks like, evaluation is impossible, and without evaluation the system cannot be safely operated.
Identify who owns outcomes today and who will own them afterward. Automation without a named accountable owner produces systems nobody maintains.
Skills and capacity
Distinguish the skills needed to build from those needed to operate. Many organizations can deliver a pilot and cannot sustain evaluation, monitoring, incident response, and periodic migration.
Assess honestly whether engineering capacity exists alongside existing commitments. Projects staffed from spare capacity tend to stall at the point where production hardening begins.
Include domain experts. Their time is required for evaluation design and reviewing outputs, and this is routinely omitted from plans.
Governance readiness
Check whether you have a policy on acceptable use, a decision path for approving deployments, a record of what is running, and an incident process.
Determine your regulatory position: which obligations apply to the intended use, whether any use case falls into a higher-risk category, what documentation is required, and who signs off.
Check data handling constraints, including residency, retention, and whether third-party model providers are permitted for the data classes involved.
Turning findings into a plan
Group findings into blockers, which must be resolved before any deployment; constraints, which shape design; and improvements, which raise the ceiling later.
Sequence blockers by lead time rather than difficulty. Data access negotiations and vendor contract changes take months regardless of engineering effort, so start them first even when other work seems more urgent.
Pick a first use case that fits within current constraints rather than one that requires every blocker resolved. Early delivery builds the organizational capability that harder use cases need.
Frequently asked questions
How long should an assessment take?
Two to six weeks for most organizations. Longer usually means it has become a project in itself rather than a decision input.
Who should run it?
Someone with access across data, engineering, and the business process, and enough independence to report problems plainly.
What is the most common blocker?
Data access and permissions, followed closely by the absence of a measurable definition of a correct outcome.
Should we assess before or after picking a use case?
In parallel. A candidate use case makes the assessment concrete, and the assessment often changes which use case is chosen.
Explore our software and web capabilities or discuss your AI workflow.
Written by
Moueen Togarvi
Founder & CEO at Voquarn Code, focused on product engineering, search growth, and practical AI systems.