What an AI readiness assessment should produce

An AI readiness assessment usually ends with a presentation. The presentation is the least useful thing it produces.

What a leadership team should keep is a small set of working documents that someone inside the organization can pick up the following week and act on. Each one should name owners, sources and costs. If the final readout leaves the team with an attractive roadmap and no idea who does what next, the money bought a briefing.

This article describes what those documents should contain and how to test them before the engagement closes. It is written for executives at mid-sized companies, nonprofits, research organizations and public agencies who are commissioning this work or have just received it.

What buyers are asking for

Published requests for proposals give a useful picture of what organizations want from this work. The Ontario Centre of Innovation ^[1] asked a consultant to identify “high-value, low-risk AI opportunities,” score them on impact, feasibility, risk and data readiness, and recommend usage guidelines with data-handling safeguards. It listed “vendor neutrality and objectivity” as a qualification and placed “building or configuring production AI systems” out of scope.

Prosper Canada ^[2] asked for a shortlist of three to five use cases, a one-to-two-year roadmap, and “a draft AI policy and governance framework,” and said the work was not expected to include a technical build or procurement of AI tools. Better Cotton ^[3] wanted “a roadmap that feels achievable rather than aspirational,” indicative cost ranges for each time horizon, and a partner who would “point out things we shouldn’t do in addition to what we should be doing.”

Those requests line up with the deliverables below. The differences between a useful assessment and a weak one show up in how specifically each deliverable is filled in.

A ranked list of use cases, with the ranking visible

Every assessment produces a list of use cases. A useful one ranks them on value, risk and data readiness, and shows its work for each score.

For each candidate, the list should record the work it affects, the people who do that work today, the evidence behind the value estimate, the consequence of a wrong output, and the data the use case depends on. A score of “high value” with no observed baseline behind it is an opinion. Ask the assessor which rows came from watching the work and which came from a workshop.

The ranking should also say why low-ranked candidates fell. “Data not ready” and “risk too high” lead to different next steps, and leadership should be able to see which applies. Our earlier piece on choosing the first operational AI use case describes the gates we apply before a candidate reaches the top of that list.

A data-readiness review that names and prices the cleanup

The readiness review is where an assessment earns its fee. In a February 2025 release, Gartner ^[4] predicted that “through 2026, organizations will abandon 60% of AI projects unsupported by AI-ready data.” The same release reported that 63% of organizations, in a July 2024 survey of 1,203 data management leaders, either lacked or were unsure whether they had the right data management practices for AI.

A general maturity score for “data” does not help anyone decide what to fund. The review should be organized by use case. For each shortlisted use case it should identify the specific tables, documents or systems involved, who owns them, what condition they are in, and what has to happen before the use case can run on them. That might mean deduplicating a contact database, scanning a shelf of paper procedures, or getting a vendor to expose an export.

Each cleanup item needs a rough cost in staff time or outside spend. Better Cotton’s request for indicative cost ranges per horizon is the right standard. A ranked use case whose data work would take a year belongs lower on the list than its value score suggests, and the leadership team should see that before it approves a pilot.

An AI use policy staff can follow

The policy is the deliverable most likely to be read by everyone in the organization, so it has to be short and concrete. It should list the AI tools staff may use, the account type for each (an enterprise tenant and a personal login carry different data terms), and the categories of information that may never be entered into any of them.

It should also say what review a person must do before AI output leaves the building or enters a record. A grant report, a regulatory filing and an internal meeting summary warrant different checks. The policy should name who approves a new tool and how long that takes, because an approval process with no timeline pushes people back to their personal accounts.

The NIST AI Risk Management Framework ^[5] and its Generative AI Profile ^[6] are reasonable reference points for the governance sections. A policy that cites them without translating them into named tools, data rules and review steps has not done the translation the organization paid for.

An inventory of the AI already in use

Most organizations are past the question of whether to start. Microsoft’s 2024 Work Trend Index ^[7], based on a survey of 31,000 people in 31 countries, reported that 78% of AI users were bringing their own AI tools to work. MIT NANDA’s State of AI in Business 2025 ^[8] report described a “shadow AI economy”: while 40% of companies said they had purchased an official LLM subscription, workers from over 90% of the companies surveyed reported regular use of personal AI tools for work.

An assessment that only looks at sanctioned projects will miss most of the actual use. The inventory should cover personal accounts, AI features switched on inside existing software, and browser extensions, along with what data each one touches. NIST’s framework calls for mechanisms to “inventory AI systems,” and the Generative AI Profile suggests recording data provenance, human oversight roles and the underlying model in each entry.

Collecting this requires asking staff directly, with a clear statement that nobody will be disciplined for what they report. The inventory is also a source of use cases. Work that people already do with personal tools is evidence of demand, and the NANDA authors note that some organizations study that usage before procuring enterprise tools.

Recommendations on what to stop or not start

A readiness assessment should say no to something. Look for explicit recommendations to end a stalled pilot, cancel a pending tool purchase, retire an unapproved integration, or leave a popular idea off the roadmap until its data exists.

The NANDA report, whose authors describe its figures as preliminary and “directionally accurate based on individual interviews,” found that just 5% of integrated AI pilots were extracting millions in value while “the vast majority remain stuck with no measurable P&L impact.” Whatever the exact share, organizations carry pilots that are not paying for themselves. NIST’s framework treats the decision of whether development or deployment “should proceed” as a normal management step, and separately calls for procedures to decommission AI systems safely.

If the assessment recommends only additions, ask the assessor directly what they would cut. For pilots already running, our day-30 pilot review gives a structure for deciding whether to expand, repair or stop.

How independent is the assessor?

An assessment that ends by recommending the assessor’s own platform, or a large build the assessor hopes to win, deserves a second reading. Ask before signing whether the firm resells or receives referral fees from any AI vendor, whether it intends to bid on the implementation, and whether the recommendations name products or describe requirements.

Public agencies have a harder rule to consider. Under New York State Finance Law §163-a ^[9], a vendor that prepares and furnishes specifications for a state agency technology procurement may not bid on that procurement as a prime vendor or subcontractor, subject to listed exceptions. New York City’s Procurement Policy Board Rules §2-05(b) ^[10] go further. A vendor that drafted any portion of the specifications may not participate in a response to the resulting solicitation unless the agency determines, with approval from the City Chief Procurement Officer, that the specifications do not favor that vendor. The rule applies whether the drafting was procured specifically, bought as general consulting or donated.

An agency that wants its assessor to build the result should settle this with procurement counsel before the assessment begins. An assessor that expects to be barred from the implementation has less reason to shape the roadmap around its own services. That is a point in its favor.

Limitations

This article is our synthesis of public procurement documents, published research and regulatory text. It does not report client results, and the deliverables described here are a working standard we use, not an industry certification. The NANDA report is a preliminary, interview-based study, and the Gartner figure is a forecast. We summarize the New York procurement rules for orientation only. Agencies outside New York operate under different rules, and none of this is legal advice.

A small organization may reasonably combine some of these documents or keep them short. The test for each one is whether a named person can act on it without calling the assessor back.

If you are scoping an assessment or reviewing one you have received, our AI advising practice produces these deliverables, and we can tell you early whether we would expect to be eligible for any implementation work that follows.