India’s Digital Personal Data Protection Act, passed in August 2023 with its implementing Rules notified in November 2025, defines personal data narrowly and specifically: data about an individual who is identifiable, directly or indirectly, by reference to that data. The Act applies only to data meeting that definition — not to data in general, and this distinction matters more for laboratories than the broader public conversation around DPDP tends to acknowledge.
A straightforward reading follows directly from that definition, and it’s worth stating plainly: an instrument reading, an environmental-monitoring log, or a quality-control batch record, on its own, with no link to an identifiable person, sits outside DPDP’s scope. A great deal of what a LIMS or ELN manages day to day — calibration records, reagent tracking, method parameters, equipment logs — simply isn’t personal data as the Act defines it.
Where this gets genuinely more complicated is in clinical, diagnostic, and research contexts, where laboratory data frequently does connect back to an identifiable person, and legal analysis specifically addressing pharmaceutical and life-sciences data handling has flagged a sharper point still: even when identifiers are replaced with codes, as is standard practice in clinical trials, that data may still constitute personal data under DPDP if re-identification is reasonably possible. Coding a sample doesn’t automatically exempt it. And responsibility for getting this right is structured in a way worth understanding precisely: contract research organisations, laboratories, and cloud or software vendors processing data on a sponsor’s instructions typically act as “data processors” under the Act, while primary compliance liability sits with whoever is the “data fiduciary” — usually the sponsor — even when the actual processing work has been outsourced. A laboratory running someone else’s samples through its LIMS does not automatically inherit that sponsor’s full DPDP liability, but it also isn’t automatically insulated from it either. This is genuinely fact-specific, contract-specific territory, and this piece is not positioned to tell any individual laboratory where it sits on that spectrum.
Vendor Lock-In: A Familiar Problem With No Clean Fix
The interoperability difficulties examined in Section 4 have a longer tail than migration headaches. Once a laboratory’s data lives inside a particular vendor’s LIMS or ELN, moving to a different platform later carries real switching costs — not just financial, but in the time, validation burden, and risk of the kind of migration errors already described. Laboratory-informatics guidance is candid that any vendor who downplays this complexity in a sales conversation is a vendor worth treating with caution; a well-scoped, honestly resourced migration is a manageable project, but one rushed or underfunded on the promise that switching platforms will be simple is a common way laboratories end up trapped by systems that no longer serve them.
There is no regulatory fix for this the way Schedule M addresses audit trails. Vendor lock-in is, at bottom, a commercial and contractual problem — solvable, where it’s solved at all, through data-portability clauses negotiated before signing, not through anything CDSCO or NABL currently mandates.
AI Liability: The First Real Precedent Just Arrived
This is where the research for this section turned up something genuinely significant, and current. On 2 April 2026, the FDA issued its first-ever warning letter explicitly citing AI misuse as a compliance violation — sent to Purolea Cosmetics Lab, and reported in detail by Pharmaceutical Technology with the actual warning letter number and citation. The finding: the firm had used AI agents to generate drug product specifications, procedures, and master production and control records, and failed to review the resulting documents for accuracy and CGMP compliance before putting them to use — a direct violation of 21 CFR 211.22(c). A related process-validation gap surfaced too, one the firm told investigators its AI agent had simply failed to identify, cited separately under 21 CFR 211.100.
This letter is, as of this writing, the closest thing available to a real regulatory answer to the question this section set out to examine: who is responsible when AI-assisted laboratory or quality decisions turn out to be wrong? The FDA’s answer, at least in this case, was unambiguous. The firm was. Using an AI agent to draft a document does not transfer, reduce, or defer the human obligation to review that document for accuracy before it enters a regulated record. The tool can assist. It cannot absorb the liability.
It’s worth noting this precedent involves cosmetics-lab GMP documentation specifically, not a laboratory LIMS or ELN system generating an AI-flagged test result — the underlying regulatory logic, however, travels well beyond that specific context. A quality system that lets an AI-generated recommendation reach a regulated record without documented human review is exposed, regardless of which specific software produced the recommendation.
– Mahesh N Kondaveeti
