AI Vendor Risk Under DPDPA: A Guide to Third-Party Risk Management

The first two parts of this series looked at data a team controls directly: training sets and model outputs. This part looks at something harder to see: the AI tools a team did not build, does not control, and may not have fully vetted before adopting.

Every vendor AI tool an enterprise uses- a chatbot platform, a document summarisation API, an analytics copilot, a recruitment screening tool- is a third party processing personal data on the enterprise's behalf the moment it touches that data. Under DPDPA, that makes it a Third Party Risk Management problem, not just a procurement decision.

Why Vendor AI Tools Are Different From Ordinary Software Vendors

A traditional software vendor, a CRM or an email platform, processes personal data in fairly predictable, well-documented ways. A vendor AI tool is often less predictable. It may send data to a model hosted elsewhere, retain prompts and outputs for its own training purposes, or pass data through additional sub-processors the enterprise never directly contracted with.

This matters because Rule 6 of the DPDP Rules extends security safeguard obligations to data processed on the enterprise's behalf, which includes vendor AI tools. The enterprise cannot outsource its liability simply because the processing happens inside someone else's model.

The Adoption Pattern That Creates The Most Risk

The riskiest vendor AI adoptions are rarely the large, formally procured platforms. They are the smaller tools a team adopts quickly to solve an immediate problem: a free or low-cost AI writing assistant, a transcription tool, a coding copilot connected to internal repositories. These tools often get adopted outside the procurement process entirely, which means they never go through vendor risk assessment at all.

This is shadow AI in its most literal form, not a hypothetical security researchers talk about, but the everyday reality of a team trying to move faster. The fix is not to ban these tools outright, since that rarely works in practice. It is to make vendor risk assessment fast and routine enough that teams actually use it before adoption, rather than after a problem surfaces.

What a DPDPA-Aligned Vendor Assessment Actually Checks

A vendor risk assessment built for AI tools specifically needs to ask questions a generic software vendor checklist often misses.

• Does the vendor train its own models on the data it processes for the enterprise, and can that be disabled or excluded contractually?
• Where is the data processed and stored, and does that location create any cross-border processing considerations?
• Does the vendor use sub-processors, and are those sub-processors disclosed and bound by equivalent obligations?
• What is the vendor's data retention policy for prompts, outputs, and logs, and can the enterprise set its own retention limits?
• Does the vendor's contract include security safeguard commitments equivalent to what Rule 6 requires of the enterprise itself?

A vendor that cannot answer these clearly, or that treats the questions as unusual, is itself a signal worth taking seriously.

Building AI Vendor Risk Into An Existing TPRM Process

Most enterprises already have some form of third-party risk management process for software vendors generally. The practical move is not to build a separate process for AI vendors specifically, but to extend the existing one with the AI-specific questions above, and to lower the threshold for what triggers an assessment in the first place.

If a tool processes any personal data, even incidentally through prompts or uploads, it should trigger the same review a traditional software vendor would, regardless of contract size or whether it came through formal procurement. The threshold for review should be about data exposure, not about deal value.

A Practical Checklist For AI Vendor Risk

1. Inventory every AI tool currently in use across the organisation, including ones adopted outside formal procurement.
2. Apply a lower threshold for triggering vendor risk review when a tool touches personal data, regardless of contract size.
3. Ask the five AI-specific vendor questions above as a standard part of every AI tool assessment.
4. Confirm the vendor contract includes Rule 6 equivalent security safeguard obligations, not just generic data protection language.
5. Reassess existing AI vendor relationships periodically, since vendor practices and sub-processor lists change over time.

How Privy By IDfy Supports AI Vendor Risk Management

Privy by IDfy extends Third Party Risk Management to cover the specific questions AI vendors raise, vendor scoring, sub-processor visibility, and contractual due diligence, in the same workflow used for any other third party.

InspectAI can also trigger a vendor review automatically when it detects personal data flowing into a tool that has not yet been assessed, closing the gap where shadow AI adoption usually slips through unnoticed.

Conclusion

A vendor AI tool is not exempt from third-party risk management because it was adopted quickly, used by a small team, or did not go through formal procurement. If it processes personal data on the enterprise's behalf, it carries the same Rule 6 obligations as any other processor, and the enterprise remains accountable regardless of where the processing happens. The teams that fold AI-specific questions into their existing TPRM process, and lower the threshold for triggering review, will catch far more of this risk before it becomes an incident.

If you want help bringing AI vendors into your existing risk process, or you would like a demo of how Privy automates vendor review, write to shivani@idfy.com.

FAQ’s

Are vendor AI tools covered by DPDPA's third-party risk obligations? 

Yes. If a vendor AI tool processes personal data on the enterprise's behalf, it falls under the same Rule 6 security safeguard obligations and TPRM scrutiny as any other third-party processor.

Does a tool need to be formally procured to require a vendor risk assessment?

 No. If a tool processes personal data, even through everyday use like prompts or uploads, it should trigger a risk assessment regardless of how it was adopted or its contract size.

What is shadow AI in the context of vendor risk?

 Shadow AI refers to AI tools adopted by teams outside formal procurement and vendor review, often free or low-cost tools used to solve an immediate problem, which can expose personal data without the enterprise's knowledge.

What should a vendor contract for an AI tool include? 

It should include security safeguard commitments equivalent to Rule 6, disclosure of any subprocessors, clarity on whether the vendor trains its own models on the enterprise's data, and defined data retention terms.

How often should AI vendor relationships be reassessed? 

Periodically, since vendor practices, sub-processor lists, and data handling policies can change after the initial assessment was completed.