Healthcare AI and the DPDP Act: What Every Hospital CXO Must Understand Before Deploying Agents

Two facts set the clock. First, the DPDP Rules 2025 were notified on 13 November 2025, and the enforcement machinery, including the Data Protection Board of India's power to inquire into breaches and levy penalties, is phasing in through 2026, with the penalty and consent-manager provisions expected around November 2026. Second, most hospitals are deploying AI faster than they are reading the law. That combination is a narrow window to get the foundations right before enforcement begins, and the hospitals that use it will deploy AI faster and more safely than the ones who treat compliance as a later patch.

Here is the part that surprises most boards. Unlike the GDPR, and unlike India's own earlier SPDI Rules of 2011, the DPDP Act removed the separate category of "sensitive personal data." Health records, diagnoses, and biometric data now sit under the same rules as any other personal data. The law does not single out patient data for extra statutory protection. The duty to treat it with the highest care therefore falls to you, in how you design and procure, rather than to a special legal tier that would do it for you. That is the lens for everything below.

You are the Data Fiduciary, and the liability does not transfer

Under the Act, your hospital is the Data Fiduciary: the entity that decides why and how patient data is processed. Your AI vendor is a Data Processor acting on your instructions. The obligation that matters most for a CXO is this: the Data Fiduciary stays liable for processing carried out on its behalf by a processor. You cannot move the risk onto the vendor by pointing at a contract.

The deployment decision: every agent you deploy needs a written data processing agreement that binds the vendor to the same standard the law binds you to, names where and how patient data is processed, and gives you the right to audit. If a vendor cannot tell you where the patient's voice recording goes, who can see it, and when it is deleted, you do not yet have a deployment you can defend.

Consent and notice have to be real, and provable

Where you rely on consent, the Act requires it to be free, specific, informed, unconditional, and unambiguous, given by a clear affirmative action. You must also give a plain-language notice that states what data you collect, the purpose, how the patient can exercise their rights, and how they can complain to the Board. If a dispute reaches the Board, the burden is on you to prove that notice was given and consent was validly taken.

The deployment decision: a patient-facing agent, such as a voice bot that books appointments or follows up after discharge, has to capture and log consent for the specific purpose it serves, in language the patient understands, in their language. Consent taken for appointment booking does not cover training a model on the call. Build the consent flow and its audit trail into the agent from day one, because reconstructing it later is not possible.

Collect only what you need, use it only for what you said

The Act builds in purpose limitation and data minimisation. You may process personal data only for the specified purpose the patient was told about, and you should collect only what that purpose needs.

The deployment decision: resist the engineering reflex to feed an entire patient record into a model "in case it helps." Scope the data each agent sees to the task in front of it. A scheduling agent does not need the full clinical history. A triage assistant needs the presenting complaint rather than the billing file. Minimisation is both a legal duty and the single best way to shrink your breach exposure.

Where the data lives is now a deployment parameter

The DPDP framework restricts cross-border transfer of personal data. Rule 15 of the 2025 Rules works on a negative-list model, where the government can name countries or territories to which transfer is restricted, and Significant Data Fiduciaries can be required to keep specified categories of data, including traffic data, inside India.

The deployment decision: this reaches straight into your AI architecture. If your agent calls a large language model hosted overseas, patient data may be crossing a border on every request. Ask your vendor which model runs where, whether patient data leaves India, and whether an India-hosted option exists. For many hospital deployments, in-country or on-premises processing moves from a preference to a requirement. This is one reason serious healthcare AI in India is being built for local deployment rather than ported in from elsewhere.

Breaches run on a clock

On becoming aware of a personal data breach, you must inform the Board and every affected patient without delay, and file a detailed report with the Board within 72 hours, extendable only on written request. The report has to describe the breach in plain language, what data was exposed, what the patient can do to protect themselves, and how to reach you.

The deployment decision: you cannot report what you cannot see. Every agent needs logging, monitoring, and an incident-response path defined before it goes live, so that a model leaking data or a misrouted record is detected and reportable inside the window. A breach you discover late is a breach you report late, and late reporting carries a penalty of up to ₹200 crore.

Patients have rights your system has to serve

The Act gives every Data Principal the right to access their data, to correct it, to have it erased when the purpose is met or consent is withdrawn, and to a grievance redressal route. These are not abstract. They are functions your systems must perform on request.

The deployment decision: before you deploy, confirm that the agent's data store can actually find, correct, and delete a specific patient's data on request, and that a withdrawal of consent flows through to every system that copied the data, including any model context or cache. An architecture that cannot honour erasure is an architecture that cannot comply.

If you are large, assume you are a Significant Data Fiduciary

The government can designate high-volume or high-risk processors as Significant Data Fiduciaries, with heavier duties: an annual Data Protection Impact Assessment, an annual audit, and added transparency about automated processing that affects patients. A large hospital network handling millions of patient records is a realistic candidate.

The deployment decision: if you are a multi-site network, plan as though SDF duties apply. Run a Data Protection Impact Assessment before a major AI deployment rather than after, document the automated decisions your agents make, and keep the audit trail an external assessor would ask for. Treating this as routine engineering practice, rather than a compliance scramble, is what separates hospitals that scale AI from those that stall.

A note on children, and a note on ABDM

Two context points complete the picture. First, Section 9 and Rule 10 impose stricter rules for patients under 18: verifiable parental consent, with approved methods including DigiLocker-based verification, and a bar on tracking, profiling, or behavioural targeting of children. Pediatric and family-facing deployments inherit these duties directly.

Second, DPDP does not sit alone. Hospitals connected to the Ayushman Bharat Digital Mission already operate a consent-based model for sharing health records through ABHA identifiers and the ABDM Health Data Management Policy. DPDP places a statutory backbone under that practice. The practical move is to align your AI consent flows with both, so a single, clean consent and data-handling design satisfies the mission you already participate in and the law that now governs it.

A pre-deployment checklist for a CXO

Before any agent that touches patient data goes live, you should be able to answer yes to each of these:

1. We have a data processing agreement that holds the vendor to our standard and lets us audit.
2. We know exactly where patient data is processed and stored, and whether it leaves India.
3. The agent takes purpose-specific consent, in the patient's language, and logs it.
4. The agent sees only the data its task requires.
5. Logging and an incident-response path exist so we can detect and report a breach within 72 hours.
6. Our systems can find, correct, and erase a specific patient's data on request.
7. We have run, or scoped, a Data Protection Impact Assessment for this deployment.

A gap in any one of these is a reason to pause the deployment rather than ship it.

Turning this list into something a hospital can run, repeatedly and provably, is the gap that compliance co-pilots are built to close. NextComply AI, our compliance co-pilot for regulated industries, is one example, helping teams convert these obligations into checkable controls rather than a document that ages on a shared drive.

The DPDP Act has not slowed healthcare AI in India. It has set the terms on which it is allowed to scale. The hospitals that build consent, data residency, vendor accountability, and erasure into their deployments now will move first and move safely. The ones who bolt compliance on after a breach will learn the price in crores.

Frequently asked questions