The Moment Policyholder Data Leaves Your Walls for a Vendor's Model
Picture the moment a claims executive uploads a hospital discharge summary into a licensed document-reading tool, or a placement team pastes a client's loss run into a generative assistant to draft a summary. In that instant, personal and often sensitive personal data, health records, bank details, an Aadhaar or PAN reference, a claimant's medical history, has crossed out of the firm's systems and into a vendor's AI. Under the Digital Personal Data Protection Act, 2023 and the DPDP Rules, 2025, that single act of upload is a regulated processing event with named consequences, and getting it wrong is what most Indian insurers and brokers are quietly exposed to in 2026.
The Act sorts the parties into two defined roles. The insurer or broker that decides why and how the policyholder's data is processed is the data fiduciary, the Indian statute's term for the accountable party. The AI vendor that runs the model on that data, on the fiduciary's instructions, is the data processor. The distinction is not academic: every substantive duty in the Act, lawful basis, a compliant notice, valid consent or a recognised legitimate use, purpose limitation, accuracy, security safeguards, retention limits, erasure and the data-principal rights, attaches to the fiduciary. The processor's obligations flow only from the contract the fiduciary puts in place. The data physically sits in the vendor's model; the legal answerability does not move an inch.
This piece deliberately keeps to the DPDP lens on AI vendors: notice and consent, the legitimate-uses carve-outs, cross-border transfer, the data-processing agreement, processor audits, breach intimation to the Data Protection Board, and the heightened position if the firm is notified as a Significant Data Fiduciary. The broader question of how India's national AI governance principles and IRDAI's sectoral model-governance rules sit on top of all this is a separate layer with its own obligations; here the subject is squarely the data, the consent behind it, and the contract that governs the vendor handling it.
Consent, Notice and the Legitimate-Use Carve-Out for AI Processing
Before a single record reaches an AI vendor, the fiduciary has to be sure the underlying processing is lawful in DPDP terms, because the vendor inherits the firm's basis, it cannot create one. DPDP recognises two routes: the data principal's consent, or one of the Act's legitimate uses. For insurance, the consent route carries a specific machinery the firm has to honour.
- The itemised notice. Section 5 and the DPDP Rules require a notice that is clear, in plain language and itemised: it must tell the policyholder what personal data is collected and the specific purpose, and the Rules push notices toward a standalone, understandable form rather than a clause buried in a proposal form. If a model will analyse a claimant's health data to triage a claim, the purpose has to be described honestly enough that the consent given actually covers that use.
- Consent that is free, specific and revocable. Consent must be as easy to withdraw as to give, and the firm must be able to action a withdrawal, which means knowing what of that principal's data has already flowed to which AI tool. A model that has ingested data for which consent is later withdrawn is a live problem the fiduciary owns.
- The Consent Manager and verifiable parental consent. The Rules contemplate registered Consent Managers and impose verifiable parental consent for children's data, relevant wherever a policy covers minors, for instance a dependant on a group health programme fed into a claims model.
- The legitimate-use alternative. Where processing rests on a legitimate use rather than consent, for example a purpose the principal voluntarily provided data for, the firm must be able to point to which legitimate use it is relying on for that AI processing, rather than assuming consent it never properly obtained.
The duty most often forgotten with AI is purpose limitation against training. Data a policyholder gave for claims handling cannot, without a fresh and proper basis, be repurposed to train a model the vendor improves and resells to other clients. A contract that lets the vendor use the firm's policyholder data "to improve the service" is, read against DPDP, a purpose-limitation breach the fiduciary will answer for. The firm has to know, and contractually control, whether its data trains the vendor's model at all.
Cross-Border Processing, Breach Intimation and the Significant Data Fiduciary Trap
Most AI tools an Indian firm licenses are hosted, at least in part, outside India, and several DPDP-specific obligations bite hardest exactly there.
Cross-border transfer. DPDP takes a negative-list approach: personal data may generally be transferred outside India except to territories the Central Government restricts by notification. That is more permissive than a localisation mandate, but it is not a free pass. The fiduciary must still know where each AI vendor processes and stores the data, must track whether any destination falls under a restriction, and must remember that sector-specific data-residency expectations can sit above DPDP. An AI vendor that silently routes processing through a sub-processor in a new jurisdiction can put the firm offside without the firm ever deciding to send data there, which is why visibility into the vendor's processing locations and sub-processors is a DPDP control, not just a procurement nicety.
Breach intimation. Under the Act and the DPDP Rules, a personal data breach must be intimated to the affected data principals and to the Data Protection Board of India, and the Rules set out the form and content of that intimation. A breach inside an AI vendor that exposes policyholder data is, for the fiduciary, a reportable personal data breach: the firm, not the vendor, owes the intimation. The contract therefore has to compel the vendor to detect, report to the firm without delay, and supply the facts the firm needs to make its own intimation within the regulatory timeframe. A vendor that learns of a breach and sits on it has put the fiduciary in default of the Act.
The penalty exposure. DPDP attaches financial penalties of real magnitude for failures such as inadequate security safeguards leading to a breach, with the Schedule contemplating penalties up to two hundred and fifty crore rupees per instance. Handing data to an unvetted AI vendor under no proper agreement is precisely the conduct the penalty regime targets.
Significant Data Fiduciary status. The Government may notify a firm, or a class of fiduciaries, as a Significant Data Fiduciary based on volume and sensitivity of data and other factors. An SDF carries heavier duties: appointing a Data Protection Officer based in India, an independent data auditor, and periodic Data Protection Impact Assessments. A large insurer or broker processing high volumes of sensitive health and financial data through AI is a realistic SDF candidate, and a DPIA on a high-impact AI tool is exactly the kind of exercise the SDF regime contemplates.
The Data-Processing Agreement: Clauses That Make an AI Vendor DPDP-Safe
Because every fiduciary duty stays with the firm, the data-processing agreement is the one instrument that pulls the AI vendor into line. A generic SaaS contract will not do it; the agreement has to carry the specific DPDP-derived clauses below, and the firm has to be able to enforce them.
Process only on instruction. The vendor must process the firm's policyholder data solely to deliver the contracted service, on the firm's documented instructions, and for no other purpose. This is the clause that closes the repurposing gap.
No training without explicit permission. State expressly whether the firm's data may be used to train, fine-tune or improve the vendor's models, and default it to no. If any training use is permitted, it must be tied to a lawful basis the firm actually holds. Silence here is the most common and most dangerous drafting failure in AI contracts.
Sub-processor control and location transparency. The vendor must disclose its sub-processors and processing locations, seek consent before adding new ones, and flow the same obligations down, so the firm can keep its cross-border position accurate and act if a destination becomes restricted.
Breach intimation to the firm without delay. The vendor must detect and report any personal data breach to the firm fast enough that the firm can meet its own intimation duty to the Data Protection Board and affected principals, and must supply the facts the intimation requires.
Assistance with data-principal rights. The vendor must help the firm honour access, correction, completion and erasure requests across whatever of that principal's data the tool holds, including deleting on instruction when consent is withdrawn.
Audit and inspection rights. The firm needs the right to audit or to receive independent assurance over the vendor's processing and safeguards, the practical mechanism behind the SDF-style independent audit and any DPIA.
Retention and deletion on exit. On termination the vendor must delete or return the firm's data and certify it, closing the loop so retired tools do not become forgotten stores of policyholder data.
The heaviest concentration of sensitive personal data in most insurance operations sits in the tools that read unstructured documents, submissions, policy wordings, endorsements and claims files, because that is where the health, financial and identity data lives. The more uncontrolled the source those tools are pointed at, the harder every DPDP duty becomes, mapping the data, proving the basis, honouring an erasure request, scoping a breach. Sarvada gives commercial-insurance brokers and corporate risk teams structured, searchable access to insurer wordings and the intelligence around them from a single governed source built on tenant isolation, no sharing of client data with rivals and no sale of data, so the wordings layer that AI tools draw on is a controlled, auditable foundation rather than a sprawl of ungoverned files. Insurers and brokers tightening the DPDP position of their AI vendors can Request Access to evaluate the platform as the governed source beneath their wordings and analytics.