1. Product liability under Lens A and Lens B

The first surviving channel is strict product liability against the producer side. Under Lens A, the claimant proceeds under Directive 85/374/EEC as transposed into national law. Under Lens B, the claimant proceeds under Directive (EU) 2024/2853. In healthcare AI, the difference between the two is not merely technical. It affects whether software supplied through cloud or software-as-a-service models is comfortably classified as a product; how much procedural assistance is available where proof depends on producer-held evidence; and how the law responds to post-deployment software change, updates and continued producer control.Footnote ¹⁸

Under Lens B, software is expressly included as a product, whether supplied on a tangible medium or through network access, cloud or software-as-a-service models.Footnote ¹⁹ This matters most for the ambient clinical scribe. If the scribe is not a medical device, its treatment under Lens A remains more contestable because older national implementations were drafted against a world of tangible goods and do not uniformly resolve the status of cloud-delivered software. Under Lens B that uncertainty is greatly reduced. The revised Directive also addresses related services and substantial modification, which is relevant where functionality is altered through software updates or ongoing learning processes beyond the user’s control.Footnote ²⁰

Across both lenses, the organising concept remains defectiveness, assessed by reference to the safety that a person is entitled to expect. CJEU case law has long recognised that, for medical products, safety expectations are especially demanding because the potential damage is abnormal and serious.Footnote ²¹ The revised Directive deepens the contextual analysis by making explicit that defectiveness may depend on continuing learning, interconnection with other products, cybersecurity and the circumstances of the intended user group.Footnote ²² It also makes clear that warnings do not, by themselves, cure defectiveness, a proposition with direct relevance to systems that are formally described as assistive but are designed in ways that predictably induce reliance.Footnote ²³

The application of those rules differs by scenario. In S1, the product claim centres on whether a false-negative triage output, combined with hard worklist prioritisation and foreseeable reliance on the prioritised queue, made the system less safe than users were entitled to expect. The case depends not only on model performance, but on how the model was embedded into a workflow such that a low-priority result could delay review of a time-sensitive scan. In S2, the claim may centre on calibration, alert logic and the design choice to place a legally and clinically decisive threshold in the hands of the deployer. If the score was accurate but the threshold too conservative, the producer will argue that the harm lay in deployment rather than defect. In S3, the product route focuses on the production of a dangerous note or field-population error, the foreseeability of incomplete human review under clinical conditions, and whether the provenance of the error can be reconstructed at all.Footnote ²⁴

Lens B improves the claimant’s position not only by clarifying what counts as a product, but also through disclosure and presumptions. Article 9 allows courts, once a claim reaches a threshold of plausibility, to order disclosure of relevant evidence held by the defendant, subject to proportionality and trade-secret safeguards. Article 10 adds proof-easing rules, including presumptions tied to obvious malfunction, non-compliance with mandatory safety requirements, and, in technically or scientifically complex cases, excessive difficulties in proving defectiveness or causation.Footnote ²⁵ These mechanisms respond directly to the way AI systems place decisive information under the control of the producer side. Yet they are still bounded. They apply only under Lens B. They depend on a plausibility threshold that can be difficult to satisfy precisely because the claimant lacks the evidence needed to make the claim plausible. They also remain bilateral in structure. They do not resolve how liability should be allocated across multiple actors who share control over deployment, configuration and use.

The older CJEU case law retains interpretive force across the legacy regime. Veedfald confirms that a medical product can be put into circulation even in a hospital-linked context. Ford Italia reinforces the breadth of the concept of producer by presentation. Boston Scientific remains central to heightened safety expectations for medical products. Commission v United Kingdom and Commission v France continue to frame the development-risk defence by reference to the objective state of scientific and technical knowledge. Sanofi Pasteur accepts proof through serious, specific and consistent indicia rather than scientific certainty, while rejecting automatic or irrebuttable presumptions. Novo Nordisk confirms that national information-access tools may coexist with the product liability regime. Dutrueux makes clear that the harmonised product route coexists with national fault-based liability where the latter rests on a different basis.Footnote ²⁶ Product liability therefore remains a viable but incomplete route for healthcare AI claims. It is strongest where the producer side is identifiable, the system is comfortably classifiable as a product, and the decisive artefacts exist and can be reached.

2. National fault-based routes in Ireland, Italy and Germany

The second surviving channel is national fault-based liability. In practice, it is often the first channel activated because the institution is visible, record-holding and usually solvent or indemnified. In Ireland, the relevant standard in clinical negligence remains the Dunne standard, as restated in later case law including Morrissey. Discovery under Order 31 remains comparatively broad, including the possibility of third-party discovery, although the practical and strategic value of that route in technically complex cases should not be overstated.Footnote ²⁷ Irish causation remains demanding. Philp v Ryan and Quinn v Mid-Western Health Board are both relevant, but it is safer to describe them as evidence of an unsettled landscape regarding expanded causation tools than as settling any specific material-contribution doctrine for AI-mediated clinical harm.Footnote ²⁸

Italy’s position is shaped by Law 24/2017. The healthcare facility is liable on a contractual footing, while the practitioner is generally liable extra-contractually under Article 2043 of the Civil Code. Product liability claims continue to proceed under the Consumer Code. The Corte di Cassazione has recently reaffirmed, in Cass. civ., Sez. III, 28 March 2025, n 8224, that the product-liability regime does not exclude or limit other liability routes, but that distinct regimes cannot simply be blended into one another. In the same decision, the Court again described product liability as a form of responsabilità presunta, literally “presumed liability,” rather than true objective liability.Footnote ²⁹ Causation remains governed by the more-probable-than-not standard, and the court-appointed expert mechanism (consulenza tecnica d’ufficio, CTU) continues to play a large role in structuring medical and technical proof.Footnote ³⁰

Germany’s provider-side route is anchored in the treatment contract provisions of the Bürgerliches Gesetzbuch (German Civil Code, BGB) and the patient-rights regime, particularly sections 630g and 630h. For healthcare AI claims, section 630h matters because it contains several burden-shifting rules with direct relevance to record-dependent disputes. Missing or inaccurate documentation can trigger presumptions. Gross treatment errors can reverse causation burdens. Failures to obtain required findings can have similar effects. Those mechanisms can significantly improve the claimant’s position against the provider side, though they do not by themselves resolve producer-side questions about how an AI system behaved, how it was configured or what intermediate artefacts it generated.Footnote ³¹ Germany also offers targeted production under section 142 of the Zivilprozessordnung (German Code of Civil Procedure, ZPO) and the independent evidence procedure under sections 485 to 494a ZPO, both of which may assist in preserving and structuring evidence before the full merits hearing begins.

Across the three jurisdictions, the national fault-based route is therefore both more available and more fragmented than the product route. It is more available because the healthcare provider is easier to identify and usually holds the clinical record. It is more fragmented because the underlying doctrines of negligence, treatment contract liability, burden allocation and procedural access vary significantly. That variation matters less, however, than might appear at first sight. In all three systems, the claimant still faces the same general challenge when the decisive event lies partly or wholly in a technical artefact outside the provider-held record. National fault-based law can structure the claim against the institution and the clinician. It cannot, without more, force the existence of a missing pre-edit draft, disclose a cloud-held inference log or reconstruct a threshold history that was never exported or retained.

3. The mediating doctrine constraint

The third surviving channel is not a compensation route in its own right, but a body of regulatory duties that shape civil proof and the standard of care through national mediating doctrines. That constraint should be stated with precision. The AI Act and the MDR do not themselves determine civil liability. They do not convert non-compliance into automatic defect or automatic negligence. Nor does compliance create civil immunity. Their role is mediated. They affect what evidence exists, what warnings and instructions were supplied, what oversight architecture was expected and what a court may regard as relevant to safety expectations or reasonable clinical care.Footnote ³²

A concrete illustration may be taken from AI Act Article 14 on human oversight. Article 14 requires high-risk AI systems to be designed and developed so that they can be effectively overseen by natural persons, with the aim of preventing or minimising risks that persist despite other requirements.Footnote ³³ In a negligence claim involving S2 or S3, that provision does not compel an Irish, Italian or German court to treat any departure from Article 14 as negligence per se. But it can inform the court’s assessment of what the institution and the producer side knew or should have known about foreseeable automation bias, alert reliance, or the need for meaningful human verification. The same is true, in a partially different register, for MDR requirements on information supplied with the device and post-market surveillance. Those requirements do not answer the negligence question. They shape the evidential and normative environment within which the negligence question is asked.Footnote ³⁴

This mediating role is especially important because human oversight has become one of the main conceptual bridges between ex ante risk regulation and ex post civil liability. Scholarship has already noted that “human oversight” is both legally attractive and operationally unstable. It can be used to justify continued human responsibility even where system design channels user behaviour in strong ways. In the healthcare setting, that instability is visible where a radiology triage tool re-orders worklists, a deterioration system normalises response to alert architecture, or an ambient scribe generates a persuasive note that a time-pressured clinician then signs. The oversight requirement is therefore relevant, but not dispositive. It informs the inquiry into reasonable care and foreseeable reliance. It does not settle it.Footnote ³⁵

1. G1: evidence asymmetry

The first and most persistent gap is evidence asymmetry. In many medical negligence cases, the key dispute concerns what the clinical record shows and how expert evidence interprets it. In healthcare AI claims, the claimant frequently first needs to know what the system actually produced, which version produced it, how it was configured, whether an alert fired, whether a draft note existed before human revision, and whether the output fell within or outside the validated performance envelope. Those artefacts are not evenly distributed. The provider side usually holds the clinical record and some governance documents. The vendor or its cloud environment often holds the system-level inference record, model version data, provenance trail, update history and configuration materials.Footnote ³⁶

The structural nature of the gap becomes clear when the scenarios are unpacked. In S1, the decisive artefact may be the patient-specific inference or worklist log showing whether and how the scan was prioritised, together with the version identifier and the validation material needed to understand performance claims. In S2, the decisive artefacts include threshold history, calibration documentation and evidence of whether an alert was generated, displayed, acknowledged or bypassed. In S3, the decisive artefact is often the pre-edit AI draft or a detailed provenance log showing what the system generated before the clinician intervened. The problem is not merely that the claimant lacks information. It is that the claim cannot even be properly particularised without artefacts that may sit wholly outside the provider-held record.

The three jurisdictions expose and absorb this problem differently, but none removes it. Ireland’s discovery rules are broader than those of many continental systems and can, in principle, extend to third-party discovery against vendors. Yet broad discovery does not itself solve circularity. The claimant often needs the producer-side artefact in order to justify seeking it. Italy’s CTU mechanism can help identify which documents matter and can support requests for production, but the route is indirect and depends heavily on the structure of proceedings and the court’s management of third-party evidence. Germany offers stronger tools through section 142 ZPO and the independent evidence procedure, and the patient-access right under section 630g BGB is robust. Even so, those advantages are strongest when the evidence sits within or adjacent to the medical record, and weaker when the decisive artefact is cloud-held, commercially sensitive or never exported to the healthcare institution.Footnote ³⁷

Lens B reduces G1 materially, but not completely. Article 9 of the revised Product Liability Directive gives the claimant a route to seek relevant evidence from the producer side, and Article 10 provides presumptions where defectiveness or causation are especially difficult to prove in technically complex cases.Footnote ³⁸ That is a real change. Yet the plausibility threshold still poses a familiar difficulty in AI disputes. Trade-secret objections remain available. The claimant still needs enough information to identify what to ask for. The AI Act also reduces G1 in part because logging, technical documentation and deployer-side retention obligations can make some operational artefacts more visible or at least more likely to exist.Footnote ³⁹ But those gains are limited by time, scope and custody. Model-level documentation remains largely producer-held. Deployer-side log retention under Article 26 is measured in months, while medical litigation may arise much later. The result is that evidence asymmetry remains the most persistent structural weakness across all three scenarios.

2. G5: documentation integrity

The second gap is documentation integrity, and it is most visible in S3. G1 concerns artefacts that exist but are difficult to access. G5 concerns artefacts that may never have been preserved at all. If an ambient scribe generates a draft note, the clinician edits it, and only the final signed note survives, the claim may reach an attribution dead end. The decisive question, whether the harmful misstatement was generated by the system, introduced by the human editor or created later in the record chain, may become practically insoluble. Disclosure cannot retrieve what was never retained.

This gap is narrower in scope than G1, because it appears most sharply in the ambient-scribe scenario. But where it appears, it can be more severe. A false triage output or a missed deterioration alert may still leave some machine-facing trace in worklist logs, thresholds or audit records. A note-generation system that overwrites the draft and retains only the final signed text may erase the most legally relevant distinction in the case. This matters not only for claims against the producer side. It also affects claims against the institution and the clinician because it blurs the line between machine-generated and human-authenticated content.

The three jurisdictions again differ in how much doctrinal support they can offer once documentation integrity has failed. Ireland offers no special documentation presumption comparable to Section 630h(3) BGB. The claimant can point to a contaminated record and argue from surrounding evidence, but the absence of a provenance artefact remains a serious handicap. Italy’s burden structure under Law 24/2017 can improve the claimant’s general position against the facility, but it does not recreate a missing intermediate note or directly resolve attribution at the level of draft generation. Germany offers the strongest substitute through documentation-linked presumptions. If the medical record is inaccurate or incomplete in a legally relevant way, section 630h may shift burdens or create evidential advantages against the provider side.Footnote ⁴⁰ Even then, the mechanism is only a partial answer. It can help the claimant show that a misdocumented matter should not be treated as accurately recorded. It does not by itself establish what the AI system generated or whether the producer side designed adequate provenance and review safeguards.

The sensitivity of G5 to regulation is more differentiated than that of G1. The AI Act can reduce documentation-integrity problems substantially, but only where the system falls within scope, the relevant provisions have begun to apply, and the deployment is compliant. Article 12 requires logging, and Article 26 requires deployers to keep automatically generated logs for a minimum period.Footnote ⁴¹ For medical device AI, the MDR also brings traceability and post-market documentation into the picture. Recent MDCG guidance reinforces the importance of traceability, transparency and human oversight in medical device AI and links them to accountability across the lifecycle.Footnote ⁴² Yet it would be too broad to say that documentation-integrity problems disappear under the later regime. The ambient-scribe setting may fall outside MDR classification; the relevant AI Act provisions may not yet apply; and compliant high-level logging does not necessarily guarantee retention of the exact pre-edit draft or the patient-level provenance detail that litigation later demands. G5 is therefore best described as materially reducible, not removable, by later regulation.

3. G3: multi-actor control

The third gap is multi-actor control. Healthcare AI deployments distribute control across a chain of actors in ways that neither the product-liability route nor the provider-liability route maps neatly. The producer side may control design, training, performance claims and updates. The deployer may control procurement, threshold setting, workflow placement, local validation and incident response. The clinician may control final action or signature. In some cases, especially S3, a downstream clinician may act on information already shaped by the system without ever using the system directly. The legal question is not merely who caused the harm. It is which actor controlled the risk point that made the harm possible.

The structural character of G3 can be seen by comparing the scenarios. In S1, control is distributed, but the central contest is often still bilateral: producer design and updates against deployer workflow integration. In S2, threshold configuration introduces a more explicit allocation problem because the same model may behave differently depending on a parameter set locally rather than by the vendor. In S3, the chain expands again: producer-side note generation; provider-side procurement and governance; clinician review and signature; downstream clinician reliance. The ambient-scribe scenario therefore shows why control allocation is not only a product-liability issue or only a medical-liability issue. It is a chain problem.

Ireland, Italy and Germany each provide partial but incomplete answers. Ireland’s law of concurrent wrongdoers and contribution can manage multi-defendant litigation after several parties have been joined, but it does not give a freestanding normative account of AI-mediated control allocation. Italy’s dual-track architecture is good at distinguishing institution and practitioner, but less obviously suited to integrating the producer side into the same conceptual frame. Germany’s doctrine is stronger in relation to organisational fault and to provider-side responsibility for documentation and process, but it too leaves unresolved the interface between producer control, deployer configuration and clinician use. The revised Product Liability Directive does not solve this problem, because it is still principally concerned with the producer side, even though it contains provisions on presentation as producer, related services and substantial modification.Footnote ⁴³ The AI Act clarifies value-chain roles for regulatory purposes, including circumstances in which a deployer becomes a provider. But that is a public-law allocation of compliance responsibility, not a civil-law theory of multi-actor attribution.Footnote ⁴⁴

This is also the point at which the limits of the withdrawn Directive need to be stated carefully. The proposed AI Liability Directive would have improved access to producer-side evidence and would have eased some causation burdens in fault-based claims. It would not have supplied a complete structure for allocating responsibility across four parties in a clinical workflow. G3 therefore persists for a different reason from G1 and G5. Its source is not just missing evidence. It is the imperfect fit between legal routes organised around bilateral relationships and technical deployments organised around distributed governance.

4. G6: warning and reliance

The fourth gap is the mismatch between formal warnings and real reliance patterns. In all three scenarios, the producer side can say that clinicians remain responsible, that outputs require review, and that the system is only assistive. In all three scenarios, the deployment may nonetheless be arranged so that the system predictably shapes clinician behaviour in ways stronger than those warnings imply. Hard worklist prioritisation makes non-prioritised cases less salient. Active alert architectures normalise reliance on the presence or absence of alerts. Auto-populated notes and medication fields reduce the intensity of human verification, especially where clinical work is fast-moving and documentation tasks are burdensome.Footnote ⁴⁵

The structural issue is therefore not simply whether warnings existed, but whether they were consistent with the system’s real position in the workflow. This is why the gap is properly described as one of warning and reliance rather than as a simple failure of disclosure. If the system is built and deployed in a manner that makes superficial review or selective adherence foreseeable, the existence of a warning does not settle the safety or negligence question.Footnote ⁴⁶ The revised Product Liability Directive reinforces this by expressly providing that warnings do not, by themselves, cure defectiveness. The AI Act reinforces it in a different way by requiring human oversight measures commensurate with risk, autonomy and context of use.Footnote ⁴⁷ But neither instrument abolishes the behavioural gap. They help identify it; they do not make it disappear.

The jurisdictions again differ more in the intensity than in the shape of the problem. In Ireland, the intervening-clinical-act defence remains potent, especially where a clinician has signed a note or had an ostensible opportunity to reject an output. Italy and Germany likewise preserve a strong place for human professional responsibility. Yet the strength of that defence changes across the scenarios. In S1, the clinician can plausibly say that the workflow itself was already channelled by the triage design. In S2, alert architecture and local escalation protocols make the defence less straightforward than a simple appeal to human autonomy suggests. In S3, the producer side has its strongest formal point because the clinician reviewed and signed the note. At the same time, S3 is where the human-verification story can be least realistic if the system generated a fluent, plausible and workflow-ready draft under conditions in which detailed review was foreseeable but not assured.Footnote ⁴⁸

The sensitivity of G6 to the later EU instruments is therefore modest but real. The revised Directive helps because it makes reasonably foreseeable use and behavioural design part of the safety analysis. The AI Act helps because Article 14 places oversight, interpretability and override capacity closer to the core of lawful design, and because current guidance on medical device AI already stresses the relationship between human oversight, instructions for use, usability engineering and patient safety.Footnote ⁴⁹ But the remaining question is sociotechnical rather than formal. Does the system’s operational role sit coherently with the degree of human scrutiny the producer and deployer later invoke in litigation? That question remains under-answered by current law.

5. G2: causation under uncertainty

The fifth gap is causation under uncertainty. Healthcare AI harms rarely present a short path from technical event to injury. In S1, a low-priority triage output may delay review; the delay may postpone diagnosis; the postponement may or may not have altered treatment or outcome. In S2, an alert that did not fire, or did not cross a threshold, may affect escalation, monitoring or discharge; each step is contestable in clinical and evidential terms. In S3, a contaminated note may shape later clinical understanding, but only through a chain involving authorship, review, reliance and the timing of later investigation. Each of these cases requires the claimant to stabilise a counterfactual across several actors and several decision points.

The three jurisdictions differ sharply here. Ireland remains the least claimant-friendly of the three because the but-for test continues to dominate clinical negligence, and the law is still unsettled as to how far expanded causation tools can travel in medical settings. Philp and Quinn do not resolve the matter in a way that maps neatly onto AI-mediated chains, and Morrissey does not remove that underlying difficulty.Footnote ⁵⁰ Italy’s more-probable-than-not standard and the burden structure of Law 24/2017 soften the edges of uncertainty, especially as against the healthcare facility, but they do not by themselves solve multi-link chains involving producer-side evidence gaps. Germany offers the strongest statutory assistance through section 630h, yet even there the assistance is usually strongest on the provider side and weaker when the contested issue concerns producer-side design, provenance or calibration.

Lens B improves the claimant’s position in product claims through Article 10 presumptions, including the rule for excessive difficulties in establishing defectiveness or causation in technically complex cases.Footnote ⁵¹ That is a substantial change, especially for producer-side claims involving opaque software. But it does not extend to the negligence or treatment-contract route against the hospital, which often remains the first and most practical claimant route. The AI Act also helps only in part. Better logging can illuminate the first node in the chain, such as whether an alert fired or whether a record was generated. It does not by itself answer the later counterfactuals, whether a clinician would have acted differently, whether a different action would have occurred in time, and whether outcome would thereby have changed. G2 therefore persists because the main fault-based route continues to depend on proof structures that the new product-liability tools cannot fully reach.

1. An uneven but workable architecture

The post-withdrawal landscape is uneven rather than empty. The revised Product Liability Directive improves the producer-side environment for software claims, particularly where classification, disclosure and presumptions matter. The AI Act, together with the MDR where applicable, improves the governance and evidential environment by requiring technical documentation, logs, instructions, post-market monitoring and oversight structures. Those are significant gains. Yet they do not create a general EU bridge between regulatory non-compliance and civil compensation, or displace the central role of national medical liability law, which remains the route through which most claimants will first proceed.Footnote ⁵²

The unevenness is intensified by time. Many healthcare deployments already in use will not acquire richer AI Act artefacts merely because the Regulation exists. Some systems will fall outside the later high-risk obligations. Others will remain in service without the kind of significant change that would trigger application to pre-existing deployments. Still others will be formally in scope but unevenly compliant. The result is a patchwork in which some claimants benefit from richer logs, documentation and instructions, while others continue to depend on sparse records, proprietary environments and difficult counterfactuals. In that setting, risk regulation cannot be assessed only by asking whether it promotes ex ante safety or formal compliance. It must also be assessed by asking whether it leaves behind a litigation environment in which serious harms can be reconstructed and responsibility allocated with a reasonable degree of coherence.

2. Procurement-mandated patient-level artefact retention and exportability

The first immediately actionable measure is procurement-mandated patient-level artefact retention and exportability. This follows directly from G1 and G5. The point is not merely to preserve data in some general sense. It is to ensure that, when a serious incident is later alleged, the healthcare institution can retrieve the artefacts that correspond to the legally relevant event. For S1, that means patient-level inference records, worklist effects, timestamps and version identifiers. For S2, it means threshold history, alert generation logs, acknowledgment traces and protocol-linked escalation markers. For S3, it means retaining the pre-edit draft, revision history or a functionally equivalent provenance record that distinguishes system-generated content from later human edits.Footnote ⁵³

A worked example makes the regulatory logic clearer. A public hospital procuring a deterioration-score system could require, as a condition of contracting, that the vendor provide a secure export function capable of generating a patient-level incident package on request. That package would include the score history relevant to the admission, the threshold in force at the time, any alert emitted, evidence of display or acknowledgment, the model version, and any material configuration changes during the relevant period. The same clause could require retention for a period aligned with the institution’s incident-reporting, clinical-record and claims-management needs rather than defaulting to the minimum AI Act period. Such a clause does not alter substantive liability rules. It changes the evidential environment within which those rules later operate.

This measure is not limited to contract drafting. It also has implications for notified bodies, national competent authorities and large public purchasers. For medical device AI, notified bodies reviewing technical documentation and post-market arrangements can pay closer attention to whether traceability and log design are capable of supporting patient-level reconstruction rather than only aggregate monitoring. National competent authorities and guidance bodies can encourage or standardise retention expectations, especially where institutions have less bargaining power than major vendors. Large public purchasers, including centralised health systems, have the leverage to move these requirements from bespoke clauses to framework-level conditions. In a field where liability frequently turns on whether an artefact exists and can be reached, procurement is not a peripheral site of governance. It is one of the places where later litigability is built.

3. Express contractual control-point allocation across the AI supply chain

The second immediately actionable measure is express contractual control-point allocation. This responds directly to G3. Healthcare AI contracts often allocate risk in broad and familiar ways through warranties, limitations of liability and general compliance clauses. Those mechanisms do not answer the question that later dominates litigation: who controlled the risk point that made the harm possible? Contracts should therefore allocate control more specifically. Design control, model updating, threshold setting, workflow integration, disablement, incident response, user training, audit access, and post-market monitoring responsibilities should be assigned expressly and connected to documentation and notice duties.Footnote ⁵⁴

The point is not only recourse between defendants after judgment. It is upstream visibility. In S2, for example, the legal significance of a missed alert can change substantially depending on whether the decisive threshold was fixed by the hospital, recommended by the vendor but adjustable locally, or locked by the vendor. That question should not be left to inference from technical annexes and support emails disclosed years later. It should be answered in the contract and the deployment record. In S3, a contract should make clear whether the vendor retains provenance logs, whether the provider can obtain them promptly after an incident, what audit rights exist, and who bears responsibility if a system update alters how draft text, revisions or audit traces are stored.

A worked example can again be given. Suppose a health system deploys a radiology triage tool across multiple sites. The supply contract could include a schedule identifying who controls worklist logic, update timing, model rollback, alert or priority visibility in the interface, user training materials and incident investigation support. Each control point would be paired with a documentation obligation, a notice obligation for changes and a right of the deployer to obtain a time-stamped record of what was changed and by whom. Such a schedule will not abolish disputes. But it narrows the space in which parties can later deny control or argue that a legally decisive function sat somewhere else in the chain. For regulators and professional bodies, this suggests a further role: model contractual schedules or procurement guidance could standardise how control points are described and evidenced across common healthcare-AI deployments.

4. Deployment-stage reliance-architecture consistency assessment

The third immediately actionable measure is a deployment-stage reliance-architecture consistency assessment. This responds to G6 and, indirectly, to G2. The assessment asks whether the system’s actual place in the workflow is coherent with the level of human verification that warnings, instructions and later litigation positions presuppose. The question should be asked before the system goes live and revisited when systems are updated or workflows change. It is a governance exercise directed to the relationship between interface design, workflow placement, organisational expectations and the kind of human oversight that is realistically possible under clinical conditions.Footnote ⁵⁵

A worked example shows how this differs from conventional user training. In S3, an ambient scribe may be marketed with the warning that clinicians remain fully responsible for verifying every part of the generated note. A reliance-architecture assessment would ask whether the interface, note length, autopopulated fields, time pressures and review workflow make that expectation realistic. Are high-risk fields, such as medication, denial of symptoms or red-flag history, visually marked? Is the system designed to distinguish machine-generated text from human additions? Are users expected to perform a line-by-line review, and if so, is the workflow designed to make that plausible? If the answer to those questions is negative, the system’s reliance architecture is misaligned with its warning architecture.

The same assessment translates into S1 and S2. In a triage system, it asks whether hard or soft prioritisation, queue display and override functions make it realistic to insist that clinicians treat non-prioritised cases with unaffected attentional intensity. In a deterioration system, it asks whether the alert structure, dashboard design and escalation rules normalise reliance on alert absence in ways not candidly addressed by warnings. This is also the place at which professional bodies, hospital regulators and notified bodies can do more than restate generic human-responsibility language. They can encourage or require deployers to document how human oversight is expected to work in the actual workflow, not merely in the abstract language of instructions for use. In that sense, reliance-architecture assessment is both a patient-safety instrument and a proof instrument. It records, at the point of deployment, what patterns of human reliance were foreseeable.

5. Implications for regulators, guidance bodies and public purchasers

These three measures show that the most immediate response to the post-withdrawal liability landscape lies in upstream governance rather than in doctrinal development alone. That has implications for several actors. National competent authorities responsible for MDR and AI Act enforcement can treat traceability, retention and oversight design not merely as compliance matters, but as features that affect the reconstructability of harm events. Notified bodies can give closer attention to whether lifecycle documentation, instructions for use and post-market arrangements are sufficient to support patient-level incident reconstruction rather than only abstract conformity review. Guidance bodies such as HIQA-type quality agencies, the G-BA and AIFA-linked governance environments, and relevant professional bodies can frame procurement and deployment expectations in terms that connect safety governance with later accountability.Footnote ⁵⁶

The accountability mechanisms created by the AI Act should be understood in the same setting. They include technical documentation, instructions for use, automatic logging, deployer monitoring and log retention, post-market monitoring, serious-incident reporting and, in limited Annex III settings, a right to an explanation of the AI system’s role in an individual decision. In the health sector, these mechanisms can make the relation between provider design choices, deployer use and clinical interpretation more traceable. Blatti and Tramacere’s analysis of transparency and liability in AI-based medical systems is useful here because it shows how transparency and human oversight can operate as accountability mechanisms before litigation begins, while remaining bounded by the scope of the AI Act and by the fact that regulatory accountability is not the same thing as civil liability.Footnote ⁵⁷ For the purposes of the present article, this means that AI Act accountability mechanisms are not ignored. They are treated as part of the evidential and governance environment that can reduce opacity, support incident reconstruction and inform the standard of care through national mediating doctrines.

Large public purchasers have a particularly strong role. In concentrated markets, individual hospitals may lack leverage to insist on richer logging, provenance retention or audit access. Framework-level procurement, central guidance and collective contracting can change that bargaining position. The same is true of professional bodies that issue guidance on AI-enabled clinical tools. If their guidance remains at the level of general caution, it risks reproducing the warning-and-reliance gap. If, instead, it asks institutions to document control allocation, artefact retention and oversight realism, it can improve both governance and later legal clarity.

6. What the withdrawn Directive would and would not have solved

The withdrawn Directive should therefore be understood with restraint. It would have addressed G1 and part of G2 by giving claimants a clearer route to producer-held evidence and by easing some causal proof under opacity. Those are precisely the points at which its absence is most clearly felt in healthcare AI cases. It would not have provided a complete theory of responsibility across the AI supply chain, and it would not have displaced the central role of national medical liability law. Multi-actor control would still have required national doctrines on negligence, contribution, organisational responsibility and clinical accountability. The Directive’s value lay in targeted procedural assistance, not in replacing that wider legal landscape.Footnote ⁵⁸

That bounded claim matters for risk regulation. It prevents the current debate from collapsing into a false choice between “more AI-specific liability law” and “no legal problem.” The post-withdrawal framework already contains meaningful resources, and the revised Product Liability Directive and the AI Act improve the position, though unevenly. But their combination still leaves the claimant exposed where the decisive artefact sits outside ordinary reach, where provenance was not preserved, where control is distributed across several actors, and where the main negligence route still bears the weight of causal uncertainty. The task for risk regulation is therefore not only to reduce harm ex ante. It is also to leave behind a legal and evidential environment in which harms that do occur can be reconstructed with tolerable clarity.