Anyone can have an AI opinion right now. The data on what's actually happening is less opinion and more verdict: MIT's Project NANDA found that roughly 95% of generative AI pilots fail to deliver measurable P&L impact. RAND's analysis of over 2,400 enterprise AI initiatives put overall failure above 80% — twice the rate of comparable IT projects without AI. This isn't a rumour circulating in industry Slack channels. It may be the best-documented trend in enterprise technology right now.

What's striking isn't that AI pilots fail. It's why. Across RAND, MIT, and Gartner's research, the model itself is rarely the cause. The failures trace back to data readiness, workflow integration, unclear ownership, and governance that was never defined — the same root causes that slowed early SOA rollouts, complicated cloud migrations, and derailed more "digital transformation" programmes than most people would like to admit, long before generative AI existed. AI hasn't introduced a new failure mode. It's running an old one at higher speed, with a great deal more money behind it.

The pilot always works. Scale is where it breaks.

A proof of concept succeeds because it's small, contained, and forgiving. Someone picks a narrow use case, feeds it clean data, and the model performs beautifully. Everyone gets excited. Then the organisation tries to scale it across a real business function, and the cracks that were invisible at pilot scale become the whole story: fragmented data sources, no single source of truth, unclear ownership, and no governance model for what happens when the system gets something wrong.

None of that is an AI problem. It's an architecture problem — the same one that shows up whenever an organisation tries to integrate a new capability without first doing the unglamorous work of defining data contracts, ownership, and system boundaries. AI adoption doesn't remove the need for that discipline. It raises the stakes for skipping it.

Anyone can have an AI opinion. Few can back it with real enterprise architecture, delivery accountability, and regulatory compliance project experience.

Governance is not the thing slowing you down

There's a common instinct to treat governance as friction — something that gets bolted on after the fact, once legal or compliance finally notices what's been built. That instinct is exactly backwards, and it's the same mistake I've watched play out in cloud migrations and system integrations for years. Governance defined early doesn't slow adoption down. It's what lets you scale with confidence instead of scaling blind and hoping nothing breaks in front of a customer or a regulator.

Treat every AI system the way you'd treat any other system boundary: define what data it can see, who is accountable when it's wrong, and what "acceptable" actually means before it's making decisions that matter. That's not bureaucracy. It's the difference between an AI initiative that survives contact with production and one that gets quietly shelved after the first embarrassing incident.

Three things architecture discipline brings to AI adoption

None of this requires slowing AI adoption to a crawl. It requires bringing the same rigor to it that already exists for every other significant system in the enterprise — because that rigor was never optional in the first place. It was just easier to skip when the thing you were adopting felt experimental rather than core to the business. That window is closing fast.

Sources