A CEO asked me last spring what I expected to find in his infrastructure assessment. Not after. Before.
I told him three things. His customer data would disagree with itself the moment two systems had to describe the same person. Nobody in his building would be able to name the owner of his integration layer. And when the AI project finished, he would have no way to prove whether it worked.
He pushed back on all three. He was proud of the data. He had a competent IT director. He had dashboards.
Six weeks later we walked the findings. All three were true.
The assessment is the same every time. That is the point.
Every Summit AI engagement starts the same way, with an infrastructure assessment. It is the entry point, not an upsell. Across 25 active clients — manufacturers, professional services firms, distributors, a couple of regional healthcare groups — I have run the same diagnostic against wildly different businesses.
The businesses have nothing in common. The failures do.
That surprised me at first. I spent 20 years at IBM and Kyndryl assuming failure modes scaled with complexity, that a Fortune 500 would break in more exotic ways than a 40-person distributor. It does not work that way. The Fortune 500 breaks in the same three places. It just costs more when it does, and takes longer to notice.
Here is what breaks, in the order I find it.
Break one: your data is clean until two systems have to agree
Every client tells me their data is good. Most of them are right, inside any single system.
The CRM is clean. The ERP is clean. The billing platform is clean. Each one has an internal logic that holds up under audit, and the person who owns it can defend it.
The break happens at the seam. Ask three systems to describe the same customer and you get three answers, because each system was built to answer a different question. Sales defines a customer as a signed contract. Finance defines a customer as an entity that pays an invoice. Operations defines a customer as a shipping address.
None of those definitions is wrong. They are just not the same definition, and no human ever needed them to be. A person reading a report does the reconciliation in their head without noticing they are doing it.
A model cannot do that. Feed it three definitions and it will confidently produce an answer built on whichever one it saw most. You will not catch the error, because the output will look reasonable. That is the dangerous part — bad data produces obviously bad output, but inconsistent data produces plausible output that is quietly wrong.
I have never once found a client where this was not true. Not once in 25.
Break two: nobody owns the integration layer
The second finding is organizational, and it is the one that makes rooms go quiet.
I ask a simple question in the assessment: who owns the connection between these two systems? Not who built it. Who owns it today, this quarter, by name.
The answer is almost always a story instead of a name. A contractor built it four years ago. The person who maintained it moved to another team. IT owns the servers, the application team owns the app, and the thing in between belongs to whoever notices it broke.
This is not incompetence. It is how integration work gets funded. Integrations are built inside projects, and projects end. Ownership was never assigned because the project charter did not have a line for it.
You can run a business this way for a decade. Integrations are patient. They fail loudly and infrequently, somebody fixes them, everyone moves on.
AI changes the math. An agent that reaches across four systems creates a dependency on every one of those connections holding, continuously, without a human watching. Unowned infrastructure under an AI workload does not fail loudly and infrequently. It fails quietly and constantly, and the failure shows up as a model that gives worse answers than it did last month.
Ask the question in your own building this week. Who owns the integration layer, by name? If you get a story, you have found break two.
Break three: you cannot prove it worked
The third one is the most expensive, and almost nobody sees it as a problem until the money is already spent.
Most companies have dashboards. Dashboards are not instrumentation. A dashboard reports what a system says about itself. Instrumentation measures what actually happened, independently, over time, in a way you can compare against a baseline.
Without a baseline, you cannot prove value. You will spend six figures, the team will feel faster, and when the CFO asks what changed you will have a feeling and a vendor’s slide.
The most useful thing I ever learned about this came from an engagement that had nothing to do with AI. Years ago on a Fortune 500 account at Kyndryl, the client asked for a 25% improvement in incident detection. We delivered 38%, and more than $2 million in documented savings followed.
Here is the part people find strange. We never got meaningfully better at fixing things. We got better at knowing things were broken. The money did not come from remediation. It came from instrumentation, and it showed up downstream, in outages that never became outages.
That engagement is the reason break three sits in every assessment I run. The clients who can measure their baseline before an AI project can defend the investment afterward. The clients who cannot will be arguing about anecdotes in a budget meeting eighteen months from now, and they will lose, because anecdotes always lose to spreadsheets.
Why it is always these three
There is a reason the list does not change.
None of these are AI problems. All three exist before any model is introduced, and all three were survivable before AI because a human was quietly absorbing the failure. A person reconciled the customer definitions. A person noticed the integration broke. A person had a sense of whether things were better.
AI removes the human from the middle of the process. That is the entire value proposition. But the human was also the compensating control, and nobody wrote that down anywhere.
So when a company adds AI to an operation with these three conditions present, it does not fail because the model is bad. It fails because the model faithfully executed on a foundation that was being held together by people who are no longer in the loop.
This is why I do not run AI readiness assessments. I run infrastructure assessments. The AI part is rarely where the risk is.
What this costs when you find it late
The cheapest version of this discovery is a six-week assessment before you commit budget.
The expensive version is discovering it in month seven of an implementation, after contracts are signed, after a team has been reorganized around a workflow that does not work, and after an executive has told the board a date.
I have watched a client spend into the mid six figures before anyone asked who owned the integration layer. The model was fine. The vendor was fine. The project died anyway, and the postmortem blamed the vendor, which meant they were set up to repeat it.
Finding out late does not just cost money. It costs you the correct explanation, and without that you will make the same decision again with a different logo on the invoice.
Do this in the next two weeks
You do not need me to start. Three questions, asked out loud, of the people who would know.
Ask three systems to define your most important business entity — customer, order, patient, whatever it is for you — and see whether the definitions match. Ask who owns your integration layer by name. Ask what your baseline is for the process you want AI to improve, and whether you could produce that number today without building anything.
If you get three clean answers, you are in better shape than any of the 25 businesses I currently work with, and you should move forward with confidence.
If you get three stories instead, you have your roadmap. And you found it for the price of three conversations instead of the price of a failed implementation.
So which is it in your building — three answers, or three stories? Tell me, because from where I sit the score is 25 to nothing, and I would like to be proven wrong.
Ready to find your three? The infrastructure assessment is where every Summit AI engagement starts, and it is designed to be run before you commit budget, not after. Start the conversation here.
Want to see what the full engagement looks like? Assessment, strategy, implementation, and adoption — sequenced so the foundation work happens first. See our services.
Want the rest of the pattern? I write about what actually breaks in AI projects, with real numbers, twice a month. Read the blog.