The question we hear most often from clients right now is not whether to add AI to an application. It is why the AI they already added is not delivering what the demo promised. In some case, the model is not the problem.
The application underneath it was never built to support what they are now asking it to do.
This is not a niche issue.
Cloudera and Harvard Business Review Analytic Services surveyed enterprise leaders in early 2026 and found that only 7% consider their data completely ready for AI, while 73% say their organisation is actively struggling with AI data preparation. The barriers they cite are specific and fixable: 56% point to siloed data, 44% to the absence of a clear data strategy, 41% to data quality and bias issues, and 34% to regulatory constraints. None of these are model problems. They are application and infrastructure problems, and they sit squarely in the domain of how a system was designed, not which AI vendor was chosen to sit on top of it.
Getting an application genuinely ready for AI comes down to three things: the data it holds, the APIs it exposes, and the governance built around both. Skip any one of them and the AI layer will either underperform quietly or fail loudly at the worst possible moment.
AI-ready data is not simply "a lot of data." It means data that is accessible from one place, consistent in format, current enough to be useful, and clearly owned by someone who can vouch for its accuracy. Most legacy applications fail on the first point before they even get to the rest. Customer information duplicated across three systems, financial figures stored in two currencies without a conversion rule, inventory counts that update nightly instead of in real time: an AI layer built on top of this does not fix the inconsistency. It just answers questions more confidently while being wrong.
Regulatory pressure and privacy expectations make this harder to defer. Enterprise leaders in the same Cloudera and HBR research rank protecting sensitive data as their top data strategy priority at 59%, ahead of data quality at 46% and governance at 41%. That ordering matters, because it tells you where the risk actually sits: not in the model misbehaving, but in the AI layer surfacing data it was never meant to expose in the first place.
The practical fix is rarely a full data platform rebuild, and we would discourage most clients from starting there. The more useful move is to pick the specific workflow you want AI to support and trace its data dependencies end to end, before writing a line of integration code. If a support agent is meant to answer billing questions, find out exactly which system holds the authoritative billing record, whether it is updated in real time, and who is accountable for its accuracy. That scoped exercise usually surfaces the one or two data gaps that would otherwise sink the whole initiative six weeks in.
A model can reason about your business all day, but it cannot act on it without an interface. This is where the API layer becomes as important as the model itself, and where most existing systems were never designed with this use case in mind. Traditional REST APIs were built for human developers writing deliberate, well-scoped calls. An AI agent working through a multi-step task behaves differently: it explores, retries, and sometimes calls the wrong thing entirely, which means the API in front of it needs to assume less trust, not more.
The Model Context Protocol has become the common way enterprise agents connect to internal systems, and the lessons from early rollouts are worth taking seriously. Kong's research on enterprise agentic AI, drawing on Forrester's analysis, documents a telecom company whose AI agent ran up $50,000 in charges within four hours because no runtime limits existed on the third-party APIs it could call. The same research points out that GitHub's own MCP server exposes roughly 800 tools, which overwhelms an agent's context window and makes it less capable, not more. Exposing more of your API surface to an agent is not the same as making it more useful.
What works better is deliberately narrower. Build task-oriented endpoints that match what an agent actually needs to accomplish, rather than exposing your entire database schema and hoping the model figures out the right sequence of calls. Apply authentication, rate limiting, and scoped permissions per agent identity the same way you would for a junior employee with limited system access, because that is functionally what an agent is. And treat "which tools does this agent get" as a design decision made upfront, not a default setting left on because turning things off felt like extra work.
Governance gets treated as paperwork bolted onto a project near the end, which is exactly why it fails so often. Handled properly, it is closer to infrastructure: the set of rules that decide who can see what, what gets logged, and where a human needs to approve an action before it goes through. Applications that build this in from the start do not move slower because of it. They move faster later, because nobody has to stop and retrofit an audit trail after a regulator or a customer asks a question the team cannot answer.
Three things belong in the application itself rather than in a policy document sitting in a shared drive. Access control needs to operate at the level of individual data fields and tools, not just at the level of the whole application, so an AI agent handling HR queries never has a path to financial records it does not need. An audit trail needs to record what the agent read, what it decided, and why, in enough detail that the decision can be reconstructed later without guessing. And any action with real consequences, refunds, contract changes, anything touching a customer relationship, needs a human checkpoint built into the flow rather than left to the agent's judgement.
The regulatory backdrop makes this less optional than it used to be. The EU AI Act and comparable frameworks now require traceability and human oversight for higher-risk use cases specifically, which means governance decisions made at the application layer today are the difference between a straightforward compliance conversation next year and a costly one.
None of this needs to happen all at once, and trying to do it all at once is usually how these projects stall. The order that tends to work is to pick one workflow, map its data dependencies honestly, design or adapt the API around what the agent actually needs to do rather than what already exists, and build the access control and audit trail into that workflow from day one. Get that one workflow genuinely AI-ready, end to end, and you have a template the rest of the organisation can follow, rather than a demo that impressed people in a meeting and then quietly went nowhere.
This is the same territory we have worked in for over a decade, wherever the specific project sits: a legacy system that needs modernising before it can support anything new, an API layer that needs redesigning around agents rather than dashboards, or a governance model that needs building before the second and third AI use case arrives. The technology changes every year. What makes it work in production has stayed consistent the whole time.
If you are looking at an application and trying to work out whether it is genuinely ready for AI or just has a chatbot bolted onto the front of it, let's talk about how this framework applies to your product.
.jpeg)
It means the application has three things in place before AI is added: consistent, accessible data that isn't split across silos, an API layer designed for how an AI agent behaves rather than a human developer clicking through a screen, and governance controls (access rules, audit trails, human checkpoints) built into the workflow itself. Without these, the AI layer will either underperform or fail in ways that are hard to trace back to a cause.
In most cases we see, the model is not the weak link. Research from Cloudera and Harvard Business Review Analytic Services found only 7% of enterprises consider their data completely ready for AI, with siloed data, unclear data strategy, and quality issues cited as the leading barriers. An AI layer built on top of inconsistent or fragmented data will answer questions confidently while still being wrong, which is a harder problem to spot than the model simply not working.
At minimum, three things belong in the application itself: access control at the level of individual data fields and tools (not just the whole system), an audit trail that records what an agent read, did, and why, and a human checkpoint for any action with real consequences, such as refunds or contract changes. Frameworks like the EU AI Act now require traceability and oversight for higher-risk use cases, which makes this a compliance requirement as much as a design choice.
