Medical-AI Readiness Assessment

The medical-AI readiness assessment maps what the AI Act adds to a device's existing MDR file, requirement by requirement, and what it does not. It is for manufacturers of an AI medical device or in vitro diagnostic that a notified body already assesses: it confirms the high-risk determination that follows by operation of law, works the seven requirements of Arts. 9 to 15 AI Act as a delta over the technical documentation and quality system already in place, rates each one, and dates the obligations against the conformity timeline; the fixed fee is quoted before engagement.

Who it serves

  • Manufacturers of an AI device or IVD already in a notified-body procedure, who need the AI Act work scoped against the file they have rather than started from nothing.
  • Companies whose device was certified before the AI feature was added, or whose model has been retrained since the certificate issued.
  • SaMD companies that have been quoted for an AI Act project as though it were a separate conformity route, and want the scope checked before they buy it.
  • Hospitals, health systems and service providers putting a CE-marked diagnostic into use, whose duties are the deployer's rather than the provider's.
  • Investors and acquirers who need a reasoned view of an AI device's readiness against the combined bar before a transaction closes.

What's included

  • The high-risk determination, with its route: whether the AI system is, or is a safety component of, a product covered by Annex I AI Act that needs third-party conformity assessment (Art. 6(1) AI Act), walked through the Digital Omnibus carve-out for AI used solely for convenience, performance or quality control and the health-and-safety limb that puts it back (Art. 6(1a) and Art. 6(1b) AI Act). The device class is an input, never re-derived here.
  • The single-assessment position: that the AI Act requirements are assessed inside the MDR or IVDR procedure rather than beside it (Art. 43(3) AI Act), and whether the notified body already engaged is one that may take the work.
  • The delta table: each of the seven requirements of Arts. 9 to 15 AI Act set against the technical documentation and quality system the manufacturer already maintains, saying what is satisfied, what is partly satisfied and what is absent. This is the part a general AI-compliance review cannot produce, because it needs the device file.
  • The provider and deployer duties that sit outside the seven: the provider obligations and quality-management system (Arts. 16 and 17 AI Act), registration and post-market monitoring (Arts. 49 and 72 AI Act), the deployer duties where the client also deploys (Art. 26 AI Act), and the AI-literacy duty that binds both, in the terms the Digital Omnibus left it (Art. 4 AI Act).
  • The data-governance position: what Art. 10 AI Act requires of training, validation and testing data, and the narrow permission to process special-category data for bias detection and correction (Art. 4a AI Act), which runs to the client and never to the firm.
  • Obligation calendar and Swiss position: the dated duties on the limb that applies, and the fact that Switzerland has not adopted the AI Act, so the overlay is EU-market-only while the MepV track runs in parallel.
  • Method note and sign-off: a short account of what was done and why, and the attorney's sign-off before anything leaves the firm, in the careful and conscientious practice the professional rules require (Art. 12 lit. a BGFA).

The three determinations the assessment turns on

The value is not in listing the AI Act's requirements, which are public. It is in three calls a general AI-compliance review gets wrong for a medical device, each of which changes the size of the project.

High-risk is a conclusion of law, not a risk appetite

Where an AI system is, or is a safety component of, a product covered by the Union harmonization legislation in Annex I AI Act, and that product must undergo third-party conformity assessment, the system is high-risk (Art. 6(1) AI Act). The MDR is point 11 and the IVDR point 12 of Annex I, Section A AI Act, so a device above the self-certified classes is caught by operation of law. There is no appetite to set and no election to make. What there is, since the Digital Omnibus, is a walk: AI used solely for non-safety-related user assistance, performance optimization, service efficiency, automation, convenience or quality control is not a safety component (Art. 6(1a) AI Act), and AI whose failure or malfunctioning would endanger health and safety is one regardless (Art. 6(1b) AI Act). The assessment states which limb it used.

It is one conformity assessment, not two

For a device the provider follows the conformity assessment procedure the MDR or the IVDR already requires, and the AI Act requirements are part of that assessment (Art. 43(3) AI Act). There is no separate AI Act CE marking, no second technical file and no parallel audit. A readiness plan built around a phantom second process budgets for work that does not exist and misses the work that does, which is closing the delta inside one procedure. The same article conditions which notified bodies may assess those requirements, so whether the body already engaged can take the work is checked rather than assumed, and a dual-designation gap is a finding with a lead time attached.

The delta is against the file that exists

All seven requirements apply: risk management, data and data governance, technical documentation, record-keeping, transparency to deployers, human oversight, and accuracy, robustness and cybersecurity (Arts. 9 to 15 AI Act). A manufacturer in a notified-body procedure already satisfies part of each through the MDR technical documentation, the quality system and the post-market file. The assessment says which part, and the answer is rarely uniform: risk management and technical documentation usually carry the furthest, data governance and human oversight usually carry the least, and record-keeping turns on what the software already logs. Rating a requirement the manufacturer has largely met as a gap is as unhelpful as missing one it has not.

What the assessment does not cover

The boundary is stated in writing before work begins, because a bounded scope is what a fixed fee rests on. The assessment does not:

  • certify anything: it is not a conformity assessment and produces no statement that the device conforms, which only the notified body can give;
  • classify the device, which is its input rather than its output, and which the firm's MDR and IVDR compliance work supplies;
  • perform technical, quality-system, clinical or model-evaluation work of any kind;
  • draft or remediate the documents the delta table names; each of those is its own deliverable, priced separately;
  • correspond with a notified body or an authority;
  • ingest patient data: the assessment is worked from the technical documentation and the governance documents, and training-data content is discussed structurally (Art. 5 lit. c DSG, Art. 9 GDPR).

The rating is a readiness signal that sets the order of work. It is not a reasoned legal opinion on any single question; that is a separate deliverable, and the assessment names it where one is needed.

What the firm needs from the client

  • The device's classification and the basis for it, and the notified body engaged, with the certificate if one has issued.
  • The technical documentation index, the quality-system procedures relevant to software and risk management, and the post-market surveillance plan. The index matters more than the volume: the assessment reads what is there to establish what is covered.
  • A description of the AI component: what it does, whether it is trained or fixed, whether it is updated after release, and whether any part of it is a third-party model.
  • One scoping call, usually under an hour, to settle anything the questionnaire leaves open.
  • No patient data and no model weights. Nothing in the assessment requires either, and the intake is built so that neither is requested.

How it works

  1. Intake. The questionnaire and a short scoping call establish the device, its class, the AI component and the conformity route already under way.
  2. Determination. The high-risk conclusion is confirmed against Art. 6(1) AI Act with the Omnibus limbs walked, the role is fixed as provider, deployer or both, and any third-party model dependency is identified.
  3. Delta walk. Each of the seven requirements is set against the existing file and rated, the duties outside the seven are assessed, and every uncertainty is flagged rather than resolved quietly.
  4. Attorney pass. Every determination and every rating is confirmed or corrected, the flagged points are resolved, and the order of work is set against the dates.
  5. Quality gate and delivery. Citation integrity against the sources, consistency across the ratings, then the rated report, the gap register and the method note. Nothing leaves the firm without the attorney's sign-off.

Where the outcome is a remediation program rather than an answer, it is scoped from the report and runs as EU AI Act compliance work, or as an integrated mandate under digital health compliance where the device, AI and data workstreams are better held together. Where a company does not yet know whether the AI Act is its exposure at all, the broader regulatory posture audit surveys the whole surface first.

Fees

One fixed fee per device or device family

Quoted before engagement

The fee is set by how many devices or AI components are in scope, by whether the client is provider, deployer or both, and by the state of the existing file. Group-wide and multi-entity work is scoped and quoted separately. A written fee proposal follows the intake request and precedes any engagement.

Common questions

What does the assessment produce?
A single rated report in five parts: the high-risk determination with the provision it rests on and the route it came in by; a delta table covering each of the seven requirements of Arts. 9 to 15 AI Act, stating what the existing MDR or IVDR technical documentation already satisfies and what it does not; a rating of each requirement with the gap and the action that closes it; the dated obligation calendar set against the conformity timeline; and a short note on what was done and why. It is delivered in English or in German.
Does the AI Act mean a second CE marking?
No, and a readiness plan built around a second process is built around something that does not exist. For a device the provider follows the conformity assessment procedure the MDR or the IVDR already requires, and the AI Act requirements are part of that assessment (Art. 43(3) AI Act). One procedure, one CE marking, one notified body. What the article does add is a condition on that body: it may assess the AI Act requirements only where its compliance with Art. 31(4), (5), (10) and (11) AI Act was assessed in its notification, so whether the client's existing notified body can take the work is a question with an answer, and it is one the assessment asks early.
Does the assessment decide whether our device is high-risk?
It confirms it and states the route, rather than choosing it. High-risk follows by operation of law where the AI system is, or is a safety component of, a product covered by the legislation in Annex I AI Act and that product needs third-party conformity assessment (Art. 6(1) AI Act); the MDR is point 11 and the IVDR point 12 of Annex I, Section A AI Act. The Digital Omnibus added a carve-out for AI used solely for convenience, performance or quality control (Art. 6(1a) AI Act) and put back AI whose failure would endanger health and safety (Art. 6(1b) AI Act), so the walk through those two is stated rather than assumed. The device class itself is an input, taken from the classification work and never re-derived here.
Is this a conformity assessment?
No. It is a reasoned assessment of readiness against the combined bar and of the gaps to close, and it produces no statement that the device conforms. Only the notified body can certify conformity, and the report says so on its face. The firm also performs no technical, quality-system or clinical work: what is read is the documentation.
We deploy an AI device rather than make one. Is there anything here for us?
Yes, and it is commonly underestimated. A hospital or health system putting a CE-marked diagnostic into use is a deployer, with its own duties: use in accordance with the instructions, human oversight by competent people, input-data relevance, log-keeping and monitoring (Art. 26 AI Act). The AI-literacy duty binds provider and deployer alike (Art. 4 AI Act), and since the Digital Omnibus a deployer of a high-risk system may also process special-category data for bias detection and correction on the narrower conditions of Art. 4a(2) AI Act, where the predecessor provision ran to providers alone.