On this page · 13 sections
- The seven hurdles at a glance
- 1. Classify the software correctly
- 2. File with the right licensing authority
- 3. Build the technical evidence an AI submission needs
- 4. Plan for model updates with an Adaptive Change Protocol
- 5. Meet the DPDP Act as a Data Fiduciary
- 6. Handle health data as sensitive, including de-identified data
- 7. Follow ICMR ethics and own the liability question
- India-specific considerations
- A pre-deployment checklist
- FAQ
- How eCorpIT can help
- References
Summary. Clinical AI in India is moving from pilots to real deployment in 2026, and two regulators sit between a model and the bedside. The Central Drugs Standard Control Organisation (CDSCO) treats clinical software as a medical device under the Medical Device Rules 2017, and on October 21, 2025 it released draft guidance on Medical Device Software that classifies AI diagnostic tools by risk into Class A to D. The Digital Personal Data Protection Act (DPDP) 2023, with its 2025 Rules, makes every hospital, lab, and health-tech vendor a Data Fiduciary for patient data, with penalties reaching ₹250 crore. India has the demand and the rails: the Ayushman Bharat Digital Mission (ABDM) had issued about 799 million digital health IDs by August 2025. This guide sets out 7 CDSCO and DPDP hurdles to clear before you deploy clinical AI, with what each one demands. Treat it as a planning checklist, not legal advice.
The opportunity is real, and so is the gap many teams miss: a clinical-AI product is regulated twice over. It is a medical device in the eyes of CDSCO and a processor of sensitive personal data in the eyes of the DPDP regime. Clear one and you can still be blocked by the other. The seven hurdles below are the ones that decide whether a model reaches patients or stalls in review.
The seven hurdles at a glance
| Hurdle | What it requires | Regulator |
|---|---|---|
| 1. Classify the software | SaMD vs SiMD, then Class A to D | CDSCO |
| 2. File with the right authority | State for A and B, CDSCO for C and D | CDSCO |
| 3. Build the technical evidence | Datasets, validation, algorithm logic | CDSCO |
| 4. Plan model updates | Adaptive Change Protocol for changes | CDSCO |
| 5. Meet DPDP as a Data Fiduciary | Consent, security, breach notice | DPDP |
| 6. Handle health data as sensitive | Localisation, de-identification limits | DPDP |
| 7. Follow ICMR ethics and own liability | Transparency, safety, accountability | ICMR and courts |
1. Classify the software correctly
Everything downstream depends on getting this right. CDSCO's draft guidance separates Software as a Medical Device (SaMD), standalone software that performs a medical purpose on its own, from Software in a Medical Device (SiMD), which is embedded in hardware and takes the device's classification. A diagnostic algorithm that reads scans is SaMD; firmware inside an infusion pump is SiMD.
SaMD then sits in a risk-based class from A to D, driven by two factors: the significance of the information the software provides and the seriousness of the clinical situation it addresses. Software that diagnoses or guides treatment in critical or life-threatening scenarios, an AI cancer-detection tool or an autonomous diagnostic system, attracts the highest class, D. Misclassifying your product is the most expensive early mistake, because it routes you to the wrong authority and the wrong evidence burden.
| Category | Risk and example | Licensing authority |
|---|---|---|
| SiMD | Takes the parent hardware device's class | Follows the device |
| Class A | Low risk, simple data display | State Licensing Authority |
| Class B | Low to moderate risk | State Licensing Authority |
| Class C | Moderate to high risk | CDSCO Central Licensing Authority |
| Class D | High risk, diagnoses critical conditions | CDSCO Central Licensing Authority |
2. File with the right licensing authority
Classification decides who reviews you. Class A and Class B SaMD are licensed by State Licensing Authorities, while Class C and Class D fall to CDSCO's Central Licensing Authority at the national level. Applications go through the CDSCO Medical Device Online Portal for manufacturing and import approvals.
For most clinical-AI products that inform diagnosis or treatment, that means the central route and a higher bar. Build the regulatory plan around the class first: a Class D diagnostic tool and a Class B wellness aid face different reviewers, timelines, and evidence requirements, and assuming the lighter path because the software looks simple is a common and costly error.
3. Build the technical evidence an AI submission needs
Here is the nuance that catches AI teams. India's Medical Device Rules and the CDSCO draft guidance do not yet contain AI- or ML-specific rules. The draft guidance clarifies how existing rules apply to software rather than creating new ones, and it remains in draft, with the consultation period closed and a final version pending. That absence is not a free pass. The emphasis on technical documentation and risk classification means an AI developer must be ready to explain datasets, validation methods, and algorithmic logic in the submission.
In practice, prepare the evidence a reviewer will expect even though no rule names it: what data the model was trained and validated on, how representative it is of the Indian patient population, how performance was measured, and where the model can fail. Industry bodies have pushed for exactly this clarity. The Medical Technology Association of India (MTaI) welcomed the draft but urged CDSCO to sharpen clinical-evaluation protocols and algorithm-change management for AI and ML devices, while Nasscom filed its own recommendations.
4. Plan for model updates with an Adaptive Change Protocol
AI models change, and regulators know a static approval does not fit a system that retrains. CDSCO's framework allows an Adaptive Change Protocol (ACP): once a licensing authority approves it, predefined updates can proceed without separate approval for each change. For a learning system, this is the mechanism that lets you ship improvements without re-filing every time.
The limits matter. An approved ACP is not, by itself, regulatory approval of the software, and it does not dilute ongoing obligations for safety, quality, or post-market surveillance. So design your change-management process up front: define which updates fall inside the protocol, monitor performance in the field, and keep the post-market reporting that the class demands. The teams that struggle are the ones that treat approval as the finish line rather than the start of a monitored lifecycle.
5. Meet the DPDP Act as a Data Fiduciary
The second regulator is data protection, and it is not optional. Under the DPDP Act 2023 and its 2025 Rules, hospitals, clinics, diagnostics labs, health-tech platforms, and pharmaceutical companies are all classed as Data Fiduciaries, directly responsible for lawful, secure processing of patient data. The duties are concrete: obtain clear consent, secure the data, and notify breaches. Penalties under the regime reach up to ₹250 crore, the same framework reshaping other sectors that we cover in our DPDP playbook for D2C.
For a clinical-AI vendor, the practical consequence is that your model's data pipeline is now a regulated system. We design clinical-AI data flows aligned with DPDP requirements rather than claiming any deployment is automatically compliant. Map where patient data enters the model, where it is stored and processed, and how consent and deletion are honoured, because a brilliant model with an unlawful data pipeline cannot ship.
6. Handle health data as sensitive, including de-identified data
Health data carries extra weight, and a common shortcut does not hold. Cloud-deployed clinical AI must meet DPDP expectations on consent, security, and breach notification, and a cautious reading treats even de-identified data as sensitive, requiring consent or ethics approval. Some hospitals fold a broad consent into admission forms, but its adequacy under the new law is uncertain, so relying on it alone is a risk.
Two design choices follow. Decide your lawful basis for every data use, training, validation, and inference, rather than assuming de-identification removes the obligation. And plan for data localisation and residency, because where patient data is processed is now a compliance question, not just an architecture one. For cloud or cross-border AI, that can decide which deployment model is even permissible.
7. Follow ICMR ethics and own the liability question
Beyond the two regulators sits a third layer: ethics and accountability. The Indian Council of Medical Research (ICMR) published ethical guidelines for AI in biomedical research and healthcare in 2023, centred on patient safety, privacy, and transparency. These are not binding law in the way CDSCO licensing is, but they set the standard a hospital ethics committee and a court will reference.
The unsettled part is liability. When an AI diagnostic tool contributes to an error, who is responsible, the clinician, the hospital, or the vendor, is an open question Indian law has not fully resolved. For a vendor, that means building explainability and clear human-oversight points into the product, documenting the model's limits, and being explicit about where a clinician must stay in the loop. Treat the liability gap as a design constraint, not a footnote, because it shapes how the product should behave at the point of care. This sits inside the wider discipline of an enterprise AI strategy for regulated environments.
India-specific considerations
India's advantage is its digital health infrastructure. ABDM had issued roughly 799 million digital health IDs by August 2025, with hundreds of thousands of facilities and professionals registered, which gives clinical AI a federated data backbone few markets can match. The constraint is that this scale raises the stakes on both regulators at once: more data flowing means more DPDP exposure, and more clinical use means more CDSCO scrutiny. The realistic Indian path is to design for both from day one, classify correctly with CDSCO and build a DPDP-lawful data pipeline in parallel, rather than treating compliance as a step after the model works. A model proven in a pilot but built on an unlawful data flow or the wrong device class has to be rebuilt, not just relicensed.
A pre-deployment checklist
Confirm whether your product is SaMD or SiMD, then fix its risk class before anything else. Map the class to its licensing authority, State for A and B, CDSCO Central for C and D. Assemble the technical file a reviewer expects: dataset provenance, validation, performance, and failure modes. Define an Adaptive Change Protocol for model updates and the post-market monitoring around it. Stand up a DPDP-lawful data pipeline with consent, security, localisation, and breach processes. Treat de-identified health data as sensitive. And build ICMR-aligned transparency and clear human oversight so the liability question has a defensible answer.
FAQ
How eCorpIT can help
eCorpIT is a senior-led technology consulting organisation in Gurugram that helps healthcare founders, hospital CIOs, and clinical-AI vendors deploy inside India's rules. We help classify your software for CDSCO, assemble the technical evidence an AI submission needs, design an Adaptive Change Protocol for model updates, and build a data pipeline aligned with the DPDP Act and ICMR ethical guidelines, with human-oversight and explainability designed in. If you are taking a clinical-AI product from pilot to deployment, contact us to map the CDSCO and DPDP path before you build. This guide is general information, not legal advice.
References
_Last updated: June 22, 2026._
