Start by handling it as a normal quality incident, not as a special category that bypasses existing controls. The immediate priorities are containment, product impact assessment, and preservation of evidence. The AI component matters, but it should be investigated within the same NCR, deviation, CAPA, or 8D discipline you already use.
If there is any chance the AI influenced disposition, inspection, process parameters, routing, work instructions, record completion, or release decisions, stop relying on that output until the scope is understood. Segregate affected product if needed, identify where the AI output was used, and determine whether any downstream records or approvals were based on it.
Contain the operational risk. Pause the affected AI-assisted workflow, revert to approved manual or previously validated methods where possible, and prevent further use of suspect outputs.
Preserve evidence. Keep the exact prompt or input, model version, configuration, output, timestamp, user identity, source data, connected system transactions, and any human review or approval records.
Assess scope. Determine which lots, serial numbers, work orders, inspections, or documents were touched by the AI-assisted process.
Open a formal investigation in your quality system. Do not treat it as only an IT issue. If product quality, traceability, or record integrity is involved, quality, engineering, operations, and IT should all be involved.
Establish whether the AI was advisory or decision-enforcing. The response is more severe if the system could change records, instructions, parameters, or release status without effective human control.
Do not assume the model is the root cause just because AI was present. In many incidents, AI is one contributor inside a larger control failure. Typical causes include poor source data, stale documents, weak role permissions, unvalidated integrations, ambiguous prompts, missing review gates, and operators trusting output that looked plausible.
Your investigation should cover at least these areas:
Data lineage: What data did the AI use, and was it current, approved, complete, and in scope for the task?
Model and configuration control: Which model, retrieval source, rules, thresholds, and version were active at the time?
Workflow design: Was there a required human check, and was it meaningful or just a rubber stamp?
System integration: Did MES, ERP, PLM, QMS, LIMS, EAM, or document systems pass the right context, revision, and status data?
User behavior and training: Did users understand limits, confidence issues, and escalation criteria?
Change control: Was the AI feature, prompt template, connector, or knowledge source changed without adequate review, testing, or validation?
Detection failure: Why did existing in-process checks, inspections, approvals, or exception handling not catch the issue earlier?
Document the incident in a way that preserves traceability. In regulated and high-consequence environments, that usually means linking the quality record to the exact digital evidence trail, not just summarizing what happened in narrative form.
At minimum, retain:
the business purpose of the AI use case
the specific task the AI performed or supported
the input data set or source references used at the time
model or service identifier and version if available
prompt, template, rule set, or orchestration logic
output generated and any edits made by a user
review, approval, and override records
affected product, records, documents, or transactions
containment actions and verification results
If you cannot reconstruct what the AI saw, produced, and influenced, your investigation will be limited. That is a control gap in itself.
The right CAPA depends on how the AI is used. Common actions include tightening approved data sources, locking document revisions, adding hard stops before release-impacting actions, limiting the AI to advisory use, introducing confidence thresholds with mandatory escalation, improving audit logs, and retraining users on when not to trust generated output.
Sometimes the correct action is to remove the AI from that workflow entirely. That is especially true when the process requires deterministic behavior, strict revision control, or evidence-grade traceability that the current implementation cannot support consistently.
Also review governance beyond the single incident. You may need formal classification of AI use cases by risk level, validation expectations, periodic monitoring, and change control for prompts, retrieval content, connectors, and model upgrades.
In most plants, AI does not operate in isolation. It sits on top of older MES, ERP, PLM, QMS, historian, and document systems with uneven master data quality and integration debt. That matters. A weak connector, stale revision mapping, or missing transaction context can create a quality incident even when the model behaves as designed.
For that reason, full replacement is usually not the answer. In regulated, long-lifecycle environments, replacing core systems to solve an AI control problem often fails because of qualification burden, validation cost, downtime risk, retraining effort, and the complexity of re-establishing traceability across connected systems. It is usually more practical to strengthen interfaces, evidence trails, review gates, and change control around the existing stack.
Do not delete prompts, logs, or generated outputs to reduce exposure. That destroys evidence needed for investigation.
Do not blame the model alone without checking process design, training, data quality, and oversight.
Do not let the incident stay only within IT or data science. Product and process owners need to be involved.
Do not assume a human approval step was effective just because a signature exists.
Do not resume use based on a superficial test. Recovery should be controlled, documented, and appropriate to the risk of the workflow.
So the practical answer is yes: handle it through your existing quality incident process, but expand the investigation to include AI-specific evidence, configuration, data lineage, and governance. The key question is not only whether AI contributed, but whether your controls were strong enough to detect, constrain, and reconstruct that contribution.
Whether you're managing 1 site or 100, C-981 adapts to your environment and scales with your needs—without the complexity of traditional systems.
