Montro
Third-Party Risk9 min read

Third-Party Risk Management When Every Vendor Is an AI Vendor

Third-Party Risk Management When Every Vendor Is an AI Vendor
AuthorNamita Razdan
Published on24 Sept 2026

TL;DR:  Your third-party risk programme was built for a world where a vendor was a stable, known quantity you assessed once a year. That world is gone. Every vendor is quietly becoming an AI vendor - the CRM adds a feature, the payroll tool switches on an assistant, and the risk you cleared last year is not the risk running today. Traditional TPRM, built on annual questionnaires and point-in-time reviews, cannot see this. And when a vendor's AI causes harm, regulators increasingly treat it as your problem, not the vendor's.


There was a time when assessing a vendor meant understanding a fairly fixed thing. You knew what the software did, where the data went, who the company was. You sent a questionnaire, reviewed the answers, filed the result, and revisited it next year. For most of the history of third-party risk management, that was enough, because vendors did not change much between reviews.


They do now. And the reason is that the vendor you assessed has quietly become an AI vendor since you last looked.


Every vendor is becoming an AI vendor


This is the shift that breaks the old model, and it is happening almost invisibly. The tools an organisation already buys are adding AI features, month by month, without changing their name, their contract, or their place on the vendor list.


The CRM your sales team has used for years switches on an AI feature that summarises customer records. The payroll platform adds an assistant that reads employee data. The support tool turns on sentiment analysis over customer conversations.


None of these is a new vendor. Each is a vendor you already assessed - back when it was not doing any of this. The assessment on file describes a company that no longer exists in the form you documented.


So "every vendor is an AI vendor" is not a prediction. It is a description of what has already happened to the vendor list most organisations are still managing with last year's assessments.


Why the vendor you cleared is a different risk now


An AI feature is not a cosmetic update. It changes the risk of the vendor in ways the original assessment never examined.


When a vendor's tool starts using AI, new questions apply that a traditional questionnaire never asked: what the model is trained on and whether your data is part of it; how its outputs are governed and whether they could be biased or wrong in ways that affect your customers; where the inference actually happens and who else touches the data on the way.


A vendor can pass a conventional security review with full marks and still carry AI risk that the review was never designed to detect.


Make it concrete. A firm assessed its customer-support platform two years ago: a SaaS tool storing tickets and contact details, cleanly scoped, low risk, signed off. Nothing on paper has changed since - same vendor, same contract, same line on the register.


But last quarter the platform switched on an AI feature that reads every ticket to summarise sentiment and draft replies. The same tool now processes customer data through a model, makes suggestions that shape how people are treated, and may train on the conversations flowing through it.


The risk profile is transformed; the assessment is identical. Nobody was asked to look again, because from the outside nothing happened - no new vendor, no new contract, no trigger. 


This is the trap in point-in-time assessment. The review was accurate on the day it was done. It simply describes a vendor that has since changed underneath it, and nothing in an annual cycle is built to notice that the change happened.


The defence that no longer works: "we bought it from a vendor"


Here is the part that raises the stakes from operational to regulatory. When a vendor's AI causes harm, the organisation that deployed it does not get to point upstream and walk away.


Regulators increasingly hold that a vendor's AI failure is also the responsibility of the organisation that put it to use, the vendor's own liability does not carry the deployer's share away.


There is already an early signal of this: a company that merely deployed a third-party AI tool, rather than building it, has been held to account for the harm it caused, with the "we bought it from a vendor" defence failing to hold.


For a financial entity the point is sharper still, because DORA makes ICT third-party oversight an explicit, documented obligation. A vendor's AI is not a problem that stays with the vendor. It is your operational resilience, your incident exposure, and your accountability, sitting inside someone else's software.


Why annual questionnaires cannot keep up


Put the two together - vendors that change continuously, and responsibility that lands on you, and the annual questionnaire stops being a control. It becomes a record of what a vendor used to be.


The questionnaire has three problems in an AI world. It is point-in-time, so it misses every change between cycles, which is exactly when AI features arrive. It is self-reported, so it captures what the vendor chooses to declare, and a feature switched on by default may not be declared at all.


And it is built around the wrong questions, because it was designed to assess a static software product, not a system that learns, infers and processes your data in ways that shift over time. A process built on all three assumptions cannot see the risk that matters most now.


None of this means questionnaires are worthless. It means they are a starting point that has been mistaken for the whole job.


What third-party risk has to become


If the vendor changes continuously, the assessment has to as well. Third-party risk management for an AI world is less an annual event and more a live picture: knowing which of your vendors have AI features, what those features do with your data, and being alerted when a vendor you already cleared switches something on.


That rests on a foundation the old model never needed: knowing what your vendors are actually running right now, not what they told you at onboarding. You cannot assess an AI feature you do not know a vendor has turned on, and you cannot govern a dependency you have not seen.


The discovery of what vendors are actually doing is the input; the assessment, the register and the oversight are what you build on top of it.


The rest of this cluster works through the pieces that follow from this: building the DORA third-party register, the questions to ask an AI supplier, the fourth-party risk hiding below your direct vendors, and the concentration risk that appears when everyone depends on the same AI provider. They share one premise. The vendor is no longer a fixed thing you assess once. It is a moving one you have to keep watching.


Frequently asked questions


What is third-party risk management?


Montro's definition: third-party risk management (TPRM) is the process by which an organisation identifies, assesses and oversees the risks that come from the external vendors, suppliers and service providers it depends on - so that those relationships do not introduce security, compliance or operational-resilience problems. Traditionally this meant onboarding questionnaires and periodic reviews. In an AI world it has to extend to what vendors' tools are doing with data on an ongoing basis, not only what they declared at the start.


Why does AI change third-party risk management?


Because vendors are no longer static. AI features are being added to existing tools continuously - an assessed vendor can switch on a feature that trains on your data or drives decisions about your customers without becoming a new vendor or changing its contract.


Traditional TPRM, built on point-in-time questionnaires, cannot see these changes, which is why the assessment on file often describes a vendor that no longer exists in that form.


Who is responsible when a vendor's AI causes harm?


Increasingly, the organisation that deployed the tool shares the responsibility, not just the vendor that built it.


Regulators have signalled that "we bought it from a vendor" is not a sufficient defence, and for financial entities DORA makes oversight of ICT third parties an explicit, documented obligation. The practical consequence is that a vendor's AI risk becomes your accountability.


Are annual vendor questionnaires still enough?


No, though they remain a useful starting point. An annual questionnaire is point-in-time, self-reported and built around questions designed for static software - three assumptions that no longer hold when vendors add AI features continuously and may not declare them. The questionnaire captures what a vendor used to be; managing AI-era third-party risk needs a more continuous picture of what vendors are actually running now.

Namita Razdan

Namita Razdan

Co-founder

Fifteen years of financial services compliance and technology consulting across HSBC, EY, Accenture, and NTT Data - and the person in the room when regulators ask the hard questions. At Montro, she owns regulatory accuracy and sets the firm's position on EU AI Act, DORA, NIS2, and GDPR.

Blog

Read next

Explore more from our library

View all

Stay informed on EU AI governance

Monthly updates on regulatory changes, compliance trends, and platform releases

By subscribing you agree to our Terms and Conditions and Privacy Policy

Montro AI governance dashboard showing tool risk tiers