What sanctioned AI adoption with real sign-off actually looks like
It helps to see the contrast with how deliberate technology governance is supposed to work when an organisation does it properly. HubSpot's own engineering team recently wrote about what sanctioned AI adoption with real sign-off actually looks like, describing how new apps and integrations get evaluated, scoped and approved before they touch production systems rather than being adopted informally by whichever team finds them useful first.
That is not a life sciences example, but the structure transfers directly. Sanctioned adoption starts with a decision: someone with authority reviews what the tool does, what data it touches and what risk it carries, and only then does it get switched on for real work. Quiet adoption skips every one of those steps. The tool is simply in use, and the review that should have preceded that use never happened because nobody was in the room to ask for it.
Why PD and MSAT are where this shows up first
Process development and MSAT functions are natural early adopters of AI tools because their day-to-day work is exactly what large language models are good at accelerating: summarising deviation investigations, drafting tech transfer protocols, restructuring batch record narratives, and pulling patterns out of large sets of unstructured process data. None of that work necessarily looks like "using a new system" to the people doing it. It looks like getting through a backlog faster, often with a general-purpose AI tool that was never scoped, risk-assessed or brought to QA's attention.
This is where the gap tends to open. IT and QA functions are set up to catch systems that go through procurement, onboarding or a formal request. They are far less equipped to catch a tool that a scientist or engineer started using on their own initiative because it was faster than the alternative, particularly when the output looks like ordinary written work rather than a system-generated record.
The real validation gap is the sign-off, not the software
| Stage | Sanctioned adoption | Quiet adoption |
|---|---|---|
| Selection | Risk assessed against intended use before rollout | No assessment, tool chosen informally by the end user |
| Categorisation | Classified under a framework such as GAMP 5 before use | Never categorised, because it was never flagged as a system |
| Data handling | GxP data flows reviewed before the tool touches them | Unknown what data has already passed through the tool |
| Audit trail | Mapped into the quality management system from day one | Absent, because the tool sits outside any tracked system |
GAMP 5 and 21 CFR Part 11 both assume a system has been identified as being in scope for validation. Neither framework has a mechanism for validating something that QA does not know exists. That is why "the AI tool needs validating" is the wrong framing for most of what is actually happening in PD and MSAT right now. The tool is not failing a validation standard it was never assessed against. It is operating entirely outside the process that would decide whether it needs validating, what category it falls into, and what evidence would satisfy an inspector asking about it.
Where computer system validation needs to catch up
The validation process itself is well understood once a system is properly in scope, and organisations that want a structured walkthrough of that process, including where risk-based approaches under GAMP 5 apply and where they do not, can start with our guide to computer system validation challenges for a deeper look at how the validation lifecycle itself is meant to work.
What that guide will not solve on its own is the discovery problem sitting upstream of it. Validation methodology is not the missing piece for most quietly adopted AI tools. Visibility is. Until QA and IT have a working mechanism for finding out what PD and MSAT teams are actually using, day to day, no validation framework has anything to attach to.
What actually needs to change
Closing this gap starts with making disclosure the path of least resistance rather than something that only surfaces during an audit or an incident. That means a straightforward way for teams to flag a tool they have started using, a genuine fast track for low-risk cases so disclosure does not feel like inviting a six-month validation project, and periodic discovery activity that goes looking for tools in active use rather than waiting for someone to volunteer the information.
The tool itself is rarely the risk that keeps a quality director awake. The risk is a GxP-adjacent process running on something the quality management system has no record of, discovered only when a regulator or an internal audit asks the question nobody in PD or MSAT thought to raise first.
Explore quality management solutions
Automate and streamline your quality processes, identify opportunities for excellence and achieve compliance with regulations and standards.