The AI approval boundary nobody talks about until the audit finds it

When I first witnessed an AI system approving a CAPA closure, my initial reaction was pause. It wasn't because the decision was incorrect— it proved accurate—but because I could not locate a written record specifying who had authorized the AI to make that call. This occurred approximately 18 months ago, during a period of assessing electronic Quality Management Systems (eQMS) platforms.

Both platforms offered AI features at varying stages of development. The underlying question that has persisted remains surprisingly straightforward: does your tool possess a clearly documented list of tasks the AI is prohibited from approving? I am not referring to its capabilities. Even a complex system possesses the theoretical ability to perform nearly any function.

Rather, I am concerned with the explicit governance boundary— the line drawn within your Quality Management System (QMS) that delineates what AI may approve versus what requires human intervention. The reason this list holds greater significance than the feature itself is rooted in ISO 13485:2016's emphasis on management responsibility, the EU MDR Article 2 (46) definition of "human oversight," and the FDA's guidance on AI/ML-based software which continually references "intended use" and "meaningful human control."

However, these documents do not provide a checklist of AI tasks explicitly prohibited. Instead, you must create this list yourself, and if you do, you must understand what boundaries your platform has already established—or whether any boundaries exist at all. In our implementation (Class II, using Greenlight Guru with around 200 personnel), the AI features we employ are primarily advisory.

The system identifies potential Nonconformities (NCs) from complaint text, suggests CAPA linkages, and drafts risk matrix summaries. Nevertheless, closing a CAPA necessitates a named human in the approval process. This requirement has always been in place, and we documented it in our Standard Operating Procedure (SOP). I understand that qmsWrapper takes a similar approach, as they have documented that their AI system blocks specific actions, including CAPA closure, reportability, risk acceptability, and regulated submissions.

This level of explicitness is crucial for audit purposes. The critical question I pose to others in this field is: does your eQMS vendor provide you with a written list of AI-prohibited approvals? Or did you only discover the boundary through accident, similar to my experience? The distinction between platform-enforced boundaries—where the software physically prevents the AI from approving certain workflow states, and SOP-enforced boundaries—where you have written the rule yourself but the software does not enforce it is significant.

Implied boundaries, where the AI does not currently possess that capability, present their own challenges. Each type of boundary carries a different audit posture. The first is defensible, the second is acceptable if your SOP is well-crafted and adhered to, while the third represents a gap that could become exposed. I have observed instances where near-misses occurred due to the absence of explicit boundaries.

For instance, a peer at a smaller organization (Class I, operating in Europe) recounted a near-miss they experienced last year. Their eQMS had been automatically closing low-risk CAPAs after 90 days of inactivity. This function operated seamlessly for months until someone realized that a genuine corrective action had been closed without a formal root cause review because the AI treated the lack of activity as acceptance.

While they were able to rectify the situation, it took them two days to reconstruct the records and adjust their workflow. Had a notified body audited during that period, the CAPA would have appeared as closed without a human sign-off. ISO 13485:2016 clause 8.5.2 underscores the importance of reviewing corrective action adequacy.

If your system automatically closes CAPAs, can you demonstrate that a human determined the adequacy of the closure? Even if this determination was simply confirming a pre-filled form? The practical request I have is to understand how others are managing this issue. Specifically: does your platform document its AI approval boundaries, or is this behavior undocumented and discovered through testing?

If you have drawn this boundary yourself in an SOP, have you tested whether the software enforces it or merely expects it? And, most crucially, if a notified body were to ask you to explain why your AI cannot approve a CAPA closure, do you have a written answer prepared? As regulations such as the EU AI Act and ISO 42001 (AI management systems) will likely make this matter more formal in the future, it would be prudent to have a ready answer now.

My personal approach is simple: AI can recommend, but humans must approve— in writing, within the record, with clear accountability. The strength of the boundary depends on the evidence that someone drew it and whether the system respects it. Does your current eQMS possess an explicit, documented list of AI-prohibited approvals—and if so, how did you obtain confirmation from the vendor?