AI vendor risk in Indian regulated sectors — a 2026 reference

ControlForge free guide · 2026-05-24 · Synthesis across NIST AI RMF, EU AI Act Article 25, ISO/IEC 42001, IT (Intermediary Guidelines) Amendment Rules 2026, DPDPA, and the Indian sectoral cyber/IT regimes

Quick reference

The problem in one line: every Indian regulated entity now has AI in its vendor estate — often without knowing it — and the existing TPRM, contract, and inspection frameworks were built for non-AI vendors. The 2026 global TPRM survey found that no organisation feels extremely confident managing vendor AI risk, and Indian regulators are starting to ask about AI vendor governance even where no AI-specific direction yet applies.
The three vectors that matter most in 2026:
AI already in existing vendor products — KYC, fraud detection, AML, decision support, customer support — without disclosure to the regulated entity that AI is part of the service.
Pure-play AI vendors — LLM gateways, AI coding copilots, AI compliance review, AI content moderation — introducing AI-specific risks (training data, model output reliability, prompt injection, hallucination, IP contamination).
Customer-facing AI through vendor channels — chatbots, automated decisioning, AI-mediated underwriting — invoking IT Rules 2026 SGI labelling, DPDPA Section 7 automated-decision implications, and sectoral consumer-protection obligations.
The Indian regulatory layers most likely to apply:
DPDPA Section 7 / Rule 5 — automated decision-making implications for processing personal data.
IT (Intermediary Guidelines) Amendment Rules 2026 — Significantly Generated Information (SGI) labelling for AI-generated content.
CERT-In CISG-2025-02 — AI/ML system incident reporting under the 6-hour CERT-In window.
RBI / SEBI / IRDAI sectoral expectations — AI vendor due diligence emerging in inspection practice through 2025–26.
Audience: CISOs, CRO, Heads of Procurement, Heads of AI / Data Science, DPOs, General Counsel, AI Governance leads.
ControlForge density: 30+ controls across cl-ai-supplier-management, cl-ai-data-governance, cl-ai-resource-inventory, cl-ai-incident-reporting, cl-ai-content-labelling, and cl-ai-content-provenance; cross-walked across NIST AI RMF, EU AI Act, ISO 42001, MeitY AI Advisory, CERT-In CISG-2025-02, and sectoral Indian regimes.

Why AI vendor risk is structurally different

AI vendor risk is not a new category of risk; it is an intensification of risks that traditional TPRM handles plus a small set of genuinely new vectors. Three structural differences make it different from the vendor risk programmes built between 2015 and 2023.

First, AI capabilities are opaque to traditional due diligence. A vendor questionnaire asks about ISO 27001 certification, encryption, vulnerability management, BCP, incident response. None of these surface AI-specific risks: training data provenance, model behaviour under adversarial conditions, output reliability, hallucination patterns, intellectual property contamination, model drift, prompt-injection exposure. A vendor can be ISO 27001 compliant, SOC 2 attested, and still operate AI with material undisclosed risks.

Second, AI vendor capabilities update faster than contracts. A vendor providing fraud detection in 2022 likely was using rule-based models; by 2026 the same vendor product probably uses ML models updated quarterly, possibly with generative AI components for case-summary generation or anomaly explanation. The contractual coverage from 2022 did not contemplate AI capabilities, training data, or model retraining. The vendor relationship is genuinely AI-now even though the contract is pre-AI.

Third, AI vendor failures have systemic propagation patterns that traditional vendor failures do not. A traditional vendor outage affects service availability. An AI vendor failure (model drift, biased outputs, prompt-injection exploit, hallucinated outputs reaching customers, IP contamination of generated content) propagates through every decision the model has made or will make until corrected. This propagation creates regulatory exposure (DPDPA Section 7 automated-decision-making, consumer protection, sectoral fairness expectations) and customer impact at scale that a traditional vendor incident does not.

The net effect: AI vendor risk needs to be addressed as a distinct layer of TPRM with its own due diligence framework, contractual provisions, monitoring approach, and incident response specifics — not bolted onto general vendor risk processes.

The three vectors — what each looks like

Vector 1: AI in existing vendor products without disclosure

Many established vendors (Indian and international) have introduced AI / ML capabilities into existing products. The regulated entity may not know unless it asks. Common patterns:

KYC vendors introducing AI for document verification, face matching, fraud detection scoring.
AML vendors using ML models for alert generation, suspicious-activity pattern detection.
Fraud detection vendors moving from rules-based to ML-based with frequent retraining.
Customer service vendors integrating LLM-based agent assist, automated case summarisation, sentiment analysis.
Sales and marketing vendors using ML for lead scoring, churn prediction, personalisation.
Cybersecurity vendors using ML for anomaly detection, threat hunting, automated triage.

In most of these cases the vendor genuinely thinks of the AI as an internal capability improvement, not a service change. From the regulated entity's perspective, AI has been introduced into the service without the AI-specific risks being assessed.

Pattern of remediation: - Add an "AI/ML use disclosure" section to standard vendor due diligence. - Re-due-diligence existing material vendors with the AI lens. - Update contracts to require ongoing notification of material AI capability changes. - Build an AI-vendor inventory derived from the due diligence exercise.

Vector 2: Pure-play AI vendors

New entrants providing AI-as-a-service. The risks are AI-specific and the regulated entity is, often, an early customer with limited operational track record to draw on.

Common categories in the Indian regulated-sector context:

LLM gateways: providing access to OpenAI, Anthropic, Google, or open-source models through an India-region gateway with rate limiting, prompt management, output filtering, audit logging.
AI coding copilots: developer-facing assistants integrated into IDEs, with implications for IP contamination of source code.
AI compliance review: tools that read contracts, regulatory filings, or documents and produce summaries / annotations / reviews.
AI content moderation: tools that classify or moderate user-generated content.
AI fraud detection and AI risk scoring: domain-specific ML services replacing or augmenting in-house models.
AI customer service: voice / chat AI agents handling customer interactions directly.

AI-specific risks to assess: - Training data provenance: where the training data came from, what consents underpinned it, whether it included data the regulated entity should not be associated with. - Model output reliability: accuracy on the regulated entity's actual data, not vendor benchmarks; behaviour on edge cases. - Adversarial robustness: behaviour under prompt injection, jailbreak, model extraction attempts. - Hallucination patterns: where the model is most likely to generate incorrect outputs with high confidence. - IP contamination: for generative AI, whether the outputs may reproduce copyrighted material from training data. - Drift monitoring: how the vendor monitors model performance over time and what triggers retraining or rollback. - Incident response for AI-specific incidents: prompt injection exploit, model poisoning, output anomaly, training data contamination. - AI inventory and model cards: documentation of every model in the vendor's product, its purpose, its training data, its evaluation metrics.

Pattern of remediation: - AI-specific due diligence framework with the assessment areas above. - Model card / data card disclosure required from the vendor. - Adversarial testing or attestation from the vendor. - AI-specific incident notification SLA. - Limitation on AI use for high-stakes decisions until vendor track record matures.

Vector 3: Customer-facing AI through vendor channels

Banks, insurers, and capital-markets entities increasingly deploy AI capabilities directly to customers via vendor-provided platforms. The risks are most acute because the AI failures affect customers directly:

Customer chatbots — for service queries, complaint handling, transaction initiation.
AI underwriting / credit scoring — affecting loan, insurance, or trading decisions.
AI claim processing — affecting insurance payouts.
AI fraud decision — affecting customer transaction approval / decline.
AI advice / recommendation — affecting customer financial decisions.

Regulatory layers applying: - DPDPA Section 7 / Rule 5 — automated decision-making implications for processing of personal data; the Data Principal's rights include the ability to seek information about the processing, and (where DPBI specifies) human review for significant automated decisions. - IT (Intermediary Guidelines) Amendment Rules 2026 — Significantly Generated Information (SGI) labelling requirements for AI-generated content, including disclosure that content is AI-generated. - Sectoral consumer-protection expectations — RBI's customer protection framework, IRDAI's policyholder protection, SEBI's investor protection — all increasingly include AI-decision review provisions in inspections. - DPDPA Section 6 / consent — where AI processing is for a purpose beyond what the Data Principal consented to (e.g., behavioural analytics for cross-selling), the original consent does not cover the AI use.

Common failures observed in 2024–26: - AI customer chatbot deployed without SGI labelling per IT Rules 2026. - AI underwriting / claim decisions without human-review pathway available. - AI-mediated decisions impacting customers without DPDPA-compliant notice of automated processing. - AI fraud-decline communication to customers without explanation of the basis (creating consumer-complaint exposure).

The contractual layer — what AI vendor contracts need beyond standard TPRM

In addition to the standard contract elements (covered in the TPRM guide), AI vendor contracts need AI-specific provisions:

AI scope and disclosure: - Identification of all AI / ML components in the vendor's service. - Notification obligation for material new AI capabilities or material changes to existing AI components. - Vendor's AI governance framework (NIST AI RMF, ISO 42001, EU AI Act readiness, or equivalent).

Training data and model: - Training data sources and consent / licensing basis. - Restrictions on the regulated entity's data being used to train models beyond the regulated entity's use case (no "your data improves our model for all our customers" without explicit consent). - Model card and data card disclosure as standard documentation. - Model retraining cadence and change-control process.

Output quality and reliability: - Reasonable performance commitments calibrated to the regulated entity's data and use case. - Drift monitoring and rollback procedures. - Adversarial robustness testing or attestation.

AI-specific incident notification: - Notification within defined SLA of AI-specific incidents: prompt injection exploit, model poisoning, output anomaly affecting customers, training data contamination. - AI incident definition aligned with CERT-In CISG-2025-02 categories.

IP and content provenance: - For generative AI, commitments on output IP cleanliness (no reproduction of copyrighted training data). - C2PA / IPTC content provenance for generated media where applicable.

Customer-impact and explainability: - For customer-facing AI, explainability commitments — the vendor provides sufficient information for the regulated entity to satisfy DPDPA Section 7 automated-decision-making and sectoral explainability expectations. - Human-review pathway availability for high-stakes decisions.

Audit rights extending to AI: - Right to audit the vendor's AI governance, model documentation, training data records, evaluation results. - Right to require third-party AI assurance (independent model audit) for high-risk uses.

Termination and exit: - Data return covering both training data the vendor holds about the regulated entity and any model outputs / artefacts. - Restrictions on the vendor retaining model improvements derived from the regulated entity's data after termination.

Most vendor contracts in 2026 do not have these provisions. The 2026 priority is AI-overlay addenda for material AI vendors, alongside the general TPRM contract refresh.

The DPDPA Section 7 / Rule 5 automated-decision layer

DPDPA Section 7 enumerates legitimate uses for processing without consent; Rule 5 elaborates on consent. Where AI is used for automated decision-making affecting Data Principals, the implications:

Notice must disclose that AI / automated decision-making is part of the processing.
Consent must cover the AI use as a specific purpose (not bundled under general service consent).
Significant automated decisions — those producing legal or similarly significant effects on the Data Principal — require additional safeguards (anticipated DPBI guidance from 2027).
Data Principal rights include the ability to seek information about the processing logic in a Data Principal-accessible form.

For Significant Data Fiduciaries (post-designation), additional obligations under Section 10 may include: - Annual algorithmic transparency assessment. - DPIA covering AI / automated decision-making. - Independent annual audit covering AI processing.

These obligations are anticipated but not yet operational; the runway is to May 2027 for general DPDPA enforcement, with SDF designations expected post-May 2027.

The IT Rules 2026 SGI labelling layer

The IT (Intermediary Guidelines) Amendment Rules 2026 introduced provisions for Significantly Generated Information (SGI) — content produced wholly or substantially by AI that meets specified thresholds. Key requirements:

Machine-readable labelling: AI-generated content must carry machine-readable provenance metadata.
User-visible disclosure: AI-generated content must be disclosed to users in a recognisable manner.
Aligned standards: implementation aligned with international standards (C2PA, IPTC for media).

The rules apply to intermediaries hosting or distributing AI-generated content. Regulated entities deploying AI customer-facing capabilities through vendor channels need to ensure their vendor's AI output flows comply with SGI labelling — and that their own user interfaces present the labelling appropriately.

The CERT-In CISG-2025-02 layer

CERT-In's CISG-2025-02 guidance (issued in 2025) addresses cyber security incident reporting for AI / ML systems. The implications for AI vendor risk:

AI / ML incidents affecting the regulated entity — model poisoning, training data compromise, adversarial-input exploitation, output anomaly — are within the CERT-In 6-hour reporting window per the general Direction 70B framework, with CISG-2025-02 providing AI-specific category guidance.
AI inventory maintained at the regulated entity should include vendor-supplied AI components, so that vendor-side AI incidents are scoped quickly when flow-back occurs.
Vendor incident notification flow-back must include AI-specific incident categories; standard "security incident" notification may not surface AI-specific events.

For regulated entities with material AI vendor footprints, the IR runbook should include AI-specific incident scenarios alongside the traditional cyber scenarios (ransomware, DDoS, data exfiltration).

The sectoral layer — what RBI, SEBI, IRDAI are starting to ask in 2026

No Indian sectoral regulator has yet issued comprehensive AI-specific directions. However, inspection practice through 2025–26 has surfaced consistent questioning:

RBI inspections have started asking: - What AI / ML is in use in the bank's customer-facing or risk-decision processes? - What is the AI governance framework? Is the Board involved? - How is AI vendor risk being assessed? - What are the customer-impact assessments and human-review pathways for AI-mediated decisions? - Is the AI being used in payment systems or for fraud decision? If so, what is the explainability posture?

SEBI inspections have asked similar questions in the context of: - AI-mediated investment advisory or robo-advisory. - AI in algorithmic trading and surveillance. - AI in compliance review and risk assessment.

IRDAI inspections have raised: - AI in underwriting and claim processing. - AI customer-service chatbots. - AI fraud detection and integration with claim decisioning.

The pattern is consistent: regulators are surveying the AI estate before drafting specific directions, and the entities that have a mature inventory + governance framework + vendor risk programme are clearing the inspection questions cleanly. Entities without such programmes are facing the recurring observation: "the entity's AI estate is materially larger than the entity's AI governance".

What good looks like — a 2026-mature AI vendor risk programme

The structural properties of a mature AI vendor risk programme:

AI inventory covering every AI / ML component in use, whether in-house or vendor-supplied, with model cards / data cards documenting purpose, training data, evaluation metrics, and risk classification.

AI vendor due diligence framework with the AI-specific assessment areas (training data provenance, output reliability, adversarial robustness, drift monitoring, IP contamination, AI-specific incident response).

AI vendor contracts with the AI-overlay provisions, including AI scope disclosure, model card requirements, output quality commitments, AI-specific incident SLAs, audit rights extending to AI.

AI governance integration — AI vendor risk integrates with the broader AI governance committee, the AI risk register, and the Board's AI oversight cadence.

Customer-impact assessment for every customer-facing AI capability, mapping the regulatory layers (DPDPA Section 7, IT Rules 2026 SGI, sectoral consumer protection) and documenting compliance posture.

Human-in-the-loop architecture for high-stakes AI decisions, with the human-review pathway designed, documented, and tested.

AI-specific incident response integrated with the broader IR runbook, including tabletop exercises covering AI-specific scenarios.

Periodic AI audit — internal or external assurance covering the AI estate, the governance framework, vendor management, and customer-impact controls.

Common pitfalls in 2026

Six recurring failure patterns:

1. AI estate larger than AI governance. The entity's AI use has grown organically — internal experiments, vendor capabilities, customer-facing tools — without a corresponding governance maturity. Inspection question: "what AI is in use here?" produces an inadequate answer.

2. AI in vendor products not disclosed. Vendor questionnaires don't ask about AI; vendors don't volunteer. AI capabilities are inside the service surface but invisible to the entity's vendor risk programme.

3. SaaS adopted with default settings; AI capabilities active. Many SaaS tools enable AI features by default in 2026. The entity may not have made an active decision to use the AI; it just is.

4. Customer-facing AI without SGI labelling. Chatbot deployed without IT Rules 2026 SGI compliance. Generated content reaching customers without machine-readable provenance.

5. AI decisions affecting customers without DPDPA-compliant notice. Notice was written before AI was part of the processing; AI is now used; notice not refreshed.

6. AI vendor incident response not tested. General IR tabletops; AI-specific scenarios absent. SOC analysts have not been trained on AI incident categorisation per CISG-2025-02.

Two further patterns:

7. Training data leakage through vendor. The entity's data is sent to a vendor; the vendor uses it (deliberately or accidentally) to improve a model that is then offered to other customers. Contractual coverage is the remediation; many existing contracts don't have the necessary language.

8. AI explainability gap surfacing in customer complaints. AI-mediated denial or decision; customer asks "why"; entity cannot answer because the vendor's AI is opaque to it. Consumer-protection escalation follows.

How ControlForge supports this

The AI vendor risk area has rich cross-reference density in the KB:

cl-ai-supplier-management — AI-specific vendor governance.
cl-ai-data-governance — training data, data flow, lineage.
cl-ai-resource-inventory — AI inventory at the entity.
cl-ai-incident-reporting — CISG-2025-02 alignment.
cl-ai-content-labelling — IT Rules 2026 SGI compliance.
cl-ai-content-provenance — C2PA / IPTC integration.
cl-ai-roles — AI governance roles and responsibilities.
cl-ai-transparency — explainability and disclosure.
cl-ai-conformity-assessment — assurance and audit.
cl-ai-gpai-obligations — general-purpose AI model obligations (relevant for entities procuring LLM services).

The synthesis surfaces the cross-walk across NIST AI RMF + NIST GenAI Profile + EU AI Act + ISO 42001 + ISO 27701 (where personal data is involved) + MeitY AI Advisory + CERT-In CISG-2025-02 + DPDPA Section 7 / Rule 5 + IT Rules 2026 SGI provisions.

For Indian regulated entities, the practical synthesis allows a single AI governance programme to satisfy emerging Indian expectations while remaining export-ready for EU AI Act and US state AI regulation as those regimes mature.

A 90-day AI vendor risk uplift

For Indian regulated entities recognising the AI estate gap:

Days 1–30: Inventory and disclosure. - Survey all material vendors for AI / ML disclosure. - Build the AI inventory (in-house + vendor-supplied) with model cards / data cards where available. - Identify customer-facing AI capabilities and assess them against IT Rules 2026 SGI + DPDPA Section 7.

Days 31–60: Due diligence framework and contracts. - Develop the AI-specific due diligence framework. - Re-due-diligence the top 5 material AI vendors with the AI lens. - Draft AI-overlay contract addenda; negotiate with the top 5 vendors.

Days 61–90: Governance, IR, and inspection-readiness. - Integrate AI risk into the broader risk register and AI governance cadence. - Update the IR runbook with AI-specific scenarios; conduct an AI tabletop. - Brief the Board / risk committee on the AI estate and the governance posture. - Document the inspection-ready evidence pack.

By day 90, the entity should have a structured AI vendor risk posture with the highest-risk gaps in active remediation. Continuous improvement extends from there.