Data quality. Governance. Workflow redesign. Integration. Clear success metrics.
Most articles on why enterprise AI underdelivers arrives at some version of that list, and nothing on it is inaccurate. But consider what the list quietly assumes.
It answers one question: how do you insert AI into a process that already exists? Ticket routing, document summarization, contract review. For those, the list is close to complete, because the hard thinking was done years ago by whoever designed the process. Nobody is debating what a support interaction is for.
Building something custom is a different activity altogether. A demand forecasting tool. A dispatch model. A redesigned planning process. Nothing has been decided in advance. Someone has to determine what the problem is, how it should be constructed, and whether the answer is right. None of that appears on the standard checklist.
Which may explain a much-quoted number: MIT’s NANDA initiative reviewed over 300 disclosed deployments and found 95 percent of enterprise generative AI pilots delivered zero measurable return. The more useful takeaway is that most activity sits on the deployment side, where the ceiling was always modest. You cannot summarize your way to a P&L impact. That is the first place value is lost: effort concentrated where the ceiling was low to begin with.
Every build has three acts. You frame the problem, you generate a solution, and you judge whether it worked. AI essentially collapsed the middle one. Work that used to take weeks now takes hours, and that change is both real and profound.
It did almost nothing to the other two phases. Framing still requires knowing which entities exist, how they should be represented, and under what conditions the representation holds true. Judgment still requires knowing what a wrong answer looks like. Both run entirely on domain knowledge, and raw generation capacity substitutes for neither.
Here is the part that often runs against intuition: cheap generation increases the demand for domain expertise rather than reducing it. When your build cycle drops from three weeks to an afternoon, you go round the feedback loop forty times instead of four. Every single loop consumes framing at the front and judgment at the back. Fast loops on a wrong frame simply help you reach a confident wrong answer much sooner.
Framing is not a static specification you write once. In practice, it gets revised repeatedly, usually after seeing what came back and realizing the question itself was slightly wrong. Three core pillars must be settled:
A non-expert can state the intent. Usually, they cannot settle the ontology or design the architecture. That is where the domain requirement stops being merely useful and becomes critical.
Take one case through all three pillars. A grid-connected battery earns revenue two ways: buying power cheaply and selling it at higher prices, and holding capacity in reserve for the system operator, who pays for the assurance that power will be there if called. A model is built to schedule both.
Intent. The model assumed the battery cleared its full offered reserve capacity nearly every hour. Revenue looked strong and the arithmetic reconciled. But a system operator buys a fixed, capped quantity of reserve, and every asset on the grid competes for a share of it. One battery does not supply the reserve of a region. Energy arbitrage survived reality check; reserve revenue did not.
Ontology. Reserve isn’t a single product. The model collapsed two distinct reserve products into one category, applying the exact same delivery duration to both. Because delivery duration dictates how much capacity actually qualifies, this core definition error produced a downstream architecture flaw — and no automated check flagged it.
Architecture. The model sold the exact same block of battery capacity into three different reserve products simultaneously. Physically impossible, but the code didn’t flag because no guardrail had been written to stop it.
In practice a capable model carries you a meaningful distance toward a sound architecture before stopping short of one, and the gap widens as the application becomes more bespoke. Published benchmarks tell the same story. Industry-standard optimization tests find that systems perform well only because the test problems have already been pre-framed by humans. At industrial scale, performance degrades sharply because the model has to handle the unassisted framing itself.
The obvious objection is that better prompting closes the gap. But the objection contains its own answer, because better prompting requires knowing what to put in the prompt in the first place.
The failure mode that truly destroys value is rarely fabrication. It is output that looks pristine, checks out internally, but is infeasible in the real world. Take those same three failures and ask a different question. Not what was wrong with each, but why nothing announced it.
None produced an error, a failed test, or an inconsistency. Each was surfaced the same way, by someone asking a question the model had no reason to ask itself.
The intent failure is the best example because it had already been caught and dismissed. The revenue numbers looked suspiciously high, so the team checked the code. The code matched a validated single-day run, so they signed off and ignored it. It took a high-level question about market structure (not a bug check) to catch it. It wasn’t a hallucination; it was a closed loop reasoning perfectly inside a flawed frame that hadn’t been challenged.
These were not isolated incidents. Across sixty-three defects logged over nine builds, thirty-five were surfaced by domain challenge and twenty-three by adversarial review designed by someone who knew where to look. Three came from benchmark comparison. Just two came from automated checking. A model can check its work. It cannot check its premises.
The natural reaction is to pair a domain expert tightly with a modeler. That helps, but it creates a bottleneck. In traditional software, a slow review loop is fine because bugs eventually crash the page or fail a test. In modeling work, nothing announces itself. A wrong answer looks just as clean and formatted as a right one. That’s why domain experts need to be able to read the model’s logic — not just describe the problem at kickoff.
So if domain knowledge is the primary constraint, what do you do when you don’t have it? It doesn’t have to sit with one person, but it does have to sit somewhere in the team, and it has to be present at the two points where it gets consumed. It can also now be cheaper to acquire than it used to be.
Take a real example: a systems optimization expert who suddenly needs to build for power grid operations. Instead of sifting through comprehensive industry literature and academic textbooks, they can use AI to build a custom, 30-day structured course with one specific directive: Explain each power grid concept through the lens of systems optimization.
Learning accelerates wherever the new material has a direct structural analogue to something already understood. Concepts that typically take weeks land in days because the underlying logic is familiar — only the industry terminology is new. You don’t need to be a lifelong industry veteran to frame problems effectively; a strong functional anchor to reason from can prove highly beneficial.
Historically a domain expert’s time went to production: building a model, running the analysis, assembling the numbers. Framing got compressed into a kickoff meeting, and judgment happened at the end, usually too late to change anything. Cheap generation frees up precious expert time, allowing teams to reallocate domain depth right where it impacts ROI:
For institutions designing technical training, the message is related but distinct. The concern that AI erodes the junior expertise pipeline is well founded. Discussed far less is that scaffolded acquisition, learning a new domain through the lens of one you already hold, builds depth faster. It is not a substitute for the first domain, but it is a cheaper route to the second and third, and worth designing for deliberately. None of the challenges outlined in this article are technology bottlenecks — they are talent allocation decisions. The fix is not a better model; its pulling domain experts out of the middle execution loop and positioning them squarely at the edges.
Ultimately, data and governance determine whether an organization is ready to build. Domain knowledge determines whether what gets built is worth having.
*Originally published at *https://www.linkedin.com/pulse/where-ai-value-won-lost-ramkumar-karuppiah-go4yc/ Where AI Value is Won and Lost was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.