AI Vendor Due Diligence: 10 Questions Before Your Institution Signs a Contract
Updated: Sep 22
Engaging with third-party AI vendors introduces opportunities for operational efficiency, improved decision-making, and enhanced customer experiences. However, this engagement also brings complex risks that extend beyond the scope of traditional Third-Party Risk Management (TPRM). Standard TPRM frameworks, while essential, may not adequately address the specific technical, operational, and compliance challenges inherent in AI systems.
Before an institution enters into a relationship with an AI vendor, its leaders should conduct a thorough due diligence process that probes the technology’s underlying mechanics, intended use, data dependencies, and potential failure modes. This requires a structured inquiry into the system’s entire lifecycle, from development and validation to ongoing performance monitoring and governance. A comprehensive approach involves understanding the technology, its limitations, the necessary contractual protections, and the institution's capacity for ongoing oversight.
To guide this process, senior risk, compliance, and business leaders should organize their pre-contract due diligence around ten fundamental questions. Answering them provides the clarity needed to make informed decisions, align vendor solutions with the institution's risk appetite, and establish a defensible governance framework.
Table of Contents
1. What does the AI system actually do, and what decisions or processes does it influence?
The first step is to establish a clear and precise understanding of the AI system’s function and its intended impact on the institution’s operations. It is not enough to accept a vendor’s high-level description of capabilities. Due diligence teams should document the specific business problems the system is designed to solve, the exact decisions it will support or automate, and the operational processes it will modify. This includes identifying whether the system will be used for critical functions such as credit underwriting, fraud detection, marketing, or compliance monitoring.
A detailed functional analysis helps determine the system's materiality and the appropriate level of risk management. For example, a system used to automate internal reporting carries a different risk profile than one used to make fair lending decisions. This clarity is the foundation for assessing potential harms, defining performance metrics, and communicating limitations to end-users and control functions.
2. Does the system meet the institution's definition of a model, or is it another type of AI/software?
Properly classifying an AI system is a critical early step that dictates the applicable governance and risk management framework. Institutions should evaluate whether a vendor’s technology falls within their internal definition of a “model.” This classification is not always straightforward and should be based on the system's characteristics and use rather than a rigid, universal test.
For example, the April 2026 interagency guidance on model risk management, transmitted by the Federal Reserve through SR 26-2 and by the OCC through Bulletin 2026-13, defines a model as a complex quantitative method, system, or approach that applies statistical, economic, or financial theories to process input data into quantitative estimates. The guidance is risk-based and nonbinding and is expected to be most relevant to banking organizations with more than $30 billion in total assets, while potentially being relevant in certain circumstances to smaller organizations with significant model risk exposure. Generative and agentic AI are outside the scope of the guidance.
3. What data does the system use, and how is data quality, security, privacy, and lineage addressed?
The performance and reliability of any AI system are fundamentally dependent on the data used to train, test, and operate it. Due diligence must scrutinize the vendor’s data governance practices. Key areas of inquiry include:
Data Sources and Lineage: Where does the data come from? Is its origin and transformation history well-documented and auditable?
Data Quality and Integrity: What processes are in place to ensure data is accurate, complete, and appropriate for its intended use? How are data errors and anomalies handled?
Data Security and Privacy: How is data protected, both in transit and at rest? Does the system handle non-public personal information (NPPI), and if so, how does the vendor ensure compliance with relevant privacy laws like the Gramm-Leach-Bliley Act (GLBA)?
Bias and Representativeness: Was the training data representative of the institution's customer base or the population it will affect? What steps did the vendor take to identify and mitigate potential biases in the data?
Inadequate data management can lead to poor system performance, biased outcomes, and significant compliance and reputational risks.
4. How was the system developed, trained, tested, and validated?
Understanding the vendor’s development and validation processes provides insight into the system's reliability and conceptual soundness. Institutions should request documentation detailing the system’s design, underlying theory, and development methodology. While vendors may not disclose proprietary algorithms, they should be able to explain their overall approach.
The vendor’s internal validation reports can be an important source of information for the institution's due diligence. The nature and extent of the institution's own assessment should be commensurate with the system's risk, purpose, use, complexity, and materiality. For higher-risk systems, the institution may determine that additional validation, outcome analysis, benchmarking, or other testing is appropriate. For high-risk systems, particularly those classified as models, the institution may need to conduct its own validation activities, including outcome analysis and benchmarking against alternative approaches. This independent review helps confirm that the system performs as expected and is suitable for its intended purpose within the institution's specific context.
5. What are the system's known limitations, assumptions, failure modes, and performance boundaries?
No AI system is infallible. A responsible vendor should be transparent about its product's limitations and the assumptions baked into its design. Due diligence should actively seek to uncover these boundaries. Questions to ask include:
Under what specific conditions or data scenarios is the system likely to perform poorly or fail?
What are the key assumptions (e.g., about data distributions or market conditions) that underpin its performance?
What happens if the system receives unexpected or adversarial inputs?
How does the system's performance degrade as real-world conditions diverge from its training environment?
This information is vital for establishing appropriate controls, setting realistic performance expectations, and developing contingency plans. It also ensures that human users understand when and how to override the system’s outputs.
6. How does the vendor monitor performance, changes, drift, incidents, and material modifications?
An AI system's performance is not static; it can degrade over time as underlying data patterns and relationships change—a phenomenon known as model drift. A critical component of due diligence is evaluating the vendor’s framework for ongoing performance monitoring and change management.
The institution should understand the key performance indicators (KPIs) the vendor tracks, the thresholds that trigger alerts, and the process for investigating and responding to performance degradation. Furthermore, clarity is needed on how the vendor manages system updates or material modifications. The institution needs to know how changes are communicated, what testing is performed before deployment, and what rights the institution has to review and approve significant updates.
7. What information can the institution obtain to conduct appropriate due diligence and effective challenge despite proprietary restrictions?
Vendors often cite proprietary concerns as a reason to limit access to a system’s internal workings. While protecting intellectual property is a legitimate concern, it does not absolve the financial institution of its risk management responsibilities. Where model risk management principles apply, effective challenge involves objective, informed, and critical analysis of relevant assumptions, limitations, performance, and use. The nature and extent of that challenge should be appropriate to the system's risk and the institution's governance framework.
Even with "black box" systems, institutions can perform robust due diligence. This can include:
Outcome Analysis: Testing the system's outputs against known inputs to verify its logic and performance.
Benchmarking: Comparing the vendor system’s performance against an internal benchmark or an alternative system.
Sensitivity Analysis: Assessing how the system’s outputs change in response to variations in key inputs and assumptions.
Review of Vendor Documentation: Scrutinizing the vendor's documentation for its development, testing, and validation processes.
The ability to obtain sufficient information to conduct a credible assessment, commensurate with the system's risk, should be a key factor in the vendor selection process.
8. How are applicable compliance, consumer protection, fair lending, cybersecurity, and operational risks addressed?
AI systems do not operate in a regulatory vacuum. Their use can create or amplify a wide range of compliance risks, including those related to fair lending, Unfair, Deceptive, or Abusive Acts or Practices (UDAAP), and Bank Secrecy Act/Anti-Money Laundering (BSA/AML) rules. Due diligence should assess how the proposed use of the system could affect applicable legal, regulatory, consumer protection, cybersecurity, privacy, and operational risk requirements and whether the vendor's controls and contractual commitments appropriately address those risks.
The review should assess the system’s controls for preventing discriminatory outcomes, supporting applicable explanation and adverse-action requirements where the system is used in a credit decisioning context. It should also cover broader operational and cybersecurity risks, evaluating the system's resilience to attack, its integration requirements, and its potential impact on business continuity. For a holistic view, explore how the system fits within the institution's broader enterprise risk framework.
9. What contractual rights and protections address audit/access, data use, changes, incidents, subcontractors, and termination?
The vendor contract is a critical risk management tool. It should codify the rights and responsibilities of both parties and provide the institution with the necessary protections. Before signing, legal and risk teams should ensure the agreement adequately addresses key areas, including:
Audit and Access Rights: Appropriate rights to assess the vendor's controls and performance, directly or through independent reports, certifications, or other evidence, commensurate with the risks of the relationship.
Data Ownership and Use: Clear terms on who owns the data, how it can be used by the vendor, and what happens to it upon contract termination.
Service Level Agreements (SLAs): Specific, measurable performance standards and remedies for failure to meet them.
Incident Notification: A clear obligation for the vendor to promptly notify the institution of security breaches, performance failures, or other significant incidents.
Subcontractor (Fourth-Party) Risk: Visibility into the vendor’s key subcontractors and provisions to ensure they are held to similar standards.
Termination and Exit Rights: A clear exit strategy that allows the institution to transition away from the vendor with minimal disruption and ensures the return or destruction of its data.
A well-structured contract can be an important component of the institution's broader third-party risk management framework.
10. How will the institution govern, monitor, and periodically reassess the relationship after implementation?
Due diligence does not end when the contract is signed. The final question focuses on the institution’s own readiness to manage the vendor relationship and the AI system over its full lifecycle. This requires establishing a clear internal governance structure with defined roles and responsibilities for ongoing oversight.
The plan should include processes for monitoring the system’s performance against established metrics, reviewing vendor reports, and conducting periodic risk assessments. It should also define a process for managing system changes, incidents, and contract renewals. Effective post-implementation governance can help the institution monitor whether the AI system continues to perform as intended and whether changes in the system, vendor relationship, or risk environment require additional controls or reassessment.
Executive Takeaways for the Board and Senior Management
Adopt a Structured Framework: Use a structured, ten-question due diligence framework for evaluating AI vendors, adapting the depth and scope of review to the nature and risk of the proposed relationship.
Clarify System Classification Early: Determine whether a proposed AI system qualifies as a "model" under the institution's own risk management framework to ensure the appropriate level of governance and validation is applied from the outset.
Prioritize Access for Effective Challenge: Confirm that the institution can obtain sufficient information (through documentation, testing, vendor discussions, independent reports, or other appropriate means) to conduct a credible assessment of the system's risks and limitations.
Scrutinize Contractual Protections: Ensure that vendor agreements provide robust contractual rights regarding data ownership, audit access, incident notification, and clear exit strategies to protect the institution throughout the relationship lifecycle.
Plan for Lifecycle Governance: Establish clear internal ownership and a comprehensive plan for post-implementation monitoring, performance tracking, and periodic reassessment of the AI system and the vendor relationship.
How Versapien Can Help
Versapien provides senior-led advisory services to help financial institutions navigate the complexities of AI vendor due diligence. Our team assists clients in assessing AI vendors, evaluating governance and technology risks, and establishing robust oversight frameworks. We help strengthen contractual considerations and develop practical, risk-based approaches for ongoing monitoring that align with the institution's operational and risk management objectives.
Comments