REGULATORY QMSR replaces 21 CFR Part 820 — is your quality system ready? Check your gaps free →
Enterprise-grade Security
No implementation required
GDPR & CCPA Compliant
QMS / THOUGHT LEADERSHIP

AI-Generated SOPs: Why Inspectors Are Starting to Ask Questions

10 min read

The SOP That Passed Internal Review and Failed the Audit

The procedure looked good. Genuinely good.

It had all the right headings: purpose, scope, responsibilities, procedure steps, references, related documents. The language was clear, consistent, regulatory-sounding. It moved through document control review, got two approvals, was loaded into the training module. Operators completed their training. The record closed.

Then came the Notified Body audit.

The inspector spent about five minutes reading the CAPA procedure before asking a question that wasn't in anyone's prep guide: "Walk me through how this procedure was developed. Who was involved in drafting the process steps?"

The procedure had been drafted in about 90 minutes using ChatGPT. The quality engineer had prompted the AI with the company's basic CAPA requirements, reviewed the output, made some edits, and submitted it for approval. The approvers read it and found it satisfactory. It was coherent. It referenced ISO 13485 Clauses 8.5.2 and 8.5.3 in the right places.

But when the inspector started asking about specific process steps: why the timeline thresholds were set at those particular values, how the root cause classification schema mapped to the company's actual complaint categories, who owned the escalation path to management review. The answers weren't in the document. Because the document hadn't been built from the process. It had been built from a prompt.

The inspector's next question was quieter: "Do any of your other procedures have similar development histories?"

That's where the audit shifted.

4.1.6 ISO 13485 clause requiring validation of QMS software, including AI tools used in document development
820.40 21 CFR section (now in QMSR) requiring document review for adequacy, not just a signature
Part 11 FDA regulation requiring validation of systems that create or modify electronic records

The Quiet AI SOP Boom

Most quality managers already know this is happening in their departments. They may not know exactly which procedures, or exactly which prompts, but they know.

It's not hard to understand why. Quality teams are stretched across more regulatory obligations than they were three years ago. The procedure backlog never shrinks. New standards create new documentation requirements. Post-market surveillance under EU MDR demands more structured output. The clock doesn't slow down for audits.

ChatGPT, Copilot, and similar tools produce document-quality text instantly. For someone under deadline pressure, that's genuinely useful. The output sounds professional. It uses the right terminology. A quality engineer reviews it, cleans it up, routes it through document control. Everyone moves on.

People using AI isn't the issue. Most quality teams just haven't thought through what it means for their QMS. Inspectors are figuring that out faster than the teams using the tools.

The 4 Compliance Problems QA Teams Keep Underestimating

1. Traceability and Authorship: "Who Wrote This Procedure?"

Under ISO 13485:2016 Clause 4.2.4, controlled documents must be reviewed and approved for adequacy before use.[1] Under the former 21 CFR 820.40 (replaced by the QMSR as of February 2, 2026, which incorporates ISO 13485 by reference), documents must be reviewed and approved with date and signature of the approving individual(s).[2]

Neither standard explicitly prohibits AI tools. But both assume something that AI use complicates: that the person approving a document has a genuine basis for asserting its adequacy. That basis requires understanding where the content came from, who made the substantive decisions, and whether the procedure reflects actual practice.

When an inspector asks "who wrote this?", the regulatory question isn't a name. It's an explanation of the authorship process that's defensible. "Our quality engineer reviewed and approved it" answers the signature question. It doesn't close the question of what was being reviewed and whether the reviewer had sufficient basis to attest to its adequacy.

ISO 13485:2016 Clause 4.1.6 adds a software dimension to this directly: organizations must document procedures for the validation of computer software used in the quality management system.[1] If a QA engineer used ChatGPT to draft procedures that are part of the QMS, the tool that produced them sits inside the scope of that requirement.

2. Validation of AI Tools Used in QMS Work

This is the one that surprises quality managers most.

ISO 13485:2016 Clause 4.1.6 requires that organizations document procedures for the validation of computer software used in the QMS, with such software validated prior to initial use and after changes.[1] The Johner Institute's analysis is worth reading here: manufacturers must validate LLM-based systems like ChatGPT if they are used as part of the QMS and results are not fully verified downstream.[3] The validation requirement doesn't go away because you review the output. It goes away only if that review constitutes a complete verification that would catch any error the AI could produce.

For 21 CFR Part 11, the scope is similar. Any system used to create or modify electronic records must be validated to ensure accuracy, reliability, and consistent intended performance.[4] An AI tool generating content that becomes a controlled document is squarely within that scope.

GAMP 5's second edition (2022) added a dedicated appendix on AI and ML systems, noting unique challenges: model drift, non-deterministic outputs, the difficulty of validating systems that change behavior over time.[5] No exception for tools used only to draft documents. If the output influences your QMS, the tool is in scope.

What validation looks like in practice: A written procedure for how the AI tool is used in document development. Test cases with known correct outputs to verify accuracy. Documentation of the model version used. A change management process for when that model is updated. Most teams using ChatGPT for SOPs have none of this.

3. Generic Content That Doesn't Match Your Actual Process

This is the most common reason AI-drafted SOPs fail effectiveness checks, and the hardest to catch in review.

AI generates plausible, professionally structured procedures based on how most organizations describe processes like CAPA, document control, or management review. It produces the industry-average version of the procedure. Clean, logical, correctly referenced.

Your process isn't the industry average. Your escalation thresholds came from a specific failure mode you had in 2022. Your complaint investigation timelines came from a negotiation with your notified body. Your root cause classification categories map to your actual product and failure modes, not a generic taxonomy. An AI doesn't know any of that.

There's a variant that hits smaller companies especially hard: the AI-drafted procedure that's slightly better than your actual process. It describes controls you don't have, review steps that don't happen, escalation paths no one follows. The QMS ends up looking stronger on paper than it actually is, and that gap between what's documented and what's executed generates findings every time.

4. Version Control and Change Management for AI-Assisted Development

If an inspector asks in 18 months to reproduce how a procedure was developed, can you answer?

Specifically: which AI model was used, what prompt was given, who reviewed the output, what changes were made between the AI output and the approved document, and whether the same process was followed for subsequent revisions. Most teams can't answer those questions about documents drafted six months ago. The model has been updated. The prompt is gone. The quality engineer who did the drafting may have left.

This matters because your document control procedure requires you to understand development history well enough to manage changes to it. If you can't reconstruct how the original was created, you can't adequately assess the impact of changes to it. You also can't demonstrate consistency between a procedure drafted in Q1 and one drafted in Q3, even if both carry the same approver's signature.

What Inspectors Are Starting to Ask

These are showing up in audit prep conversations and, increasingly, in actual inspection observations.

"Walk me through how this procedure was developed." Not a casual question. It's asking for the development history: who was involved, what inputs were used, how process-specific content was validated against actual practice.
"Can you show me review evidence for the content itself, not just the approval signature?" Approval signatures confirm someone reviewed and approved the document. They don't confirm what the review covered. Inspectors want to see evidence of substantive engagement, not just a signature line.
"Is any software used in the development of controlled documents validated?" The ISO 13485:2016 Clause 4.1.6 question in plain language. If the answer needs to include AI tools, the follow-up is "what does your validation look like?"
"How do you ensure procedures reflect your actual process and not a generic template?" This targets the core failure mode of generic AI content. The honest answer for many teams would be uncomfortable.
"What is your organization's policy on AI tool usage in QMS activities?" Most organizations don't have one. The absence of a policy isn't automatically a finding, but it makes every other question harder to answer.

AI-Assisted vs. AI-Generated: The Line That Matters

The distinction is real, and experienced inspectors can usually sense it, even when they can't always articulate what they're detecting.

AI-Generated AI-Assisted
AI owns the thinking. Human provides a prompt, reviews output, routes through document control. Human owns the thinking. AI accelerates expression, structure, and coverage-checking.
Process steps, thresholds, decision criteria came from the model. Process steps, thresholds, decision criteria came from people who run the process.
Human served as editor and approver, not as the substantive author. AI accelerated work on a draft that already reflected actual practice.
Defensible only if inspector doesn't ask the right questions. Defensible because the reasoning is traceable to its source.

Here's what the difference looks like in practice.

A quality engineer needs to write a new deviation investigation procedure. The AI-generated approach: prompt the tool with "write a deviation investigation SOP for a medical device manufacturer compliant with ISO 13485" and edit the result. The AI-assisted approach: first map the actual deviation workflow with the quality team. Who identifies deviations, what the triage criteria are, where the 30-day vs. 90-day timelines come from, who approves closure. Then use AI to check whether that draft covers all the clauses in Clause 8.3, standardize the language, and cross-reference related procedures.

The end documents might look similar at a glance. Under audit scrutiny, they're very different.

A Defensible Framework for Using AI in SOP Development

None of this means quality teams should stop using AI tools. Used correctly, they're genuinely useful for structure, consistency, and clause coverage checking. The goal is to use them in a way you can defend.

Six Controls That Make AI Use Defensible

  • Human-authored first drafts for process-specific content. The sections that describe what your organization actually does (process steps, decision criteria, responsible parties, timelines) should come from someone who knows those things. Notes from a process walk-through. Input from the team that executes the process. AI can take that raw input and turn it into polished procedure language. That's a defensible workflow.
  • AI for structure, coverage, and consistency checking. Prompt the tool to review a draft for gap coverage against specific clauses. Ask it to check whether terminology is consistent. Use it to generate a cross-reference table. These tasks are low risk, high value, and easy to validate.
  • A written AI tool usage policy in your QMS. It doesn't have to be long. Define which tools are permitted, what controls are required, and what records must be maintained. Without it, every other control is informal and unauditable.
  • A validation approach for AI tools in controlled document development. For lower-risk uses like formatting and terminology, a documented rationale and periodic spot-check may suffice. For higher-risk uses like drafting procedure logic that won't be independently verified, more rigor is appropriate. Document the risk classification and the approach.
  • Reviewer attestation that content reflects actual practice. Make this explicit in the review form: "I have reviewed this procedure against actual practice and confirm it accurately reflects the process as executed." This changes what reviewers are certifying, and tends to surface the generic-content problem before the auditor does.
  • Documented prompts and workflow for reproducibility. Record the AI tool used (including version where available), the prompt(s) used, and who conducted the AI-assisted drafting. Store this as part of the document's development history. It solves the "reproduce how this was developed" problem entirely.

The 10-Minute AI SOP Risk Self-Check

Run these questions against your current document control process. Where you can't answer clearly, you have a gap.

  1. Can you produce a written policy on AI tool usage in QMS activities? Not a draft, not a plan to write one. An actual documented policy. If you can't, you have an undocumented process.
  2. For any procedure drafted with AI assistance in the last 12 months, can you identify which AI tool was used and what prompt was given? If the development history is gone, your change management process for those documents has a gap.
  3. Has any AI tool used in controlled document development been validated under ISO 13485:2016 Clause 4.1.6? If not, and if the tool produced content that wasn't subject to complete independent verification, this is an open compliance item.
  4. For your most recently AI-assisted SOP, could you walk an inspector through how the process-specific content was developed? Who provided input? What was the basis for the thresholds and decision criteria? If the honest answer is "the AI determined those," that's a problem.
  5. Do your document reviewers know which procedures were AI-drafted? If they reviewed documents without knowing the content came from an AI tool, their "review for adequacy" may not have covered the questions that review should include.
  6. When the AI model you use gets updated, does your change control process capture that? Model updates can change how the tool responds to the same prompts. Without version tracking, you can't demonstrate consistency across documents developed at different times.
  7. Can you produce evidence of substantive review, not just approval signatures, for AI-drafted procedures? Comments, tracked changes, process verification records, or meeting notes showing the reviewer engaged with the content, not just the format.

If you answered "no" or "not sure" to more than two of these, your current AI document development practices have audit exposure worth addressing before it surfaces in an inspection.

Where This Lands

The opening scenario is a composite of patterns quality teams are running into, and that inspectors are becoming more practiced at identifying. Inspectors rarely ask "did you use ChatGPT?" directly. "Walk me through how this was developed" gets them to the same place.

AI tools aren't inappropriate for QMS document development. Used well, they make quality teams more efficient and can genuinely improve document consistency. But "used well" requires the same rigor you'd apply to any other QMS tool: validation, documented procedures, and controls proportionate to the risk.

The difference between a professional-looking SOP and a defensible one is exactly what inspectors are trained to find.

Build Compliance Documentation That Holds Up Under Inspection

Aligntra helps QA teams build defensible, traceable procedures, with gap analysis against ISO 13485, FDA QMSR, and other standards, plus evidence linking built into the workflow. Our SOP Builder is designed for exactly this use case: AI-assisted document development with built-in traceability, clause coverage verification, and audit-ready development records.

Whether you're assessing your current documentation or building a process for AI-assisted development, we can help.

Explore Aligntra Compliance Services

References

[1] ISO 13485:2016, Medical devices — Quality management systems — Requirements for regulatory purposes, Clauses 4.2.4 (Control of documents) and 4.1.6 (Validation of computer software used in the quality management system). International Organization for Standardization. https://www.iso.org/standard/59752.html
[2] U.S. Food and Drug Administration. "Quality Management System Regulation (QMSR) — 21 CFR Part 820." Final rule effective February 2, 2026. https://www.fda.gov/medical-devices/postmarket-requirements-devices/quality-management-system-regulation-qmsr
[3] Johner Institute. "Validating ChatGPT: Essentials for Medical Device Manufacturers." 2024. https://blog.johner-institute.com/regulatory-affairs/validating-chatgpt/
[4] U.S. Food and Drug Administration. "21 CFR Part 11 — Electronic Records; Electronic Signatures," Subpart B, Section 11.10(a): validation of systems to ensure accuracy, reliability, and consistent intended performance. https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11
[5] ISPE. "GAMP 5: A Risk-Based Approach to Compliant GxP Computerized Systems (Second Edition)." 2022. Appendix D11: AI and Machine Learning. https://ispe.org/publications/guidance-documents/gamp-5-guide-2nd-edition