Everyone's running an AI pilot. Almost no one is running it against honest data.
The conversation that leads to these projects isn't usually a vendor pitch. It's internal. Something works in the demo. The result looks convincing. Leadership gets excited. Scope gets approved. Then it hits production.
It drowns.
I watched this happen from the inside. In a past role, I owned the platform and the environments underneath the product. I was close enough to hear the warning directly - and watch leadership overrule it.
An enterprise software company - almost no small or mid-size clients - acquired a startup's AI planning tool right as the startup was adding natural-language processing to it. The startup had a handful of customers, and its own engineers had built the data pipeline for every one of them by hand. The data was clean because the people who understood it had touched every record in it.
The acquirer pulled its older, proven planning tool off the sales floor and pushed the new one in its place. In the demo, against that handful of small, hand-tuned accounts, it was fast and confident. Leadership loved it. Sales loved it. The c-suite was ready to ship it yesterday.
Its real customer base wasn't a handful of small accounts. It was enterprise clients running hundreds of thousands, sometimes millions, of product combinations. Against that data, runtime went from conversational to twenty or thirty minutes a query. The engineers said plainly: this isn't a hardware problem, the processing has to be rewritten to run in parallel at this scale. Leadership added servers.
That's the Clean Data Premise: the pilot doesn't fail because the model is bad. It fails because it was proven inside a world that doesn't look like the one it's about to meet.
And the fastest way to build that gap by accident is to test only against the data that already agrees with you. Honest data isn't just clean records. It's the real volume, the real combinations, the real exceptions, and the real latency the product has to survive - not just the version of reality that was easiest to hand it.
Nobody in that room was lazy or dishonest. The team that built the pilot had genuinely solved the problem, for the handful of accounts they had. Nobody asked what happens at the accounts they didn't have yet, because that question wasn't going to speed up the launch. Sales, told the old product was no longer for sale, went and sold the new one anyway - landing a large food processor and a large supplement retailer, among others, on the strength of a demo that had never met their data. Six months of sales cycle on the quiet hope the tool would somehow catch up before those contracts closed.
It didn't.
Build for the data you have, not the data you want - the same thing I said a few weeks ago about why clean data is a myth. Three places to start.
One: be the leader who asks for the ugly path. When your team shows you the happy path demo, don't approve it. Send them back to find the account that breaks it - the messiest data, the most exceptions, the customer with fifteen years of workarounds baked in. Let them fail. Then celebrate them for it. A team that gets rewarded for finding the failure will keep looking for it. A team that gets rewarded for a clean demo will stop looking the moment the demo works.
Two: build a timeline, not a hope. Match your capability roadmap to your ambition before you match it to a sales forecast. Hope is not a strategic initiative. Dedicated resources against a specific growth plan for specific market targets is. If the plan for handling enterprise scale is "we'll figure it out once we land the deal," that's not a plan. That's a deadline wearing a plan's clothes.
Three: ask the harder questions before the room does. When does this break? What are the real restrictions - data volume, complexity, latency - not the ones in the deck? What haven't we tested that we're about to find out about in front of a customer instead of in front of engineering? Those questions feel like they slow the launch down. They're the only thing standing between a pilot and a freight train.
The pilot isn't supposed to prove it works. It's supposed to show you where it breaks.