DPDP Compliance When Using Third-Party AI APIs

The DPDP Problem with Third-Party AI APIs

When you call OpenAI's API from your Indian application with Indian users' personal data in the prompt, you are transferring personal data to a US-based third-party processor. Under DPDP Section 16 (cross-border transfers), this requires the destination to be a government-notified adequately protective country — a list that may or may not include the US when finally published.

Even if the cross-border transfer is legally permissible, you remain the Data Fiduciary responsible for the data. If OpenAI uses your API prompts for model improvement (depending on your subscription tier), you've potentially shared personal data with a processor without explicit consent for that secondary purpose.

Protective Measures for API Usage

Opt out of training data use: OpenAI's API (unlike ChatGPT) does not use API inputs for training by default. Verify this is still the case and confirm it in writing. For Azure OpenAI, review the Azure OpenAI data, privacy, and security documentation. For Gemini, check Google Cloud's data processing terms.

Execute Data Processing Agreements: ensure you have a DPA or equivalent in place with each AI API provider. The DPA should specify: purpose limitation, data retention limits, sub-processor list, security controls, and your right to audit or request deletion.

Redact before transmission: regardless of legal basis, follow the data minimisation principle. Redact PII from prompts before they leave your infrastructure. If the LLM receives '[AADHAAR_HASH]' instead of the actual number, any legal uncertainty about the third-party transfer becomes moot.

Choosing API Providers Based on DPDP Risk

Risk tiers for Indian companies: Tier 1 (lowest risk) — self-hosted open-source models (Llama, Mistral) on Indian cloud infrastructure. No cross-border transfer at all. Tier 2 — Azure OpenAI on Azure India region with private networking and redaction gateway. Tier 3 — OpenAI API Enterprise tier with DPA, opt-out of training, and redaction gateway. Tier 4 (highest risk) — OpenAI API consumer tier, Gemini API without DPA, third-party APIs without data processing agreements.

For most BFSI and healthcare AI companies, Tier 1 or 2 is required for sensitive data. For general-purpose SaaS with a good redaction gateway, Tier 3 is defensible.

Compliance operational checklist

DPDP Compliance When Using Third-Party AI APIs should be reviewed as an operating control, not only as a reference article. The minimum checklist is a data inventory, a stated processing purpose, owner approval, PII detection at the AI boundary, redaction or tokenisation where possible, retention limits, vendor transfer records, and a tested user-rights workflow. This checklist gives engineering and compliance teams a shared language for deciding what must be blocked, what can be allowed in shadow mode, and what needs human review before production release.

For AI systems, the review should include prompts, retrieved context, tool call arguments, model responses, logs, traces, analytics events, exports, and support attachments. Many incidents happen because teams scan only the visible form field while sensitive data moves through background context or observability tooling. CrewCheck's recommended pattern is to place the scanner at the request boundary, record the policy version, and keep audit evidence that shows which identifiers were detected and what action was taken.

A practical rollout starts with representative samples from production-like traffic. Run a DPDP scan, sort findings by identifier sensitivity and blast radius, fix Aadhaar, PAN, financial, health, children's, and precise-location exposure first, then move to consent wording, retention, deletion, and vendor review. Use shadow mode when false positives could disrupt users, and promote to enforcement only after the exceptions have owners and expiry dates.

This page is educational and should be paired with legal review for final policy interpretation. The operational proof should still come from repeatable evidence: scanner results, audit exports, pull-request checks, policy configuration, and a documented owner for the workflow. That combination is what makes the content useful during buyer diligence, board review, regulatory questions, or an incident investigation.