The shift from build-to-buy in banking AI is well underway. Credit scoring engines, fraud detection platforms, document extraction tools, customer service LLMs — the majority of new AI deployments in Indian banking are procured from vendors rather than developed in-house. This shift has governance implications that most procurement frameworks have not caught up with, and procurement teams who treat an AI purchase like a software license purchase are the ones who find that out the hard way.
Buying an AI system does not transfer the bank's governance obligations to the vendor. The bank remains accountable to RBI for the outcomes that AI system produces. The bank must conduct independent validation regardless of the vendor's own validation. The bank must ensure that India-specific fairness requirements — proxy variable testing, DPDP Act compliance, Fair Practices Code explanation requirements — are met, even if the vendor's AI was designed and tested for a different regulatory context entirely.
AI procurement governance is the process of ensuring a procured AI system can be deployed in a way that satisfies all of these obligations — before the procurement decision is made, not after the contract is signed and the vendor's leverage has changed completely.
AI Vendor Due Diligence: Six Assessment Categories
1. Model governance — vendor's own validation and documentation. What independent validation has the vendor conducted? Is validation documentation available for bank review? What validation framework did the vendor follow (SR 11-7, EU AI Act conformance requirements, or another)? How frequently is the model re-validated, and on what trigger? What is its current validation status, and are there open findings? Red flag: a vendor that cannot provide validation documentation, or treats it as proprietary.
2. Explainability — explanation capability for regulatory compliance. Can the vendor produce per-decision explanations (SHAP, LIME, or equivalent)? Are explanations available in plain language suitable for customers, and in regional Indian languages? Does the explanation method satisfy the Fair Practices Code's disclosure expectations? Are explanations produced at inference time or only on request? Red flag: a global explainability dashboard with no per-decision individual explanation capability.
3. Fairness testing — conducted and available. What fairness dimensions has the vendor tested — demographic variables, proxy variables? Has it conducted India-specific proxy variable testing? What disparate impact ratios does the model produce on the vendor's own test data? Does testing include intersectional analysis? Will the vendor conduct supplemental India proxy variable testing on request? Red flag: EU or US demographic fairness testing only, with no India proxy variable coverage at all.
4. Security — adversarial robustness and security posture. Has the vendor tested against prompt injection and evasion attacks specifically, not just general application security? What security certifications does it hold (SOC 2, ISO 27001)? What is its data isolation architecture for multi-tenant deployments? How does it handle security incidents affecting the AI system, and what's its penetration testing cadence for the model itself? Red flag: security testing covers the general application but not AI-specific adversarial testing.
5. Data governance — DPDP Act compliance and data residency. Where does the vendor process Indian customer data at inference? Does it have India data centre capability? What retention periods apply to Indian customer data, and how does it handle DPDP Act deletion requests? Is Indian customer data used in model training or improvement without a separate basis? Red flag: inference on Indian customer data routed outside India without a clear assessment of whether that's permissible for the data in question.
6. BCM and resilience — business continuity for the AI service. What SLAs cover AI service availability specifically, not just platform uptime? What is the vendor's historical availability record? Does it give advance notice of planned maintenance or model updates? What is its RTO for unplanned disruption? Does it participate in the bank's own BCM documentation for vendor dependencies? Red flag: an SLA that covers platform availability but says nothing about AI model performance availability — a model can be "up" and still be silently degraded.
Minimum AI Contract Provisions for BFSI Deployment
| Contract provision | Minimum requirement | Why required |
|---|---|---|
| Model change notification | 30 calendar days advance notice for material model changes; materiality defined in the contract; bank approval required before production update | Sound third-party risk management practice for any critical vendor dependency; |
| Explainability rights | Bank has the right to produce per-decision explanations; vendor provides explanation methodology documentation; vendor supports regional language explanation format | Fair Practices Code credit rejection explanation expectations; DPDP Act data principal explanation right |
| Audit rights | Bank has the right to audit vendor's validation documentation, training data documentation, and monitoring outputs; vendor must provide supporting evidence within 30 days of request | RBI's outsourcing framework preserves audit rights for critical third parties; examination practice expects vendor oversight evidence |
| India fairness testing | Bank may conduct India proxy variable fairness testing on the vendor model; vendor provides sufficient model access or API capability; vendor cooperates with examination fairness inquiries | India proxy variable fairness assessment is increasingly expected in practice, consistent with the direction of FREE-AI's recommendations, even where not yet a codified named requirement |
| Data residency | Indian customer personal data processed within India where required (payment system data, specifically, under RBI's 2018 circular); inference on Indian customer data on India-hosted infrastructure where the data in question is subject to that rule; no cross-jurisdiction training use without explicit bank approval | RBI's payment data localization requirement (not a blanket rule for all data); DPDP Act purpose limitation |
| Exit and data portability | Minimum 6-month transition period on termination; export of monitoring history, audit trail, and model documentation in standard formats; support for parallel running during validation of a replacement model | Continuity planning for critical vendor dependencies and exit planning expectations under RBI's outsourcing framework |
India-Specific AI Procurement Requirements
India proxy variable fairness testing as a procurement condition. International AI vendors selling credit and fraud AI have typically conducted fairness testing for US or EU demographic dimensions — testing that does not address India's specific fairness exposure. Make India proxy variable fairness testing a procurement condition: either the vendor provides an assessment covering India proxy variables (pincode-based caste proxy, UPI counterparty religious community proxy, regional language proxy), or the contract explicitly permits the bank's own testing on the vendor system before deployment. A vendor that offers neither should be rated as a governance risk, not just a documentation gap to close later.
Business Correspondent network deployment procurement. AI deployed through Business Correspondent (BC) networks has requirements that pure digital deployments don't: operation on low-bandwidth or intermittent connectivity, outputs interpretable by BC agents without advanced technical training, and fallback protocols — offline mode, manual override — appropriate to BC network operations. Test the AI specifically under simulated BC network conditions during procurement, not just in branch or digital channel conditions where the demo always looks great.
Multilingual and regional language requirements. India banking customers interact in 22-plus official languages and hundreds of regional dialects. AI procured for customer interaction — chatbots, IVR, document processing — needs assessment specifically on regional Indian languages, not just Hindi and English. Specify minimum performance thresholds for the languages in the bank's actual deployment geography in the contract itself, and rate vendors who can't demonstrate that performance lower on technical fit, not as a limitation to fix after go-live.
AI Procurement Action Checklist
- Rewrite internal procurement checklists that cite a "2024 AI Circular" to state the actual negotiated contract requirement and its rationale, so the obligation survives scrutiny of its source.
- Make India proxy variable fairness testing a pass/fail procurement gate, not a post-deployment remediation item.
- Separate the payment-data localization requirement from DPDP Act purpose-limitation obligations when drafting data residency clauses.
- Require vendor AI-specific SLA language — not general platform uptime — before signing, with a defined RTO for model performance degradation, not just outages.
- Test any BC-network-bound AI system under simulated low-bandwidth conditions during the procurement evaluation, before the contract is signed.
Related: AI vendor and third-party governance
AI procurement governance — vendor due diligence, India proxy variable gap assessment, contract gap analysis
Zytra's procurement governance module automates the six-category due diligence checklist, scores vendor India compliance gaps, and runs contract gap analysis against minimum provisions. Procurement risk scores and due diligence findings become part of the examination evidence chain.