EU MDR AI Controls Mapping for Medical Device Software

A controls map earns its place when a reviewer can point to one requirement and locate its owner. The same row identifies the decision point and test result, followed by the retained record. EU MDR AI controls mapping should begin with the current consolidated Medical Device Regulation, then connect Articles 10 and 83 to 86 with Annexes II and III. I would reject a map that stops at product names. A named tool says where someone hopes the control lives. A repeatable test shows where the decision actually occurs.

TL;DR

• Give every mapping row an MDR anchor and objective. Add the owner and control point, followed by the test and evidence artifact. End each row with its boundary.
• Keep intended purpose and classification upstream of technical enforcement. Route policy consumes approved context; it does not create the regulatory conclusion.
• Connect release configuration to risk and validation. Add post-market signals, changes, plus CAPA through stable identifiers.
• Assign authenticated HTTP LLM traffic to the request control point. Keep embedded inference and clinical performance with their established owners. Conformity work stays there too.

Use seven fields in every control row

Start each row with the MDR anchor and the objective it creates. Add the accountable owner, followed by the system where the decision occurs. Define a test with inputs and expected results. Name the retained artifacts and finish with exclusions.

This shape prevents one vague control called AI governance from absorbing the entire quality system. Article 10(9) spans regulatory strategy and supplier control. It covers risk management and clinical evaluation, followed by production and post-market surveillance. Vigilance, CAPA, output monitoring, plus data analysis complete the stated quality-system scope. Each element needs its own owner and evidence path.

The AI governance framework provides a wider operating model. The rows below focus on medical-device software and the specific joins a quality or security team can test.

Intended purpose and software classification

MDR objective: establish the device function and intended purpose, followed by applicable rules and risk class.

Owner and control point: regulatory affairs owns the conclusion. The approved function inventory and classification procedure hold it.

Test and evidence: select one AI function and reproduce its classification using the approved intended-purpose statement and patient-impact rationale. Retain the classification memo and Basic UDI-DI. Add the approver plus current configuration reference. MDCG 2019-11 rev.1 explains qualification and Rule 11 treatment of software used for diagnostic or therapeutic decisions.

Boundary: the runtime policy layer consumes the approved function and data context. Regulatory status and MDR class remain upstream conclusions.

Technical documentation and configuration traceability

MDR objective: keep Annex II documentation clear and organised. It must also be readily searchable and unambiguous, with the current revision visible. Article 10(4) requires the technical documentation to include Annexes II and III.

Owner and control point: document control owns the index. Design assurance owns the approved baseline, with software engineering responsible for configuration capture.

Test and evidence: choose release 4.2 and follow its intended purpose to requirements and architecture. Continue to the risk file, verification results, plus validation results. Clinical evaluation and labelling follow. Supplier references and release approval complete the trace. Preserve link-check output and revision identifiers. For hosted dependencies, retain the exact endpoint and available model version or alias.

Boundary: a model-route event identifies what production called. The quality system decides if that configuration matches the approved device. AI data lineage for audit addresses the artifact join.

Risk, validation, and release control

MDR objective: maintain risk management and verify the implemented design. Manage modifications within the quality system required by Article 10(9).

Owner and control point: the risk owner and design assurance approve evidence. Change control is the release decision point.

Test and evidence: introduce a synthetic endpoint or prompt change. Confirm that the workflow identifies affected hazards and validation work. Clinical evidence and labelling must be reviewed, along with surveillance metrics and regulatory assessment, before deployment. Retain the ticket and impact assessment. Add the test report, approvals, deployment time, plus rollback result.

Boundary: request enforcement can block an unapproved route and record the policy version. It cannot grade clinical performance or approve a device change.

Post-market surveillance and CAPA

MDR objective: actively gather and record device data, then systematically analyse quality and performance. Safety data remains part of the same lifetime process. Article 83 requires conclusions to feed preventive and corrective action and updates to technical documentation.

Owner and control point: post-market surveillance owns signal intake and analysis. Quality owns CAPA; safety and clinical owners supply their judgments.

Test and evidence: select a complaint and trace it to the device version. Follow the investigation and risk reassessment, then the disposition and resulting CAPA or documented closure. Check the approved indicators and thresholds in the Annex III plan. Retain the source query and complaint record. Add the investigation, CAPA test, plus PSUR or Class I report reference.

Boundary: routed request records can link a complaint to identity and destination. They can also retain policy plus response handling. Causality and benefit-risk conclusions remain with qualified teams. Reportability remains with those teams as well. The AI governance audit framework helps test these joins.

Record availability and integrity

MDR objective: keep required technical documentation available under Article 10(8), at least 10 years after the last covered device is placed on the market and at least 15 years for implantable devices.

Owner and control point: records management owns retention and restoration. Security owns protected storage and integrity monitoring.

Test and evidence: retrieve an old release packet and its linked field record, then record the query time and missing joins. Alter a copy of one event and verify that the integrity mechanism detects it. Retain permissions and integrity output. Add the archive procedure plus reviewer sign-off.

Boundary: tamper evidence strengthens a runtime record. It never substitutes for an approved retention schedule or a complete technical file. The tamper-evident audit log guide explains that narrower mechanism.

AI Act integration for medical-device AI

Regulatory objective: identify applicable AI Act duties and integrate them with MDR processes while preserving each regime's requirements.

Owner and control point: regulatory affairs and legal counsel own applicability. The quality-system cross-reference is the operating control.

Test and evidence: confirm both high-risk conditions in MDCG 2025-6. The AI must be a safety component or itself a medical device, and third-party conformity assessment must apply. Retain the analysis and integrated technical-documentation index. The guidance also says governing MDR sampling rules continue to apply.

Boundary: MDCG 2025-6 is joint guidance rather than Regulation text. It supports a common application approach and supplies no universal runtime sample size.

Authenticated HTTP model traffic

Control objective: enforce approved identity and purpose before a routed LLM request leaves the manufacturer-controlled application. Destination plus information policy run at the same point.

Owner and control point: IAM supplies identity context. The application supplies approved workflow context. Security engineering owns the inline HTTP decision point.

Test and evidence: send one permitted synthetic request and one disallowed request to the same route. Add a missing-identity case and a response-policy case. Retain identity validation and content classification. Add the destination and policy version, followed by the decision and response disposition. Timestamp plus a stable event identifier complete the record.

Boundary: embedded inference and local models need separate controls. Consumer browser sessions and stolen provider credentials do too, along with opaque vendor-managed inference. Clinical validation and CAPA remain outside the request path. Notified-body sampling plus submissions also remain outside.

DeepInspect

DeepInspect is the control point for authenticated HTTP traffic deliberately routed between a manufacturer-controlled application and an LLM endpoint. It evaluates application-supplied identity and workflow context, applies versioned request and response policy, and records the decision with a signed, tamper-evident event.

In this map, DeepInspect contributes to destination and information-flow enforcement. It also supports repeatable runtime tests plus request-level evidence. Intended-purpose analysis, MDR classification, device validation, clinical evidence, post-market conclusions, CAPA, notified-body work, and regulatory submissions remain with the manufacturer's assigned owners. Book a technical deep dive at deepinspect.ai.