Compliance and data rules for AI in healthcare

Four rule sets shape AI in Indian healthcare: the DPDP Act 2023 for personal data, the Ayushman Bharat Digital Mission's health data management policy for consent and identifiers, HIPAA where US patients are involved, and your own hospital's clinical governance. Together they decide where data sits, who may retrieve it, and what you must be able to show a reviewer.

Compliance discussions in healthcare tend to stall at the level of principle. This article does the opposite: it maps each obligation to the architectural decision it forces, sets out the six controls a healthcare AI system needs regardless of jurisdiction, and says what the compliance work adds to a build in time and money.

The rules that actually bind an AI system

The DPDP Act 2023 is India's general personal data law and it applies to health data like any other personal data, with obligations arriving through subordinate rules. For an AI system the operative parts are purpose limitation, notice and consent, the right to erasure, and accountability for processors you engage. A model vendor processing your prompts is a processor, and that relationship needs a contract, not an assumption.

The Ayushman Bharat Digital Mission publishes the Health Data Management Policy that governs consent-based exchange of health records across the national digital health ecosystem, described on the ABDM site. If your platform participates, consent artefacts, health identifiers and the federated architecture are design inputs rather than a later integration. If it does not participate, you still inherit the vocabulary, because Indian hospital IT increasingly speaks it. Consent artefacts and health identifiers are becoming the default vocabulary for record exchange between providers, insurers and diagnostics chains, and a system that cannot express them will need retrofitting.

HIPAA binds covered entities and their business associates in the United States, and it reaches Indian firms through business associate agreements on offshore work. Where an Indian development team touches protected health information for a US provider, the control expectations travel with the data. Alongside all of this sits your own clinical governance: who may authorise an automated output, what constitutes a clinical decision, and which committee signs off. That last layer is often stricter than the law, and it is the one that actually blocks a launch.

From rule to architecture decision

Each obligation has a concrete consequence in the build. This is the mapping we work from.

Six controls every healthcare AI system needs

These apply whether you are in Bengaluru, London or Boston, and they are the ones internal audit asks about first.

• Identity-aware retrieval. The system answers as the user, not as an administrator. Permission-aware retrieval is the mechanism; without it, a knowledge assistant becomes a data leak with a chat interface.
• Minimisation at ingestion. Strip identifiers the feature does not need. A protocol assistant does not need patient names; a discharge summariser does, and should say so explicitly.
• Prompt and trace retention limits. Model traces contain patient data. Set a retention period, enforce it automatically and record that you did. Indefinite trace retention is the quietest compliance failure in production AI systems.
• Versioned prompts and model pins. You must be able to say which prompt and which model version produced an output eighteen months ago. Pin versions and log them with every response.
• Approval gates on clinical paths. Any output that reaches a patient record or a patient passes through a named human. The gate is a product feature, not a policy document.
• A monitored escalation route. Every system needs a way for a clinician to flag a wrong answer and a person who reviews those flags weekly.

What does compliance add to the build?

Honestly, between a fifth and a third of engineering effort on a first healthcare system, concentrated in access control, audit and deployment. It is not a separate workstream you can defer; it changes the data model. In price terms, the difference shows up in which service you commission. Retrieval over clinical documents with permission filtering starts at $14,000 or ₹8,80,000. Where the residency position rules out hosted APIs, a self-hosted agentic system starts at $31,500 or ₹20,80,000 plus infrastructure, and the infrastructure is a real line: GPU capacity, patching, monitoring and on-call.

Afterwards, compliance is a running cost. A Care Plan at Enterprise level is $5,250 or ₹3,40,000 a month with 24x7 cover, one-hour response and a named engineer; the AI add-on at $750 or ₹40,000 covers evals, prompt regression and re-indexing, which is precisely the work that keeps an audit position true after a model version changes. Starting figures are published on the pricing page.

Design decisions that follow

Choose the deployment before the feature

Hosted model APIs with a processing agreement are faster and cheaper. In-region or self-hosted open-weight models are slower to stand up and cost more to run. The choice is a policy decision, not an engineering preference, and making it late is expensive because it dictates where retrieval, logging and evaluation infrastructure live.

Treat consent as runtime state

Many teams check consent when they ingest a document and never again. Consent is revocable, so it has to be evaluated when the retrieval happens. That means the index stores a reference the system can re-check, not a copy that outlives the permission.

Log the evidence, not just the answer

An audit record that contains only the output is useless. Record the question, the documents retrieved, the model and prompt version, the confidence signal and what the human did next. AI audit trails sets out the full record structure.

Where compliance advice goes wrong

The commonest failure is treating compliance as a gate at the end. A system designed without identity-aware retrieval cannot have it added cheaply, because the index was built without the metadata to filter on. The second failure is the opposite: a firm decides everything must be on-premise, spends eighteen months procuring hardware, and ships nothing. Most healthcare organisations have a mix of data sensitivities, and a protocol assistant over public clinical guidelines does not need the same perimeter as a discharge summariser.

The third is scope creep disguised as caution. Requiring a full model risk audit for a system that only drafts internal text, reviewed by a person before use, adds months without reducing risk. Match the control to the exposure and write down the reasoning, so the next reviewer does not reopen the question. A short, dated risk note against each feature saves more time over a programme than any amount of policy documentation.

What this looks like in a real build

A hospital network needed multilingual appointment booking. Booking is not a clinical decision, which lowered the governance bar, but the system still touched patient identity and phone numbers, which raised the data bar. The controls that mattered were call recording consent, retention limits on transcripts, an audit record of every booking action and a hand-off to a human whenever the agent was uncertain. It launched in shadow mode so staff could hear proposals before the agent acted. The build is described in the multilingual voice agent case study.

The sequencing lesson generalises. Separate the data question from the clinical question and answer them independently. Ask first what personal data the feature touches and where it may sit; ask second whether the output influences care, and therefore who must approve it. Features that score low on both, such as internal knowledge retrieval over policies, can ship in weeks. Features that score high on both deserve the full control set and a slower rollout, and mixing the two into a single governance conversation is how healthcare AI programmes stall for a year without anyone making a decision.

Checklist before the first patient record is touched

• Write down which rule sets apply, including any business associate obligations
• Decide residency and deployment before the data model is designed
• Confirm the source of truth for consent and how the system re-checks it
• Define the retention period for prompts, traces and transcripts, and automate it
• Name the reviewer for every patient-affecting output
• Agree the audit record fields with internal audit before you build them
• Plan shadow running and a weekly escalation review for the first quarter

Related reading

Patient data and AI goes deeper on consent, retention and access in India, HIPAA-aligned AI for healthcare providers covers the US control set, and our healthcare page describes the systems and constraints we build against. For a review of a specific design, get in touch.

Compliance in healthcare AI is not a document you attach at the end; it is the set of decisions that determine where your data lives and what your system can prove.