Very few banks build their AI systems entirely in house. Credit scoring engines, fraud detection platforms, chatbots, document processing tools, and collections analytics increasingly arrive through a vendor relationship, whether a specialised fintech, a large technology provider, or a niche AI startup. This makes AI vendor risk a subset of third party risk that deserves its own dedicated scrutiny, since AI systems introduce failure modes, from biased outputs to unexplainable decisions, that traditional vendor due diligence checklists were never designed to catch.
Outsourcing the technology does not outsource the accountability. Under RBI’s outsourcing framework and the more recent guidance on model risk management, the regulated entity remains fully responsible for the outcomes an AI vendor’s system produces, regardless of who built the underlying model. This makes pre deployment due diligence one of the most important, and most frequently under resourced, steps in adopting third party AI.
Why AI Vendors Need a Different Due Diligence Approach
Standard vendor risk assessments tend to focus on data security, service level commitments, business continuity, and contractual protections. These remain essential for AI vendors too, but they are not sufficient on their own. An AI vendor’s product carries additional risk dimensions, how the underlying model was trained, what data it was trained on, whether its outputs can be explained and defended, and whether the vendor can support the bank’s own regulatory obligations around model validation, bias testing, and ongoing monitoring. A vendor that scores well on data security and uptime can still introduce serious risk if its model was trained on unrepresentative data or cannot produce an audit trail for individual decisions.
Key Questions Banks Should Ask Before Deployment
How was the model trained, and on what data? Banks need to understand the source, scope, and representativeness of the training data behind a vendor’s AI system. If the training data does not reflect the bank’s actual customer base, geography, or product mix, the model’s performance and fairness in production can differ significantly from what the vendor’s marketing materials suggest.
Can the vendor explain individual model decisions? For any AI system used in credit, fraud, or other customer impacting decisions, the vendor needs to demonstrate that individual outputs can be explained in a way that satisfies regulatory and customer facing requirements. A vendor that cannot answer this clearly is transferring explainability risk directly onto the bank.
What bias testing has been performed, and can results be shared? Banks should ask vendors for evidence of testing across relevant demographic and behavioural segments, not just aggregate accuracy metrics. A model that performs well on average can still produce systematically unfair outcomes for specific customer groups.
Who owns model updates, and how are they communicated? AI models are rarely static. Vendors regularly retrain, fine tune, or replace underlying models, sometimes without material changes to the customer facing product. Banks need contractual clarity on when and how they will be notified of model changes that could affect decision outcomes, since a silent model update can invalidate prior validation and monitoring work without anyone at the bank realising it.
What happens if the vendor’s system fails or the relationship ends? Business continuity planning for AI vendors needs to address not just system downtime but the harder question of how the bank would continue critical decisioning processes if the vendor relationship ended, including data portability, model documentation handover, and the practical difficulty of replacing an embedded AI dependency quickly.
Does the vendor support the bank’s regulatory reporting and audit obligations? Banks need contractual assurance that vendors will provide the documentation, access, and cooperation needed to satisfy RBI examinations, internal audit reviews, and model risk validation exercises, since the bank cannot simply tell a regulator that the information sits with a third party and is unavailable.
How is the vendor’s own subcontracting and data handling structured? AI vendors frequently rely on cloud infrastructure providers, data labelling services, and other subcontractors. Banks need visibility into this extended supply chain, since risk introduced at any point in it ultimately becomes the bank’s risk to manage.
What concentration risk does this vendor create? If a bank is relying on the same AI vendor across multiple critical functions, or if a small number of vendors dominate a critical category like fraud detection across the industry, this concentration itself becomes a systemic vulnerability worth assessing at the portfolio level, not just per contract.
Building This Into Formal Vendor Governance
These questions work best when embedded into a formal, repeatable due diligence process rather than handled informally by whichever team happens to be evaluating a specific tool. This means creating a standardised AI vendor risk assessment template that goes beyond generic third party risk checklists, involving model risk, compliance, and business teams jointly in vendor evaluation rather than leaving it solely to procurement or technology, and building ongoing monitoring obligations into vendor contracts from the outset rather than treating due diligence as a one time gate before signing.
Conclusion
AI vendor risk sits at the intersection of technology procurement and model governance, and banks that treat it as a standard vendor checklist exercise are likely to miss the risks that matter most. Asking the right questions before deployment, and building the contractual and monitoring structures to keep answering them afterward, is what genuine AI vendor governance looks like.
Build This Capability with RMAI
RMAI’s Online Certificate Course in Third Party and Vendor Risk Management covers due diligence, contract governance, and ongoing monitoring practices directly relevant to AI vendor relationships.
For teams building the model governance capability that AI vendor oversight depends on, the Online Certificate Course in Risk Management for Artificial Intelligence covers explainability, bias, and AI specific governance requirements.
Explore RMAI’s complete suite of risk management courses to build this capability further.
