A clause-level mapping of FDA's quality system rules (21 CFR 820, now the QMSR), ISO 13485, ISO 14971, IEC 62304, EU MDR, and MDSAP audit expectations to a private AI platform deployed inside a manufacturer's own validated Azure environment.
Medical device companies are in a specific bind on AI.
Consumer tools such as ChatGPT, Copilot, Gemini, and Claude become an IP loss the moment an engineer pastes a draft 510(k), design history file content, or a CAPA narrative into a public model. “AI-enabled” device-industry SaaS often sits outside the manufacturer's QMS scope, so every output is technically an unqualified record. And shadow AI is already happening across regulatory, design, manufacturing, and post-market teams. The VPs of Quality we talk to confirm it, and none of them have the audit trail an FDA inspector or MDSAP auditor will ask for.
This paper documents the architecture nBrain deploys for medical device manufacturers, mapped clause by clause. The same architecture runs for Regal Technology Partners, a Tier 2 defense manufacturer, under ITAR and CMMC rules, an environment with audit and isolation requirements stricter than most device QMS deployments.
The platform is a non-product, production-support tool (legacy §820.70(i), ISO 13485 §7.5.6), validated for its intended use and wired into your existing CAPA, change-control, and management-review processes.
FDA's Quality Management System Regulation (QMSR) took effect on February 2, 2026. It replaced the old 21 CFR 820 subparts by incorporating ISO 13485:2016 by reference. Many quality teams still map to the legacy §820 sections, so this paper keeps them as a crosswalk next to the ISO 13485 clause that now governs. Your regulatory counsel confirms the final mapping.
If both are answered, integration is straightforward. If either fails, the deployment is at risk no matter what the vendor's marketing says.
If the AI is built into a marketed device, giving diagnostic output, treatment recommendations, or driving device behavior, it is Software in or as a Medical Device (SiMD or SaMD). Then IEC 62304, ISO 14971, FDA premarket requirements, and FDA's predetermined change control plan (PCCP) guidance for AI-enabled device software apply.
If employees use it in regulated workflows that produce device records (submissions, design reviews, complaint handling, CAPA, supplier audits), it is a production-support tool: validated for its intended use and integrated into the QMS, but not itself a regulated device. The architecture here is a production-support tool. Embedding AI in a marketed device is a separate IEC 62304 effort.
An FDA investigator, MDSAP auditor, or notified body asks two things of every record: who made it, and how. If a 510(k), CAPA closure, complaint investigation, or design-review minute was AI-assisted, the QMS has to show on demand which AI tool and version, what prompt, which sources were retrieved, who approved the output, and what training that reviewer had.
The platform writes a log entry for every prompt, retrieval, model call, reviewer action, and administrative action to Microsoft Sentinel or your existing SIEM. It is queryable in seconds and exportable as a signed bundle an auditor can check against the underlying records.
If your QMS satisfies FDA's quality rules and ISO 13485, and you can validate a controlled tool used in QMS workflows, this AI capability fits the same pattern.
Every manufacturer picks one of three patterns for AI in QMS-affected workflows. Each carries a different audit posture.
| Dimension | Private AI (this paper) | Consumer AI (ChatGPT, Copilot, and similar) | AI-enabled device SaaS |
|---|---|---|---|
| IP exposure for 510(k), PMA, and clinical evaluation content | None. Runs in your tenant | Active. Vendor cloud, vendor logs | Depends on the vendor |
| Model trains on regulated content | No. Committed in Microsoft's data protection terms | Possibly. Read the EULA | Depends on the vendor |
| Audit trail under your control | Yes. Written to your SIEM | None | Partial. Exported on request |
| QMS integration | Production-support tool (legacy §820.70(i), ISO 13485 §7.5.6) | Outside the QMS. Every output is an unqualified record | Vendor-claimed; your QMS team validates |
| MDSAP coverage (five jurisdictions) | Same architecture for all five | Not assessable | Depends on the vendor |
| Notified body and FDA inspectability | Read-only access on request | None | Depends on the vendor |
Legacy §820 sections are shown with the ISO 13485:2016 clause the QMSR now incorporates.
| Reference | Requirement | How the architecture meets it | Owner |
|---|---|---|---|
| §820.20 / ISO 13485 §5.6 | Management responsibility: quality policy, planning, review. | AI capability added to existing management-review inputs (audit findings, complaint trends, CAPA effectiveness). Your executive owns AI capability decisions. | Manufacturer |
| §820.22 / ISO 13485 §8.2.4 | Quality audit: internal audits of QMS effectiveness. | The AI tool is an auditable element of your internal audit program. Read-only audit access documented; findings flow to existing CAPA. | Manufacturer |
| §820.25 / ISO 13485 §6.2 | Personnel: qualifications, training, awareness. | Your training function keeps records and verifies competence before anyone uses AI in QMS workflows. | Manufacturer |
| §820.40 / ISO 13485 §4.2 | Document controls. | AI configuration, validation deliverables, SOPs, and work instructions versioned in your eDMS. Changes follow your change-control SOP. | Manufacturer |
| §820.50 / ISO 13485 §7.4 | Purchasing controls: supplier qualification. | Microsoft (Azure, Azure OpenAI) qualified as the cloud and model supplier under the Microsoft Products and Services DPA. nBrain qualified as the implementation and support supplier, with documented security and quality controls. nBrain holds no ISO 27001, SOC 2, ISO 9001, or ISO 13485 certification; your supplier qualification reviews the controls directly. | Manufacturer |
| §820.70(i) / ISO 13485 §4.1.6, §7.5.6 | Software validation for software used in production or the QMS, for its intended use. | The most-inspected control. Validated as a non-product computer system per FDA's software validation guidance and ISO 13485: documented intended use, risk-based validation, and model qualification covering accuracy, consistency, and bias for the workflows in scope. | nBrain |
| §820.75 / ISO 13485 §7.5.6 | Process validation for special processes. | Not directly applicable; the AI is a tool, not a manufacturing process. If it supports a special process (for example document generation for a sterilization-cycle review), that validation incorporates the tool's validation status. | Manufacturer |
| §820.100 / ISO 13485 §8.5 | Corrective and preventive action (CAPA). | Integrated into your CAPA system. Anomalies (output drift, audit-trail anomalies, accuracy-test failures) raised through the existing workflow. AI-assisted CAPA narratives pass a reviewer-approval gate before commitment. | Manufacturer |
| §820.180 / ISO 13485 §4.2.5 | Records: general requirements. | AI-assisted records retained per your retention SOP. The audit trail shows AI involvement. Records reproducible in human-readable form and exportable. | nBrain |
| §820.181 / ISO 13485 §4.2.3 | Device master record / medical device file. | The AI is not part of the device, so not part of the DMR. AI-assisted DMR documents follow your DMR-control SOP, including reviewer approval. | Manufacturer |
| §820.184 / ISO 13485 §7.5.1 | Device history record. | Not applicable to the tool. If used in DHR review (for example reviewing batch records for anomalies), the reviewer gate and audit trail apply. | Manufacturer |
| §820.198 / ISO 13485 §8.2.2 | Complaint files. | AI drafts the complaint investigation narrative for reviewer approval. The audit trail records AI involvement. Complaint decisions stay with your complaint-handling unit. | Manufacturer |
| §820.200 / ISO 13485 §7.5.4 | Servicing. | Not applicable to the tool. AI-assisted service records get the reviewer gate and audit trail. | Manufacturer |
The AI capability's risks, such as incorrect output influencing a submission, an audit-trail gap, or a supplier failure, go into your current risk-management file, not a separate one.
| Reference | Requirement | How the architecture meets it | Owner |
|---|---|---|---|
| §4 / §5 | Risk management process and risk analysis. | Intended use documented. Hazardous situations identified: incorrect output influencing a submission decision, tool unavailable at a regulatory deadline, audit-trail gap, supplier failure (Microsoft or nBrain), model drift between qualification cycles. | Manufacturer |
| §6 | Risk evaluation against acceptability criteria. | Your existing criteria apply. Built-in controls (reviewer approval, audit trail, supplier and model qualification) typically bring residual risk to acceptable. Your risk-acceptance authority signs off. | Manufacturer |
| §7 | Risk control measures and residual risk. | Human reviewer gate, role-based access, audit trail, signed records, periodic model-qualification review, supplier monitoring, change control. You evaluate residual risk under your SOP. | Shared |
| §8 | Risk management report and overall residual risk. | The AI tool is included in your risk-management report, reflecting built-in controls plus any manufacturer-specific compensating controls. | Manufacturer |
| §9 | Production and post-production information. | Anomaly signals (Microsoft Sentinel) and periodic model-qualification results feed your post-production risk activities. Significant anomalies go through CAPA. | Shared |
Where AI assists QMS workflows that produce technical documentation, the architecture aligns to Annex I and Annex VII.
Where AI is used in workflows the EU AI Act classifies as high-risk, extra conformity obligations may apply. The architecture supports the technical and audit requirements; the legal classification and conformity path are yours to determine with counsel.
MDSAP (FDA, Health Canada, ANVISA, TGA, MHLW) audits your QMS once for all five. Tool validation, supplier qualification, audit trail, and integrated CAPA cover its chapters without jurisdiction-specific duplication.
| Chapter | How the AI capability fits |
|---|---|
| 1 · Management | Input to management review; documented authority for deployment, expansion, and decommissioning. |
| 2 · Marketing authorization and registration | A production-support tool, not a marketed device. No separate filing. |
| 3 · Measurement, analysis, improvement | AI anomalies and qualification failures flow to existing CAPA. |
| 4 · Adverse events and advisory notices | AI-assisted complaint and advisory content passes the reviewer gate. |
| 5 · Design and development | Reviewer approval and audit trail on AI-assisted design-review and DHF content. AI is not part of the device design. |
| 6 · Production and service controls | Validated as a production-support tool (legacy §820.70(i), ISO 13485 §7.5.6). |
| 7 · Purchasing controls | Microsoft and nBrain supplier qualification documented (ISO 13485 §7.4). |
The most misunderstood boundary in device-industry AI. IEC 62304:2006/A1:2015 governs software that is part of a medical device or is itself one (SaMD).
The capability in this paper is not medical device software. Your people use it to produce QMS records: submissions, complaint investigations, CAPA narratives, design-review minutes, supplier-audit reports. FDA's quality system rules and ISO 13485 §7.5.6 govern it, not IEC 62304.
If the intended use crosses the line (the AI is built into a marketed device, drives device behavior, or gives diagnostic or treatment output to clinicians or patients), it becomes SaMD or SiMD. That takes a separate IEC 62304 lifecycle, an FDA pre-submission, and a predetermined change control plan if the model will be updated after clearance.
| Use case | IEC 62304? | Path |
|---|---|---|
| AI helps draft a 510(k), approved by a reviewer before submission | No | Production-support tool |
| AI helps draft complaint investigation narratives | No | Production-support tool |
| AI helps write CAPA root-cause analysis | No | Production-support tool |
| AI helps draft supplier-audit reports | No | Production-support tool |
| AI built into a marketed device (diagnostic, therapeutic, monitoring) | Yes | SaMD / SiMD under IEC 62304, a separate engagement |
| AI gives clinical decision support output to clinicians or patients | Likely | SaMD evaluation required, a separate engagement |
Every device-QMS control an AI deployment touches, with its status and owner.
| Reference | Topic | Status | Owner |
|---|---|---|---|
| §820.20 / §5.6 | Management responsibility | Integrated into management review | Manufacturer |
| §820.22 / §8.2.4 | Internal audit | Auditable element | Manufacturer |
| §820.25 / §6.2 | Personnel training | Module provided | Manufacturer |
| §820.40 / §4.2 | Document controls | eDMS and change control | Manufacturer |
| §820.50 / §7.4 | Purchasing and supplier qualification | Microsoft and nBrain dossier | Manufacturer |
| §820.70(i) / §7.5.6 | Software validation (production-support tool) | Implemented: IQ/OQ/PQ and model qualification | nBrain |
| §820.100 / §8.5 | CAPA | Integrated into existing CAPA | Manufacturer |
| §820.180 / §4.2.5 | Records: audit trail, retention, reproducibility | Implemented (signed bundle export) | nBrain |
| §820.181 / §4.2.3 | DMR / medical device file | Not part of the DMR; reviewer-gated | Manufacturer |
| §820.198 / §8.2.2 | Complaints | Reviewer-gated | Manufacturer |
| ISO 14971 §4–9 | Risk management | Integrated into existing risk file | Shared |
| EU MDR Annex I §17 | Electronic programmable systems | Not applicable (production-support) | N/A |
| EU MDR Annex VII | Technical documentation | Reviewer-gated where AI assists | Manufacturer |
| EU MDR Art. 83 / 86 | PMS and PSUR | Reviewer-gated where AI assists | Manufacturer |
| MDSAP Ch. 1 | Management | Management review input | Manufacturer |
| MDSAP Ch. 3 | CAPA | Integrated | Manufacturer |
| MDSAP Ch. 6 | Production and service controls | Production-support tool validation | nBrain |
| MDSAP Ch. 7 | Purchasing controls | Supplier qualification | Manufacturer |
| IEC 62304 | Medical device software lifecycle | Out of scope (not SaMD or SiMD) | N/A |
The model is pre-trained by its provider on public data. Each prompt and its retrieved context go to the Azure OpenAI endpoint in your tenant and a response comes back. Prompts are not used for training under Microsoft's data protection terms. For elevated IP protection, customer-managed keys and an approved exemption from abuse monitoring keep prompts from being stored for review.
Gateway, vector database, Azure OpenAI endpoint, and audit-log store all run in an Azure region you control. Network rules deny outbound traffic to the public internet; the only egress allowed is to documented Microsoft service endpoints within your DPA scope.
Every prompt, retrieved document, response, reviewer action, and admin event is logged and the AI service can be limited to append-only rights to the log. An FDA investigator, notified body, or MDSAP auditor can get read-only access or a signed export to check any claim against the records.
Consumer AI exposes your IP. AI-enabled device SaaS rents your IP. Private AI lets your AI work inside your QMS without your IP, or your audit trail, ever leaving your perimeter.
Bring your VP of Quality, VP of Regulatory Affairs, and Software QA lead. We'll go through this mapping, the validation deliverables, and the model-qualification protocol your QMS workflows need. No pitch deck.