EU MDR AI Compliance Checklist for Medical Device Software
This EU MDR AI compliance checklist turns intended purpose, software classification, technical documentation, quality management, post-market surveillance, change control, and routed LLM evidence into owner-assigned tests. Each check has a pass condition and retained artifact, with the request gateway boundary stated plainly.
A release ticket says model alias updated, while the regulatory-impact field remains empty. That row is where an EU MDR AI compliance checklist starts. The current consolidated Medical Device Regulation places technical documentation and modification management inside the manufacturer's controlled system. Risk management and clinical evaluation sit there too. Post-market surveillance, vigilance, CAPA, plus output monitoring complete the chain. I would block the release until the changed AI function has an owner, an impact assessment, and retrievable evidence.
TL;DR
- Give every AI function an intended-purpose decision and MDR status. Add the risk class, accountable owner, plus controlled configuration.
- Grade each check with a pass condition and evidence location. Record the finding state, remediation owner, plus retest date.
- Exercise post-market signal collection and change control. Test historical retrieval plus record integrity with real records.
- Count an HTTP gateway only for authenticated LLM traffic deliberately routed through it. Device validation and conformity decisions remain elsewhere.
Check 1: classify the function and intended purpose
Owner: regulatory affairs with the device owner.
Pass condition: every AI function has a documented intended purpose and intended user. Add the patient population and medical decision supported, followed by the operating environment and regulatory rationale. The record names the applicable MDR rule and risk class. MDCG 2019-11 rev.1 explains software qualification and Rule 11 classification, including the consequence of an incorrect diagnostic or therapeutic decision.
Evidence: approved function inventory and intended-purpose statement, followed by the classification memo, Basic UDI-DI, plus sign-off. Mark internal assistants and device functions as separate rows. A company making medical devices does not turn every office chatbot into medical-device software.
Check 2: identify the approved software configuration
Owner: design assurance with software engineering.
Pass condition: the device record identifies the released software or model version and every dependency that can materially affect behaviour. For a hosted service, include the endpoint and provider version or alias. Add the system prompt, retrieval source, classifier, plus fallback path when applicable.
Evidence: architecture diagram and software bill of materials. Add the release manifest, supplier version notice, plus approved baseline. The diagram should show a narrow arrow for each external model route. AI data lineage for audit supplies a pattern for connecting evaluated data and artifacts to the release.
Check 3: complete the Annex II evidence index
Owner: the person responsible for regulatory compliance with document control.
Pass condition: the index resolves to device description and intended purpose. It adds design information and applicable general safety and performance requirements. Risk management, verification, validation, plus clinical evaluation follow. The row ends at controlled evidence locations. Annex II requires the file to be clear and organised, as well as readily searchable and unambiguous.
Evidence: controlled index and document identifiers, followed by revisions and approvers. Retain the link-check result too. Select one applicable requirement and follow its cross-reference to the actual validation record. A green spreadsheet cell fails when the linked report was superseded three releases ago.
Check 4: run change control before deployment
Owner: quality with regulatory affairs and the software owner.
Pass condition: a proposed model or data change has a documented impact assessment before release. Apply the same control to prompts and routes, plus supplier or threshold changes. The record covers intended purpose and risk. Add validation and clinical evidence, followed by labelling and post-market monitoring. Regulatory action gets its own field. Article 10(9) explicitly includes procedures for managing device modifications in the quality management system.
Evidence: change ticket and policy or code diff. Add the impact assessment, validation result, approval, plus deployment time. Retain the rollback test and resulting configuration. The medical-device AI governance guide connects this packet to lifecycle ownership.
Check 5: reconcile post-market signals
Owner: post-market surveillance with safety and clinical functions.
Pass condition: the approved plan collects and analyses the sources named in Annex III, including incidents and non-serious events. It covers trends and literature, followed by registers and user feedback. Complaints plus similar-device information complete the source set. Defined indicators and thresholds trigger documented investigation and action.
Evidence: post-market surveillance plan and source register. Add query outputs and a complaint sample. The threshold review, investigation, CAPA linkage, and closure record complete the packet. Article 83 requires active and systematic gathering and analysis throughout the device lifetime. Article 85 requires the Class I report; Article 86 covers PSURs for Classes IIa and IIb, as well as Class III.
Check 6: test retrieval and integrity
Owner: records management with internal audit.
Pass condition: an independent reviewer retrieves an old release and its linked risk record. Validation and complaint records must resolve, along with the related change record. A copied event altered for the test fails the documented integrity check while the original remains protected.
Evidence: timed retrieval output and the access-control record. Add the integrity-test result, archive procedure, plus reviewer sign-off. Article 10(8) sets the availability period at least 10 years after the last covered device reaches the market, increasing to 15 years for implantable devices. LLM audit log retention separates a configured duration from successful retrieval.
Check 7: integrate applicable AI Act work without flattening scope
Owner: regulatory affairs with legal counsel.
Pass condition: the file records if the AI function meets both high-risk conditions described in MDCG 2025-6: it is a safety component or the AI system is itself a medical device, and the device is subject to third-party conformity assessment. Applicable AI Act material is integrated into existing MDR procedures and documentation.
Evidence: scoped applicability memo and requirement cross-reference. Add the technical-documentation index plus quality-system procedure. MDCG 2025-6 is joint AIB and MDCG guidance. The Commission guidance index states that MDCG documents are not legally binding.
Check 8: document the HTTP control boundary
Owner: enterprise architecture with security engineering.
Pass condition: every manufacturer-controlled application route to an LLM identifies the supplied user or agent and approved purpose. Add destination policy and content classification, followed by response handling and record location. Tests include a permit, a redaction, a denial, and a missing-identity failure.
Evidence: route inventory and staged events. Add the policy version, correlation identifiers, plus protected population export. Embedded inference and local models have separate owners. Direct browser use plus opaque vendor inference do too. Device validation and clinical conclusions remain outside the gateway. CAPA plus regulatory submissions stay outside as well.
DeepInspect
DeepInspect governs authenticated HTTP requests deliberately routed by a manufacturer-controlled application to an LLM. It evaluates supplied identity and workflow context, enforces versioned destination and content policy, inspects responses, and produces a signed, tamper-evident record for each routed decision.
That record can satisfy the request-route tests and support a controlled population. DeepInspect leaves intended-purpose classification, device validation, clinical evaluation, post-market conclusions, CAPA decisions, record-retention policy, and regulatory submissions with the manufacturer's qualified owners. Book a technical deep dive at deepinspect.ai.
Frequently asked questions
- Does this checklist replace a notified-body assessment?
No, because this is an operational test plan for preparing and checking controlled evidence. The notified body applies the relevant conformity-assessment procedure and sampling rules, while competent authorities retain their statutory roles.
- Does every medical-device AI function meet the AI Act high-risk test?
MDCG 2025-6 describes two conditions under Article 6(1). The AI must be a safety component or itself a medical device, and the device must undergo third-party conformity assessment. Record both parts in the applicability memo.
- Should failed and denied LLM calls appear in the evidence?
Yes, because they show policy operation and preserve the denominator for routed traffic. Excluding missing-identity failures or denials creates a polished but incomplete request population.
- What should happen when a hosted model alias changes?
Open change control and identify affected functions. Assess regulatory and risk impact, then execute the approved validation plan. Obtain release approval and update monitoring. Preserve the provider notice and deployed route evidence.
- Does a completed checklist prove MDR conformity?
It proves the listed tests passed for the defined scope and date. The conformity conclusion also depends on the full quality system and technical documentation. Clinical evidence and post-market work must support it, along with the applicable conformity-assessment procedure.