The AI implementation trap

Enterprises are spending on artificial intelligence at a scale with no precedent, and most of it is not reaching production. Gartner expects more than 40 per cent of agentic AI projects to be cancelled by the end of 2027, citing runaway cost, unclear business value and inadequate risk controls, and its analysts describe most current projects as early-stage experiments driven by hype and frequently misapplied.

A July 2026 Gartner release puts up to 234 billion dollars of enterprise application spending, roughly a fifth of all software-as-a-service spend, at risk of being reshaped by agentic AI by 2030. Nearly every large organization now has an AI agent pilot; only a small minority has one running in a live workflow with a measurable return. The money is real. The deployments, overwhelmingly, are not.

Pakistan is not watching this from a distance. Our banks, insurers, telecoms and hospitals are running the same pilots, under the same vendor pressure, with the same slide decks. The difference is that we have less capital to burn on learning the lesson the hard way. It is worth understanding, before the next budget cycle, what the lesson actually is. It is not that the models are weak. It is that we are asking them the wrong question.

Intelligence is not knowledge

The current playbook is simple: take a powerful general-purpose language model, connect it to the company's systems, wrap it in an "agent" that can retry and correct itself, and let it answer whatever the business asks. The reasoning feels sound. The model is clever, the data is there; surely it can work out how the two fit.

It cannot, because the hard part of enterprise data was never language. A bank of any age runs on dozens of databases built by different teams, in different decades, on different vendors' software. Which of forty tables is the true source for a customer? How do a core banking system from 2008 and a card platform from 2019 actually relate? What does a single row in a transaction table represent? Which columns hold the personal data the State Bank's rules protect? None of this is written anywhere a machine can read. It lives in the heads of people who have since left.

So the model guesses. It infers structure from the names of tables and columns, writes a plausible query, and returns a fluent, confident answer. The query runs. A number comes back. Nothing in the answer reveals that two tables which should never have met have just been joined. Gartner's own analysts describe most current agentic projects as hype-driven experiments, frequently misapplied, and note that many of the use cases sold as "agentic" never required an agent at all. Of the thousands of vendors claiming the label, Gartner counts roughly 130 as genuine. The industry has built ever more sophisticated ways to guess, when the problem was never a shortage of guessing.

What it costs

The first cost is visible: capital spent on pilots that never reach production, and the cloud bills of a model re-reasoning over the same database structure every time someone asks a question.

The second cost is invisible until it is expensive. A probabilistic system does not fail loudly. It produces a figure. In a board pack, a regulatory return to the State Bank, an insurer's claims reserve or a hospital's clinical report, a number built on a mis-joined table is not a glitch. It is an audit exception or a restatement, discovered months later.

The third cost is the one that stops most projects in regulated institutions. To understand a schema, these tools routinely send sample records to the model provider; to narrate an answer, they send the results.

For a Pakistani bank, sending customer data to an external AI service raises serious regulatory, confidentiality and data-governance concerns: State Bank rules impose specific conditions on cloud use and offshore outsourcing, depending on the institution and the workload. A pilot that ignores those requirements may impress in a demonstration, only to stall when it reaches compliance review.

Put the model in its place

The fix is not a better model. It is a narrower job for the one you have.

The structure of an organization’s data is not a matter of opinion. Which tables relate, which system is the authority, how records in one system correspond to records in another, where personal data lives: these are facts, and they can be measured from the data itself, deterministically, the same way every time, with an explicit grade of evidence attached.

Once that verified map exists, the language model is given it and asked to do only the two things it is genuinely good at: understand a question asked in plain business language and explain the answer in plain language. The model does not decide how the data is structured, and it does not need access to raw customer records; those responsibilities belong to a separate deterministic layer that establishes and validates the underlying facts before the model interprets a question or explains a result.

I came to this view from inside a bank. Leading digital payments at one of Pakistan's largest banks, I have spent years watching simple business questions take days to answer because the figure lived in three systems that nobody could join with confidence, and I have seen what it takes to get a technology proposal through a bank's data-governance and risk review. Any system that guesses at structure or sends customer records outside would not survive that review, and should not.

That experience is what led me to spend my evenings over the past year building a data-intelligence platform on exactly the principle above. Its validation on reference databases, with every relationship deliberately undeclared, recovered the true structure and rejected the decoys that name-based inference falls for; every result reproduces identically across runs, so an auditor can check it; and because the structural work is done once rather than re-reasoned on every question, the model's role, and its cost, shrinks to the question itself.

Most importantly, it can run entirely on an institution's own premises, with nothing sent abroad. That is the difference between an AI pilot and an AI deployment, and it is a difference Pakistani institutions can afford.

Five questions before the next line item

Before approving the next AI proposal, a chief executive or board should ask five things.

First, what does the model establish, and what does it merely explain? If it is deciding how your data is structured, it is guessing.

Second, can the answer be reproduced? Ask the same question twice. If the system cannot show the same path and the same number, it will not survive an audit.

Third, what leaves the building? Demand a written account of exactly what is sent to any external model. "Only the structure and the question" is the acceptable answer.

Fourth, does the use case need an agent at all? Many do not. Autonomy adds cost and risk; add it only where the value is clear.

Fifth, what happens when it cannot answer? A system that says "I cannot, and here is why" is safer than one that always produces a number.

The institutions that will show a return on AI in 2027, in Karachi or in New York, will not be the ones that bought the largest model. They will be the ones that stopped asking it to guess.