I have watched dozens of enterprise AI initiatives launch with real executive buy-in and stall within six months. The pattern is consistent enough that I can usually predict which ones will make it by the end of the first architecture review, before a line of model code has been written.
The model works on clean data. Production data is not clean.
The question nobody wants to ask first
Every AI conversation in an enterprise starts with “what model should we use?” Sometimes it starts with “should we build or buy?” It almost never starts with “what does our data actually look like?”
That is the right first question, and most teams avoid it because the answer is almost always uncomfortable. In most enterprises, data lives in silos. It has gaps, duplicates, and undocumented transformations buried in ETL pipelines that nobody fully understands. The gap between demo-quality data and production-quality data is where the majority of AI initiatives go quiet.
I spent three months in 2024 with an industrial SaaS customer who had four years of sensor telemetry, a capable engineering team, and a funded ML roadmap. Their data problem was not that the data did not exist. It was that the failures they were trying to predict were underrepresented by a factor of fifty to one, and the failure events that did exist in the logs often had gaps in the telemetry that preceded them, because the failure itself was frequently what caused the monitoring system to stop recording.
Nobody had looked at this before the ML engineering work started. By the time the problem was understood, eighteen months of engineering effort had been committed to an approach that required data that did not exist. The pivot took another three months and required bringing in two domain consultants with twenty years of industrial maintenance experience to generate synthetic training data.
The model that shipped worked. The six-month delay was avoidable.
Resistance is signal
When frontline teams push back on AI adoption, they are usually telling you something specific. Maybe the model’s recommendations do not match their domain expertise. Maybe the integration disrupts workflows that evolved for good reasons. Maybe they do not trust a system they cannot explain to their customers.
Resistance is not a change management problem. It is signal. The teams I have seen that treated it as signal, brought end users into the design process, and incorporated their feedback early built AI products that got used. The teams that treated resistance as an obstacle to manage built products that got ignored after the rollout celebration.
The most useful thing a frontline maintenance technician told us in that industrial engagement was that false positives were worse than missing a failure. A missed failure happened occasionally. A false positive required them to stop production, bring in the maintenance team, inspect the machine, find nothing, and document why they had overridden the system’s recommendation. The model had been optimized for recall. It should have been optimized for precision.
They knew this. We had not asked.
What a real business case looks like
“AI will improve efficiency” is not a business case. It is a category. “This model will reduce claim processing time from four hours to twenty minutes for sixty percent of standard cases” is a business case. It maps to specific FTEs, specific SLAs, and specific costs that someone in finance can evaluate and a VP can defend to the board.
Before building anything, define what success looks like in terms that already exist in the business. Tie the outcome to a KPI that someone in the room already reports to their manager. If you cannot draw a clear line from model output to business outcome, you are not ready to build yet.
This sounds obvious. In practice, most AI projects I have reviewed had success metrics defined by the engineering team and validated by other engineers. The business stakeholders who would actually feel the impact of the system were not in the room when the metrics were set.
Start with augmentation
The most successful enterprise AI deployments I have seen do not replace human judgment. They augment it. They surface relevant information faster. They flag anomalies that humans might miss. They handle routine cases so experts can focus on the complex ones.
This is not just a change management strategy, though it functions as one. It is also the right technical approach for systems where the cost of a wrong answer is high. A model that helps a human make a better decision is recoverable when it is wrong. A model that replaces human judgment is not.
The path from augmentation to automation, if automation is the right destination, runs through a period of demonstrably accurate augmentation. Skip that period and you will find out later, in production, in the worst possible way, that the model’s accuracy assumptions were wrong.
The infrastructure nobody budgets for
GenAI has changed the conversation about what AI can do, but not the fundamentals of deploying it reliably. You still need model versioning, drift monitoring, governance around which decisions AI can influence and which require human approval, and clear escalation paths when the model produces a result that seems wrong.
Most AI projects budget for model development. They do not budget for the operational infrastructure that makes the model trustworthy over time. That infrastructure is not glamorous. It is also the difference between an AI initiative that runs for a year and one that gets quietly decommissioned after the second quarterly review.
The organizations deploying AI sustainably are the ones treating inference cost, latency, and model accuracy as first-class operational metrics alongside the metrics they already watch. Not as a future concern. From day one.