AI can explain CAPA — but it cannot certify adequacy (here’s how I use it)

I use generative AI every week for CAPA work. It is excellent at one thing: turning messy inputs into tidy overviews. Where it becomes dangerous is when teams — or auditors in a pinch — start treating those overviews as evidence of adequacy.

I’ll explain what I let AI do, what I never let it decide, and the practical controls that keep the RA/QMS story audit-ready. I’ll cite the standards that matter in practice and give a short checklist you can use this afternoon.

What AI does well (and what I actually ask it for)

In my workflows, AI is a productivity tool for humans, not a replacement.

Typical uses:

• Drafting a neutral “what is a CAPA” or “CAPA lifecycle” summary for training or onboarding.
• Turning a long non-conformance report into a succinct problem statement, containment actions, and proposed root-cause hypotheses.
• Producing a first-draft CAPA plan with suggested verification steps and measurable acceptance criteria.
• Triage: prioritising CAPAs for escalation based on keywords (safety, complaint, MDR reportable).
• Generating meeting notes and action-item lists from recorded discussions.

To be fair, that first-draft plan often saves engineers and suppliers 30–60 minutes of boilerplate work. In practice this means more time for evidence collection and verification — the parts that actually matter to auditors.

Where AI is dangerous

AI gives the impression of certainty. It will write a beautifully structured CAPA closure report that looks complete — but it cannot replace context, evidence, or judgement. The key failure modes I see:

• No access to original evidence: AI can summarise but not prove you performed certain tests, reviews, or supplier corrective actions.
• Weak linkage to risk: adequacy requires showing how the CAPA changes the risk profile (ISO 14971), not just describing actions.
• Missing verification: "CAPA implemented" ≠ "CAPA effective." Evidence of effectiveness must be objective, date-stamped, and traceable.
• Audit trail gaps: auditors want who-reviewed-what-and-when. AI outputs without traceability are red flags.

Standards matter here. ISO 13485:2016 clause 8.5.2 sets expectations for corrective action records and effectiveness verification. MDR Annex II and post-market obligations expect traceability between PMS, CAPA and technical documentation. To paraphrase: explanations are fine, evidence is not optional.

How I use AI in a CAPA workflow — a practical pattern

I build a “human-in-the-loop” workflow. This is what works for us and survives notified-body scrutiny.

1. Input control

   • Use AI only on structured inputs: NCMR, complaint log entry, audit finding, or lab report.
   • Attach source documents before generation. If your tool cannot ingest attachments, don’t rely on its output beyond drafting.

2. Drafting and triage

   • Ask AI to produce a draft problem statement, containment, proposed root-cause analysis techniques (5-why, fishbone), and suggested verification metrics.
   • Label the output clearly as “draft — requires documented evidence.”

3. Human verification and enrichment

   • The CAPA owner completes the draft with concrete evidence: test reports, supplier emails, training records, risk-impact calculation.
   • Record changes in your QMS with versioning and reviewer sign-off. Traceability is the audit currency.

4. Closure and effectiveness

   • Define objective acceptance criteria up front (e.g. reduction in complaint rate to X per month, supplier defect rate <Y).
   • Use AI for suggestion but not for sign-off. The evidence must be human-reviewed and stored with timestamps.

This is a controlled, reviewable, traceable pattern — in other words, a connected workflow.

Practical controls and validation (what auditors will ask you)

Notified bodies are looking for three things when they probe a CAPA: rationale, evidence, and verification. Implement these controls:

• Evidence-first policy: do not accept an AI-generated closure statement without hyperlinks to the underlying documents in the record.
• Change impact mapping: demonstrate how the CAPA affects Technical File elements (design inputs, risk files, IFU). This is the “trace to Annex II” habit.
• Reviewer accountability: each AI-assisted draft must have a named reviewer and a reasoned assessment recorded in the CAPA record.
• Version history: keep the prompt and model version (or tool version) in the record — yes, auditors ask for reproducibility.
• Periodic validation: treat your AI assistant like a software tool that influences quality decisions. Periodically sample AI outputs against human judgement and document the results.

These controls support audit readiness and align with ISO 13485 expectations for documented procedures and records.

One pragmatic template I use (short)

• Source documents attached: NCMR#, complaint#, date, raw data.
• Problem statement (AI draft) — edited by owner.
• Root-cause hypothesis and method (AI suggests; owner selects).
• Corrective actions (specific, owner, due date).
• Verification method and objective acceptance criteria (owner-defined).
• Evidence attachments (test reports, supplier CAPA, training records).
• Reviewer comments and sign-off (name, date).
• Effectiveness review date and result.

If your eQMS supports connected workflows and triggers (automated CAPAs, training triggered by events), wire these fields directly into the CAPA form so nothing lives only in a Word doc.

Final thought

AI is great at reducing the friction of writing and triage. Granted, that saves time. But adequacy is a judgement made on evidence, not prose. In my experience, the single hardest thing to recreate after an AI-driven draft is the human rationale recorded in a way an auditor can follow.

How have you integrated AI into your CAPA process — and what controls have prevented an AI-written report from becoming the only record of “what we did”?