Most enterprise AI projects in financial services fail at the same point, and it is not the model.
They fail where the system meets an obligation: an answer that must be auditable, a decision that must be explainable to a regulator, a customer record that cannot cross a border, a transaction that must be traceable to a human authorisation. The pilot works beautifully in a sandbox and dies in the gap between demonstrated capability and permitted operation.
That gap is where the actual work is.
The problem with the general-purpose approach
The prevailing pattern is to take a general-purpose model, give it access to internal documents, and expect institutional competence to emerge. In regulated financial workflows this produces three predictable failures.
Confident wrongness on regulated content. A model asked about a product's terms will generate a plausible answer whether or not it has the correct one. In an unregulated context that is an inconvenience. In a banking context, an incorrect statement about fees, eligibility, or contractual terms is a communication the institution is answerable for.
No audit trail. "The system decided" is not a defensible position in a supervisory examination. If a workflow cannot reconstruct which inputs produced which output under which version of which policy, it cannot be deployed in a controlled process regardless of how well it performs.
Uncontrolled data movement. Sending customer data to a general-purpose endpoint is a cross-border personal-data transfer with obligations under KVKK, GDPR, and sector-specific banking secrecy rules. Teams routinely discover this after the pilot, at which point the architecture has to be rebuilt rather than adjusted.
Domain-specific deployment means the opposite of a general assistant with broad access. It means narrow scope, defined inputs, constrained outputs, and a logged path from question to answer.
Where AI is genuinely working in these environments
Stripped of the marketing, the deployments that hold up in production share a shape: high volume, structured input, tolerance for human review, and a clear correctness standard.
First-line customer support triage. Not answering customer questions autonomously — classifying and routing them. Categorisation, urgency scoring, language detection, and pre-population of a case record before it reaches a human. The correctness standard is clear, errors are cheap and visible, and the volume justifies the build.
Document extraction. Onboarding packs, statements, invoices, trade documents. Converting semi-structured documents into validated fields with a confidence score and a human review queue for anything below threshold. This is unglamorous and it is where most of the realised value sits.
Transaction monitoring support. Not replacing rules-based monitoring, which exists partly because regulators understand it — but reducing the alert burden by clustering related alerts, surfacing supporting context, and drafting the narrative an analyst would otherwise write from scratch. The analyst still decides. The time to decision falls substantially.
Internal knowledge retrieval. Staff querying policy and procedure documentation with citation-linked answers. The critical design choice is that the system must return the source passage, not a summary of it. Answers without traceable sources are unusable in a compliance context.
Communication drafting under review. Drafts for human approval, never autonomous sending. The productivity gain is real; the control is that no generated text reaches a customer without a person accepting responsibility for it.
Where it is not working
Equally worth stating, because the failures are consistent.
Autonomous credit and eligibility decisions. Explainability requirements, fairness testing obligations, and adverse-action reasoning make black-box decisioning a regulatory problem before it is a technical one.
Unsupervised customer-facing conversation on regulated products. Anything touching terms, pricing, eligibility, or advice. The failure mode is a mis-statement the institution owns.
Fully automated compliance sign-off. Compliance functions exist to place accountability with a named person. A system that removes the person removes the accountability, which is the opposite of what the function is for.
The pattern is consistent: AI performs well as preparation and poorly as final authority. Deployments that respect that boundary succeed. Deployments that cross it get pulled back after the first incident.
What deployment actually requires
Six components, in roughly this order.
Scope definition. A single workflow with a measurable current cost — handling time, error rate, backlog. "AI transformation" is not a scope. "Reduce average onboarding document processing time from eleven minutes to under four with sub-two-per-cent field error" is.
Data architecture. Where the data lives, where it may travel, where it may be processed, and how long it may be retained. This determines whether the system can be hosted at all, and it is a legal question answered before any technical selection.
Retrieval layer. Domain competence comes from grounding in the institution's own approved documentation, versioned and access-controlled, with the retrieved source returned alongside the answer.
Human-in-the-loop design. Where the review point sits, what the reviewer sees, and what happens on rejection. A review step nobody can perform quickly gets bypassed within a month.
Logging and audit. Every input, output, model version, document version, and reviewer action recorded and queryable. Build this first. Retrofitting audit logging onto a live system is significantly harder than including it from the start.
Monitoring in production. Output quality drifts as inputs change and documents update. A system nobody is measuring after month three is a system nobody knows the current accuracy of.
The measurement that matters
The metric that survives scrutiny is not model accuracy in evaluation. It is end-to-end outcome change in the live workflow: time to resolution, error rate after human review, throughput per analyst, backlog trend.
Measure the baseline before deployment. This is skipped constantly, and it makes the resulting claims unfalsifiable — which is exactly why nobody senior believes them.
Where the value shows up most reliably is in latency reduction on high-volume, low-complexity work, and in shifting skilled staff from preparation to judgement. Those are real gains. They are also less dramatic than the pitch that accompanies most enterprise AI proposals, and the gap between the two is where institutional scepticism comes from.
The compliance layer is not a phase
Data protection, auditability, and vendor risk are not a gate at the end of the project. They are inputs to the first architectural decision.
Under KVKK and GDPR, processing customer personal data through an AI system requires a lawful basis, defined retention, documented transfer mechanisms where processing crosses borders, and — for higher-risk processing — an impact assessment. Financial institutions carry additional obligations around outsourcing, operational resilience, and supervisory notification that vary by regulator.
The practical consequence: hosting location and vendor selection are compliance decisions with technical implications, not technical decisions with compliance implications. Reversing that order is the most expensive mistake available in this category of project, because it is discovered late and remedied by rebuilding.
Our compliance framework covers the data protection and AML positions we operate under, and our business units page sets out how technology deployment and regulatory advisory are combined rather than sequenced.
A reasonable starting position
For an institution evaluating this: pick one workflow with a measurable cost, establish the baseline, define the compliance envelope before selecting a vendor, build the audit log on day one, and keep a human accountable for every output that leaves the institution.
That approach produces smaller wins than the pitch decks promise. It also produces wins that survive an examination, which is the only kind worth having in this sector.
Further analysis is published under Insights. To discuss a specific workflow, contact the team.
