There is no AI-specific notification to the FCA or PRA. You notify under Principle 11 and SUP 15.3 where the regulator would reasonably expect notice, and separately where the arrangement is a material third party or outsourcing arrangement. Running the system on hardware you own does not remove the question: it changes who the third party is.
Is there an AI-specific notification to the FCA or PRA?
No. There is no AI notification form, no AI register held at the regulator, and no approval gate you pass through before switching a model on. Both regulators have taken the position that their existing frameworks apply to artificial intelligence rather than writing a separate AI rulebook, so the duties that catch an AI deployment are the ones that already caught everything else.
Firms get this wrong in both directions. Some read "no AI-specific rule" as "nothing to tell them". Others notify every internal experiment and bury their supervisor in noise. The accurate reading is narrower and more work: you decide, deployment by deployment, whether this use of this system engages Principle 11, the notification rules in SUP 15.3, or the outsourcing and third party regime. Three tests, three separate answers, one written record of how you reached them.
When does Principle 11 bite for an AI deployment?
Principle 11 in PRIN 2.1.1R requires a firm to deal with its regulators in an open and cooperative way and to disclose anything relating to the firm of which the FCA would reasonably expect notice. PRA Fundamental Rule 7 is the mirror image for dual-regulated firms. Neither mentions technology, and that is the point. The test is not "is this AI", it is "would my supervisor reasonably expect to hear about this before reading about it somewhere else".
SUP 15.3 puts specific edges on that. A firm must notify immediately where it becomes aware, or has information reasonably suggesting, that it may fail to satisfy the threshold conditions, that a matter could have a significant adverse effect on its reputation, that a matter could affect its ability to continue providing adequate services to customers with serious detriment resulting, or that it could be liable to pay significant compensation. Read those triggers with a generative system in mind. If a model sits in the path of a regulated outcome, credit decisions, suitability, financial promotions, transaction monitoring, then a failure mode that produces the same wrong answer at scale reaches at least two of those limbs.
So the practical question is placement, not novelty. A system drafting internal meeting notes is not a Principle 11 event. A system that shapes what a customer is told, what they are charged, or whether they are offered something is a change to how a regulated activity is delivered, and your supervisor will expect to know. Write down the assessment, the date, and who made it. Two firms running the same software can reach different answers and both be defensible, as long as the reasoning exists on paper before anyone asks for it.
What makes something a material third party arrangement?
Materiality is measured by impact on your ability to meet regulatory obligations and serve customers, not by contract value. The outsourcing and third party rules in SYSC 8, and the PRA's Supervisory Statement SS2/21 on outsourcing and third party risk management, point at the same factors: how critical the function is, whether the provider is substitutable, how long exit would take, whether failure would disrupt a regulated activity, how sensitive the data is, and where it is processed.
Apply that to an AI supplier and the answer often comes out higher than the invoice suggests. A vendor whose model sits inside your lending decisions, or whose platform holds customer records, can be a material arrangement on modest spend. A licence for a summarising tool used by the marketing team usually is not. The consequence of materiality is concrete: the arrangement belongs in your outsourcing register, it needs a tested exit plan, and it carries a notification expectation before you enter into it or significantly change it, not afterwards.
Keep that separate from the critical third parties regime, where His Majesty's Treasury designates a provider whose failure would threaten stability across the sector. Designation is not something you or your vendor decide, and it does not transfer your obligations. For that distinction in full, see is your AI provider a UK critical third party.
What changes under the new operational incident and third party reporting rules?
The direction of travel is settled. The FCA finalised the regime in PS26/2 on 18 March 2026, creating single FCA, PRA and Bank of England regimes for operational incident and third party reporting, and the requirements take effect on 18 March 2027. Firms must report operational incidents against defined thresholds on a standard submission, notify material third party arrangements and significant changes to them, and submit a register of those arrangements annually. Read the detail at PS26/2: Operational incident and third party reporting.
Two consequences matter now, and the date to work back from is 18 March 2027. First, you will name suppliers in a structured return rather than describe an approach in prose, so "our AI stack" will not survive the form. Second, incident reporting on a clock means you need to know when an automated process started producing wrong output, not just that it did. That is a records question before it is a compliance question, and it is the one most firms are least ready for.
Do the FCA or PRA approve or certify AI tools?
They do not. Neither regulator approves, certifies, accredits or maintains a list of permitted AI systems, and no vendor can hold an approval for a model because no such approval exists. If a supplier implies otherwise, look harder at everything else they have told you.
What is supervised is your firm: governance, controls, the outcomes customers get, and the evidence you can produce. Banks in scope of the PRA's SS1/23 on model risk management carry further expectations: identify models, validate them, own them at board level. The Consumer Duty asks whether the outcome was good, not whether the tooling was fashionable. A regulator will accept a system it has never heard of, delivering results it can see you understand. Our longer note sits at PRA model risk and AI under SS1/23.
Who signs off internally before you notify?
A named person, and the notification decision is downstream of that. Under the Senior Managers and Certification Regime, accountability sits with individuals holding senior management functions and prescribed responsibilities. Operational resilience and outsourcing commonly sit with the Chief Operations function, the regulated outcome sits with the business function that owns it, and the notification judgement sits with compliance advising both. A model is not an accountable person and never becomes one.
The question a supervisor actually asks is who decided, on what information, and inside what limits. That means recording the approval, what the approver was shown, what the system was authorised to do without further sign-off, and what it was not. In the Mickai Sovereign Intelligence Operating System, consequential actions wait for a named person to approve them, and that approval is part of the record rather than a line in someone's inbox.
Does running AI on your own hardware change what you report?
It changes who the third party is and what sits in your register. If the model runs on hardware you own, inside your own network, with no data egress, then the processing of customer data is yours. A whole category of questions about where data went, who could read it, and which jurisdiction it landed in stops applying, and your accountability story for the Information Commissioner's Office gets shorter.
What it does not do is remove a duty. Principle 11 still applies. Model risk still applies. The software supplier is still a supplier, and you still rely on them for updates, fixes and support, so the materiality assessment and the exit plan are still owed. Anyone selling deployment location as a compliance exemption is selling you a problem.
What it adds is evidence. In our system the Open Audit Record seals every consequential action under ML-DSA-65, the post-quantum signature scheme NIST published as FIPS 204 in 2024, and an auditor verifies an exported record offline with a public key, using tools that are not ours. That is tamper-evident, not tamper-proof. The distinction is worth being precise about: nothing physically stops someone altering a stored record, but an altered record fails verification, and failed verification is the property an auditor can use. When a supervisor asks what the system did on a particular date, you hand over a sealed record instead of a reconstruction.
None of this is an argument against the companies building compute or cloud. Cloud remains the right answer for plenty of work that carries no regulated data. The argument is with the assumption that a regulated firm must rent its intelligence, ship data offsite, and take a vendor's word for what happened to it. If that is the decision in front of you, start with AI for UK financial services and sovereign AI, then our note on keeping customer data in house.
Frequently asked questions
Do we need FCA permission to use AI?
No. There is no permission, authorisation or waiver that covers the use of AI, and nothing in your Part 4A permissions turns on the technology you use to deliver a regulated activity. What you do need is governance showing the deployment sits inside your existing permissions, and a notification judgement recorded under Principle 11 before the system goes near customers.
Is every AI supplier automatically a material third party?
No. Materiality depends on what the supplier does for you, not on what the software is called. If the arrangement supports a function whose failure would disrupt a regulated activity, harm customers or breach your obligations, treat it as material and put it in the register with an exit plan. A tool used for internal drafting normally is not.
What happens if we notify late?
Late notification is itself the problem. Principle 11 and PRA Fundamental Rule 7 require openness, so a delay becomes a second issue sitting on top of the first, and it costs you the benefit of having raised the matter yourself. If you find a gap, notify now, explain the timeline honestly, and show what you have changed so it cannot recur.
Do we have to tell the FCA about an internal AI pilot?
Usually not. A contained pilot with no customer data, no live customer impact and no regulated outcome sits below the Principle 11 threshold. It changes the moment real customer records enter the system, or output reaches a customer, a file or a decision. Define those boundaries in writing at the start, because that document is what later proves the pilot stayed a pilot.
Does SM&CR change who is accountable for an AI decision?
It does not change anything: it confirms that accountability stays with people. A senior manager holds the relevant prescribed responsibility whether the work was done by a team or a model, and "the system decided" is not an answer a supervisor accepts. The practical step is recording which named person approved each consequential action, and what they were shown before approving.
Related briefings
Financial services
- PRA SS2/21 and AI Outsourcing: Is Your Supplier Material?
- 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)