I spent a year and a bit as architecture lead on a global platform at a pharmaceutical company, which is where I learned that "we cannot deploy on Friday" can be a regulatory position rather than a cultural one.
Life sciences software sits on a fault line. On one side, computational biology has advanced fast enough to change what researchers ask software to do. On the other, the regulatory framework governing systems used in regulated activities was designed around the assumption that software changes rarely and is validated exhaustively when it does. Reconciling those is, in my view, the defining engineering problem in the sector.
What structure prediction actually changed
Protein structure prediction going from a multi-year experimental effort to a compute job is the headline, and it deserves the attention. But the second-order effects are the ones that reshaped software requirements.
Structures became abundant rather than precious. When a structure was a PhD's worth of work, the software around it was a viewer. When you can predict a proteome, the software becomes a pipeline — screening, docking at scale, comparing, ranking — and the bottleneck moves to data management and orchestration.
The extension into complexes and interactions — protein with ligand, nucleic acid, ion — is what made this directly relevant to drug discovery rather than structural biology alone. And generative protein design turns the pipeline around entirely: instead of predicting what a sequence does, you specify a function and search for sequences. That is a fundamentally different workload, and one where the wet lab is now the validation step for a computational hypothesis rather than the origin of it.
The infrastructure implication is unromantic. These are GPU-hungry batch workloads with enormous intermediate artefacts and results that must be reproducible years later for a filing. That means content-addressed storage, pinned container images, recorded random seeds, and provenance for every artefact. Reproducibility is not a nice engineering property here; it is what makes the result usable in a submission.
The validation problem, stated fairly
If a computerised system is used in a regulated activity — manufacturing, quality, clinical, anything touching a submission — you must demonstrate it is fit for purpose. Electronic records and signatures carry specific requirements: audit trails, access controls, record integrity, the ability to reconstruct who did what and when.
The historical interpretation produced enormous documentation sets, testing every function against written specifications, with change control that made any modification expensive. Which is why so much pharma software is a decade behind — not because the engineers did not know better, but because the cost of change was deliberately made high.
The reframing that has been gaining ground is critical thinking and risk-based assurance: focus effort proportional to patient risk and product quality impact, rely on supplier testing where it is credible, and use automated testing as evidence rather than re-executing everything manually with screenshots.
That reframing is what lets modern engineering practice into the building. Specifically:
| Traditional CSV | Risk-based assurance |
|---|---|
| Test every function equally | Effort proportional to risk |
| Manual execution, screenshot evidence | Automated tests as primary evidence |
| Re-validate everything on change | Impact-assessed, targeted revalidation |
| Documentation as deliverable | Documentation as by-product of the pipeline |
The last row is the one worth chasing. If your CI pipeline emits a signed, timestamped, immutable record of which tests ran against which commit with what result, you have generated better validation evidence than a manual protocol — because it is complete, tamper-evident and produced automatically every time.
I will be honest that getting a quality organisation comfortable with this is slower than building it. The argument that worked for us was not technical: it was demonstrating that the automated evidence answered auditor questions faster than the binder did.
The lab data problem
Every research organisation has the same shape of mess. Instruments from a dozen vendors, each with proprietary output formats. An electronic lab notebook that half the scientists use as intended. A LIMS that is authoritative for sample state and nothing else. Analysis happening in notebooks on laptops.
The consequence is that the most expensive asset — experimental data — is the least findable. I have watched an experiment be repeated because nobody could locate the previous result, which is the most expensive possible outcome of a metadata failure.
What actually helps, in the order I would attempt it:
- A sample and entity identifier scheme that everything references. Boring, foundational, and skipped constantly. If a sample has three identifiers across three systems, nothing else works.
- Instrument integration as a platform capability, not per-project scripts. Standards for lab device interfaces and analytical data exist; adopting them where instruments support them removes a category of bespoke parsing.
- Data contracts between the lab and the analysis layer. Same idea as any other domain: a documented schema that both sides agreed to, versioned.
- Rich metadata capture at the point of generation. Nobody will backfill it. If it is not captured when the experiment runs, it does not exist.
Note that none of these are analytics. Organisations reliably want to buy the analytics layer and skip the identifier scheme, and then wonder why the analytics do not work.
Clinical trials went hybrid and the data model did not keep up
Decentralised and hybrid trial designs — remote visits, wearables, patient-reported outcomes from a phone — expanded meaningfully and are not going back. The clinical data model, however, was built around the site visit as the atomic unit.
Continuous data from a wearable does not fit that shape. It has no visit, arrives at a volume that dwarfs traditional case report form data, is intermittently missing in ways that correlate with patient behaviour, and needs a defensible answer to "was the patient wearing it?"
The concept doing the most work here is eSource: capturing data electronically at origin rather than transcribing from paper, with the electronic record being the source record. It removes a transcription step and an error class, and it makes provenance cleaner. It also means the capture system is now a regulated system, with everything that implies.
The AI-in-GxP question
This is live and unresolved, and I would not trust anyone who claims otherwise.
If a model influences a decision in a regulated process, the existing framework asks how you validated it. A model that is retrained, non-deterministic, or whose behaviour depends on a prompt does not fit the frame of "specify, test, freeze". Broad AI regulation adds obligations on top.
Where I have seen a workable line drawn:
- Models that draft for human review — a document summary, a proposed classification, a candidate deviation categorisation — are tractable, because the human is the control and the record shows what they changed.
- Models in the decision path — release decisions, patient-facing determinations, anything where no human meaningfully reviews — need validation evidence nobody has fully standardised yet.
So the practical strategy is to deploy AI where a human approval step is natural, capture what the model proposed alongside what the human decided, and build the evidence base while the framework catches up. That dataset — proposal, decision, delta — turns out to be exactly what you need both to argue for wider deployment later and to improve the model.
What I took away from it
The instinct that transfers everywhere: in a regulated domain, the thing being audited is your process, and if your process emits its own evidence, compliance stops being a project. The teams that struggled were the ones treating compliance as documentation produced after the engineering. The teams that did well built pipelines that generated the record as a side effect of doing the work.
Which, stripped of the domain, is just good engineering with the receipts kept.