When a company tells me it’s AI-ready, I’ve learned to ask for the measurements behind that claim. The answer is almost always the budget and top-level enthusiasm. Both matter, but in my experience, neither breaks a model in production. What breaks it is the data, or the fact that nobody’s quite sure who runs the system once it’s live. Hardly anyone measures either of those.
I’m the CTO at Svitla Systems, and I spend a lot of my time in the discovery phase with companies that want AI in production. At some point, we stopped taking readiness on faith. Before we price a build, we score the company on five things a roadmap takes for granted and place it in one of four maturity tiers. We call it the Svitla AI Readiness Benchmark, which is probably too grand a name for a scoring sheet and a few awkward questions.
The gap behind the roadmap
Almost every roadmap I review has AI near the top, and very little of it makes it to production. In Deloitte’s State of AI in the Enterprise 2026, only a quarter of the 3,235 leaders surveyed had moved 40% or more of their AI pilots into production. Data is a big part of the reason. In Informatica’s CDO Insights 2026 survey of 600 data leaders, 57% named data reliability as a key barrier to getting AI projects from pilot to production.
The same report found that 65% of those data leaders believe most or nearly all of their employees trust the data they’re using for AI (“believe” is doing a lot of work in that sentence!). When I ask a steering committee how it knows the company is ready, I hear about the approved budget and the CEO’s personal involvement. Neither tells you whether the customer table has one ID per customer or three.
The people who could tell you that usually sit a level or two below the room where the roadmap gets its budget. The readiness scorecard I get handed was typically filled in by the roadmap’s owner, often a transformation office or the sponsor’s team. When engineering and business leaders score it separately, the biggest gaps are around data and system ownership after launch.
Five dimensions of AI readiness
Before anyone walks me through a roadmap, I ask to see the data for the first use case, pulled from the same system the model will use in production. It sounds a little rude, but it takes minutes and tells me more than the readiness slide. If the answer is a meeting next week with another department, nobody clearly owns that data, and that’s a finding in itself. Most teams know their data exists and assume it’s owned, documented, and reachable from production, which is why data shows the biggest gap between their scores and ours.
Once we’ve seen the data, the conversation moves to plumbing. A prototype can get by on a cleaned-up extract and somebody’s API key, but a production system has to read from the ERP and write back to the CRM, and keep running when one of them goes down on a Saturday night. Then there’s the bill. I rarely see a roadmap that prices inference at production volume. In August 2026, Gartner predicted that inference costs per agentic workflow will rise more than fivefold through 2028, even as the price per token gets lower.
Governance is the one everybody agrees is important, and somehow it always ends up in phase two. Building oversight and audit trails into the first release costs far less than bolting them on after a regulator or a big customer questions an outcome. So we ask a dull but useful question: what gets logged for each decision? We want the input, the model version, the output, and any human override.
Ownership is where meetings go quiet. Ask who will own the system a year after launch, and you’ll typically find that IT assumes the business will, the business assumes IT will, and the data team assumes somebody will eventually tell them.
The last one is value, which is usually the CFO’s first question. We ask for the KPI and today’s number, agreed in writing before the first sprint.
The five dimensions, and when each gap comes to light:
| Dimension | Typical assumption | Required evidence | When the gap becomes visible |
| Data foundations | “We have ten years of history.” | An owner and production access for each source | The first time the model reads live data |
| Architecture | “It’ll plug into our systems.” | Integrations tested at volume, and inference priced at scale | Integration testing, or the first cloud bill |
| Governance | “Compliance will sign off before launch.” | Decision logs and human oversight in the first release | A regulator’s or a large customer’s question |
| Operating model | “IT will run it.” | A named owner with authority over the system | The vendor’s last week on the project |
| Value measurement | “It will save time.” | The KPI and its baseline, agreed before development | The first budget review |
Patterns in client work
Teams rate their data as ready until a model touches it, which usually happens in the first weeks of integration. The data has been fine for reporting for years, and reporting is a forgiving customer. A dashboard can average over a missing field, but a model will happily make a decision based on it. Looking back across our assessments, the use cases we’ve marked “not yet” were held back far more often by integration and ownership than by model accuracy. The model was usually fine. What was missing was everything between a working demo and a system with a named owner.
The cleanest example I have is a regional property insurer. Its AI roadmap came out of a strategy engagement, and claims triage was first on the list. Nobody had opened the data yet, so the readiness slide gave it a green check because the company had twelve years of claims history. To be fair, the pilot looked good. Trained on that history, the model agreed with senior adjusters’ routing decisions most of the time, which helped it get approved for production.
What nobody had written down was that about a quarter of new claims now came through a broker portal, a leftover from the insurer’s purchase of a smaller carrier. Those claims arrived as emails and PDFs, and a nightly job loaded them into the claims system, leaving most structured fields blank. The model read the blank fields as low severity, so water damage claims from that channel sat in the standard queue for days. The first person to notice was a broker, who asked (politely at first) why their clients were waiting twice as long as everyone else.
Then compliance asked for the reasoning behind a few of those routing decisions. Unfortunately, nobody could say which model version had scored which claim, or with which inputs. The vendor that built the pilot had rolled off, IT assumed the claims department owned the model, and the claims department assumed the opposite.
None of this required detective work. A week of live claims from every intake channel would have shown the blank fields in an afternoon.
In my experience, that’s the usual governance pattern: reacting to someone else’s question long after the big architecture decisions. ROI goes the same way. In RSM’s 2026 survey of 1,030 middle-market leaders, 54% said their AI investments had exceeded ROI expectations, and I’d love to know how many of them wrote down a baseline first. The insurer had none. When the CFO asked what triage had saved, the only honest answer was that nobody knew the cost of routing before the model.
Maturity tiers
We use four tiers (Exploring, Piloting, Scaling, and Operationalized), and most mid-market teams I meet sit in the Piloting tier. They have a working prototype, but no production path, no assigned owner, and a strategy deck that doesn’t change that. Plenty of them would tell you they’re Scaling, and I don’t blame them, because the pilot itself is good. The giveaway is usually the second use case. If it needs its own pipeline and its own approvals, the company has nothing repeatable in place.
The four tiers and the signals behind each one:
| Tier | Signals | Typical blocker | Next step |
| Exploring | Use cases on a slide, with no assessment behind them | Nobody has looked at the data | Score the five dimensions for the top two use cases |
| Piloting | A prototype on an extract, with no production path or owner | Integration and ownership | Name an owner and price the production architecture |
| Scaling | One use case in production, built as a one-off | Every new use case starts from zero | Make the first build’s pipelines and monitoring reusable |
| Operationalized | Shared data, MLOps, governance, and KPIs | Cost control and keeping governance current | Add use cases by value and retire the unprofitable ones |
Takeaways
If a CTO or CFO takes one thing from this, I hope it’s that readiness can be measured like anything else in engineering, before anyone funds the roadmap. A budget and a sponsor tell me the company wants AI, which isn’t the same as being ready for it.
I’d also give the people who see the blockers first a real say in the build order. The data engineer who knows the broker claims arrive half empty belongs in the sequencing meeting.
And it helps to be honest about your tier. A fourth use case won’t move a company from Piloting to Scaling. Fixing the weakest of the five dimensions will, and it usually costs less than the next use case on the roadmap.
If you’d like a first read on where your organization stands, take our AI readiness assessment. It’s a short questionnaire, and you’ll get your score right away. If the results raise more questions than they answer, my team is happy to run the full benchmark with your engineering and business leaders.
