EU AI Act Medical Devices: What Changes in the MDR File

Article 43(3) hands the procedure back to your sector: "the provider of the system shall follow the relevant conformity assessment procedure as required in accordance with the relevant Union harmonisation legislation." The next sentence changes your submission: "The requirements set out in Section 2 of this Chapter shall apply to those high-risk AI systems and shall be part of that assessment." Part of it, not beside it: Articles 8 to 15 arrive inside a review your notified body already schedules.

Amended Article 43(3) adds a short list on top: "Points 4.3., 4.4., 4.5. and the fifth paragraph of point 4.6 of Annex VII shall also apply." MDCG 2025-6 Q28 names the same four: data set access at 4.3, the power to demand further evidence and run its own tests at 4.4, conditional access to the trained models at 4.5, and at the fifth paragraph of 4.6 the rule that a system failing on its training data has to be re-trained before a new assessment can be applied for.

Keep that list separate from Article 17. The Article 17 quality management system is a provider obligation at Article 16(c) and it applies; the Annex VII point 3 assessment of that system is not in the list amended Article 43(3) names, so ask your notified body which procedure it will run. The audit stays the MDR or IVDR one, which MDCG 2025-6 Q28 describes as already requiring a quality management system audit, a technical documentation review and inspections for Class IIa, Class B and above.

Your notified body may not be designated under the AI Act yet, and Article 43(3) does not rush it: bodies notified under Section A legislation "shall apply for designation ... by 28 January 2028". Applying is not being designated. Ask yours where it sits before planning a submission window.

Adding a model does not drag a device into third-party assessment it did not previously need: manufacturers "are not required to choose" that route "only because the product includes a high-risk AI system as a safety component".

Article 6(1) has two conditions joined by "and". Point (a) asks whether the AI system is a safety component of a product covered by the Annex I legislation, or is itself such a product. Point (b) asks whether that product "is required to undergo a third-party conformity assessment" before being placed on the market. Point (b) is not a question about the model but about the class you already hold, which puts the scoping decision with regulatory affairs.

Three amendment paragraphs sharpen the two conditions. Article 6(1a) narrows point (a): systems "solely used for non-safety related aspects of user assistance, performance optimisation, service efficiency, automation or convenience or quality control shall not qualify as safety components." Article 6(1b) pushes back the other way, keeping systems whose "failure or malfunctioning ... would endanger health and safety" inside it. Article 6(1c) narrows point (b), excluding products assessed by a third party "solely due to risks other than risks to health and safety", naming electromagnetic interference.

Table 1 of MDCG 2025-6 turns the test into eight rows.

Causation runs one way. MDCG 2025-6 Q4, citing Recital 51, states that high-risk classification under Article 6(1) "does not imply that the medical device ... falls in a higher risk class". A Class IIa device does not become Class IIb because of the model inside it.

The last row covers health institutions building their own tools. A device made and used only within a health institution under Article 5(5) is not subject to third-party conformity assessment, so MDCG 2025-6 Q35 concludes it is not high-risk. That is not an exemption: other obligations still apply, including the prohibited practices.

One sentence of the guidance belongs in your quality manual: every reference to manufacturer within the meaning of the MDR or IVDR is read as a reference to provider under the AI Act, and the AI Act deployer cannot be read as the MDR or IVDR user. Where a third-party model ships inside your device, who counts as the provider once you fine-tune a model is a separate question.

Five provisions do the folding.

Both retention clocks run ten years: Article 18(1) for the documentation set, Article 47(1) for the declaration, counted from placing on the market.

MDCG 2025-6 Q6 counts at least thirteen aspects in the AI Act quality management system, implemented proportionately to the provider's size, and says manufacturers may include those elements in the existing MDR or IVDR system. Those are procedures added to an ISO 13485 system, and they fail in the same shape as the fold-it-into-the-existing-file problem under EU GMP: a parallel binder that no change control reaches.

You also do not register the device under Article 49: every paragraph of it is scoped to Annex III, and Article 16(i) points only at Article 49(1). Nor is there a new sampling regime, because MDCG 2025-6 Q13 keeps the sampling rules of the governing conformity assessment procedure.

MDR clinical evaluation asks whether the clinical data supports the claim. Article 10 asks about the data sets themselves, and no MDR Annex II heading asks those questions in that form.

Article 10(2) lists eight lettered practices that training, validation and testing data sets shall be subject to, appropriate for the intended purpose: (a) design choices; (b) collection processes and data origin, plus the original purpose of collection for personal data; (c) preparation operations including annotation, labelling, cleaning, updating, enrichment and aggregation; (d) assumptions about what the data is supposed to measure; (e) assessment of availability, quantity and suitability; (f) examination for biases likely to affect health and safety or fundamental rights; (g) measures to detect, prevent and mitigate them; (h) identification of data gaps preventing compliance.

Article 10(3) requires the sets to be relevant, sufficiently representative, and to the best extent possible free of errors and complete in view of the intended purpose. Article 10(4) requires them to account for the characteristics particular to the setting of use, geographical, contextual, behavioural or functional.

The Act splits the data into four defined terms, and MDCG 2025-6 Q10 reproduces all four: training data at Article 3(29), validation data at 3(30), the validation data set at 3(31), which may be a separate set or a fixed or variable split of the training set, and testing data at 3(32), for "an independent evaluation ... to confirm the expected performance". A file with one section headed "the dataset" does not answer Article 10.

MDCG 2025-6 Q11 maps the requirement into documents you hold: MDR Annex II sections 3(a), 3(b) and 6, MDR Article 61 and Annex XIV, and IVDR Annex XIII part 2.3.2(m) on performance study population selection. It names the patient characteristics to be represented: age, gender, sex, race, ethnicity, geographical location and medical condition; check subgroup coverage against that list.

The record that closes the gap is a datasheet per data set, structured on the article rather than on your pipeline. Values below are illustrative.

# Article 10(2) practices and Annex IV point 2(d), as one record per data set.
# Sits inside the MDR Annex II technical documentation, not beside it.
dataset:
  id: derm-train-2026-03
  role: training            # training | validation | testing  (Art 3(29), 3(30), 3(31), 3(32))
  split_note: "validation set is a fixed 15 percent hold-out of the same collection"

  design_choices: |        # Art 10(2)(a)
    Single-lesion dermoscopy crops; malignancy label from histopathology report.

  collection:              # Art 10(2)(b)
    origin: "three EU dermatology departments, 2019-2024"
    original_purpose: "routine diagnostic care, secondary use"
    personal_data: true

  preparation:             # Art 10(2)(c)
    annotation: "two dermatologists, disagreements adjudicated by a third"
    labelling: "binary malignant / benign"
    cleaning: "duplicate hash removal, blur rejection below variance threshold"
    enrichment: "none"
    aggregation: "per-lesion, not per-patient"

  assumptions: |           # Art 10(2)(d)
    Dermoscopy image is assumed to carry the diagnostic signal without clinical context.

  suitability:             # Art 10(2)(e)
    n_images: 41230
    n_patients: 12904

  bias_examination:        # Art 10(2)(f)
    axes: [fitzpatrick_type, age_band, sex, acquisition_site]
    finding: "Fitzpatrick V-VI under-represented relative to the intended population"

  bias_mitigation: |       # Art 10(2)(g)
    Targeted collection at two additional sites; class-balanced sampling at training time.

  gaps: |                  # Art 10(2)(h)
    No paediatric lesions. Intended purpose restricted to adults in the IFU.

  representativeness:      # Art 10(3) and 10(4)
    target_population: "adults presenting to EU dermatology outpatient clinics"
    setting: "clinic-grade dermatoscope, indoor lighting, trained operator"

Write it now rather than waiting for a standard: MDCG 2025-6 Q11 records the Commission's horizontal guidelines on Article 10 and CEN/CENELEC Joint Technical Committee 21's standard on data and bias as work in progress.

Article 12(1) is a design requirement, not a records policy: "High-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system." Article 12(2) dictates the schema indirectly, by naming three downstream uses: identifying situations that may result in the system presenting a risk within the meaning of Article 79(1) or in a substantial modification, facilitating the post-market monitoring referred to in Article 72, and monitoring the operation referred to in Article 26(5).

The prescriptive minimum-field list at Article 12(3) is scoped to point 1(a) of Annex III, remote biometric identification. It is not a device requirement. Design from the three uses instead.

{
  "schema": "aiact-art12-log/1",
  "record": {
    "event_id": "uuid",
    "occurred_at": "RFC3339 timestamp",
    "device_udi_di": "basic UDI-DI of the device the system ships in",
    "ai_system_version": "semver of the model artefact and the inference stack",
    "deployment_site": "opaque site identifier, no patient identifier",

    "art_79_1_risk_signal": {
      "comment": "Art 12(2)(a): situations that may result in the system presenting a risk",
      "out_of_distribution_score": 0.0,
      "confidence": 0.0,
      "input_rejected": false,
      "human_override": false
    },

    "pmm_signal": {
      "comment": "Art 12(2)(b): facilitating the post-market monitoring under Art 72",
      "subgroup_key": "the Art 13(3)(b)(v) subgroup this input falls in",
      "outcome_label_available": false
    },

    "deployer_monitoring": {
      "comment": "Art 12(2)(c): monitoring of the operation under Art 26(5)",
      "oversight_user_role": "role, not name",
      "suspension_triggered": false
    },

    "substantial_modification_marker": {
      "comment": "Art 12(2)(a) second limb: modification not part of the initial assessment",
      "model_hash": "sha256 of the deployed weights",
      "predetermined_change_ref": "Annex IV point 2(f) entry id, or null"
    }
  },
  "retention": {
    "provider_floor_months": 6,
    "deployer_floor_months": 6,
    "comment": "Art 19(1) and Art 26(6): a period appropriate to the intended purpose, of at least six months, unless Union or national law provides otherwise. Both duties are scoped to logs under that party's control."
  }
}

Article 19(1) requires the provider to keep the logs the system generates automatically, to the extent they are under their control, for a period appropriate to the intended purpose and of at least six months unless Union or national law provides otherwise, and Article 26(6) puts the identical floor on the deployer under the identical qualifier. Six months is a floor beneath a period the intended purpose sets, so a device whose post-market signal takes a year owes a year.

Architecture decides which of you owes it, because both duties turn on "under their control". Cloud-hosted inference leaves the logs with the manufacturer, who carries Article 19. On-premise inference inside a hospital moves them behind the hospital's perimeter, moving the retention duty onto the hospital as deployer and leaving the manufacturer's Article 72 monitoring obligation exactly where it was.

That is a design problem, not a contract problem. The manufacturer needs Article 12 events for post-market monitoring and the hospital holds them, so Article 13(3)(f) requires the instructions for use to describe the mechanisms that let deployers collect, store and interpret the logs. Specify the export path, its content, its schedule and its lawful basis before the device ships. Where running inference with no outbound path at all is the requirement, that means an export the hospital initiates, not a telemetry channel the vendor opens.

The hospital picks up its own duties: use in accordance with the instructions for use at Article 26(1), human oversight by competent, trained and authorised persons at 26(2), representative input data at 26(4), and monitoring with a duty to inform the provider and suspend use at 26(5).

Annex VII point 4.3 grants the notified body, where relevant and limited to what is necessary for its tasks, full access to the training, validation and testing data sets used, expressly including through interfaces enabling remote access with appropriate security safeguards. A manufacturer that trained on hospital data under an arrangement that cannot admit a third-party assessor has an unbuildable conformity assessment, not a strong security posture. Plan that access as a controlled, logged, revocable route into the perimeter the training ran in, decided alongside where the training data is allowed to sit.

Article 15(3) is one sentence and it turns a performance claim into a labelling obligation: "The levels of accuracy and the relevant accuracy metrics of high-risk AI systems shall be declared in the accompanying instructions of use."

Article 13(3)(b)(ii) adds the detail: the instructions state the level of accuracy and its metrics, tested and validated and expected, plus known and foreseeable circumstances that may affect it. Article 13(3) runs from point (a) to point (f) and point (b) has seven sub-points, so the accuracy figure never ships alone.

MDCG 2025-6 Q14 lands that in a document you already ship, tying AI Act transparency to Annex I GSPR 23 on information supplied with the device and GSPR 14.2(h) on software developed to the state of the art. No new label, a new section in the existing one.

AI performance declaration (AI Act Article 15(3) and Article 13(3)(b))

Intended purpose and setting (Art 13(3)(b)(i))
  Adults presenting to dermatology outpatient clinics; clinic-grade dermatoscope.

Declared level of accuracy and its metrics (Art 15(3), Art 13(3)(b)(ii))
  Sensitivity 0.00 (95% CI 0.00 to 0.00) and specificity 0.00 (95% CI 0.00 to 0.00)
  on an independent test set of N lesions from M sites not used in training or validation.
  Operating threshold: 0.00. Metric definitions: per-lesion, histopathology reference standard.

Known circumstances affecting that level (Art 13(3)(b)(ii) second limb)
  Degraded on images with hair occlusion above X percent of lesion area.

Performance on specific groups (Art 13(3)(b)(v))
  Reported separately for each Fitzpatrick band, with the n behind each figure.

Input data specification (Art 13(3)(b)(vi))
  Minimum resolution, colour calibration and capture distance.

Pre-determined changes (Art 13(3)(c), Annex IV point 2(f))
  The changes assessed at conformity assessment and the performance envelope they keep.

Human oversight measures (Art 13(3)(d), Art 14)
  What the reviewing clinician sees, and what they can override.

Compute, lifetime and maintenance (Art 13(3)(e))
  Hardware requirements, expected lifetime, and maintenance measures and their frequency.

Log collection mechanism (Art 13(3)(f))
  How the deploying institution collects, stores and interprets the Article 12 logs.

The placeholders stay placeholders until your own test report fills them, and every figure there is one a market surveillance authority can hold you to.

Article 15(4) and 15(5) name things MDR Annex I section 17 does not. Paragraph 4 requires resilience regarding errors, faults or inconsistencies, allows robustness through technical redundancy including backup or fail-safe plans, and addresses adaptive behaviour directly: systems that continue to learn after being placed on the market shall be developed to reduce as far as possible the risk of biased outputs influencing input for future operations, with those feedback loops duly addressed.

Paragraph 5 names five AI-specific vulnerabilities the technical solutions have to address: data poisoning, model poisoning, adversarial examples or model evasion, confidentiality attacks, and model flaws. MDCG 2025-6 Q22 ties this to MDR Annex I section 17, IVDR Annex I section 16 and MDCG 2019-16 rev. 1, and tells manufacturers to secure AI-specific assets such as training data sets and the trained model. Where the threat model in your file stops at network and access control, what data poisoning and model inversion look like against clinical models is the gap to close first.

One boundary in that answer saves work: medical devices and IVDs are recorded as out of the scope of Regulation (EU) 2024/2847, the Cyber Resilience Act. The evidence base stays the Article 15(5) list read against the documents Q22 already names.

That evidence has to survive a reviewer who can escalate. Where the notified body is not satisfied with the provider's tests, Annex VII point 4.4 has it carry out adequate tests itself. Point 4.5 reaches the trained models and their relevant parameters, but only after other verification routes have been exhausted and proven insufficient, on a reasoned request, and subject to intellectual property and trade secret protection. Weight access is the escalation, not the routine.

MDCG 2025-6 Q34 states that the major monitoring change required by the AI Act will be the need, where relevant, to detect interaction with other AI systems, including other devices and software. Everything else folds: Article 72(4) lets a Section A provider integrate the necessary elements into plans already existing under the sectoral legislation, provided an equivalent level of protection is achieved. The document does not fold. Article 72(3) makes the post-market monitoring plan part of the technical documentation referred to in Annex IV, and set 2 February 2026 as the Commission's deadline for a template. Check whether that template has issued before drafting from the article text alone.

Nine rows, one per article: the AI Act provision, the MDR or IVDR document it folds into, and the record the AI Act adds. The list drops Article 8, which is the instruction to comply rather than a record, and adds Article 17 and Article 72, which sit outside Chapter III Section 2 but land in the same files.

# Run this against the technical file you already hold. Three columns per row:
# the AI Act article, the MDR/IVDR document it folds into, and the record the
# AI Act adds. Integration is permitted by Art 8(2), 9(10), 17(3), 72(4).
gap_analysis:
  - article: "Art 9 risk management"
    existing: "risk management file, MDR Annex I Chapter I and Annex II"
    missing: "fundamental-rights risks and data-bias risks as named hazard entries"

  - article: "Art 10 data and data governance"
    existing: "clinical evaluation, MDR Art 61 and Annex XIV"
    missing: "one datasheet per training, validation and testing set"

  - article: "Art 11 and Annex IV technical documentation"
    existing: "MDR Annex II and Annex III"
    missing: "computational resources used to develop and train; Annex IV 2(f) pre-determined changes"

  - article: "Art 12 record-keeping"
    existing: "UDI traceability and PMS data collection"
    missing: "an event log schema tied to Art 79(1), Art 72 and Art 26(5)"

  - article: "Art 13 transparency"
    existing: "instructions for use, MDR Annex I GSPR 23"
    missing: "declared accuracy and metrics; the deployer log-collection mechanism"

  - article: "Art 14 human oversight"
    existing: "usability engineering file"
    missing: "the in-built operational constraints the system cannot override itself"

  - article: "Art 15 accuracy, robustness, cybersecurity"
    existing: "MDR Annex I section 17, MDCG 2019-16 rev. 1"
    missing: "feedback-loop mitigation; evidence against poisoning, evasion and confidentiality attacks"

  - article: "Art 17 quality management system"
    existing: "ISO 13485 QMS under the MDR"
    missing: "the AI-specific procedures among the thirteen or more Art 17 aspects"

  - article: "Art 72 post-market monitoring"
    existing: "PMS system and PMS plan, MDR Art 83"
    missing: "detection of interaction with other AI systems, devices and software"

Four Annex IV items have no natural home in an MDR structure: 2(c), the architecture and computational resources used to develop and train; 2(d), datasheets describing training methodologies, provenance, scope and characteristics of the data sets; 2(f), the pre-determined changes and the solutions adopted to keep them compliant; and 2(g), validation and testing procedures with test data, accuracy metrics and dated, signed test logs. Point 7 takes either the harmonised standards applied or a description of the solutions adopted where none were, which is the paragraph you write today.

Point 2(f) is where the commercial consequence sits. MDCG 2025-6 Q30 states that changes pre-determined by the manufacturer, assessed at the initial conformity assessment and held in the Annex IV point 2(f) documentation, shall not constitute a substantial modification, and are not a change to the certified device under MDR Annex IX Section 4.10 or IVDR Annex IX Section 4.11. A retraining envelope written into the file at submission is one you can use; a change that is not in it is a new assessment every time the model moves.

Two of those six rows are easy to misread. The 2 December 2027 row is the Annex III route and does not touch a device that reaches high-risk status through Article 6(1). And guidance written before the amendment reasons from a different Annex I date: MDCG 2025-6 Q31 works from 2 August 2027 and concludes that a device placed on the market before the application date picks up the obligations only if its AI system undergoes significant design changes on or after it. The reasoning holds; the date moved to the 2 August 2028 row.

Do one thing this week. Take a single cleared product, open its Annex II technical documentation, and put a document reference and an owner against each of the nine rows above. The rows that come back empty are the AI Act work. Then read all 36 questions of the joint guidance yourself. For the same reasoning on neighbouring instruments, see our writing on AI in regulated businesses.