{"slug": "letting-ai-touch-capa-the-validation-question-nobody-actually-answers", "title": "Letting AI touch CAPA: the validation question nobody actually answers", "summary": "A developer prototyping an AI assistant for CAPA triage under 21 CFR 820 and ISO 13485 found that traditional software validation does not apply to probabilistic LLMs. The team created a validation pattern using a golden-test corpus, acceptance criteria, continuous monitoring, and human-in-the-loop controls to move from experiments to a controlled assistive deployment.", "body_md": "I started prototyping an AI assistant for CAPA triage because our backlog was burying the QA team. The idea felt obvious: have a model read an incoming nonconformance or complaint, suggest probable root-cause categories, surface related docs from the technical file, and propose a draft corrective action for a human to edit. It sped up screening in a sandbox — until the uncomfortable question landed: how do we validate this so a regulator (or my internal auditors) can accept it?\n\nIf you work under 21 CFR 820 and ISO 13485, you already know CAPA is not a place for unproven gamble: 21 CFR 820.100 expects documented procedures and verification of effectiveness; ISO 13485 expects controlled corrective/preventive processes. But those standards are written for human processes and classic software validation. AI changes the shape of \"verification\" and \"evidence.\"\n\nBelow are what I learned by prototyping, plus a pragmatic validation pattern we used to move from experiments to a controlled assistive deployment.\n\n##\nThe core problem: what is \"validated\" when a model is probabilistic?\n\nTraditional software validation is: input X -> expected deterministic output Y. With an LLM, output is probabilistic, context-sensitive, and can change with model updates. That means you can't treat the model like a black-box SOP that always produces the same correction plan. You can, however, treat the model as \"controlled assistance\" — a source of suggestions that are subject to human review and traceability. But treating it that way still requires validation artifacts.\n\n##\nWhat I prototyped (practical, not theoretical)\n\n- Ingested a de-identified sample of historic CAPA and nonconformance reports from our QMS (we scrubbed PHI and supplier-sensitive text).\n- Built an embeddings index of our controlled documents (design history, risk assessments, past CAPAs) so the assistant could surface context.\n- Created a \"shadow mode\" pipeline: the AI wrote suggestions but we did not act on them — we logged suggestions and compared them to the original human outcomes.\n- Measured alignment: did the AI's root-cause category match the human category? Did its top-3 suggested references include docs humans actually used?\n\nThis revealed the usual: helpful hits, plausible-but-wrong rationales, and occasional hallucinations with confident-sounding citations that didn't exist.\n\n##\nValidation pattern that made sense for us\n\nI didn't want to \"validate the model\" (too brittle); I wanted to validate the controlled-assistance process and produce evidence that regulators expect. We defined the following, iterated, and kept everything under change control:\n\n-\nDefine scope and boundaries\n\n- Which CAPA types can the assistant touch? (e.g., administrative triage only; not manufacturing hold decisions)\n- Allowed data: no PHI or regulated supplier IP to public LLMs.\n\n-\nCreate a golden-test corpus\n\n- De-identified historical cases with human-accepted root cause, references used, and final corrective actions.\n- Include edge cases and ambiguous inputs.\n\n-\nAcceptance criteria (measurable)\n\n- Example metrics: top-1 root-cause agreement vs human, presence of at least one correct doc in top-5 references, rate of hallucinated citations per 100 suggestions.\n- Define pass/fail thresholds based on risk (higher scrutiny for anything that influences product disposition).\n\n-\nContinuous monitoring and drift detection\n\n- Catalog model version, prompt templates, and embedding index version.\n- Run periodic re-tests against the golden corpus and new live-decision audits.\n- If performance drops, initiate change-control and revalidation.\n\n-\nHuman-in-the-loop controls\n\n- The assistant's output is saved as a draft in the CAPA record with clear provenance (model version, timestamp, prompt).\n- A named human reviewer must accept, edit, and sign off before any action is taken.\n\n-\nDocumentation and traceability\n\n- SOPs for assistant use, validation plan, test reports, and periodic review logs.\n- Maintain an auditable trail linking suggestions to final CAPA content.\n\n##\nImplementation notes useful to engineers\n\n- Treat prompts, test suites, and evaluation code as source-controlled artifacts. We used a small CI job to run the golden-corpus tests when we changed prompts or upgraded the model.\n- Snapshot your embedding index and store the version used by the assistant in each CAPA record. That preserves \"why\" the assistant surfaced a doc.\n- Redact or tokenise PHI and supplier secrets before any call to an external LLM. If you must send sensitive data, prefer enterprise/private-hosted models under a DPA and SOC2 controls.\n- Log everything to an append-only audit store (we wrote logs to our QMS via webhook so each draft suggestion became part of the CAPA's history).\n- Define roles: who can accept AI suggestions, who can only view, and who can edit model prompts/policy.\n\n##\nWhere auditors and notified bodies will push back\n\nFrom my experience, reviewers care about:\n\n- Evidence that the assistant doesn't change CAPA outcomes without oversight.\n- Reproducible records showing model versioning and the decision path.\n- Data protection controls (especially for clinical complaints).\n- Clear SOPs on when the assistant can be used and when it must be bypassed.\n\nIf you can't demonstrate those artifacts, expect questions — and be ready to show your golden-corpus test results and revalidation plan.\n\n##\nFinal thoughts\n\nAI can materially reduce triage time and surface relevant evidence from large technical files. But the validation conversation isn't a one-off checkbox; it's an ongoing program: test corpus, monitoring, change-control, and human oversight. In the end, we accepted AI where it reduced admin work and never where it could directly change product disposition without a human sign-off.\n\nWhat I'd like to learn from this community: do you have a concrete list of test cases or metrics you used to convince internal auditors or a notified body that an AI-assisted CAPA workflow was \"validated enough\"? If so, can you share the kinds of test cases or acceptance criteria that worked in your audits?", "url": "https://wpnews.pro/news/letting-ai-touch-capa-the-validation-question-nobody-actually-answers", "canonical_source": "https://dev.to/jwithfield_qa/letting-ai-touch-capa-the-validation-question-nobody-actually-answers-l0k", "published_at": "2026-07-22 19:20:33+00:00", "updated_at": "2026-07-22 19:31:04.228080+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-safety", "ai-policy", "developer-tools"], "entities": [], "alternates": {"html": "https://wpnews.pro/news/letting-ai-touch-capa-the-validation-question-nobody-actually-answers", "markdown": "https://wpnews.pro/news/letting-ai-touch-capa-the-validation-question-nobody-actually-answers.md", "text": "https://wpnews.pro/news/letting-ai-touch-capa-the-validation-question-nobody-actually-answers.txt", "jsonld": "https://wpnews.pro/news/letting-ai-touch-capa-the-validation-question-nobody-actually-answers.jsonld"}}