| Quick answer |
| To protect your AI healthcare product in India, treat it as five separate assets. The model may be patent-protectable when claimed as a technical system or device, but methods that perform diagnosis for treatment risk exclusion under Section 3(i). Training data and weights sit under trade-secret and contract, with DPDP Act overlay. AI-generated content falls under Section 2(d)(vi) Copyright. The brand uses trade marks; the interface uses designs. |
Five AI healthcare assets, five different protection regimes
An AI-enabled healthcare product rarely sits inside one IP regime. A startup building a retinal-screening tool is simultaneously building a diagnostic model (patent territory, with a diagnostic-method exclusion to navigate), a labelled training dataset curated from clinical partners (trade-secret territory, with DPDP Act obligations layered on top), a clinical report-writing module that generates patient-facing text (copyright territory, with an authorship question), a product brand (trade mark territory), and a device UI (design territory). Each regime asks different questions and expects different evidence.
| Your AI healthcare asset | Primary protection in India | One strategic move |
| Diagnostic or clinical-decision model | Patent (conditionally) | Frame the claim as a device or system with technical effect, not as a method of diagnosis |
| Training data, weights, fine-tuning | Trade secret + contract | No statutory trade-secret Act; lock with NDAs, IP assignment, access controls |
| AI-generated clinical content | Copyright (Section 2(d)(vi)) | Identify the human who “causes the work to be created” and contract authorship forward |
| Product brand and mark | Trade mark registration (Trade Marks Act 1999) | File in the human or corporate applicant’s name; AI design of the logo is not a bar |
| Device interface and wearable aesthetic | Design (Designs Act) | Human author named; documented contribution at prompt, iteration and selection stages |
Indian IP law was not written for AI, and the statutes in force in 2026 still assume a human creator, owner and applicant. What has changed is how the courts and the Patent Office apply those statutes to AI-enabled inventions, particularly after the 29 July 2025 CRI Guidelines and the 9 October 2025 Delhi High Court decisions on Section 3(i). The framework below is the broader four-regime picture in the horizontal AI-IP pillar applied vertically to healthcare assets, with two regulatory overlays unique to this vertical: the Digital Personal Data Protection Act 2023 (DPDP Act) for training data and the Central Drugs Standard Control Organisation (CDSCO) draft guidance on Medical Device Software.
The practical starting point is to list the product’s protectable components before reaching for a regime. A founder who files a patent before mapping the asset landscape typically protects one element and leaves four exposed. The sequence in the sections below runs from the most contested asset (the model) to the most operationally important (filing sequence), not from the most glamorous. A MedTech team reading in order gets a filing-and-contracting plan by the final section.
Protecting the AI diagnostic or clinical-decision model: patents and the Section 3(i) boundary
The model is the most patent-visible asset, and the most legally constrained. Two Patents Act 1970 provisions do the work: Section 3(i) excludes any process for medical diagnosis or treatment of human beings, and Section 3(k) excludes a computer programme per se and an algorithm. Section 10(4) controls the enablement standard for the specification.
Between October 2025 and March 2026 the Delhi High Court issued five decisions on Section 3(i). The Sequenom, Natera and EMD Millipore judgments on 9 October 2025 (Justice Prathiba M. Singh), Hirotsu Bio Science on 17 January 2026 (Justice Karia), and Geron Corporation on 17 March 2026 (Justice Arora) together indicate that substance is treated as governing over labelling, although as single-judge decisions they remain an emerging trend rather than a settled doctrinal position. A method that identifies pathology for treatment attracts Section 3(i) regardless of whether it is styled as “screening,” “detection,” “in vitro analysis,” or a computer-implemented pipeline. High diagnostic accuracy is treated as evidence that the method is diagnostic in substance, not as an independent trigger.
For a MedTech AI team the practical consequence is that claim framing, not subject matter avoidance, carries the patent. A model that classifies a chest CT for pulmonary nodules and outputs a clinician-facing report attracts Section 3(i) where its claimed functionality performs the diagnostic determination. A model embedded in the imaging device that improves reconstruction latency, signal-to-noise ratio, or acquisition-pipeline throughput does not, because its capability does not extend to identifying pathology. Device claims, system claims, and technical-process claims remain available; method-of-diagnosis claims do not.
Section 3(k) is separately navigable for software-implemented models. Following Ferid Allani v Union of India (Delhi HC, 12 December 2019) and the 2025 CRI Guidelines, an invention that produces a concrete and measurable technical effect is not excluded merely because it is implemented in software. The Guidelines’ Table 1 identifies “technical implementation of medical image analysis using inventive algorithms to detect anomalies or enhance image quality leading to better technical outcome” as a category that may not fall under the exclusion. The full Guidelines text is published on the IP India portal. The practitioner move is to quantify the technical effect in the specification (measured latency reduction, measured precision improvement over a named baseline, measured compute-cost reduction), and locate the inventive contribution at the system, process, or data-transformation level rather than the clinical-output level.
Section 10(4) enablement is where MedTech AI specifications typically fail. Caleb Suresh Motupalli v Controller of Patents (Madras HC, 29 January 2025) confirmed that the person skilled in the art for an interdisciplinary invention is a team, not a single specialist. For a medical-imaging AI invention the team is typically a model-design software engineer, a data scientist familiar with annotation protocols, and the relevant clinician. The specification has to satisfy each discipline’s reproducibility question, calibrated to where the inventive step lies, with architectural detail where architecture is inventive, dataset traits where those traits are inventive (CRI Scenario 6 is explicit on this conditionality), training methodology where the methodology is inventive.
Protecting training data, weights, and clinical-partner pipelines: trade secret, contract, and DPDP
Training data and model weights are the assets most founders most worry about and India protects most indirectly. India has no trade-secret statute; confidentiality rests on the common law of confidence, NDAs, employment IP-assignment clauses, clinical-partner licensing terms and technical access controls. For a MedTech AI team this is an operational architecture question rather than a filing question. The protection stack is contractual and procedural, not registered.
Four building blocks carry most of the load. NDAs at every external boundary, including annotation vendors, clinical-partner hospitals, evaluation contractors, and red-teaming partners. Employment IP-assignment clauses that capture model improvements, prompts, fine-tuning datasets, and clinical-domain adaptation work. Access controls and audit logging that establish reasonable measures of secrecy, the evidentiary foundation for any future breach-of-confidence claim. Licensing terms on outbound distribution, including restrictions on fine-tuning, reverse engineering and redistribution of weights.
The DPDP Act 2023 adds a statutory layer on the same training data, because personal data in digital form processed within India, or processed outside India in connection with offering goods or services to Indian Data Principals, falls within its scope under Section 3. A MedTech AI model trained on labelled patient images or clinical records is processing digital personal data. The Data Fiduciary obligations follow: consent under Section 6 that is “free, specific, informed, unconditional and unambiguous” and “limited to such personal data as is necessary for such specified purpose”; reasonable security safeguards under Section 8(5), breach of which may attract a monetary penalty up to Rs 250 crore under the Schedule, imposed by the Data Protection Board after inquiry under Section 33; and Data Protection Officer and audit obligations under Section 10 where the Central Government notifies the entity as a Significant Data Fiduciary.
The research exemption under Section 17(2)(b) is narrow and tempts misreading. It permits processing for research, archiving or statistical purposes only where “the personal data is not to be used to take any decision specific to a Data Principal” and the processing meets prescribed standards. A training pipeline that flows into a production model making per-patient diagnostic classifications does not qualify, because the end model makes decisions specific to individual Data Principals. Research-purpose consent obtained from a clinical partner’s patient cohort therefore does not, without more, authorise downstream commercial deployment. Although the DPDP Act and Rules are being implemented in a phased manner, AI-healthcare teams should design consent, notice, purpose-limitation, security, breach-response, and vendor-governance processes now, because clinical datasets are difficult to regularise retrospectively. The IP and data privacy interaction analysis covers this overlap in more detail.
Three operational moves follow. Structure consent language to cover both the research-stage training and the production-stage inference use, named specifically, not by reference. Document the legitimate-basis analysis at each processing stage, not retrospectively. Align the training-data characterisation needed for Section 10(4) patent disclosure with the dataset description used for DPDP purpose limitation, since the same dataset narrative that supports enablement supports the Data Fiduciary’s purpose record. Separately, the pending Delhi High Court judgment in ANI Media v OpenAI on whether Section 52 fair-dealing reaches AI training will change the position on publicly scraped text data but not on clinically sourced data, which is consent-governed regardless of how the copyright-training question resolves. For the copyright-training litigation backdrop see the training-data copyright litigation note.
Protecting AI-generated clinical content: copyright under Section 2(d)(vi)
Modern AI healthcare products generate text. Clinical note drafts, discharge summaries, radiology-report first drafts, triage messages, patient-facing explainers. These are copyrightable literary works, and the ownership question is settled by Section 2(d)(vi) of the Copyright Act 1957, which provides that for a computer-generated literary, dramatic, musical or artistic work, the author is “the person who causes the work to be created.”
The statute points to a “person” who causes the work to be created. “Person” includes corporate persons under general Indian law, so deployment-chain candidates extend across both human and corporate participants, but the statute does not identify which one. For an AI medical-scribe or clinical-content product these candidates include the treating clinician prompting the tool, the MedTech company operating the model, the model developer whose pre-trained weights are upstream, and the hospital deploying it. Indian courts have not ruled on the allocation; Indian copyright office practice on the Suryast registration (ROC No. A-135120/2020, co-authored with an AI tool named RAGHAV, November 2020) is a regulatory signal of uncertainty rather than a binding precedent. The practical resolution is contractual: who in the deployment chain supplies the skill, labour and judgment that shapes the output and who takes the IP assignment for it.
For a healthcare AI company this means three drafting steps in the deployment contract. First, allocate authorship explicitly between the operator, the clinician user, and the hospital, because the default allocation in silence is uncertain. Second, capture an assignment of any authorship that otherwise arises in the clinician user’s favour. Third, distinguish the model code itself (a literary work under Section 2(o), ordinarily owned by the developer or assignee), from the outputs the model generates (Section 2(d)(vi), governed by deployment context). Code and outputs are separate assets with separate ownership rules. The broader treatment of authorship of AI-generated works is a useful companion read.
Copyright registration is not mandatory but is evidentially useful under the Copyright Rules 2013, particularly where the AI-generated output may later be contested or licensed to hospitals, clearinghouses or platforms.
Protecting the MedTech product brand and the device interface: trade marks and designs
The brand around the AI healthcare product is protectable as a trade mark under the Trade Marks Act 1999, on ordinary grounds. Section 9(1)(a) requires a mark that has distinctive character, meaning it is “capable of distinguishing the goods or services of one person from those of another person.” Whether the mark was designed by a human, generated by an image model, or selected from a generative-AI proposal set does not change the registrability question; the distinctiveness test is judged from the perspective of the average consumer, not the average algorithm.
The practical consideration for MedTech AI brands is clearance, not filing mechanics. The full trademark registration process in India sits behind the Section 9 (absolute grounds) and Section 11 (relative grounds) filters. Section 11 cuts across NICE classes where channels of trade overlap. For an AI healthcare product the relevant classes typically include Class 10 (medical devices), Class 42 (software services), Class 44 (medical services), and Class 9 (downloadable software). Pre-filing clearance should cover registered MedTech marks and adjacent device-industry and pharmaceutical marks.
The device interface and the wearable aesthetic are protectable as industrial designs under the Designs Act 2000 where they are applied to a physical article or device display, registered under Section 2(d) for shape, configuration, pattern, or ornament judged solely by the eye. For pure AI-app screen flows without a physical anchor, design registrability is less settled in Indian practice; copyright in the visual elements alongside contractual protection against unfair copying may be the more realistic stack. The originality hurdle: Section 2(g) defines “original” as “originating from the author of such design.” A design generated with no meaningful human contribution may face vulnerability on authorship grounds at registration or in a Section 19 cancellation challenge. Documentation of human contribution at the prompt, iteration and selection stages is the practical workaround.
Where the same AI-generated visual has both industrial application and artistic value (a medical-app icon set, for example), Section 15 of the Copyright Act removes copyright protection on industrial application beyond fifty reproductions unless the design has been registered under the Designs Act. Design registration is the protection that survives scale.
Decision guide: what to file, when, and in what sequence
A MedTech AI team making a protection plan in 2026 runs five decisions in sequence, driven by the asset rather than the regime.
Decision one, the model. Identify whether the inventive contribution sits in the architecture, the training methodology, or the deployment system. File the patent around the element that carries the contribution, framed as a device, system, or technical-process claim. Avoid method-of-diagnosis framing. File provisional first where the invention is still being characterised; the 12-month priority window preserves the option of refining the specification as training and validation data mature.
Decision two, the data and weights. Do not file anything. Put the protection architecture in place before the first clinical-partner arrangement is signed. Standardise an NDA template, an employment IP-assignment clause, a clinical-data-use agreement, and a weights-licensing template. Document access controls and data-flow topology from day one; retrofitting the evidentiary record after a breach is difficult.
Decision three, the generated content. Map who in the deployment chain generates what, and contract authorship and assignment accordingly. For hospital deployments, the contract with the hospital should carry an express clause on ownership of AI-generated outputs and an indemnity structure for content that later proves problematic. Copyright registration is optional; use it where the output is commercially significant or likely to be contested.
Decision four, the brand. Run the clearance search before the product name is publicly committed. File the trade mark application in the company’s name under Form TM-A. Consider a second-level filing for a distinctive product feature mark where the AI functionality itself is the differentiator (for example, a named scan protocol or a named diagnostic routine).
Decision five, the interface and device aesthetic. Where the product has a physical form or a distinctive visual interface, file design registrations for both. Document the human design contribution. Where the product is a software-as-medical-device (SaMD), plan the patent timeline and the SaMD clinical-validation timeline together. CDSCO’s October 2025 draft guidance on Medical Device Software signals a four-tier risk classification (Classes A through D) and indicates that AI cancer-detection and diagnostic software may be treated as higher-risk software, with Class C treatment indicated in the draft, subject to confirmation under the Medical Devices Rules 2017, final CDSCO notification, and product-specific classification. Validation evidence produced for SaMD clearance is the same evidence that strengthens the Section 10(4) enablement record, and filing the patent after validation produces a materially stronger prosecution record than filing before.
The overall sequence: contract architecture for data and weights first, because the downstream patent and copyright positions depend on clean data provenance; trade-mark clearance second, because the brand cannot be changed cheaply after launch; patents third, timed against regulatory validation; copyright as needed; designs at or before commercial launch.
Frequently Asked Questions
Pure diagnostic-method claims face serious risk under Section 3(i) of the Patents Act 1970. Where the contribution can be claimed as a device, system, or technical data-processing pipeline whose output is not itself a diagnosis for treatment, patent protection may be available. The Delhi High Court between October 2025 and March 2026 treats substance as governing over labelling, which means careful claim framing carries the patent.
Section 2(d)(vi) of the Copyright Act 1957 provides that for a computer-generated literary work, the author is “the person who causes the work to be created.” The provision does not resolve who that person is in a multi-party AI deployment chain, and corporate persons can qualify as well as natural persons. Allocation is resolved by contract: register authorship explicitly in the deployment agreement.
India has no trade-secret statute as at April 2026. Protection rests on the common law of confidence, NDAs, employment IP-assignment clauses, and access controls. The protection architecture is contractual and operational, not registered. A well-drafted four-element stack (NDA, IP assignment, access controls, outbound-licensing restrictions) is what Indian courts recognise in a breach-of-confidence action.
The DPDP Act 2023 regulates how training data is collected and used, not whether the resulting model is patentable. The operational overlap is in Section 10(4) disclosure: the dataset characterisation needed for patent enablement is the same description that supports the Data Fiduciary’s purpose record under Section 6. Aligning the two records strengthens both positions; misaligning them exposes both.
No. Patentability and regulatory approval are independent. CDSCO’s October 2025 draft guidance on Medical Device Software signals that AI cancer-detection software may be treated as higher-risk software, with Class C treatment indicated in the draft; final classification awaits the Medical Devices Rules 2017, final CDSCO notification, and product-specific assessment.
The Designs Act 2000 protects the interface as an industrial design, provided a human designer is named and the design is “original” under Section 2(g), meaning originating from the author. A design generated autonomously by a model without human direction has no statutory author and is vulnerable at registration. Document the human contribution to prompt, iteration, and selection.
Disclaimer
This article is for informational purposes only and does not constitute legal advice. Indian IP and data-protection law as applied to AI healthcare products remains in active development, and specific outcomes depend on the invention, the dataset, and the deployment context. DPDP Rules 2025 provisions relating to Data Fiduciary obligations are staged; the substantive compliance phase takes effect on 13 May 2027. Verify current applicability before relying on any specific provision. For advice on a specific product or pending application, consult a registered Indian patent agent or qualified IP counsel. Verified as of April 2026.