A language model on its own is a well-read consultant who has never seen your business. Useful for drafting, useless for deciding.
The same model connected to your data is something else: a system that can read every claim file, every contract, every support conversation, and answer questions about them in seconds. Not because it's cleverer than your people — because it reads at a scale and speed no team can match, and it never gets bored on file four thousand.
That's the whole proposition. This article covers where it produces real value, where it doesn't, what it costs, and what has to be true before any of it works.
The change is who can ask, not what can be answered
The instinct is to frame this as automation: the model does the analysis a person would have done, faster and cheaper. That framing undersells it and leads to disappointing projects.
The real change is the cost of asking a question.
In most large organisations, a question that isn't already on a dashboard is expensive. You raise a request, it queues behind other requests, an analyst writes a query, and you get an answer in a fortnight. The cost is high enough that people stop asking. Nobody tracks this, because it shows up as questions that were never raised.
When the cost of asking drops to near zero, the behaviour changes. People ask the second question, the one that follows from the first answer. They ask the awkward question they wouldn't have used an analyst's fortnight on. They explore.
The value doesn't come from the model answering a question a human would have asked. It comes from the questions nobody was going to ask.
That's harder to put in a business case, which is why most business cases for this technology understate its value while overstating the mechanism.
Three things it does that people genuinely cannot
Be precise about the advantages, because vagueness here produces bad projects.
Reading everything, not a sample. An analyst reviewing why claims are being rejected reads perhaps fifty files. A model reads all four hundred thousand. If the interesting pattern is in a subgroup that appears twice in fifty files, the human sampling method will never find it. This is the clearest and most defensible advantage.
Working across formats. The useful signal is often split between a structured field and a sentence in an unstructured document — the policy says one thing and the adjuster's note says another. Historically, connecting those required a project per question. A model reads both natively.
Never getting tired. Human review quality degrades over a long day. Model quality doesn't. For high-volume, moderately difficult review work, consistency is worth more than peak performance.
And the honest counterweight, which belongs in the same conversation:
It has no idea when it's wrong. A model produces a confident answer whether or not the underlying data supports it. It doesn't know that the field it read was deprecated in 2019, or that a region stopped reporting a metric. A human analyst carries that context; the model does not, unless you build it in.
This is why every serious deployment keeps a human in the loop for consequential decisions — not as a compliance gesture, but because the failure mode of these systems is confident wrongness rather than visible breakage.
What's actually in production
Two examples from public disclosures, both useful because they show what mature deployments look like.
A major European bank put a research assistant into production in September 2024, built on a large model with a retrieval architecture grounded in internal research and external filings. It serves thousands of analysts, handling collection, synthesis, summarisation, proofreading and drafting. The bank is now extending the approach to agents that monitor trading activity for anomalies and escalate to human compliance officers.
Note the shape: grounded in internal sources, aimed at a specific professional population, with a human decision point at the end. Not a general-purpose assistant.
A major European insurer reports over 900 AI use cases deployed, an internal platform available to employees, and an agentic system that cut spoilage claims processing from days to hours — explicitly with a human in the loop.
Note again: a specific process, a measurable before-and-after, a human checkpoint.
Neither is a chatbot. Both are narrow systems aimed at a defined workflow. That's the pattern that reaches production.
What it costs
Inference. Cost per request times volume. Cheap in a pilot, occasionally alarming at scale. Model this early — some use cases are economically fine at 100 requests a day and absurd at 100,000.
Retrieval infrastructure. Making documents findable and keeping them current. This is engineering work, priced as engineering work.
Evaluation. The line most often omitted and the one that determines whether the system survives. You need a set of known-good questions and answers, run automatically, so that when the underlying model changes — and it will, without asking you — you find out before your users do.
Data preparation. Usually the largest line. Accenture disclosed that half of its AI projects bundle data modernisation. That ratio is a reasonable planning assumption.
Ongoing operation. Someone owns this system. If the answer is "the project team", the system degrades the day the project ends.
The rule of thumb I'd use: the model is the cheapest part of the system and the least of your problems.
Four preconditions
If any of these is missing, the project will demo well and stop.
Can the system reach the data live? Not "is the data available for reporting" — can a service query it at request time, as a specific user? A great many pilots run on a hand-prepared export and discover this only at the point of production.
Can permissions be enforced at retrieval? This is the most common blocker. If your access rules live in application code rather than in the data layer, a retrieval system will happily surface documents the user was never entitled to see. It's the reason more working pilots fail security review than any other.
Is there a defined owner for the answer? When the system is wrong, who corrects it and how does the correction persist?
Is there an evaluation set? If not, you have no way to know whether a change made things better or worse. You'll be told by a customer.
How to choose the first use case
Most organisations pick the use case with the highest projected value, discover it needs infrastructure that doesn't exist, and stall.
Better criteria, in order:
- A specific professional population with a repeated task. Not "the whole company". Claims adjusters reviewing a category of claim. Analysts producing a recurring assessment.
- A measurable before. If you can't state today's cost in time or money, you won't be able to demonstrate improvement.
- A natural human checkpoint. Somewhere in the workflow a person already reviews the output. That's where the model goes — behind an existing control, not around it.
- Data in one or two systems, not nine. Save the cross-estate use case for later.
- It forces you to build one durable piece of platform. Deliberately. The first project pays for infrastructure; the third project is where the speed shows up.
The honest expectation
The first deployment will be less impressive than the demo and take longer than planned. Most of the time will go on data access, permissions and evaluation rather than anything to do with the model.
If the first one is chosen well, the second takes a fraction of the time, because the plumbing already exists. That's the actual return curve — flat then steep — and it's why organisations that judge the technology on their first project usually judge it wrong, in both directions.
Sources: MIT NANDA, "The GenAI Divide: State of AI in Business 2025"; Accenture Q1 FY2026 earnings commentary; Google Cloud and company disclosures on named production systems; Allianz public communications. All accessed 2026-07-26.
Fares runs QartMina Labs, an independent backend and AI engineering practice.