If the AI gets it wrong, who is liable?

When a clinical AI tool contributes to an error, our working reading is that liability splits by what failed. Clinical judgment sits with the clinician who acted on the output, and vicariously with the hospital. System behaviour sits with the vendor. Deployment sits with the hospital, because the hospital decides how the tool is used.

That split is the core of the answer, and almost nobody states it plainly. Vendors blur it to promise more. Hospitals blur it because the clean version shows how much stays with them. A Medical Director signing off on an ambient scribe or a triage assistant needs the uncomfortable version, so here it is, failure class by failure class, with the questions your counsel should answer before you sign.

Clinical judgment: the case law predates AI

Indian medical negligence law predates every model on the market, and it attaches to the professional who makes the decision. In Indian Medical Association v. V.P. Shantha (13 November 1995), the Supreme Court brought medical services under consumer protection law, which opened the consumer commissions to negligence claims against doctors and hospitals. In Jacob Mathew v. State of Punjab (5 August 2005), the Court set the standard for criminal negligence: the doctor must have fallen short of the care a reasonably competent practitioner would exercise, and the lapse must be gross. Section 106(1) of the Bharatiya Nyaya Sanhita 2023, which replaced Section 304A of the Indian Penal Code, carries a specific provision for registered medical practitioners.

These tests ask whether the doctor exercised reasonable professional judgment. They say nothing about software. Our working reading is that a clinician who accepts an AI suggestion without the scrutiny a competent peer would apply has made a professional decision, and that the hospital sits behind it. In Savita Garg v. Director, National Heart Institute (2004), the Supreme Court placed the burden on the hospital to show who treated the patient and that they took due care.

Take three questions to counsel. Does any reading of these cases let a hospital move responsibility for a clinician's decision onto a software vendor? Would a vendor clause indemnifying clinical judgment survive a complaint from a patient's family? How would a court or consumer commission treat a note the clinician signed but did not write? We know of no CDSCO or NMC pathway that moves clinical accountability onto a software company. Nextdot does not sell indemnity it cannot legally deliver, and any vendor telling a hospital otherwise is selling comfort.

What the NMC has said, and what it has not

The National Medical Commission has not issued a regulation on AI in clinical decisions. What exists is direction of travel. On 1 January 2026, NMC Chairperson Dr Abhijat Sheth told ANI that AI practice in healthcare must not compromise ethical and clinical values, and that AI should not replace doctors (reported by The Week, 3 January 2026). Education has come before binding rules: the National Board of Examinations in Medical Sciences (NBEMS), which Dr Sheth also heads, opened applications for a free AI course for doctors on 30 December 2025.

For a hospital, the prudent working assumption is that any AI output a doctor acts on becomes part of that doctor's clinical decision, until the Commission writes something AI-specific. Ask counsel whether the current professional conduct framework supports that assumption, and what would change it.

System behaviour: what a vendor can actually own

The vendor's share is real and it is specific. It covers failures of the system itself:

• Output outside the intended-use envelope the vendor documented.
• A note attributed to the wrong encounter or the wrong patient.
• Retrieval that pulls the wrong record into context.
• Uptime breaches against the agreed service level.
• Data protection obligations the vendor carries as a Data Processor under DPDP 2023.

Each of these belongs in the contract as a measurable commitment: accuracy thresholds tied to the intended use, an SLA with defined uptime, and indemnity for system behaviour. The DPDP layer deserves attention now. The DPDP Rules were notified on 14 November 2025, with the main substantive obligations phasing in over eighteen months (PIB, November 2025). The hospital is the Data Fiduciary and answers to the Data Protection Board. The vendor answers to the hospital, by contract, for how it processed the data.

A vendor who cannot list its own failure classes in this form has not been through a serious legal review.

Deployment: the hospital's operational control

The third class is the one hospitals most often forget they own. Every clinical AI deployment should carry two documents: an intended-use statement that says what the system is for and what it is not for, and a mandatory human review step. Nextdot writes both into every engagement.

Once those exist, a large set of failures moves into operations. A site that runs the tool outside its stated envelope, for a specialty or patient group it was not scoped for, has made a deployment decision. A clinician who signs an ambient note without reading it has skipped the review step the hospital committed to. Both are failures of operational control, and they sit with the hospital's clinical governance.

The intended-use statement matters more than any accuracy claim, because it draws the boundary between the vendor's failure class and the hospital's.

Where CDSCO changes the picture

Intended use also bears on a regulatory question. The Medical Devices Rules 2017 define medical devices to include software intended for diagnosis, prevention, monitoring or treatment. CDSCO issued draft guidance on medical device software on 21 October 2025 and finalised it on 30 July 2026, according to Emergo by UL. The guidance separates software in a device from software as a medical device, classifies standalone software into Classes A to D by the healthcare context and the significance of its output to the decision, and asks manufacturers of AI software to disclose training data composition, bias and generalisability.

A scribe that transcribes and structures what the clinician said looks very different from a tool that suggests a diagnosis or a dose. The closer the output sits to the clinical decision, the more the device question matters in your file. Ask every vendor, in writing, whether they believe their intended use brings the product under the device rules and what class they think applies. Then ask your own regulatory counsel whether they agree.

Clinical validation and the ethics committee

Two different activities get confused here, and the confusion causes real exposure.

The ICMR Ethical Guidelines for Application of Artificial Intelligence in Biomedical Research and Healthcare (March 2023) address creators, clinicians, institutions and ethics committees directly, and set out an ethics review process for AI. They sit alongside the ICMR National Ethical Guidelines of 2017. A prospective study that compares AI output against clinician judgment on real patients looks like research. Where the product is a device under clinical investigation, the Medical Devices Rules 2017 add their own approval requirements.

Routine use of a licensed or non-device tool inside its intended use looks more like clinical governance. Where that line falls for your tool is a question for your institutional ethics committee and counsel, and routing new clinical AI through the ethics committee or a clinical AI governance board is the defensible default. What matters in a later dispute is that you can show the tool was validated for the population it served, that a qualified person reviewed that validation, and that the decision to deploy was minuted.

Keep the intended-use statement, the validation evidence, the review step as written into SOPs, training records for the clinicians using it, and the vendor's device status.

None of this works unless you can reconstruct what happened

Here is the hinge. Every allocation above depends on proving which failure class you are in. Was the output inside the envelope? Did the clinician see it, change it, or sign it unread? Which model version and which prompt produced it? Without the record, the dispute is likely to settle on the clinician and the hospital, because they are the parties the existing case law already reaches.

Reconstruction needs three things: audit logs of inputs and outputs, versioned models and prompts, and captured human overrides. Nextdot runs all three as standard on every deployment. Formal evaluation against clinician-labelled ground truth is a harder discipline, and it does not yet run on every Nextdot account. Extending it is a current engineering priority, and a hospital should hear that from its vendor directly.

The test that exposes most vendors takes one sentence. Ask to see the last thirty overrides. At a hospital with an incumbent AI vendor, there is almost never an answer. A vendor who cannot produce that record cannot help you prove the failure was theirs, which means it becomes yours.

Frequently asked questions