Most AI readiness assessments measure the wrong thing. They score how enthusiastic the leadership team is and how many use cases the workshop generated. Enthusiasm is not readiness. The assessment that’s worth paying for measures something colder: whether you can put a working model in front of a real user, keep it running, and know if it helped. That’s a much shorter list of questions, and most organizations flunk two or three of them without knowing it.
We’re gmware, a custom software and AI development firm in Austin, TX with engineering centers in Bangalore and Mohali, India. We run these assessments before we quote a build, and we’ve killed more of them at the assessment stage than we’ve greenlit. This is what a real one checks, what it should cost, and the cases where you should skip it and just build a pilot.
Why the assessment exists at all
The failure rate is the reason. Gartner predicted that at least 30% of generative AI projects would be abandoned after proof of concept by the end of 2025, citing poor data quality, weak risk controls, and unclear business value. A RAND study of AI projects put the share that fail to reach production above 80%, roughly double the failure rate of non-AI software projects. And McKinsey’s most recent State of AI work found that while most organizations now use AI somewhere, only a small minority are seeing real bottom-line impact.
Read those three numbers together and the pattern is clear. Getting a demo working is easy now. Getting a demo to survive contact with your actual data, your actual users, and your actual compliance team is where projects die. A readiness assessment is a cheap way to find the thing that will kill your project before you spend a build budget discovering it.
Cheap is the operative word. The assessment should cost a fraction of the build. If it doesn’t, you’re buying indecision.
The five things a real assessment scores
Skip any assessment that doesn’t produce a number against each of these. A qualitative “you seem ready” is worth nothing.
Data access and quality. This is the one that fails most often, and it fails quietly. The question is not “do you have data” (everyone does) but “can the model that needs this data reach it, and is it clean enough to trust.” A retailer we scoped had beautiful sales dashboards and assumed its data was model-ready. It wasn’t. The numbers on the dashboard were aggregated nightly from four systems that disagreed about what a “return” was. The dashboard hid the disagreement. A model would have inherited it. The assessment’s job is to trace the specific data your use case needs, from source to usable state, and score how much work that path still needs.
The target workflow. You are not adding AI to your company. You are changing one workflow. A good assessment forces you to name it: the 14-patient Tuesday afternoon where intake takes too long, the after-hours calls a plumber misses, the invoices a controller keys in by hand. If you can’t name the workflow to the level of who does what today and where it hurts, you’re not ready to automate it. You’re ready to study it.
The team that will own it. A model is not a deliverable, it’s a dependency. Someone has to watch it, retrain it when the world shifts, and decide what happens when it’s wrong. The assessment should identify that owner by name and function, not by aspiration. “We’ll hire for it later” is a real answer, but it changes the plan and the timeline, and it needs to be on the scorecard.
Governance and risk. For regulated work this is not optional, and it’s not a checkbox. If the use case touches health data, money, or hiring, the assessment has to check whether you can meet the rules that apply, log what the model did, and explain a decision when someone asks. We’ve seen otherwise-strong use cases parked here because nobody could answer “who’s accountable when the model denies a legitimate claim.” That’s a good reason to park it.
A first use case narrow enough to kill. The single best predictor of a project that ships is a first use case scoped small enough to prove or disprove in about a quarter. Broad mandates (“transform customer service with AI”) don’t fail loudly, they fail slowly and expensively. The assessment should hand you a use case with a clear success metric and a clear kill condition. If you can’t say what result would make you stop, you can’t say what result would make you continue.
What you should walk away holding
The deliverable is a scorecard and a decision, per use case. For each candidate: a score across the five areas, the specific blockers ranked by what to fix first, a rough cost and timeline if you proceed, and a plain go, no-go, or fix-this-first. That last category is the useful one. Most honest assessments come back “not yet, and here’s the shortest path to yes.”
You should also walk away owning the artifact. If the only copy of your readiness analysis lives in the consultant’s deck and evaporates when you don’t sign the build, you rented a sales pitch. Ask up front what’s yours to keep.
Here’s an opinion we’ll defend: the fix-this-first list is usually more valuable than the AI project it’s gating. Cleaning up the data path, naming an owner, and reconciling the four systems that disagree about a “return” are things that pay off whether or not you ever ship the model. The assessment that sends you to do that work first, instead of selling you a model on top of a broken foundation, is the one that was worth the fee.
What it should cost, and the two traps
Most readiness assessments are sold as a fixed-fee engagement of roughly two to six weeks, priced in the low five figures rather than billed hourly. The fixed fee matters. The deliverable is a decision, so paying by the hour rewards a slow decision.
Two traps sit on either side of a fair price. The free assessment is a funnel: it exists to justify a bigger contract, and it will rarely tell you “don’t build this,” because the whole point is to sell you the build. The six-figure, three-month assessment is the opposite failure, a way to bill for the months you spend not deciding. A genuine assessment is short, costs real but modest money, and is perfectly willing to end in no.
If you want the longer version of how this fits into a full engagement, our note on what good AI consulting actually delivers covers the roadmap and pilot stages that come after. And if you already suspect data is your blocker, why AI pilots fail goes deeper on the specific ways that plays out.
When to skip the assessment entirely
Not every project needs one, and we’ll say so before you pay us. Skip it if all three of these are true: you have exactly one obvious use case that everyone already agrees on, the data it needs is already clean and reachable, and you have someone on staff who has shipped machine learning to production before. In that situation the assessment is ceremony. Build a small pilot instead, scope it to a quarter, and let the pilot be the assessment.
The assessment earns its fee in the opposite case: several candidate use cases and no honest way to rank them, data you suspect is messier than the dashboards admit, or a regulated context where getting the governance wrong is expensive. That’s most organizations, most of the time. It’s just not all of them, and a firm that tells you that before invoicing is a firm worth talking to.
The point of the exercise is not to feel ready. It’s to find out, cheaply, whether you are, and to leave with a ranked list of what to do next either way.