Every regulated UK institution that takes AI seriously eventually reaches the same meeting. A team has a workload that touches customer, client or policyholder data, the obvious route is a hosted model API, and someone in risk asks whether the data should leave the building at all. The question sounds technical. It is really a question about who carries which obligation, and the honest answer depends on the workload rather than on the model.
The scale of the decision is no longer hypothetical. The Bank of England and FCA survey of AI in UK financial services, published in November 2024, found that 75% of responding firms were already using AI, against 58% in the 2022 survey, and that a third of all AI use cases were third-party implementations, up from 17%. The same survey found that, of firms using or planning to use AI, 46% reported only partial understanding of the AI technologies they use against 34% reporting complete understanding, and it attributed the gap largely to third-party models.
This guide is about the deployment decision itself: what self-hosted AI actually means, why self-hosting does not take a model out of UK outsourcing and third-party rules, which workloads genuinely need it, and what a firm takes on when it runs its own model. It is written for the CISO, the Head of Technology and the Head of Operational Resilience at a bank, insurer or fund manager. It deliberately cedes two neighbouring questions. Law firm confidentiality and the SRA's expectations belong to our guide to AI for UK law firms, and continuous DORA resilience evidence for banking groups belongs to our guide to AI for UK banks.
This guide is shipped by the team behind DATS, the five-stage system DILR.AI uses to place AI inside enterprise workflows. Or see the AI operating model, which sets governance, RACI and lifecycle for each placement.
What does self-hosted AI actually mean for a regulated UK institution?
Self-hosted AI, for a regulated UK institution, means the model runs on infrastructure the firm controls rather than behind a provider's public API. In practice it is a spectrum of four deployment patterns, not a single switch: a public hosted API, a hosted API under enterprise terms, a model inside the firm's own cloud tenancy, and a model on the firm's own hardware. Each pattern moves different obligations onto the firm.
The four patterns differ in who operates the model, who can see the prompts and outputs, and who you depend on when something breaks. A public hosted API puts operation, logging and capacity with the model provider. A hosted API under enterprise terms keeps the provider as operator but adds contractual controls such as regional processing and retention terms. A model deployed into the firm's own cloud tenancy moves operation to the firm while the hyperscaler still supplies the compute. A model on the firm's own hardware moves almost everything inside, including the capacity planning and the failure modes. Choosing the pattern per workload is a placement decision, and the AI operating model design then sets the governance, RACI and lifecycle around it.
In our experience, the word "private" gets attached to all of the last three patterns, which is why the term is close to useless in a risk committee. The useful question is narrower: for this workload, which of the four patterns meets the data, resilience and accountability bar, at the lowest operating burden? Answering that question is a placement decision, and it is the same decision our enterprise AI consulting guide describes for keeping sensitive data inside the perimeter. This guide goes one level down, into the rules and the running costs that sit behind the choice.
Does self-hosting take an AI model out of outsourcing and third-party rules?
Self-hosting does not take an AI model out of UK outsourcing and third-party rules. It changes which third parties sit in the chain, but rarely removes them. A model deployed in a firm's cloud tenancy still depends on the hyperscaler, the open-weight model publisher and the inference software. Under PRA expectations, the board stays accountable for every one of those arrangements, whichever pattern the firm chooses.
The clearest statement of the principle sits in the PRA's supervisory statement on outsourcing and third party risk management (SS2/21), which sets the PRA's expectations of UK banks, building societies and PRA-designated investment firms, Solvency II insurers, and UK branches of overseas banks and insurers. It does not apply to FCA-only firms such as most fund managers, which look to the FCA guidance described below. Paragraph 4.3 of the current version reads: "Boards and senior management, in particular individuals performing SMFs, cannot outsource their responsibilities. Firms that enter into outsourcing arrangements remain fully accountable for complying with all their regulatory obligations."
Two further points in SS2/21 matter for a self-hosting decision. First, paragraph 2.7 says certain requirements apply to all third party arrangements, irrespective of whether they count as outsourcing, so a GPU cloud contract or a model licence does not escape scrutiny by being labelled something other than outsourcing. Second, the statement recognises that firms and service providers share responsibilities differently depending on the service model, naming Infrastructure as a Service, Platform as a Service and Software as a Service. Moving from a hosted API, which behaves like software as a service, to a model in your own tenancy, which runs on infrastructure as a service, does not end the shared-responsibility question. It moves the line, and more of the stack lands on your side of it, which is why our approach to placing AI maps the whole stack before a pattern is chosen.
For FCA-regulated firms more broadly, the longer-standing reference point is FG16/5, the FCA's guidance on outsourcing to the cloud and other third party IT, first published in July 2016 and last updated on 18 March 2026. The practical reading is the same: self-hosting is a choice about where risk sits, not a way to make third-party risk management disappear. A firm that presents a self-hosted deployment to its board as "no third party involved" has usually left the hyperscaler and the model publisher off the register. Our guide to AI in UK banking covers the resilience-evidence side of the same problem.
How concentrated is AI supply in UK financial services?
AI supply in UK financial services is concentrated in a small number of providers. The Bank of England and FCA 2024 survey asked firms to name their top three third-party providers for cloud, models and data, and the three most-named providers accounted for 73% of cloud mentions, 44% of model mentions and 33% of data mentions. Concentration at that level makes third-party AI dependencies a resilience question in their own right.
The same survey reported that respondents expect the largest increase in systemic risk over the next three years to come from critical third-party dependencies. That expectation is the background to the UK's critical third parties regime, set out by the PRA, FCA and Bank of England in the critical third parties policy statement of November 2024. Its rules took effect from 1 January 2025, but they bind only a provider that HM Treasury has designated as a critical third party, and only from the date its designation order comes into force. At publication, HM Treasury had not designated any. If your register already names a likely candidate, talk to us about the register before the deployment pattern is fixed.
The regime is easy to misread from the buyer's side. It does not transfer any obligation from a bank or insurer to a designated provider. The policy statement is explicit that, once a provider is designated, firms remain accountable and responsible for managing the risks in their arrangements with it. In our view, concentration cuts both ways for the deployment decision. A hosted API from a dominant provider adds to an exposure the sector already shares. A self-hosted model deployed in a firm's cloud tenancy may run on one of the same dominant clouds, so the cloud exposure can remain even when the model exposure falls.
What changes on 18 March 2027 for material third-party AI arrangements?
From 18 March 2027, new FCA, PRA and Bank of England rules require in-scope UK financial firms to notify the FCA, or their own regulator, of new or significantly changed material third-party arrangements, and to keep a register of them and submit it annually. Depending on how the definition applies, a hosted model API or a GPU cloud contract supporting an important service may fall within it, so the pattern a firm picks now can shape what it reports.
The FCA's policy statement PS26/2 on operational incident and third party reporting, published on 18 March 2026, creates single FCA, PRA and Bank regimes that apply from 18 March 2027. The third-party reporting rules define a material third party arrangement and apply to firms including enhanced-scope SM&CR firms, banks, designated investment firms, building societies and Solvency II firms. The FCA's own explanation names AI directly, noting that third parties are now supplying their services by means of technological innovations like AI. The PRA has published an updated version of SS2/21, following its own policy statement PS7/26, which takes effect on the same date.
For the self-hosting decision this has a practical consequence. In our view, whichever pattern a firm chooses, it should assess each component behind a material service against the new definition: the model provider for a hosted API, and the cloud provider and model publisher for a self-hosted one. A firm that designs its register and its exit plans alongside the deployment, rather than after it, does the work once. In DATS, governance, RACI and lifecycle are designed at the operating model stage, which our comparison of an AI operating model against a centre of excellence explains in more depth.
Groups with EU entities face a parallel regime. DORA, the EU Digital Operational Resilience Act, has applied to in-scope EU financial entities since 17 January 2025, according to the European Banking Authority. It binds those EU entities, not a purely domestic UK firm. The detail of what DORA asks of a banking group sits in our banking guide, and the voice-specific reading sits in our post on DORA and operational resilience for voice AI.
Which workloads genuinely need a self-hosted model?
A workload genuinely needs a self-hosted model when the data cannot lawfully or contractually leave the firm's infrastructure, when the model supports an important business service that must survive a provider failure, or when the firm must explain the model in more depth than a hosted provider will allow. Most other workloads are better served by a governed hosted API, because self-hosting adds operating burden without reducing the risk that matters.
In our view, five questions place a workload, and they work best asked in order, because the first one that gives a firm answer usually decides the pattern.
- Can this data leave the firm at all? Contractual confidentiality, client instructions and data classification sometimes rule out a hosted API before any other question is asked. Where the answer is no, the choice is between the firm's own tenancy and its own hardware. The law-firm version of this question sits in our law firm AI guide.
- Does the workload support an important business service? Under the FCA and PRA operational resilience rules in PS21/3, Building operational resilience, firms had until 31 March 2025 to show they could stay within impact tolerances for each important business service. A model inside such a service needs a tested answer to "what happens when the provider is down".
- How hard would exit be? A workload whose prompts, evaluations and outputs are tightly coupled to one provider's proprietary model is harder to move than one built against a portable interface.
- How much explanation will supervisors and customers need? The survey gap between partial and complete understanding is, by the Bank and FCA's own reading, largely a third-party model problem. A self-hosted model with a firm-owned evaluation harness gives the firm more to show.
- What volume and latency does it run at? A steady, high-volume workload is the case where a firm-operated model is most likely to justify its running cost. A spiky, low-volume one rarely is.
Once a pattern is chosen, our AI execution office is the embedded delivery engagement that ships production software inside the client's stack, and the code is the client's.
A worked reading makes the test concrete. A claims-notes summariser at an insurer that handles health information often fails question one and lands in the firm's own tenancy. A marketing-copy assistant with no customer data passes question one, supports no important business service, and belongs on a governed hosted API. A fraud-triage model inside a payments service may pass question one under contract but fail question two, which pushes it towards a firm-operated pattern with a documented exit route. The insurance-specific detail sits in our guide to AI for UK insurers.
What does a firm take on when it runs its own model?
A firm that runs its own model takes on the provider's job. It becomes responsible for patching and securing the serving stack, for evaluating every model update before release, for capacity and failover, for logging that supervisors can rely on, and for an exit plan of its own. Self-hosting buys control of the data path at the price of these standing obligations, which do not end when the project does.
The security obligations come first. The NCSC's Guidelines for secure AI system development, published on 27 November 2023, are written for providers of any system that uses AI, whether built from scratch or on tools and services provided by others. They are guidance rather than law and bind no one. When a firm self-hosts, though, it is the provider in the sense the guidelines describe, so secure design, secure deployment and secure operation become its own engineering work rather than a line in a supplier questionnaire.
The model lifecycle comes second. Hosted providers retire and replace models on their own timetable, and a firm on a hosted API inherits that timetable. A self-hosting firm sets its own, which is an advantage only if it runs the evaluation work: a fixed test set, a regression gate before any new weights reach production, and records of what changed and why. Without that, self-hosting simply freezes an ageing model in place. The six productised enterprise AI solutions DILR.AI runs include evaluation and observability for production agents.
Capacity and failover come third. A hosted API absorbs demand spikes for you. A self-hosted model needs reserved compute, a second region or site if it supports an important business service, and a tested fallback, which may itself be a hosted API kept warm for a stressed exit. The cost of that capacity is real, and this guide gives no figures for it because they depend on the model size, the volume and the contract. What it can say is that the capacity question belongs in the business case before the build, not after the first outage.
The exit plan comes last and is the one most often missing. SS2/21 chapter 10 expects a documented exit strategy that covers both a stressed exit, such as a provider failure or insolvency, and a non-stressed exit for commercial, performance or strategic reasons. For a self-hosted model the provider in question might be the cloud, the model publisher or the inference software vendor, and the plan should name each. Our post on embedded AI delivery teams against project consulting covers who should own this work once the build team leaves.
How should the board and senior managers govern the choice?
The board and senior managers should govern the self-hosting choice as an accountability decision, not a technology preference. Under the Senior Managers and Certification Regime a named individual already owns the relevant risk, and PRA expectations say that responsibility cannot be outsourced. The board's job is to see the deployment pattern for each material workload, the third parties behind it, and the exit route.
The Bank of England and FCA survey found that the governance scaffolding already exists at most firms using AI: 84% of them reported an accountable person for their AI framework. What is often missing is the link between that accountable person and the deployment pattern of each workload. SS2/21 paragraph 5.24 expects firms to periodically assess their overall reliance on third parties and their concentration risk or vendor lock-in, and that assessment is hard to do honestly if the AI estate is recorded by use case rather than by provider and pattern.
A simple discipline closes the gap. For each material AI workload, the board pack should show the pattern chosen from the four, the named third parties behind it, the important business service it supports if any, the last evaluation result, and the exit route. That one page turns a recurring argument about "private AI" into a reviewable decision. It also maps directly onto the register PS26/2 will ask for from March 2027. Our guide to board-level AI investment decisions covers the wider board agenda, and the compliance category of this blog collects the regulator-led detail.
What is the best way to deploy a private LLM in a UK bank, insurer or fund in 2026?
The best way to deploy a private LLM in a UK bank, insurer or fund in 2026 is workload by workload, not estate-wide. Self-host only the workloads whose data cannot leave the firm or whose service must survive a provider failure, and run the rest on governed hosted APIs. The right partner depends on the scale of the change, and for some firms a large consultancy is the better buy.
In our view, four criteria separate the options: whether the partner places workloads rather than selling one pattern, whether it writes production code inside your stack, whether it leaves the firm owning the evaluations and runbooks, and whether it designs the register and exit plans alongside the build. In our view, measured that way, a hosted enterprise API from a hyperscaler such as Azure, AWS or Google Cloud wins for low-materiality workloads where the data may leave the firm, because it is the fastest route and the provider absorbs the operating burden. DILR.AI's own services page says a large consultancy is the better buy when you need hundreds of people working across many countries at once, or when the work is mostly organisation redesign or change management beyond AI, which is where firms such as Accenture, Deloitte and PwC compete. Our review of the Faculty AI alternative after the Accenture deal covers how that market is shifting.
DATS fits a narrower case, and DILR.AI says so on its own services page: hire DILR when your data cannot leave your own infrastructure and the models have to run on your hardware, and when you want to own the code, prompts and evaluations and run them yourself afterwards. The live services page describes the private-model pattern as small models that run on your hardware when data cannot go to a hosted API. That is a placement, not a default, and the diagnostic exists to decide where it applies. Read about our approach to placing AI inside enterprise systems, or talk to the team about a specific workload.
Is an open-weight model automatically safer than a hosted API?
An open-weight model is not automatically safer than a hosted API. Running open weights inside the firm keeps prompts and outputs on infrastructure the firm controls, which addresses data movement, but the firm then owns patching, evaluation, capacity and exit for that model. A badly operated self-hosted model can carry more operational risk than a well-governed hosted API, so safety depends on the operating discipline around it.
The deciding factor is usually evidence rather than architecture. A firm that can show its evaluation results, its change records and its tested exit route for a self-hosted model is in a stronger position with a supervisor than one that can only say the model runs on its own servers. The same evidence standard applies to a hosted API, where the firm leans on the provider's assurances and its own contract terms instead.
Can a firm start on a hosted API and move to self-hosting later?
A firm can start on a hosted API and move to self-hosting later, provided the move is designed in from the start. That means building against a portable interface, keeping prompts and evaluation sets under the firm's own control, and writing the non-stressed exit into the plan from day one. Without those steps, the later move becomes a rebuild rather than a migration.
The test set is the asset that makes the move possible. If the firm owns a fixed set of representative inputs and expected outputs, it can run a candidate self-hosted model against the same set and show the result before switching any traffic. That evidence-first discipline is how we would run the move, and the DATS methodology shows how the five stages are structured, turning a deployment change into a measured decision rather than a leap.
The broader adoption picture explains why so many firms are at this point now. McKinsey's State of AI survey of November 2025 found that 88% of organisations use AI in at least one function, while 33% have it in production. In our view, the deployment pattern is one of the decisions that sits between those two figures, and it is cheaper to take deliberately than to inherit. For the data-residency side of the same choice in voice workloads, see our guide to EU data residency for enterprise voice AI, and for the wealth and private-markets reading see our guide to AI for wealth, PE and hedge funds.
Want to place this in your own firm? See how DATS runs AI consulting as a five-stage system, read our enterprise AI consulting guide, browse the productised enterprise AI solutions, or read about who builds DATS and how the team works.
Decide which workloads stay inside.
30-min scoping call · No deck · Confidential. We will tell you where AI belongs in your estate, and where it does not.
Written by the Dilr.ai engineering team, practitioners who ship enterprise AI in production. Follow us on LinkedIn for shipping notes, or subscribe via the RSS feed.