Not every pipeline step needs the same validation

Where does the validation effort go?

The organisation is about to face an inspection from a regulatory authority, the last step before bringing to market the product the team has worked on for years. You look at the stack of validation documents and think, “Great, everything is settled.” Then, while walking the inspector through the pipeline, you realise the reference database was updated and never validated. At that moment the team wanted results, and nobody stopped to check the new database against known results. This is an extreme case, and experienced teams rarely end up here. But it shows how easily one dependency slips through.

That story is one end of a common pattern. In regulated life-science companies, analysis pipelines tend to fall into one of two defaults. In the first, every script gets the full validation package, whatever it does. In the second, analysis code is treated as research and is rarely validated. Both feel safe at the start, and both have costs that appear later.

The first default creates a backlog. Analysts avoid touching validated code, so pipelines stay on old tool versions and old reference databases long after better ones exist. The second default works until a partner, an auditor or a regulator asks how a result was produced, as in the inspection above, and nobody can answer with evidence.

Adding AI to the pipeline makes both defaults more expensive. A language model behind an API can change without notice, and every test run against it is billed by the token.

In a previous article, Milad Adibi argued that sending every request to the largest model is the expensive default, not the safe one. The same applies to validation. In both cases, nobody decided before the work started how much each step really needed.

Most steps are low risk

Most of the work in a pipeline does not decide anything. Reformatting a sample sheet, drawing a QC plot or converting file types matters, but an error there is visible and cheap to fix. A step that produces a taxonomic profile used to release a batch is different because an error there ends up in a decision.

Risk-based validation means tiering pipeline components by what their output is used for, not by the fact that they are code. The ISPE GAMP 5 guide, revised in 2022, scales validation effort to risk [1]. The FDA guidance on Computer Software Assurance, finalised in September 2025, goes further. It asks companies to keep testing and documentation no heavier than the risk requires, and to save the most rigorous testing for high-risk functions [2]. That guidance is written for medical-device manufacturing, but it shows the direction regulators are taking.

For AI, regulators have already drawn a red line. The draft EU GMP Annex 22, published in July 2025, states that generative AI and large language models should not be used in critical GMP applications [3]. They can still be used in non-critical tasks with no direct impact on patient safety, product quality or data integrity, as long as a qualified person checks the output. In practice, language models should stay at the edges of the pipeline, where a person reviews the output, and away from the steps that produce the results that are going to be reported.

Pin what the results depend on

A result can only be reproduced if everything it depends on stays the same, including tool versions, parameters, reference data and, more and more often, a model. For the critical steps identified above, this means running them in containers with every version pinned. Community frameworks such as nf-core already work this way, and each pipeline release ships with its software pinned in containers [4]. Steps outside that core, such as exploratory plots or ad-hoc checks, can change more freely because their output does not feed a result that is going to be reported.

Pinning the software is not enough, because a pipeline also depends on data that is not code.

Back to the opening example. Say your team decides to move taxonomic profiling to the newest reference database. It should be better, but that is not a reason to skip checking it. Taxonomy evolves, and an organism can be renamed or moved to another genus between two database versions. In 2020 the genus Lactobacillus was split into 25 genera, and a familiar species such as Lactobacillus plantarum became Lactiplantibacillus plantarum [5]. If nobody checks, that species can seem to vanish between two time points of the same study, and a renaming is read as a treatment effect. So first run the new version on samples with known results and check that the output matches expectations. If it does, lock that version and re-profile both legacy and new datasets with it.

A language model is one more dependency to pin, and a harder one to control. Chen et al. tested two releases of GPT-4 three months apart. On the same prime-number questions, accuracy fell from 84% to 51% [6]. When a pipeline calls a model through an API, the vendor decides when it changes. In practice, pin the exact model version and treat any model change like a change to a validated system. For steps close to the core, a self-hosted model is the safer option.

Let the pipeline write its own evidence

Much of a validation package is evidence that the system works as intended and that every run can be traced. A well-built pipeline produces most of this evidence by itself. Unit tests check individual steps. A regression test runs a frozen reference dataset and compares the output with a known result. Continuous integration repeats both on every change and keeps the record. Workflow managers such as Nextflow keep a record of every run, including the launch command and the script each step executed [7]. The FDA guidance also accepts logs and audit trails generated by the system as validation records [2].

AI also changes the budget here. For a deterministic step, a regression test takes a few minutes of computation time and gives the same answer every time. For a language-model step, each run is billed by the token, the output can vary between runs, and the test must be repeated whenever the model changes. This is another reason to keep language models out of the validated core, and to keep their test sets small and focused when they are needed.

Where the rules are heading

The European framework is moving in the same direction. The draft revision of EU GMP Annex 11, published in July 2025 together with Annex 22, applies to all types of computerised systems used in manufacturing, and asks that validation effort be based on intended use and risk [8]. It also accepts iterative development, provided the process is controlled and documented. With more systems in scope, validating everything to the same standard will become harder to afford. Teams that already validate in proportion to risk will adapt to new rules with little extra effort.

Take-home message

Not everything needs to be validated to the same level. The best approach is to be pragmatic, giving full validation to the critical steps, pinning what they depend on and keeping light checks for the rest. AI can support this work, but it does not replace human judgement and expertise. It should stay supervised and out of the critical steps.

Jaime Imaz

References

1. ISPE. GAMP 5 Guide: A Risk-Based Approach to Compliant GxP Computerized Systems, 2nd edn. International Society for Pharmaceutical Engineering (2022).
2. U.S. FDA (CDRH, CBER). Computer Software Assurance for Production and Quality System Software. Final guidance, 24 September 2025; updated version 3 February 2026 as Computer Software Assurance for Production and Quality Management System Software.
3. European Commission. EudraLex Volume 4, Annex 22: Artificial Intelligence. Draft for public consultation, 7 July 2025.
4. Ewels, P. A. et al. The nf-core framework for community-curated bioinformatics pipelines. Nature Biotechnology 38, 276–278 (2020). doi:10.1038/s41587-020-0439-x
5. Zheng, J. et al. A taxonomic note on the genus Lactobacillus: description of 23 novel genera, emended description of the genus Lactobacillus Beijerinck 1901, and union of Lactobacillaceae and Leuconostocaceae. International Journal of Systematic and Evolutionary Microbiology 70, 2782–2858 (2020). doi:10.1099/ijsem.0.004107
6. Chen, L., Zaharia, M. & Zou, J. How is ChatGPT’s behavior changing over time? Harvard Data Science Review 6(2) (2024). doi:10.1162/99608f92.5317da47
7. Di Tommaso, P. et al. Nextflow enables reproducible computational workflows. Nature Biotechnology 35, 316–319 (2017). doi:10.1038/nbt.3820
8. European Commission. EudraLex Volume 4, Annex 11: Computerised Systems. Revised draft for public consultation, 7 July 2025.