Every major financial services firm in the UK now has access to the same AI models. GPT-4, Claude, Gemini. The capability is available to anyone through an API call, often within an afternoon. Yet the distance between organisations that have deployed AI in production and those still running pilots is growing. The gap is not a technology gap. It is an infrastructure gap, a data gap, and an organisational gap. The firms that understand this stop asking which model to use and start asking whether they are ready to use any of them.
The document problem nobody wants to talk about
Financial services runs on documents. Loan applications, KYC packs, investment memos, compliance reports, contracts, audit trails. Most of this content exists as PDFs, scanned images, or files produced by legacy systems that were never designed to be machine-readable. Before any AI system can extract useful information from this content, someone has to solve the ingestion problem: how to reliably turn unstructured documents into structured data that a model can actually work with. This is unglamorous infrastructure work. It involves document classification, OCR quality improvement, handling variable layouts, and building extraction pipelines that are accurate enough to trust in a regulated context. Most organisations planning their first serious AI deployment have not yet done this work, and they discover its difficulty only after selecting a model and building a prototype that hits a wall at the data layer.
Data quality is harder than data quantity
Firms in financial services almost always have more data than they need. The problem is that the data is inconsistent across systems, siloed by department or product line, and lacks the lineage records that make AI-generated outputs auditable. A model prompted on incomplete or inconsistent data does not refuse to answer. It produces confident output that is subtly wrong in ways that are difficult to detect before something goes wrong in a live environment. In regulated industries, that risk is not acceptable. Addressing data quality is not an AI project. It is a data governance project that has to run before the AI project, and organisations consistently underestimate how long it takes. Firms that skip this step discover it later, at much greater cost.
Compliance and explainability are architecture decisions, not final steps
The FCA and PRA have been clear that AI-assisted decisions in regulated contexts must be explainable and auditable. A firm cannot tell a regulator that a credit decision was informed by a model it does not fully understand. This changes the architecture of any AI system deployed in financial services. Consumer AI tools built without explainability in mind cannot be adapted to meet this requirement at the end of a project. Organisations that treat compliance as a final review step rather than an architecture constraint reach the end of a deployment project and face a choice between expensive rework and abandoning the project. The ones that design for explainability from the start tend to reach production. The ones that do not tend to run a very sophisticated pilot.
AI does not integrate itself
The output of an AI system is only valuable in proportion to its connection to the downstream processes that need to act on it. A model that extracts data from a loan application and delivers it to a spreadsheet rather than the core banking system creates manual work rather than replacing it. Most financial services organisations have complex, legacy-heavy system architectures where integration work is slow and expensive. Deployment projects that underestimate this consistently take two or three times longer than planned. The integration work, not the model, is almost always the critical path. Teams that plan the integration timeline accurately at the start make different decisions about scope and sequencing, and those decisions are usually what separates projects that ship from projects that are always six weeks from completion.
Nobody has decided who owns what the AI gets wrong
This is the least technical and most consequential blocker. When an AI system produces an incorrect output in a financial services context, there needs to be a clear answer to the question of who is responsible, what happens next, and what the audit trail shows. Organisations that deploy AI without defining ownership and escalation processes discover this problem the first time something goes wrong. Without clear accountability, teams revert to manual processes regardless of how accurate the AI system is overall. Pilots fail not because the model performed poorly, but because the organisation had not decided how to absorb what it produced. Defining this before go-live is not an internal process question. It is a deployment prerequisite.
What the firms that deploy successfully do differently
The pattern across successful AI deployments in UK financial services is consistent. They solve the document infrastructure and data quality problem before selecting a model. They treat integration as a first-class project requirement rather than a later phase. They define compliance and explainability requirements at the architecture stage. And they assign internal ownership to AI outputs before anything goes live. None of this is the interesting part of building AI systems. It is slower than running a pilot and considerably slower than most organisations initially plan for. But it is the only path that leads to AI operating in production rather than circling in proof-of-concept indefinitely. The models are not the bottleneck. They have not been for some time.