I started seeing LLMs in the quality workflows at my company two years ago. At first it was hobbyist — someone using ChatGPT to rephrase a CAPA description — and then teams wanted to do more: triage complaints, propose root causes, draft PSUR paragraphs. That change forced a hard question: when does a convenience tool become a GxP-relevant system that needs validation?
Below I lay out a practical, auditor-focused approach I use for any LLM/AI-assisted tool when the outputs touch GxP activities. It’s based on risk principles (ISO 14971), software lifecycle thinking (IEC 62304, GAMP 5 practices), and plain experience with notified-body and competent-authority questions. To be fair, this is a pragmatic checklist — not a white paper.
Start with scope: what the model actually does
First thing I ask: what is the intended use and is there a patient- or product-safety implication?
- Human-only drafting / admin tasks (e.g., rewording SOP text) — lower risk, but still consider records and traceability.
- Decision-support (e.g., suggesting a corrective action, classifying complaint severity) — medium to high risk; requires stronger controls.
- Autonomous actions (e.g., auto-submitting an MDR 7 report) — usually unacceptable for GxP without full validation and strict guardrails.
In practice this means writing a short Intended Use Statement for the tool. That statement determines the rest of the validation effort.
Risk assessment shapes evidence requirements
I treat every LLM as a software component in the QMS. Per ISO 14971 thinking, map harms and their probabilities:
- What can the model get wrong? (omission, hallucination, bias)
- What is the consequence if it’s wrong? (regulatory non-compliance, incorrect CAPA, delayed MDR report)
- What controls reduce that consequence? (human review, confidence thresholds, audit logs)
The output here is a simple risk control matrix linking each hazard to mitigation(s). In practice, auditors expect to see this matrix and the decision rationale behind human-in-the-loop rates.
Validation deliverables I prepare
When the LLM crosses into GxP territory I treat it like any other validated system. The minimum evidence package I keep ready:
- Validation/Qualification Plan — scope, responsibilities, acceptance criteria.
- User Requirements Specification (URS) — who uses it, what it must do, limits of use.
- Functional Specification / Design Description — including model architecture if known, connectors, and data flows.
- Risk Assessment — as above, with residual risk justification.
- Test Protocols and Test Results — test cases against URS, edge cases, failure modes.
- Traceability Matrix — URS ⇄ test cases ⇄ mitigations.
- SOPs and Work Instructions — how users must use it, review expectations, escalation routes.
- Change Control Record — versioning of prompts, model changes, fine-tuning events.
- Training Records — who is authorised, training content, competency checks.
- Monitoring Plan — KPIs, periodic re‑validation triggers, performance drift checks.
- Incident & CAPA Log — evidence that issues are handled under the QMS.
Auditors will open the validation report first. If it’s thin, they’ll follow the traceability to the SOPs and training records next.
What I test — beyond “does it answer?”
Testing has to be task-focused and reproducible:
- Functional correctness: test expected outputs for a representative test set (including negatives).
- Robustness: feed malformed, ambiguous, or adversarial prompts.
- Hallucination checks: deliberately ask for unsupported facts and confirm the model abstains or signals uncertainty.
- Consistency: same prompt, different runs — check variance and document acceptable ranges.
- Safety filters: confirm profanity, PII leakage, and regulated-advice filters are in place.
- Human‑in‑loop behaviour: measure reviewer override rates and time-to-detect errors.
To be useful for an audit, test cases must be reproducible (seeded prompts, fixed model versions) and linked to acceptance criteria in the URS.
Data provenance and training transparency
GxP auditors care about data lineage. With closed commercial LLMs you may not have full training-set visibility. That’s acceptable if you:
- Document what you do and don’t know about the model.
- Assess residual risks from unknown training data (e.g., biased outputs).
- Apply compensating controls (restricted scope, human review, provenance tagging).
If you fine-tune or maintain private training data, keep records: dataset descriptions, versioning, and why the data set is appropriate.
Ongoing monitoring — validation is not one-and-done
Expect auditors to ask: how do you prove the model still works in six months?
- Define KPIs: accuracy for a labelled sample, rate of reviewer overrides, time-to-detect anomalies.
- Set re-validation triggers: major model updates, drift beyond thresholds, new use cases.
- Retain logs: prompts, responses, user IDs, timestamps, and reviewer decisions. Make these searchable — when an auditor asks for "the last ten examples the model suggested for MDR reports", you should not be doing forensic investigation.
Connected workflow and traceability matter here: a system that links prompt → model output → reviewer decision → final artefact wins audits because evidence is straightforward to extract.
What auditors typically ask — and how I answer
From experience, these are the questions I get or expect:
- “What is the intended use?” — point to the URS and SOP.
- “How did you validate accuracy and safety?” — show the validation plan, test protocols, and results.
- “How do you detect and handle hallucinations or incorrect outputs?” — show filters, reviewer steps, escalation.
- “Who can change prompts or model versions?” — show change control, permissions, and version history.
- “How do you retain evidence for regulatory submissions?” — show logs, export capability, and retention SOP.
- “How do you guard patient data and PII?” — show data handling and anonymisation practices.
Be specific, bring the traceability matrix, and don’t hand-wave about "the model is stable".
Final notes — operational realism
To be frank, many teams under-document early. That is costly. Start small: validate a narrow, well-scoped use case, automate evidence capture, and iterate. “Controlled assistance” with human review is the default safe strategy. Granting autonomous actions to an LLM in a GxP context is rare and requires robust evidence.
I’d rather an auditor see a well-scoped, fully traced validation for a small use case than a broad, undocumented deployment.
What narrow LLM use case in your QMS would you validate first, and what acceptance criteria would you set for it?
