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.
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.
The draft missed three things:
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.
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? Here is how I draw the line for my own team:
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.
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:
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.
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.