AI third-party risk management, and what it can actually be trusted with.

AI TPRM is used to describe three quite different capabilities, and the distance between them matters more than the label they share.

• Extraction — reading a SOC 2, an ISO 27001 certificate or a security policy and pulling structured facts out of it. Mature, reliable, and the least glamorous of the three. It is also where most of the hours go.
• Inference — scoring a response, flagging a contradiction between what a vendor claims and what a scan shows, or judging whether a control is adequately evidenced. Useful, and the point at which output needs checking.
• Action — sending the chase, opening the finding, booking the call, escalating the overdue remediation. The genuinely new part, and the part that needs a governance model before it needs a feature list.

Most products that added “AI” to their category name in the last two years added the first. A smaller number added the second. The third is what changes the headcount arithmetic, because it is the only one that removes work rather than speeding it up.

Ask a TPRM team where the year goes and the answer is rarely “assessing risk”. It goes on the logistics around assessing risk. That is the part third-party risk management automation addresses:

• Questionnaire pre-population. A vendor who has sent you a SOC 2 has already answered most of a standard questionnaire. Extracting those answers and pre-filling them turns a 300-question send into a much shorter review of what could not be evidenced.
• Chasing. The single largest consumer of calendar time in most programmes is waiting, then following up, then following up again. Nothing about it requires a person.
• Evidence validation. Comparing a vendor’s claims against independent observation — scan results, breach records, public filings — is mechanical, and it is the check most often skipped when the team is behind.
• Change detection. Watching a portfolio for material change between assessments is a monitoring problem, not an analytical one.
• Reporting. Board and regulatory outputs are composition tasks over data that already exists. Producing them by hand is a reporting habit, not a requirement.

What is conspicuously absent from that list: deciding whether to onboard a vendor, setting risk appetite, accepting a residual risk, and judging whether a mitigation is proportionate. Those are accountability, and accountability does not delegate to software — a point TPRM exists as a discipline to make.

The objection to automating vendor risk work is rarely that it will not work. It is that when a regulator asks who approved something, “the system” is not an answer. That objection is correct, and it is a design problem rather than a reason to stay manual.

The workable model sets autonomy per vendor, not per customer and not per feature — because the right answer genuinely differs between a critical payments provider and a low-risk design tool:

• Manual — no agent involvement. The vendor is handled the way it always was.
• Assisted — every outbound action requires explicit human approval, including individual emails. Drafting is automated; sending is not.
• Autonomous — full automation, with the human notified rather than consulted.

Set that way, the audit trail improves rather than degrades. A programme where a person forwards a chaser from their own mailbox has no record of it; a programme where an agent sends it under an autonomy mode chosen for that vendor records the mode, the action, the timestamp and the approver. The failure mode to design out is not automation — it is automation with a single global setting nobody revisited.

For which specific tasks are worth automating in the first place, see how to automate vendor risk management.

Confident extraction from the wrong document. A SOC 2 Type I read as a Type II, or a report whose period ended fourteen months ago treated as current. The extraction is accurate and the conclusion is wrong. Scope and date checks are not optional metadata.

Scoring that launders a judgement. A number attached to a vendor feels like an assessment even when it is a restatement of what the vendor said about itself. If the input is entirely self-reported, the score inherits that and adds false precision.

Automation applied to a broken register. Automating outreach to a vendor list that is missing a third of your third parties produces faster coverage of the wrong population. The inventory problem has to be solved first, and it is the problem most programmes are quietly worst at.

Notification treated as approval. Autonomous mode with alerts nobody reads is indistinguishable from unsupervised operation. The mode is only as good as the attention behind it, which is an argument for setting it deliberately per vendor rather than globally and once.

RiskXchange runs TPRM as a set of specialist agents rather than a single assistant bolted to a dashboard — a vendor-facing agent that owns outreach and onboarding, agents for document and questionnaire intelligence, agents for outside-in scanning and breach monitoring, and agents for tiering, remediation and board reporting. The division matters because it is what makes autonomy settable per vendor and per action rather than as one switch.

The honest boundary: the agents do extraction, inference and action. They do not set your risk appetite, and they do not accept risk on your behalf. See The Agency for the full structure, or Smart Assessments for the questionnaire side on its own.