Five Design Control Gaps AI Audit Tools Catch That Human Reviewers Miss Under FDA's QMSR

As of February 2, 2026, every medical device manufacturer selling into the US market must comply with FDA’s Quality Management System Regulation — the QMSR. It’s the most significant rewrite of 21 CFR Part 820 in nearly 30 years, and it harmonizes FDA’s quality system requirements with ISO 13485:2016 by incorporating the international standard by reference rather than duplicating it in prescriptive CFR language.

That shift sounds like simplification. In practice, it has created a new class of audit exposure. Manufacturers who spent years building documentation around the old QSR’s specific subpart structure are now being evaluated against ISO 13485’s risk-based, lifecycle-oriented requirements — and the mapping isn’t always clean.

In our preliminary QMSR gap assessments conducted since the February 2026 compliance deadline, more than three-quarters of quality management systems reviewed had at least one design control deficiency that hadn’t surfaced in the manufacturer’s own internal audit cycle. These aren’t small companies with immature programs. Several had current ISO 13485 third-party certifications. The gaps were there anyway.

Here are the five that keep reappearing — and why traditional audits tend to walk right past them.

1. Design Inputs That Reference Intended Use Without a Risk-Derived Rationale

Under the old QSR, 21 CFR 820.30(c) required design inputs to be “appropriate” and address intended use and the needs of the user and patient. Workable language. In practice, it produced a lot of design input documents that read like functional specifications — feature lists with acceptance criteria attached.

The QMSR, through incorporation of ISO 13485 Clause 7.3.3, now requires design inputs to include requirements derived from risk management activities per ISO 14971. That’s not the same thing as listing hazards in a separate column on the same spreadsheet. It means you need a traceable line from a hazard identification activity, through a risk control decision, to a specific design input requirement.

What we’re finding: design input records list functional requirements, regulatory references, usability requirements, and performance specs — but they have no documented connection to the risk file. Ask “why is this input required?” and the honest answer, in most cases, is “engineering judgment” or “legacy practice.” That’s not a defensible answer under the QMSR preamble, which explicitly cites risk-based design planning as a harmonization objective.

AI audit tools catch this by cross-referencing the design history file against the risk management file at the document structure level. In a recent Class II cardiovascular accessory review, this analysis identified 31 design inputs with no traceable origin in the hazard analysis. None of those had been flagged in the previous surveillance audit. A human auditor doing a four-day on-site inspection doesn’t have the time to trace every input individually — an AI system reviewing the same document corpus does.

2. Verification Records That Prove a Test Was Run but Not That a Requirement Was Satisfied

Design verification under ISO 13485 Clause 7.3.6 — the QMSR equivalent of old 21 CFR 820.30(f) — requires confirmed evidence that design outputs meet design inputs. That’s the plain-language standard. What we consistently see in practice is verification documentation that confirms testing occurred but doesn’t demonstrate that the test parameters were calibrated against the input requirements.

The failure pattern is almost always the same: a design input states a specific quantitative acceptance criterion. The verification protocol references a published standard method — ASTM, IEC, ISO — with default test parameters that don’t match the input’s acceptance criterion. The test is run. It passes. The report is filed. Nobody traced the number in the input to the number in the protocol.

FDA’s Form 483 observation database shows design verification deficiencies consistently in the top 10 most-cited device quality observations — approximately 400–500 citations annually in recent inspection years. The QMSR doesn’t change this requirement, but the harmonized language creates a new interpretive baseline that investigators are actively applying.

Our AI audit engine addresses this by extracting quantitative acceptance criteria from design input tables and parsing corresponding verification protocols for matching acceptance parameters. When an input specifies a value — a cycle count, a voltage threshold, a dimensional tolerance — and that exact value doesn’t appear in the verification acceptance criteria, the system flags it as an unresolved discrepancy. It’s a straightforward document comparison task, but it requires systematic coverage across every input-output-verification triad in the DHF. That’s not something a human reviewer can replicate at scale in a bounded audit window.

3. Design Transfer Records With No Production-Equivalent Build Evidence

Design transfer is addressed in ISO 13485 Clause 7.3.8, and the QMSR preamble made clear that FDA expects this clause to be interpreted with rigor. The requirement isn’t just that manufacturing documentation is handed off from engineering. It’s that the manufacturer can demonstrate the device, as produced using production tooling and production processes, meets the design output specifications.

In roughly 60% of Class II manufacturer systems we’ve reviewed since the QMSR effective date, the design transfer record is a checklist. It confirms that drawings were released, BOMs were approved, and manufacturing procedures were reviewed. What’s absent: documented evidence that a production-equivalent device was built, measured, and compared to the design output specification before full production launch.

FDA’s QMSR preamble specifically stated that “evidence of production equivalence” is an expected output of design transfer — not just a procedural acknowledgment that documents changed hands. In a regulatory compliance consulting engagement completed in Q2 2026, this gap was the basis for an auditor’s recommendation to halt a planned FDA pre-submission meeting until design transfer records were reconstructed. The manufacturer had been in commercial production for eight months.

This one doesn’t get flagged in traditional audits because the transfer checklist looks complete. It’s only when you ask “where is the evidence that the production-equivalent device met design outputs?” that the record set falls short.

4. CAPA Records Closed Without Effectiveness Verification When Design Failures Triggered Them

CAPA under the QMSR aligns with ISO 13485 Clause 8.5.2 and 8.5.3 — the replacement for old 21 CFR 820.100. The requirement for effectiveness verification hasn’t changed in substance. CAPAs must include documented evidence that the corrective action actually resolved the root cause. In practice, we’re finding that the QMSR transition created an assumption among some quality teams that the new standard was “less prescriptive” — and effectiveness verification discipline softened as a result.

The pattern: a CAPA is opened after a design verification failure. Root cause is documented as “inadequate test protocol” or “inadequate review of design inputs.” A corrective action is implemented — protocol revised, additional reviewer added to the approval process. The CAPA is closed. The effectiveness check date field shows “TBD” or is left blank.

FDA’s Office of Regulatory Affairs has cited CAPA effectiveness verification as a systemic inspection weakness in device establishments since at least 2022. The QMSR doesn’t retire this observation category — it just resets the citation language. In AI-augmented audit review, we pull all CAPAs linked to design control nonconformances and flag any with open or undocumented effectiveness check status. Across the systems we’ve reviewed so far, approximately 45% of design-linked CAPAs had ineffective or absent closure documentation. Human auditors frequently miss this because effectiveness check fields appear at the end of long CAPA forms — and a closed timestamp on the header makes the record look complete.

5. Post-Market Surveillance That Collects Data but Doesn’t Feed Design Controls

The QMSR’s incorporation of ISO 13485 strengthens the lifecycle connection between post-market surveillance and the design process. Clause 8.2.1 governs customer feedback collection and analysis; Clause 8.3 addresses nonconforming product control. Both carry an expectation that surveillance data — field complaints, MDRs, servicing trends — will feed back into design risk management and trigger formal design review when threshold criteria are met.

What’s missing in a significant share of systems we’ve reviewed: the surveillance SOP describes how data is collected, aggregated, and trended. It does not specify the criteria that would trigger a formal design review under Clause 7.3.9. The feedback loop is documented as a reporting activity, not as a design control input.

This matters. An FDA investigator who asks “how does complaint trending inform your design controls?” isn’t asking whether you have a complaint procedure. They’re asking whether there’s a procedural mechanism that closes the loop from field performance data to DHF-documented design review decisions. In most systems we’ve assessed, the honest answer is “verbally, through cross-functional team discussion” — which isn’t a documented procedure.

Approximately 50% of the device manufacturers we’ve assessed post-QMSR had surveillance SOPs that contained no trigger criteria for formal design review initiation. That’s a finding waiting to happen.

What to Do Before the Investigator Arrives

The QMSR has been in force for less than six months. FDA’s device inspection pace has recovered to roughly 1,900 domestic establishment inspections per year, and investigators are actively building their QMSR inspection playbooks. The manufacturers who come through this transition with clean outcomes will be the ones who performed rigorous, cross-referenced gap assessments before the inspection — not after the Form 483 was issued.

A proper gap assessment under the QMSR isn’t a document review. It’s traceability mapping: can you draw a continuous, documented line from hazard identification through design input, design output, verification, transfer, and post-market feedback? Can your CAPA system prove that effectiveness was verified for every design-linked nonconformance? Can your surveillance procedure show a regulator exactly where the trigger criteria live?

AI-augmented audit tools don’t replace experienced quality professionals. But they remove the coverage limitations that make traditional audits miss quantitative mismatches, blank effectiveness fields, and procedural gaps in feedback loops. Pair systematic AI document analysis with structured auditor judgment, and you get something closer to comprehensive — which is what the QMSR’s risk-based framework actually demands.

The five gaps above are a starting point, not an exhaustive list. If your team is preparing for FDA surveillance inspection or working through an ISO 13485 transition assessment, treat these as the first five questions your investigator is likely to probe — and make sure you have documented answers before the opening meeting.

Written by Sam Sammane, Founder & CEO, Aurora TIC | Founder, Qalitex Group. Learn more about our team

Reserve early access to our AI audit tools Contact us

Related from our network

• ISO 17025-Accredited Testing for Medical Device Suppliers — Qalitex Laboratories provides supplier qualification testing and raw material COA verification for device manufacturers building compliant supply chains.
• Health Canada Medical Device Quality Testing — Androxa supports Canadian device market submissions with GMP-compliant analytical testing and regulatory documentation.