Sometimes. SS2/21 asks two things: is the provider performing work you would otherwise do yourself, and would weakness or failure in the service cast serious doubt on your satisfaction of the threshold conditions. An AI supplier inside an important business service usually qualifies. Software you install and run on hardware you own more often does not, but you still run the test.
What does SS2/21 mean by outsourcing?
SS2/21 treats an arrangement as outsourcing where a service provider performs a process, a service or an activity, or part of one, that the firm would otherwise perform itself. Two limbs have to hold. Someone else is doing the work, and it is work you would otherwise do. The second limb is the one people skip. If your firm has never performed the activity, has no capability to perform it and would not choose to, the arrangement is usually a purchase of something you could not make.
The statement is also clear that classification is not an exit route. It addresses third party arrangements generally, not only outsourcing, and responsibility for managing the risk a third party introduces stays with the firm whether or not the outsourcing label attaches. So the materiality question decides which specific expectations bite. It does not decide whether you have to think about the supplier at all.
Read the statement rather than a summary of it, and check the version date while you are there, because it has been updated since first publication: Outsourcing and third party risk management, SS2/21.
What makes an outsourcing material?
Materiality turns on consequence, not on contract value. The test is whether weakness or failure in the service would cast serious doubt on your continuing ability to satisfy the threshold conditions or to meet the regulator's Principles. A low cost supplier sitting inside a payment or credit decision flow can be material. A costly one supporting internal reporting may not be.
The most defensible way to run the test is from the operational resilience work you have already done. Take your important business services and the impact tolerances you set under SS1/21, walk the chain of resources behind each one, and locate the AI supplier in that chain. If a disruption at the supplier would push the service outside its impact tolerance, or if the supplier's output shapes a decision that reaches a customer, you have your answer.
Record the reasoning and not only the conclusion. Supervisors are less interested in the classification than in how you reached it, and a materiality assessment that reads as a single yes or no with no working behind it is a weak document to be holding when someone asks.
Is buying an AI product the same as outsourcing a service?
Not automatically. A licence for software you install and operate on your own estate is generally a supply arrangement rather than an outsourcing, because the provider is not performing the process. Your people run it. The supplier sold you a tool.
What pulls a licence back towards outsourcing is everything wrapped around it. Look at whether the provider holds administrative access, whether any part of the workload calls out to their infrastructure, whether model updates arrive on their schedule and change behaviour without your sign off, whether support staff can see production data, and whether you could keep operating if the provider stopped trading tomorrow. A licence with a hosted inference endpoint behind it is a hosted service with a licence stapled to the front.
The line is not clean, and pretending otherwise is how assessments get rewritten under supervisory pressure. Describe the actual arrangement rather than the commercial label on it.
Where does a generative AI supplier usually land?
Most generative AI suppliers today land on the outsourcing side, because the shape of the product puts them there. Inference runs on the provider's infrastructure. Your prompts, documents and case files cross the boundary to get there. The model version changes when the provider decides. Retention, logging and staff access to your data are set by their policy. That is a third party performing a process you could perform yourself, and it usually supports something that matters.
Two features make it harder than a conventional outsourcing. The first is substitutability. Behaviour is not portable between models, so swapping providers is a revalidation exercise rather than a migration. The second is evidence. You remain accountable for decisions the system influenced, and the record of what happened sits inside someone else's estate, in a format they control.
Where concentration is also in play, the critical third party question runs alongside your own materiality assessment rather than instead of it.
What has to go in the outsourcing register?
The register covers all outsourcing arrangements, with fuller detail for the material ones. In substance you should be able to show, per arrangement: what the function is, who the provider is as a legal entity, where the service is performed and where data is stored, whether it supports a critical or important function, the governing law, the start date with notice and renewal terms, any sub-outsourcing, the date of the last risk and materiality assessment, the person or committee accountable, and the substitutability and exit position.
Two of those fields are where AI arrangements tend to be thin. Sub-outsourcing is often opaque, because a model provider may sit on infrastructure from another party who sits on something else again, and the contract may not oblige anyone to tell you when that changes. Substitutability is usually overstated, because the alternative provider named in the register has never been tested against the same workload.
What does the PRA expect on exit and substitutability?
A plan that could actually be executed, tested well enough that you believe the timings written in it. That means separating stressed exit, where the provider fails or withdraws at short notice, from planned exit at the end of a term. It means knowing what you would run in the interim, who would do the work by hand, and how long the service could operate in a degraded state before breaching its impact tolerance.
For AI the difficult part is data and behaviour. You need your prompts, your retrieval corpus, your configuration and your decision records out in a usable form, and you need a tested estimate of how long revalidation would take on a replacement model. An exit plan that says "migrate to an alternative provider" and stops there is not a plan. The same discipline applies whether the arrangement is hosted or on premise, and it is the same test a credible cloud exit plan has to pass.
How does running AI on your own hardware change the analysis?
It changes which limb of the test fails, and it changes the evidence position. That is the design premise behind the Mickai Sovereign Intelligence Operating System. SIOS runs on hardware the firm owns, offline capable, with no data egress, so inference happens inside your own perimeter and the provider is not performing the process. On the first limb, that is a supply arrangement rather than an outsourcing in most configurations, and the register entry, the exit plan and the concentration analysis all get shorter and more honest as a result.
The evidence position moves further than the classification does. Every consequential action is sealed in an Open Audit Record under ML-DSA-65, the post-quantum signature scheme NIST published as FIPS 204 in 2024. An auditor exports a record and verifies it offline with a public key, using tools that are not ours. The record is tamper-evident, not tamper-proof: nothing physically stops a determined party altering it, but alteration makes verification fail, and that failure is exactly what an auditor is looking for. Consequential actions also wait for a named person to approve them, which is what turns a log into an accountability trail.
What does owning the hardware not remove?
Almost none of the obligation. You still owe third party risk management on the supplier, because the software, the model weights, the update path and the support relationship are all third party dependencies. You still record the arrangement, on the sensible reading that a supervisor wants to see it written down whichever category it falls in. You still need an exit plan, because a firm that cannot operate the system without vendor engineers has a dependency it has not admitted to.
What moves is the location of the risk. Data residency, provider staff access and cross-border transfer largely fall away. Software supply chain, patching, hardware capacity and internal skills come forward, and those are now yours to run. NCSC guidance on supply chain security is the right reference for the half that remains, and the wider view of what sovereign AI means for a regulated firm sets out where the boundary sits.
Mickai LTD is a UK company, Companies House 17166618, holding 104 filed UK patent applications carrying 2,340 claims. SIOS is in closed beta, with one regulated company onboarding as a design partner. None of this is an argument against the companies building the compute and cloud layer, and cloud stays the right answer for work that is not regulated. It is an argument against the assumption that a regulated firm has to rent its intelligence, ship its files offsite and take a vendor's word for what happened to them.
Frequently asked questions
Is a software licence an outsourcing?
Generally no. A licence for software your own staff install, configure and operate is a supply arrangement, because the provider is not performing the process. It can tip into outsourcing where the provider retains administrative access, hosts part of the workload, pushes behaviour-changing updates on its own schedule, or where you could not keep running without its engineers. Assess the arrangement, not the contract title.
Do we need an exit plan for an on-premise AI system?
Yes. The dependency is smaller but it is real: software, model weights, the update path, support and the skills to run it. Your plan should cover continuing to operate a frozen version without vendor help, replacing the system, and getting configuration, retrieval corpus and decision records out in a usable form with a tested revalidation estimate.
Does owning the hardware remove our third party risk obligations?
No. It removes some risks and leaves others with you. Data residency, provider staff access and cross-border transfer largely disappear. Software supply chain, patching, capacity and internal capability become yours to manage, and the vendor relationship itself remains a third party dependency that needs due diligence, contractual rights, recorded assessment and an exit position.
Where does SS2/21 sit next to the new material third party reporting rules?
SS2/21 sets the supervisory expectations for how you manage and record outsourcing and third party arrangements. Reporting and the critical third parties regime sit on top of that: they change what you must tell regulators and who they can oversee directly, not your own obligation to assess. Read the FCA's policy statement PS26/2 on operational incident and third party reporting, whose requirements take effect on 18 March 2027.
Who signs off the materiality assessment?
A named individual, with the board retaining responsibility. In most firms the operational and outsourcing risk remit sits with the Chief Operations senior management function, supported by the risk committee, with the business service owner contributing the impact analysis. Whoever signs it should be able to explain the reasoning without reading from the document, because that is what supervisors test.
Related briefings
Financial services
- Notify the FCA Before Using AI? What UK Firms Must Do
- AI and Impact Tolerances for Important Business Services
- AI Complaints Triage and Vulnerable Customers: FCA Rules
Governance, audit and oversight
- Tamper-Evident vs Immutable Log: The Real Difference
- Human on the Loop vs In the Loop: AI Oversight Explained
Part of a series of 60 briefings on deploying and governing AI in UK regulated organisations, archived with a DOI at 10.5281/zenodo.22975756.
Evaluating AI for a regulated organisation? Mickai runs on hardware you own, offline. Consequential actions wait for a named person to approve them, and what the AI did is sealed into a signed record an auditor can check without us. Applications for the invitation-only closed beta are open. Apply for the closed beta.
Written by Micky Irons, founder and chief executive of Mickai LTD.
Top comments (0)