VANKPA
The useful takeaway
Readiness is the ability to operate and evaluate a specific AI workflow, not simply access to a model.
An AI readiness assessment should answer a practical question: which task can the business improve responsibly, and what must be true before a pilot begins? Buying access to a model does not settle the quality of the source information, the consequences of mistakes, or the person responsible for reviewing the result.
Begin with a workflow the team can describe and measure. Document the input, the current method, the output, the user, and the next decision. If those details are unclear, use the assessment to establish them before comparing model features or asking for a broad automation proposal.
Measure business value
McKinsey's August 2026 survey of 1,719 participants reported that 80% saw improved individual productivity from AI, while 37% attributed some enterprise-level EBIT impact to it. These are self-reported, different indicators—not sequential stages of a conversion funnel. McKinsey research They reinforce the need to evaluate business outcomes separately from how useful a tool feels to an individual.
For your pilot, define the intended benefit in operational terms. It might be less time assembling a draft, more consistent classification, or faster retrieval of approved information. Decide how review effort, corrections, escalations, and tool costs will be included before describing the result as a saving.
McKinsey global AI survey · 2026
Individual usefulness and business impact differ
Check whether the knowledge is usable
Identify the information the workflow requires and who owns it. Is it current, internally consistent, accessible to the intended user, and permitted for this purpose? A model cannot resolve an unresolved business policy reliably by guessing which document should take precedence.
Create a small set of representative questions or tasks with reviewed expected outcomes. Include missing information, contradictory documents, and requests outside the intended scope. These cases help reveal whether the system can recognize uncertainty rather than merely generate convincing answers when the input is easy.
Define the boundaries
Decide which steps the AI may perform, which require approval, and which remain outside the pilot. Drafting a reply is different from sending it. Recommending a classification is different from changing an authoritative record. Make the distinction visible in the interface and enforce it in the system.
Stanford HAI's 2025 AI Index described a gap between advancing capabilities and standardized responsible-AI evaluation. Stanford HAI research Our application is to treat a model demonstration as a starting point for evaluation, not a substitute for it. Test the workflow with the permissions, documents, and failure conditions it will actually encounter.
Build the smallest reviewable pilot
Select a bounded group of users and a manageable task set. Record the baseline, evaluation criteria, ownership, cost limits, and stopping conditions. Keep a manual alternative available while the team learns which cases are suitable and which require another approach.
At review, examine successful outputs and failures together. Ask whether the workflow improved the task after verification and correction time was included. If the evidence is mixed, narrow the use case or improve the underlying information. Expansion should follow demonstrated usefulness within the chosen boundary.
- Choose a task with a clear input and outcome.
- Assign ownership of the source knowledge.
- Build representative evaluation cases before launch.
- Define permitted actions and approval points.
- Measure quality, review effort, cost, and exceptions together.
How much planning is needed?
Not necessarily. A focused assessment can establish the first useful workflow and the controls it needs. Broader planning becomes more valuable as multiple teams, sensitive information, integrations, and shared operating responsibilities enter the picture.
Evidence behind the guidance
Sources & context
Published research informs this article. VanKpa's frameworks and recommendations are practical applications; illustrative data is labeled where used.
- McKinsey — The state of AI in 2026: On the road to ROI ↗2026-08-25
Self-reported global survey: 1,719 participants in 97 nations, fielded May 4–June 8, 2026. Different indicators are not stages in one funnel.
- Stanford HAI — 2025 AI Index Report ↗2025
Historical reference on AI technical progress and responsible-AI evaluation gaps, not a current adoption estimate.
What could this change?
Bring the question, the current workflow, and the result you want to improve. We can help define a useful next step.
A worked scenario
Consider a firm exploring AI for a busy administrative team. The useful outcome is to choose a use case with usable evidence and ownership. This is a planning example, not a reported client result. The team needs a decision that can be checked against real work, rather than a feature list that looks complete during a presentation. The starting question is whether the proposed approach changes that particular task in a way the people doing it can recognize.
In this situation, tool enthusiasm hiding missing process definitions is the failure to guard against. Ask the responsible person to demonstrate an ordinary case and one difficult case using current records or safe test data. Record what they expect to happen, what actually happens, and where they need another person to intervene. Those observations establish the scope for this example; they do not justify an assumed improvement percentage or a guaranteed business result.
Decision checkpoints
| Checkpoint | Practical action | Evidence to retain |
|---|---|---|
| Prepare | Check task stability, source quality, and decision authority. | The approved scope, relevant source records, and unresolved questions. |
| Verify | Define a reviewed output and a failure boundary. | The test case, expected result, observed result, and correction needed. |
| Operate | Test a narrow sample before estimating wider benefits. | The responsible owner, completion record, and next review trigger. |
Use these checkpoints to choose a use case with usable evidence and ownership; they are a sequence of decisions, not a promise of a particular schedule. A completed document or screen is not enough if the underlying action still fails. Keep unresolved items visible and describe which ones prevent progression. The evidence can be a small test record, an approved mapping, or a reviewed example. It should be understandable to someone who was not present when the work happened.
Measure the useful result
A useful check for this topic is readiness conditions supported by evidence divided by assessed conditions. The numerator is readiness conditions supported by evidence; the denominator is assessed conditions. Define the sampling window, exclusions, and source of each count before interpreting the result. If only selected examples can be reviewed, describe them as a sample. Do not present a small reviewed group as a complete picture of the business, and do not assign a target simply because a round number looks persuasive.
The measure helps reveal whether the team can choose a use case with usable evidence and ownership, but it does not explain every cause of success or failure. Inspect the underlying cases alongside the summary. If the count changes after define a reviewed output and a failure boundary, check whether the operating result changed or the counting method changed. Retain enough context to explain the difference. When records are incomplete, state the limitation and use a direct task review instead of manufacturing a precise-looking estimate.