Shine Wu is the Founding Product & Ops Lead at Composite, specializing in high-trust agentic frameworks and AI operational management.gettyMIT’s NANDA initiative studied 300 enterprise AI deployments and found that 95% of generative AI pilots produced no measurable impact on the bottom line. Gartner’s numbers point the same way: it expected roughly a third of generative AI projects to be abandoned after the proof-of-concept stage, and more recent estimates put that closer to half.What Actually BreaksThe common explanation is that the models still aren’t good enough. After helping consolidate over 100 enterprise AI projects into deployment playbooks, I think that diagnosis is both wrong and expensive. The pattern I kept seeing goes like this: a pilot scores well in a controlled demo, leadership approves it and a few months into production, the system starts getting things wrong on the company’s own data. It misreads a contract clause or conflates two customer records, sounds completely confident doing it and users stop trusting it. The model hadn’t degraded. It was never where the risk lived.The failure was in the grounding layer: the connective tissue between a capable model and a company’s proprietary data, covering semantic modeling, governed retrieval and ongoing checks on whether the output is actually correct. Benchmarks don’t capture this because a benchmark is a snapshot, and grounding is something you have to keep working on. Passing an evaluation once tells you little about whether the system will still be right in eight weeks.The Asymmetry Most Budgets Miss​Underneath those failures is an economic asymmetry that often misdirects AI investment. Model capability is largely rented and improves over time as vendors release stronger versions, allowing organizations to benefit from those advances with relatively little effort. Grounding is different. It must be built around a company's proprietary data and continuously maintained. As data changes, entity relationships shift and permissions evolve, retrieval quality and correctness can gradually deteriorate. At the same time, model providers may update the underlying model, meaning a workflow that performed well last quarter can produce different results today, even if none of your own code has changed.​Most teams end up measuring the part that takes care of itself while ignoring the part that doesn’t. They track benchmark scores and the evaluation the pilot passed at launch. The maintained correctness of the system on real data, which is what actually determines whether it survives in production, usually goes unmonitored.The asymmetry is narrower than a slogan, though. Capability and grounding aren’t perfect mirror images. A rented model’s quality improves on its own, but your use of it doesn’t: a new version can quietly regress on your specific task, and validating each upgrade is its own maintenance cost. The point isn’t that capability is free and grounding isn’t—it’s that grounding’s correctness erodes unless someone is watching, and usually no one is.Measuring The Half-LifeThe asymmetry points to a more useful way to judge readiness. Instead of asking how high a system scored on a one-time evaluation, ask how long it stays correct: how many weeks it holds its accuracy as the data drifts and the model changes under it, before someone has to step in. I have started thinking about this as a correctness half-life, and treating readiness as a maintained rate rather than a single score.None of the underlying discipline is new: Site-reliability engineers have used error budgets and service-level objectives for over a decade, and ML teams have monitored data and concept drift for almost as long. What is underused is applying that same monitoring to correctness over proprietary, governed data. It changes the exit criterion for a pilot. “We hit 94% in the demo” describes a moment; “we held 94% for eight weeks through a version change, some injected drift and a red-team pass” describes something you can run a business on, and only the second should clear a system for production.This matches what I saw building earlier systems. On one product, we saw a probabilistic model paired with a deterministic execution layer, because a single model, however capable, can’t be trusted on its own for work that has to be exactly right. A lot of teams still treat that deterministic layer as a guardrail attached to a smart model, when it is closer to the structure that holds the whole system to a reliability target over time. When organizations underinvest in that layer, systems often look impressive in demonstrations but struggle to maintain reliability in production. The model is usually not the point of failure; the breakdown occurs in the mechanisms that keep outputs accurate, governed and consistent over time. In many cases, that is what the 95% figure is really capturing.​None of this depends on waiting for better models. The pilots that stall usually fail on something more ordinary and more fixable: an answer that was right at launch and quietly stopped being right, with no one assigned to catch it. Closing that gap takes a named owner and a habit of measuring how long the system stays correct, not a larger model. Teams that build that habit are the ones whose AI will likely be doing useful work a year in, long after the launch numbers have gone stale.​​Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?