In one paragraph

Searches for "AI third-party risk management" are two questions wearing one phrase. One asks how to manage the risk of the AI you buy, which the third-party governance hub and its due diligence article answer. The other asks what AI can do for the practice of third-party risk management itself, TPRM, and that is this page. The short answer is that AI is good at the labour of TPRM and no good at its judgement. It reads evidence faster than an analyst, pre-fills questionnaires, watches a supplier population for change, and finds concentrations that a vendor count hides. It cannot accept a risk, decide that a supplier is critical, or own an exit decision, and the model doing the reading is itself a supplier with the same questions hanging over it. Firms that get value from it automate the first list, keep the second firmly human, and put the tool on their own AI inventory.

Two questions that share a search box

"AI third-party risk" has meant the risk of AI for most of the last three years: what model sits under the product you bought, whether your data trains it, whether a rebrand or a fine-tune has made you the provider under EU AI Act Article 25. Those questions are not going away and the hub covers them. But the search data for this site shows a second population arriving in numbers, people typing "AI for TPRM" and "AI-powered TPRM" and, increasingly, "agentic TPRM". They are not asking what to fear. They are asking what to buy, and whether it works.

It is worth separating the two because the answers pull in different directions. The first question makes a firm more cautious about AI suppliers. The second invites it to put an AI supplier at the centre of the function that is supposed to be cautious about AI suppliers. Neither answer is wrong. They just need to be held at the same time.

What the tools actually do

Strip the marketing and five things are real, in roughly the order they pay back.

Evidence extraction. A SOC 2 report, an ISO 27001 certificate with its statement of applicability, a penetration test summary and a cyber insurance schedule are documents written for a human reader. A language model can pull the scope, the exceptions, the control gaps and the dates out of them into structured fields in minutes, work that an analyst does by reading. This is the least glamorous use and the most reliable, because the source is in front of the model and the output can be checked against it.

Questionnaire pre-population. Standard questionnaires such as the Shared Assessments SIG and the Cloud Security Alliance CAIQ run to hundreds of questions, and most of the answers already exist in the evidence a supplier has provided or in last year's response. Mapping evidence to questions and drafting answers for review is the use case the tool vendors lead with, and it works, with a caveat that comes later: a growing share of the questionnaires your suppliers return were themselves drafted by a model.

Continuous monitoring. The annual review has always been the weak point of TPRM; ISACA's May 2026 piece on questionnaire fatigue makes the point that an assessment describes a supplier on the day it was completed and nothing afterwards. Monitoring feeds, breach disclosures, regulatory actions, adverse news, leadership changes, certificate expiries and financial signals, are not new, but a model that reads them against your supplier list and your criticality tiers turns a noisy feed into a short list that an analyst can act on.

Concentration analysis. A supplier register counts contracts. The risk lives in the dependency graph underneath: which of your suppliers run on the same cloud, call the same foundation model, or sub-contract to the same processor. The Bank of England and FCA's 2024 survey found that the top three providers accounted for 73% of reported cloud providers, 44% of model providers and 33% of data providers across UK financial services, with model-provider concentration up from 18% two years earlier. Building that graph by hand is the work nobody finishes; building it from contracts, sub-processor lists and DORA registers of information is a tractable extraction problem. This is the use case most likely to tell a firm something it did not already know.

Drafting. Risk narratives, assessment summaries, remediation letters and board reporting are written from structured findings. A model drafts them and an analyst edits. Modest, and real.

Notice what is missing. None of the five is a decision. Each produces something a person then judges.

Where it fails

The failure modes are specific and worth naming, because the tool vendors will not.

Scored rationale that was never in the evidence. When a model assigns a risk rating and writes a justification, the justification is fluent whether or not it is grounded. A rating whose reasoning cannot be traced line by line to a document the supplier actually provided is an opinion presented as a finding, and it will be read as a finding by everyone downstream. The control is unglamorous: every score traces to evidence, or it is not a score.

Automation bias at the point that matters. The reason to automate triage is that analysts are overloaded. The consequence is that they will accept the triage. Automation bias is strongest exactly where a tool is most useful, in the high-volume, low-attention part of the work, and the supplier that was wrongly tiered as low-risk at onboarding is the one nobody looks at again.

Contradictions that need a lawyer, not a parser. A supplier's contract says data stays in the UK; their sub-processor list includes a US analytics vendor; their questionnaire says "not applicable". A model will flag the inconsistency, which is useful. It will not resolve it, and a tool that silently picks one answer has made a legal determination without anyone noticing.

AI answering AI. Suppliers now use the same tools to answer questionnaires that you use to assess them. The result is a loop in which a model drafts the questions, a model drafts the answers, and a model scores the answers, and the only thing that has definitely happened is that everyone's questionnaire fatigue has been relieved. The assurance content of that loop is whatever evidence sits behind it. Contextual assurance, which ISACA's authors propose as the alternative to questionnaire volume, means asking fewer questions that are specific to what the supplier does for you and verifying the answers against artefacts, and it is the only version of questionnaire automation that survives both sides automating.

The confidentiality of the evidence. Supplier evidence is confidential to the supplier, often under NDA, and frequently contains the detail of someone else's security weaknesses. Sending it to a hosted model is a data transfer that your own third-party policy would normally scrutinise. Where the model runs, what it retains and whether your supplier's evidence can surface in someone else's answer are due diligence questions, and they are questions about the TPRM tool.

The recursion. Which brings the awkward point. The model inside a TPRM platform is a third-party AI dependency, usually a foundation model from one of the three or four providers that the Bank of England's concentration figures describe. Your TPRM function now depends on a supplier that your TPRM function should be assessing, and that supplier's model will change version under you without notice unless the contract says otherwise. The tool goes on the AI inventory, gets the third-party model due diligence it would give anyone else, and has an exit plan. There is nothing paradoxical about this. It is simply easy to forget.

Agentic TPRM

The next pitch is agents: software that does not merely draft the questionnaire but sends it, chases the supplier, reads the reply, requests the missing evidence, re-scores, and raises a ticket, with a person reviewing exceptions. For high-volume, low-criticality suppliers this is where the labour saving actually is, and the firms that get there will have materially better coverage of the long tail than the ones running annual reviews on a sample.

Two cautions. The first is that an agentic system acting on your behalf towards suppliers is a communication channel with your name on it; what it asks for, what it promises and what it records are yours. The second is that agents that read supplier-provided documents are reading untrusted input, and prompt injection through a questionnaire response or an uploaded policy is not hypothetical. A supplier's PDF that persuades your agent to mark a gap as closed is a new kind of fraud with an old motive. Keep the agent's authority to the low tiers, keep human review on anything that changes a rating or a tier, and log every action it takes as if a person had taken it, because for regulatory purposes one did.

What the regulators have and have not changed

Nothing in the outsourcing and third-party rules that UK and EU firms work to was written with AI-assisted TPRM in mind, and nothing in them prevents it. The PRA's SS2/21 and the FCA's equivalent expect a firm to know its material third parties, assess them proportionately, manage concentration and be able to exit. DORA requires a register of information on every ICT third-party arrangement and reporting of it to supervisors. The critical third parties regime designates the providers whose failure would threaten the system. In none of these does it matter whether a person or a model read the SOC 2; it matters that the firm can show it was read, by whom, and what was concluded.

So the regulatory effect of AI in TPRM runs in one direction: the firm remains accountable for the output and gains a new system to be accountable for. The 2024 Bank of England survey already found a third of AI use cases in UK financial services to be third-party implementations, and third-party dependency the risk firms expected to grow fastest. A TPRM function running on a hosted model is one more of those use cases, and the sensible move is to treat it that way rather than as a category of its own.

The one place AI materially helps with the regulatory ask is completeness. Registers of information, sub-outsourcing chains and the dependency map behind the concentration question are documents that have been late and partial in most firms because they are assembled by hand from contracts nobody has read end to end. That is an extraction problem. A function that has used a model to build its register from the source documents, with a person signing off the result, is in a better position with its supervisor than one that has not, and that is a defensible reason to start.

What to evidence

For a governance function, five things.

  • The TPRM tool's own entry on the AI inventory, with the model provider underneath it named, the data handling for supplier evidence recorded, and the same due diligence any other AI supplier would receive.
  • A traceability rule: every rating, tier or finding the tool produces links to the evidence that produced it, and a rating that cannot be traced is not used.
  • The boundary, written down, between what the tool does alone, what it drafts for review, and what only a person can do. Risk acceptance, criticality, and exit decisions sit in the third group whatever the tool can technically do.
  • The reviewer's record, so that "a person reviewed it" is something that can be shown, not something that is asserted.
  • A periodic check that the tool is not drifting: a sample of its tiering and extraction decisions re-performed by hand, with the error rate reported.

The third-party governance hub covers the mirror-image question, the risk of the AI you buy, and the AI TPRM glossary entry holds both senses of the phrase for anyone who arrived by the wrong one. The recurring failure here is not that firms automate too much. It is that they automate the reading and then stop reading, and the function that was supposed to notice when a supplier changed becomes the function that has stopped noticing.