The change that looked small
Last month, a change request landed on my queue for a heat-treat subcontractor who had moved two of their furnace zones to a different EMS provider. Twelve components in scope. Four device families downstream. The change form asked one question at the top: which DHF documents does this touch?
For a Class IIa implant component, that question is not a checkbox. Get it wrong and the notified body's next surveillance audit will find orphaned drawings, outdated process validations, or a sterilization map that no longer reflects actual load patterns. Before our QA team in Germany closes the change, somebody has to think through the cascade.
That somebody is, and remains, a human.
What the AI did well
The same change request fed into an automated impact analysis. It pulled cross-references from our PLM, matched the affected part numbers against the active device master records, and produced a draft list of impacted documents inside a couple of minutes. Compare that to the afternoon I would have spent pulling the same list by hand, cross-referencing supplier codes against DHF indices, and chasing confirmations from four process engineers.
The draft was 80% there. It caught the obvious items: the validation protocol for the heat-treat cycle, the incoming inspection procedure for the affected surface finish, the supplier quality agreement itself. It also flagged two drawing callouts that had been quietly outdated for eighteen months and were, frankly, due a refresh anyway.
What the AI did not know
The draft missed three things:
- Two of our implants share a sterilization load configuration that is not formally linked to the heat-treat step, but is affected because the new EMS vendor uses a different tray geometry.
- One device family had moved to a different cleaning process six months earlier, and the impact on that line was different from the cleaning process used by the other three.
- A long-standing CAPA whose corrective action was tied to this exact furnace's temperature uniformity map.
None of that lives in a part number. None of it sits in a cross-reference table. It lives in the heads of two process engineers who have been on the line for the better part of a decade, and in the CAPA log they are still working through.
AI-assisted impact analysis will surface what your data structure can express. It will not — and probably should not — pretend to know the things only your team knows.
What the standard actually requires
Under ISO 13485:2016's document control and change control requirements, changes have to be reviewed and approved prior to issue, with the impact considered and the rationale recorded. The phrasing is deliberate. "Reviewed" implies a human has interrogated the reasoning and signed off on it. "Approved by" names a person, not a system.
EU Annex 11 and 21 CFR Part 11 both come into play when the impact analysis lives in an electronic QMS. The audit trail has to show who reviewed, when, and what they actually considered. A status of "reviewed and approved" with no record of what the reviewer looked at is not compliant. It is a checkbox.
If an AI drafted the impact list, the audit trail has to show what the AI produced, what the reviewer added, what they removed, and what they left alone. Otherwise the next auditor will ask, reasonably: how do you know this was a thoughtful review and not a click-through?
The accountability frame
Here is how I draw the line for my own team:
- The AI proposes an impact set. It is drafting work, not a decision.
- The human reviewer accepts, rejects, or amends each item. Each decision gets a recorded note against that item.
- The approver (a different person, usually the QA manager) signs off knowing the reviewer has attested to their own judgments, not just rubber-stamped the AI's output.
- The whole chain — prompt, response, reviewer notes, approval — is retrievable for the audit, not because the AI is exotic, but because the change is regulated.
This is the line I keep coming back to: AI helps you surface impact; accountability lives with the human who reviewed the reasoning. The two statements are not in tension. The first is a productivity claim. The second is a regulatory claim. Mixing them up is where QMS leaders get themselves into trouble.
What to look for in any controlled assistance
If you are evaluating AI assistance — automated CAPAs, AI-driven CAPA assistance, AI-guided impact mapping, whatever the marketing calls it — the question is not whether the model is clever. It is whether the reasoning is reviewable and the audit trail holds. Concretely:
- Can you see the inputs that produced the output?
- Can the reviewer leave a per-item justification that survives the next system upgrade?
- Does the approval step bind to a human identity, with a date and a hash of what was approved?
- Is the AI's reasoning itself covered by the same change control as the rest of the QMS, or does it live in a side process that nobody owns?
If the answer to any of these is "we will figure that out later," the system will fail an audit before it fails technically. Process automation is only as defensible as the records it leaves behind.
Open question
In your QMS, can your auditor trace a single change from "AI suggested X" all the way through "the reviewer assessed X and concluded Y because Z"? Or is the AI's contribution still a black box on the far side of someone's approval signature? I would be curious how others are handling the review-record problem in practice.
