An AI vendor risk management program for banks and fintechs is the monitoring layer that runs after the onboarding assessment closes: a defined cadence of quarterly, trigger-based, and annual reviews that catch model version changes, sub-processor swaps, and drift in a vendor’s AI behavior before an examiner or a board asks about them. A one-time due-diligence questionnaire tells a risk committee what a vendor looked like on the day it was onboarded. It says nothing about what the vendor looks like six months later, and AI vendors change faster than the traditional SaaS vendors the third-party risk program was originally built to monitor. The program below turns that gap into a defined, ownable process.
This guide is for the Chief Risk Officer, the head of third-party or vendor risk, and the Chief Compliance Officer at a bank, fintech, or insurer who already runs an AI vendor due-diligence process and now needs the monitoring layer that keeps a register current between assessments. If your team has not yet built the onboarding checklist, start with AI vendor risk assessment checklist for banks and fintechs; this guide picks up where that one ends.
Want to put this into practice? Use our AI vendor due-diligence questionnaire.
Why a one-time assessment is not a program
A traditional vendor risk program treats onboarding diligence as the heavy lift and monitoring as a lighter annual check-in, because a payroll vendor or a document-management platform mostly behaves the same way this year as last. AI vendors break that assumption in a specific, structural way: the product a bank contracted with can change underneath the contract, without a new SOW, a new signature, or in many cases any notice at all.
Three changes happen most often, and each one can move a vendor out of the risk tier it was onboarded under.
- Model version updates. The vendor retrains, fine-tunes, or upgrades the underlying model. Output behavior, accuracy, and failure modes can all shift, and a model validated at onboarding is not necessarily the model running today.
- Sub-processor and foundation-model swaps. A vendor built on a licensed foundation model can change which model sits behind its product, sometimes for cost or performance reasons that have nothing to do with your relationship, and rarely with proactive notice.
- New data flows. A vendor adds a feature that sends more of your data through the model, enables a new integration, or starts using customer interactions to fine-tune its own product, none of which was true at the diligence stage.
None of these require a new contract to happen, and none of them show up in an annual renewal review if that review only re-runs the original onboarding questionnaire. A program built to catch them needs a monitoring cadence, not just a diligence gate.
A monitoring cadence: quarterly, trigger-based, and annual
The most defensible AI vendor risk management programs run three layers of review at once, each catching a different kind of change. Running only the annual layer, which is what most third-party risk programs inherited from pre-AI vendor management, misses the changes that happen between renewal dates.
| Cadence | What it catches | Who runs it | Typical evidence |
|---|---|---|---|
| Quarterly output-quality check | Drift in model behavior, accuracy, or error rate on your own use case, independent of what the vendor reports | The business unit or model risk team using the tool | Sampled output logs, a drift metric or spot-check against a baseline |
| Trigger-based review | Model version changes, sub-processor swaps, security incidents, or a material change the vendor discloses (or that surfaces independently) | Vendor risk management, escalated to the risk committee if the tier changes | Vendor change notice, updated risk-tier memo, re-diligence on the changed component only |
| Annual full re-assessment | Everything the onboarding checklist covered, re-run against current state, plus a review of the prior year’s trigger events | Vendor risk management | Refreshed vendor questionnaire, updated register entry, renewed contract terms if due |
The trigger-based layer is the one most programs are missing, and it is the one that matters most for AI. It does not run on a calendar. It runs on an event: a vendor discloses a model change, a news report surfaces a sub-processor breach, or your own quarterly output-quality check flags a shift no one can explain. Defining the trigger list in advance, rather than deciding case by case whether something warrants a look, is what turns this from an ad hoc scramble into a repeatable control.
A minimum trigger list for an AI vendor:
- The vendor discloses a model version change, retraining event, or upgrade that affects the product you use.
- The vendor changes its underlying foundation model or adds a new sub-processor with model access.
- The vendor reports a security incident, whether or not your data was confirmed affected.
- Your own quarterly output-quality check flags an unexplained shift in accuracy, error rate, or behavior.
- The vendor’s data-handling terms change, including any new use of customer data for model training or improvement.
- A regulatory or examiner inquiry names the vendor or the use case it supports.
What “ongoing monitoring” needs to produce as evidence
A monitoring cadence that runs quietly in someone’s inbox is not a program an examiner can walk through. The June 2023 interagency third-party guidance treats ongoing monitoring as its own lifecycle stage precisely because a supervisor expects to see it evidenced, not just asserted. Three artifacts carry that evidence.
A living vendor risk register, not a static spreadsheet frozen at onboarding. Every AI vendor and the embedded AI features inside your broader SaaS stack should have one entry, a current risk tier, and a record of the last review date and the reviewer. A register that has not moved since onboarding is itself a finding.
A trigger-event log, recording every time a trigger from the list above fired, what was reviewed, and what the outcome was, even when the outcome was “no tier change.” The absence of any logged triggers over a year for a vendor whose product changes as often as most AI products do is a signal the monitoring is not actually happening, not a signal the vendor never changed.
A named owner per vendor. Ongoing monitoring fails most often not because no one decided to do it, but because no one owns it once the onboarding project team disbands. The owner does not need to run every check personally, but the register entry should name who is accountable for the vendor’s tier staying accurate.
Where this sits inside the frameworks that already govern you
There is no AI-specific monitoring rule. The obligation to monitor a vendor sits inside the third-party risk framework each type of institution already answers to, and AI just raises the bar on what “monitoring” has to catch.
- Banks and thrifts apply the June 2023 Interagency Guidance on Third-Party Relationships: Risk Management, which names ongoing monitoring as a distinct lifecycle stage alongside planning, due diligence, contract negotiation, and termination. OCC Bulletin 2013-29 sets the same expectation for national banks managing any third party with access to sensitive systems or data.
- Broker-dealers and RIAs carry the Regulation S-P service-provider oversight obligation, including the requirement to arrange for a service provider to report a breach affecting customer information without unreasonable delay. An AI vendor processing nonpublic personal information sits inside that oversight the same way any other service provider handling that data does.
- Insurers carry the NAIC AI Model Bulletin’s third-party expectation, under which the insurer remains responsible for a vendor’s AI use even though the obligation does not transfer to the vendor. A carrier’s AI Systems Program needs to name how it monitors third-party AI, not only how it diligenced it at onboarding.
- All institutions handling nonpublic personal information carry GLBA safeguarding obligations that apply to how a vendor handles that data for as long as the relationship runs, not only at the point it was signed.
The common thread across all four is that the obligation is continuous, not a one-time gate, and an examiner reviewing third-party risk expects to see a program that reflects that. A banking AI governance engagement builds this monitoring layer as part of the broader program, tying the AI vendor register to the model risk and third-party risk processes the institution already runs, rather than standing up a parallel AI-only process.
What this guide is / What it is not
What it is: A practitioner framework for the monitoring layer of an AI vendor risk management program, for a Chief Risk Officer, head of vendor risk, or Chief Compliance Officer who already has an onboarding diligence process and needs the ongoing cadence that keeps a vendor register accurate between reviews.
What it is not: A certification or a guarantee. DSE prepares organizations for audit and does not certify compliance or promise any examination outcome. This is supervisory-framework-aligned advisory work; the responsibility for the vendor relationship and for acting on what monitoring surfaces stays with the institution.
FAQ
How often should a bank monitor an AI vendor after the initial risk assessment?
Run three layers at once: a quarterly output-quality check on your own use of the tool, a trigger-based review that fires whenever a defined event happens (a model version change, a sub-processor swap, an incident, or an unexplained drift finding), and a full annual re-assessment that re-runs the onboarding diligence against current state. The annual layer alone misses the changes that happen between renewal dates, which is most of what makes AI vendor monitoring different from traditional vendor monitoring.
What triggers should require an immediate AI vendor risk review, outside the normal cadence?
At minimum: a vendor-disclosed model version change or retraining event, a change to the vendor’s underlying foundation model or sub-processor, a security incident at the vendor whether or not your data is confirmed affected, an unexplained shift in output quality or accuracy your own team catches, a change to the vendor’s data-handling or training-data terms, and any regulatory or examiner inquiry that names the vendor.
Who should own ongoing monitoring of AI vendors, the business unit or the risk function?
Both, with a clear split. The business unit using the tool is best positioned to run the quarterly output-quality check, because it sees the tool’s actual behavior day to day. Vendor risk management or the model risk function should own the trigger-based and annual reviews, and a named individual, not a committee, should be accountable for keeping each vendor’s register entry current. Ownership that dissolves once the onboarding project team disbands is the most common reason monitoring programs go stale.
Does a vendor’s ISO 42001 or SOC 2 certification satisfy ongoing monitoring requirements?
No. A certification is a point-in-time attestation about how the vendor operated at the time of the audit. It does not tell you whether the vendor changed its model, its sub-processors, or its data-handling practices since that audit closed, and it says nothing about your own deployment-side controls. Treat a certification as one input to a trigger-based review, particularly around the recertification date, not as a substitute for the monitoring cadence itself.
What does an AI vendor risk register need to include to satisfy an examiner?
A current risk tier for every AI vendor and embedded AI feature in production, the date and outcome of the last review, a log of every trigger event and how it was resolved even when no tier change resulted, and a named owner accountable for the entry. A register frozen at the onboarding date, with no trigger events logged for a vendor whose product changes as often as most AI products do, reads as evidence the monitoring is not happening rather than evidence nothing changed.
The Bottom Line
An AI vendor risk assessment answers one question well: what did this vendor look like on the day you onboarded it. An AI vendor risk management program answers a harder, more durable question: what does this vendor look like now, and how would you know if that changed. The difference is a defined cadence, quarterly output checks, trigger-based reviews tied to a named event list, and an annual full re-assessment, backed by a register and a trigger log an examiner can walk through. Institutions that stop at the onboarding checklist are running half a program. The monitoring layer is what turns a point-in-time assessment into a defensible, continuous one.
If your AI vendor register has not moved since onboarding, start with a vendor AI risk review to inventory what you are running today and stand up the monitoring cadence behind it. For the broader program that ties vendor monitoring to your model risk and governance evidence, see the AI governance checklist or the finserv compliance overview.
Key facts
- The June 2023 Interagency Guidance on Third-Party Relationships: Risk Management names ongoing monitoring as its own lifecycle stage, distinct from due diligence, because a vendor relationship approved at onboarding does not stay static (DSE, 2026).
- An AI vendor's risk profile can change without a new contract: a foundation-model swap behind the vendor's product, a retrained model version, or a new sub-processor can each move a vendor from the risk tier it was onboarded under (DSE, 2026).