Third-Party Risk Management for AI Vendors: A Bank Checklist

An AI vendor is a third party like any other, and the June 2023 interagency guidance does not carve out an exception for it. What changes is the review: questions about data use, model changes, subcontractors and logs carry more weight when the software reads customer records and acts on them.

This checklist is for a bank's third-party risk or compliance lead with an AI vendor in the queue. It follows the guidance's life cycle and adds the AI-specific questions we think belong at each stage. For the definition, see third-party risk management (TPRM).

What is third-party risk management for AI vendors?

What does the interagency guidance actually say?

The Federal Reserve, FDIC and OCC issued the Interagency Guidance on Third-Party Relationships: Risk Management in June 2023. The OCC published it as Bulletin 2023-17 on June 6, 2023, and the Federal Register notice followed on June 9. For OCC-supervised banks it rescinded OCC Bulletin 2013-29 and OCC Bulletin 2020-10.

Three points matter for AI:

• Using a third party does not diminish a bank's responsibility to operate safely and comply with law, to the same extent as if it did the work in-house.
• The guidance covers any business arrangement, with or without a contract or payment.
• Oversight scales with risk. Banks apply more rigorous oversight to higher-risk activities, including critical activities, and each bank decides which activities are critical.

The guidance text does not mention AI. In the preamble, some commenters asked the agencies for separate AI material, and the final guidance did not add any. So the AI-specific items below are our application of the life cycle, not regulatory requirements.

How should a bank classify an AI vendor before it signs?

Planning comes first in the life cycle. Write down what the AI system will read, decide and change. Then ask what the guidance lists for planning: the effect on customers, including access to their information, the information security and subcontractor exposure, and whether the bank can supervise the vendor over time. A practical tiering looks like this.

Keep the inventory current, so you can see when a relationship's risk has changed.

What due diligence applies to an AI vendor?

The guidance lists thirteen due diligence areas, from strategies and goals through insurance coverage. These AI-specific questions map onto them.

• Information security. Ask how the vendor limits access to your data and transactions. The guidance names multifactor authentication and encryption as examples. Ask where your data sits, who at the vendor can see prompts and outputs, and how long they are retained.
• Reliance on subcontractors. Most AI products sit on a model provider and a cloud host. Ask for the full chain and where each part runs. The guidance asks banks to assess how the vendor oversees its subcontractors, including location and single-provider dependency.
• Incident reporting and management. Ask how fast the vendor tells you about a security event.
• Operational resilience. Ask what happens to your workflow if the model provider has an outage.
• Management of information systems. Ask how the vendor controls changes to models, prompts and procedures, and whether it can show which version produced a given decision.

Also ask whether your data trains any model. If the vendor will not provide something, the guidance says to document the limitation, understand the risk and consider alternatives such as added monitoring or a different vendor.

What belongs in an AI vendor contract?

The guidance's contract section lists topics, not required clauses, and expects detail to follow the risk. These are the ones we would press hardest for an AI vendor.

1. Nature and scope. Name the activities the vendor performs and the terms for using the bank's and customers' information.
2. Data rights. The guidance asks banks to consider whether the third party may resell, assign or permit access to customer data, metadata or systems. For AI, state whether the vendor may use your data to train or tune any model, its own or a provider's.
3. Notification of change. The guidance lists notice of mergers, new subcontractors and key personnel changes. Add notice before a material model change or a change of model provider.
4. Audit and remediation. Reserve audit rights over the vendor and its subcontractors, and name the reports you are owed, such as SOC reports. Add how fast you can get your data and share it with regulators.
5. Performance measures. The guidance warns against measures that reward volume or speed without regard to accuracy and compliance. For an AI vendor, tie service levels to quality as well as throughput.
6. Subcontracting. Require disclosure and flow-down of the same safeguards.
7. Default and termination. Cover data return, deletion and a transition period.

The guidance notes that the board should know about contracts for higher-risk activities. If you have little negotiating power, document the residual risk you accept.

How should a bank monitor an AI vendor after go-live?

Due diligence at signing is a snapshot, and an AI system changes in ways a payroll processor does not. The guidance's monitoring list covers changes to the vendor's business and subcontractors, audit and test results, compliance and contract performance. For an AI vendor:

• Review performance against service levels, including error rates as well as volume.
• Re-run the due diligence questions on a schedule tied to the tier, and again when the model, provider or permissions change.
• Sample the vendor's outputs against your policy if it classifies alerts or drafts case notes.
• Keep a record of every access the vendor's system holds, and review it as you would any non-human account. See the agent access review entry and the guide to AI agent identity management.

How do you plan the exit from an AI vendor?

The guidance's termination factors include options for transitioning the service, the time needed to move it or bring it in-house, and managing data retention, destruction and system connections afterward. For an AI vendor, add one item: whether the procedures and rules the vendor built for you can be exported in a form a person can read. If not, the exit plan is weak.

How do model risk, the Safeguards Rule and incident rules fit in?

Three other layers touch the same vendor.

• Model risk management. If the AI vendor's system works as a model for a bank decision, your model risk framework applies on top of vendor oversight. See model risk management.
• Customer information safeguards. For a bank, the Interagency Guidelines Establishing Information Security Standards (12 CFR part 30, appendix B for OCC banks) require due diligence in selecting service providers, a contract requiring appropriate measures, and monitoring where the risk assessment indicates it. A non-bank institution under FTC jurisdiction follows 16 CFR 314.4(f), which sets a parallel duty. For how these apply to agents, see our guide to AI agents and GLBA.
• Computer-security incident notification. Under 12 CFR 53.3, an OCC-supervised bank must notify the OCC as soon as possible and no later than 36 hours after determining a notification incident has occurred. Under 12 CFR 53.4, a bank service provider must notify affected banks as soon as possible after an incident that materially disrupts covered services for four or more hours. If your response plan needs a faster window from an AI vendor, write it into the contract.

For the wider set of controls around agents, see how to govern AI agents: 12 controls for regulated enterprises and SOC 2 and AI agents.

How does Zamp run this?

When a bank evaluates us, we are the third party. We have no published banking customer case study, so none of this describes a bank's results. Certifications and subcontractor lists belong in the due diligence documents you request from us directly.

On data location, we offer SaaS, BYOC on AWS, Azure or GCP, and on-premises or air-gapped deployment. Regulated enterprises most often choose BYOC or on-premises so that data stays in infrastructure they already audit. Our deployment models guide compares them.

On access, each AI employee has its own identity with least-privilege access, and every action is logged with the input, sources, action, result, approval state and any correction. See our trust and security page. Approval limits and confidence thresholds are set per role, and a case the agent cannot resolve within scope goes to a person as Needs Attention with context assembled.

On change control, which is the monitoring and notice question, each AI employee runs one Agent Operating Procedure. Every change to it goes on a branch, runs against evals including a golden set, is reviewed and merged, so there is a change history. Learning updates the AOP only and never the model's weights, so a behavior change traces to a reviewed correction and can be reversed.

In a biopharma procurement deployment, the agent sent 64% of requests to manual review in week one, and as reviewed corrections built up its decision rate rose from 36% to 85% and manual review fell to 15%. For a bank vendor review, the lesson that transfers is to expect a high manual-review rate at launch and to treat it as the control working.

Sources

• Interagency Guidance on Third-Party Relationships: Risk Management, 88 FR 37920 (June 9, 2023); OCC Bulletin 2023-17
• 12 CFR part 30, appendix B; 16 CFR 314.4(f); 12 CFR part 53 (eCFR, current as of October 2026)