How to Get AI Tools Approved for Your ISO QMS

Somewhere in your quality department, someone is probably already using ChatGPT to draft a CAPA justification or summarize a supplier audit finding. I say that with confidence because I see it at nearly every company I walk into now, and almost none of them have a control record for it. That gap is what this article is about: not whether AI belongs in a quality management system, but how you formally bring it inside the fence so an auditor doesn't have to ask you why it wasn't there already.

Why AI Tools Trigger Requirements That Already Exist

Here's the thing quality managers keep missing: you don't need a new clause to regulate AI use. The clauses you're already certified against already cover it.

ISO 9001:2015 clause 7.1.6, Organizational Knowledge, requires you to determine the knowledge necessary for your processes to produce conforming product or service, and to consider "current knowledge and determine how to acquire or access any necessary additional knowledge." An AI tool that summarizes a regulation, drafts a risk assessment, or generates training content is functioning as an external knowledge source the moment someone relies on its output. Clause 8.5.1, Control of Production and Service Provision, requires "controlled conditions," including documented information defining the activities performed, the results expected, and the competence of the people performing them. A finding under clause 8.5.1 doesn't require the word "artificial intelligence" to appear anywhere in the standard — the clause already covers any tool, human or software, operating under conditions that need to be controlled.

If you're certified to ISO 13485:2016, the language is even more direct. Clause 4.1.6 requires manufacturers to "document procedures for the validation of the application of computer software used in the quality management system," and that validation must occur "prior to initial use and, as appropriate, after changes to such software or its application." That obligation does not distinguish between a spreadsheet macro and a large language model. If your QMS software list includes a generative AI tool and there's no validation record next to it, that's the gap an auditor will find.

How the Clauses Compare Across Standards

The Five-Step Approval Pathway

Step 1: Inventory What's Actually Being Used

Start with an honest inventory, not an aspirational one. Ask your document control coordinator, your quality engineers, and your CAPA owners what they're actually typing into. In my experience the list usually includes:

• Drafting CAPA root-cause narratives
• Triaging and coding customer complaints
• Summarizing supplier audit reports
• Generating training materials
• Translating procedures for multi-site operations
• Spotting trends in nonconformance data

None of that is inherently a problem. The problem is that most of it is happening without anyone having decided, in writing, that it's allowed.

Step 2: Classify Each Tool By What It's Actually Doing

Not every use of AI carries the same risk, and treating them all the same wastes effort you need elsewhere. I sort tools into two buckets. Assistive tools draft something a qualified human independently reviews and signs before it becomes part of a record: a first-pass CAPA description, a rough translation, a summary someone checks against the source document.

Decisional tools produce an output that becomes the record, or triggers an action, without meaningful independent review: auto-generated complaint severity codes that flow straight into your trending report, or supplier scores that feed a sourcing decision without a human recalculating them.

ISO 42001:2023 clause 6.1.2 requires an AI risk assessment before an organization relies on a given AI system for its intended purpose, and that assessment is exactly this exercise: what's the likelihood an incorrect output reaches a controlled record, and what's the severity if it does.

Step 3: Validate Before You Rely On It

This is the step almost everyone skips, and it's the one an auditor will ask about first. Borrowing the logic of ISO 13485:2016 clause 4.1.6 even if you're only certified to ISO 9001: write an intended-use statement for the tool, define what "correct output" looks like, run a representative sample of real inputs through it, and document whether the outputs met your acceptance criteria. For a decisional tool, that sample needs to be large enough to catch edge cases, not just the easy ones. Set a re-validation trigger, too: a model version change, a prompt or configuration change, or a noticeable shift in output quality should all restart this step. Unlike a piece of deterministic QMS software, an AI tool can change behavior on the vendor's schedule, not yours, which is exactly why one-time validation isn't enough.

Step 4: Write the Approval Into Your Document Control System

An approval that lives in someone's memory or a Slack thread doesn't exist for audit purposes. Add the tool to your software or equipment list, write a short SOP covering intended use, the human oversight checkpoint, who owns re-validation, and what happens if the tool's output is found wrong after the fact. Update your risk register to reflect the specific risk the tool introduces, not a generic "AI risk" line item. If you're building this against ISO 42001:2023 as a reference framework, clauses 6.1.3 (AI risk treatment) and 6.1.4 (AI system impact assessment) give you the structure for that documentation even if you never pursue certification to the standard itself.

Step 5: Monitor, Re-Audit, and Retire When Needed

Put AI tool performance on the agenda for your internal audit program under ISO 9001:2015 clause 9.2, and revisit it at management review under clause 9.3. Define a small set of things worth watching: how often a human reviewer catches and corrects an AI-drafted output, how often output quality changes after a vendor update you didn't request, and whether the tool is still being used the way it was approved for. If a vendor silently swaps the underlying model, or the tool starts getting used for something beyond its original intended-use statement, that's a re-approval event, not a shrug.

Where ISO 42001 Fits If You're Not Ready to Certify

You don't need to pursue full ISO 42001:2023 certification to use it well. I tell most of my ISO 9001 clients to treat 42001 as a reference architecture rather than a certification target, at least at first. Its Annex A groups controls under categories including policies related to AI, resources for AI systems, AI system life cycle, data for AI systems, and use of AI systems, and that structure maps almost one-to-one onto the approval pathway above. If your quality team is already ISO 9001 or ISO 13485 certified, adding a lightweight AI control layer built on 42001's structure is a fraction of the work of a full certification project, and it closes the exact gap an auditor is starting to probe.

If you want a framework that's even lighter to start with, NIST published version 1.0 of its AI Risk Management Framework in January 2023, and its four functions, Govern, Map, Measure, and Manage, map cleanly onto the plan-do-check-act cycle already built into ISO 9001:2015. ISO/IEC 23894:2023 offers similar risk-management guidance specifically written for AI systems and is worth reading alongside 42001 if you're building your risk register from scratch. Neither replaces the ISO clauses you're actually certified against. Both give you vocabulary and structure for filling in the gaps those clauses leave open.

If you're genuinely unsure where your organization stands, an AI governance gap assessment against ISO 42001 will tell you exactly which of the five steps above you've already done informally and which ones exist nowhere in writing. We've also put together a closer look at how AI is already showing up inside quality system reviews, which is worth reading if you want to see what an auditor's actual questions tend to look like before they show up in your facility.

A Simple Test for Whether a Tool Needs Formal Approval

If you're short on time, three questions will tell you where to start:

1. Does the tool's output become part of a controlled record — a CAPA, a complaint file, a supplier score, a released procedure?
2. Does a qualified human independently verify that output before it's relied on?
3. Would an incorrect output plausibly cause a nonconformity, a customer complaint, or a regulatory finding?

A yes to the first question and a no to the second means you need a formal approval record now, not after your next surveillance audit.

What Auditors Are Actually Asking Right Now

The auditors I talk to aren't asking "do you use AI." They're asking who authorized the tool, what the intended use statement says, how output accuracy was checked before go-live, and what happens when it's wrong. Those are ordinary clause 8.5.1 and 7.1.6 questions dressed up in a new topic. The organizations that get flagged aren't the ones using AI aggressively. They're the ones who never wrote any of it down.

FAQ

Do I need ISO 42001 certification before I can use AI tools in my ISO 9001 QMS? No. ISO 42001:2023 is not a prerequisite for using AI tools inside an ISO 9001 or ISO 13485 system. You can build an internal AI control process using 42001's clause structure and Annex A controls as a reference framework without ever pursuing certification to the standard itself.

Which AI tools actually need a formal approval record? Any tool whose output touches a controlled document, feeds an unreviewed decision, or reaches a customer or supplier-facing record needs a written approval. A tool that only drafts text for a human to independently review and revise before signing carries lower risk, but it still belongs on your software inventory.

Will an ISO 9001 auditor ask about AI tool use during a surveillance audit? Increasingly, yes. Auditors are trained to probe software controls generally under clauses 7.1.6 and 8.5.1, and AI tools are now squarely inside that scope even though the standard never uses the word "AI."

How long does it take to build an AI approval process? For most quality teams, inventorying tools, building a risk register, and writing a first validation protocol takes four to eight weeks. The low end reflects teams with fewer than five tools and little existing documentation; the high end reflects organizations with twenty or more tools and some controls already in place informally.

What's the difference between validating an AI tool and validating regular QMS software? Deterministic QMS software behaves the same way every time it's given the same input, so a one-time validation under a protocol like ISO 13485:2016 clause 4.1.6 is often sufficient. AI tools are probabilistic and can change behavior when a vendor updates the underlying model, so validation needs an ongoing monitoring component, not just an initial sign-off.

Last updated: 2026-09-25