FDA AI/ML Guidance AI Controls Mapping for Device Software

A control map row labelled AI monitoring tells an FDA reviewer almost nothing. The useful row names the image-triage function and its quality owner, then the production model and drift test, plus the complaint linkage and retained evidence. FDA AI/ML guidance AI controls mapping should make every row executable. I use seven fields: source anchor and objective; owner and control point; test and evidence; boundary. The last field prevents a request gateway or model platform from inheriting claims it cannot support.

TL;DR

• Build each row around a source anchor and control objective; an owner and control point; a repeatable test and retained evidence; and a boundary.
• Keep source status visible. FDA's lifecycle document is draft guidance. Its August 2025 PCCP document is final guidance, while the QMSR is a binding rule.
• Map change control to the approved device and any applicable PCCP. A vendor model release never supplies the manufacturer's regulatory assessment.
• Credit an HTTP gateway only for requests that traverse it with application-supplied identity and context.

Map source status before control coverage

The source field should distinguish obligation from recommendation. The FDA's January 2025 lifecycle and marketing submission document is draft guidance. FDA describes it as nonbinding and not for implementation. It proposes documentation and total product lifecycle considerations that may inform control design.

The August 2025 PCCP document is final guidance. It recommends a description of planned modifications and an associated methodology, along with an impact assessment for PCCPs reviewed in covered marketing submissions. Final guidance still states agency recommendations rather than creating a new regulation.

The QMSR final rule became effective February 2, 2026. Revised 21 CFR Part 820 incorporates ISO 13485:2016 by reference and adds FDA requirements. Put the source type and version in every map row. That small field stops guidance language from quietly becoming a fabricated requirement.

Intended use and function classification

Objective: connect every AI-enabled device software function to its intended use and claims; its users and patient population; its operating environment and applicable regulatory pathway.

Owner and control point: regulatory affairs owns the classification decision. The product inventory and change intake form are the control points.

Test and evidence: select one production feature and trace its user-visible output to the approved function record and submission reference. Retain the inventory row and intended-use statement; the architecture and rationale; the approver and date.

Boundary and gap: internal assistants and device-adjacent tools need their own classification rationale. The inventory should expose unmapped vendor inference as a gap. AI governance frameworks can provide the enterprise lifecycle, while the device map adds intended-use and marketing-status fields.

Data, risk, and validation control

Objective: bind the released model to the development and evaluation data; the risk analysis and validation protocol; the acceptance rules and results; and the limitations applicable to the intended use.

Owner and control point: design quality owns the release gate with clinical and ML leads. The controlled validation protocol supplies the decision point.

Test and evidence: pick the active release and reproduce its dataset versions and preprocessing; its model configuration and subgroup evaluation; its unresolved anomalies and signed approval. Retain source lineage and the executed protocol. Include the deployment identifier that joins the approved result to production.

Boundary and gap: a model provider supplies dependency evidence, while the manufacturer owns device-specific validation and safety conclusions. The FDA page on Good Machine Learning Practice guiding principles identifies a total product lifecycle frame. AI data lineage for audit explains the release-level joins.

PCCP and change control

Objective: keep each implemented modification within the authorized device and applicable PCCP, or route it to regulatory assessment before release.

Owner and control point: regulatory affairs and the change-control board share the decision. The release pipeline enforces the approved outcome.

Test and evidence: select a changed model release. Trace it to the planned modification and executed methodology; the validation result and impact assessment; the approval and deployment timestamp; the monitoring update and rollback target. Repeat with an out-of-boundary change and verify that release stops pending assessment.

Boundary and gap: the PCCP covers its reviewed scope. Combined changes can alter impact and deserve explicit assessment. My preference is a red map cell for every dependency with an unresolved version. A blank cell makes a tidy slide and a weak control.

QMS records and complaint handling

Objective: operate AI records inside the manufacturer's controlled quality management system and connect field signals to investigation and corrective action.

Owner and control point: the quality-system owner controls procedures and record custody. Complaint handling controls intake and investigation, with regulatory and safety owners responsible for their conclusions.

Test and evidence: choose one complaint involving software behavior. Retrieve its review and evaluation; the investigation and device configuration; the reportability assessment and correction; and the closure. If corrective action or a model change followed, trace that work into the release record and effectiveness check.

Boundary and gap: Section 820.35 of the revised Part 820 addresses record controls and complaint records. An AI event log can support the investigation but cannot decide reportability or patient impact. It also cannot decide corrective action.

Production route and decision evidence

Objective: govern external LLM requests made by a manufacturer-controlled application and preserve the exact rule applied to each routed event.

Owner and control point: the application owner supplies authenticated identity and approved workflow context. Security engineering owns the inline HTTP policy point. Records management owns retention and authorized retrieval.

Test and evidence: send synthetic sensitive content to approved and disallowed model destinations. Confirm the declared permit and redact outcomes, plus the deny outcome. Repeat with missing identity context. Retain the model endpoint and application; the supplied principal and classification; the policy version and decision; the timestamp and response disposition; and the integrity result. The tamper-evident audit log guide covers independent record custody.

Boundary and gap: embedded inference and local models bypass this point. Direct browser use and opaque vendor-managed calls do too. IAM owns identity proofing. The manufacturer retains validation and clinical accountability, along with QMS and regulatory accountability.

Review coverage and open gaps

A control map is operational when another reviewer can run each test. Add a test environment and declared input; the expected result and evidence location; the review date and remediation status. Record partial coverage as partial. Assign every open gap an owner and interim measure, plus a target date and retest result.

Use color carefully. A green row should mean the latest test passed for the named scope and period. It should never mean policy exists. Put bypass paths and missing joins in red on the same page. That is the diagram a CISO can defend because it shows control limits before a regulator finds them.

DeepInspect

DeepInspect is a stateless proxy for authenticated HTTP traffic routed to LLM endpoints. It evaluates the identity and approved context supplied by the calling application. It classifies content and enforces destination and policy rules, then inspects responses and writes a signed, tamper-evident decision record.

In this map, DeepInspect contributes to the production-route control and supplies bounded event evidence for investigations. It leaves routing completeness and identity proofing; embedded inference and device validation; PCCP decisions and QMS operation; and clinical conclusions and FDA submissions with the manufacturer's named owners. Book a technical deep dive at deepinspect.ai.