Who is accountable for EU AI Act compliance when a medical device is sold and deployed across multiple market actors?

Why This Matters for Security Teams

eu ai act accountability is not a single-role answer, because medical devices move through a chain of provider, importer, distributor, authorised representative, and deployer responsibilities. That means compliance failures often come from handoff gaps, where each market actor assumes another party has already completed the required checks. For a regulated medical device, that creates both legal exposure and operational ambiguity, especially when AI functionality changes how the product is assessed, monitored, or updated. The practical issue is ownership. The provider must ensure the system is designed, documented, and supported to meet the Act’s obligations, while downstream actors must verify, preserve, and use it in line with their own duties. If those responsibilities are not assigned at the control level, evidence trails break down and no one can prove who approved what. EU AI Act requirements become especially important where the same device is sold into multiple jurisdictions or clinical settings, because accountability must survive distribution, procurement, and deployment changes. In practice, compliance failures are usually discovered only after a conformity gap, a procurement review, or a post-market issue has already exposed the missing owner.

How It Works in Practice

Accountability follows the role each actor plays in the value chain, not the label on the contract. The manufacturer is generally the provider of the AI system and carries the broadest compliance burden for design-time obligations, documentation, risk management, and conformity-related evidence. Importers and distributors are not merely logistical intermediaries; they must check that the product arrives with the expected information, markings, and instructions, and they must avoid placing a non-compliant system on the market. An authorised representative, where appointed, acts as a formal contact point and can have specific verification and cooperation duties. Hospitals, clinics, and other healthcare organisations usually act as deployers when they use the device in practice. That means they are accountable for correct use, local oversight, staff process alignment, and any organisational controls needed to keep the system within its intended scope. The same device can therefore have multiple accountable parties at once, each for different obligations. A useful operating model is to split ownership by obligation type:

• Provider duties, such as design, documentation, validation, and post-market support.
• Market-entry duties, such as import, distribution, and verification of required artefacts.
• Deployment duties, such as local use constraints, monitoring, escalation, and human oversight.
• Escalation duties, such as incident reporting, corrective action, and withdrawal or suspension decisions.

This works best when organisations map each control to a named owner, a required artefact, and a decision point. The compliance question is not just who is involved, but who can prove that the obligation was met. EU AI Act regulatory framework guidance is most useful here because it helps separate provider, deployer, and intermediary responsibilities before the device is accepted into service. These controls tend to break down when procurement, regulatory, and clinical teams each assume a different team owns the final conformity and deployment sign-off.

Common Variations and Edge Cases

Tighter accountability mapping often increases coordination overhead, because the more market actors touch the device, the more handoff evidence must be preserved. That trade-off is especially visible when a device is rebranded, imported through a regional entity, or configured differently for each hospital. A common edge case is a device sold by one entity and operated by another under a service or integration arrangement. In those cases, the contractual setup does not override the functional role under the Act, so teams must test who actually controls the product, the data flow, and the deployment context. Another variation arises when software updates or model changes alter how the device behaves after sale. Then the original provider obligations may continue, while the deployer must decide whether local validation or change control is needed before continued use. For cross-border sales, organisations should also watch for inconsistent interpretations of who owns evidence retention, incident escalation, and local language instructions. Best practice is evolving, but the safe assumption is that each actor must retain the records needed to demonstrate its own obligations. The clearest sign of a weak model is when the same control appears in three policies but is signed off by no one. ISO/IEC 27001:2022 Information Security Management can help structure ownership and evidence discipline around those cross-functional obligations. In practice, accountability fails when organisations rely on one master agreement instead of testing whether each actor can still prove its part after a product is resold, integrated, or updated.

Practitioner Guidance

What to prioritise: Build a role-to-obligation matrix that names the provider, importer, distributor, authorised representative, and deployer for each regulated duty. The matrix should sit beside the procurement and change-control records, not in a separate compliance appendix.

What to verify: Confirm that every required evidence item has a single accountable owner, including conformity artefacts, deployment instructions, local oversight responsibilities, and escalation paths for post-market issues. If an obligation cannot be tied to one owner, treat it as unresolved rather than assumed.

Practitioner takeaway: The safest operating model is not “everyone is responsible”, but “every required obligation has one clearly accountable party and one verifiable record of completion.”

Related resources from NHI Mgmt Group

• How should organisations prove EU AI Act compliance across the AI lifecycle?
• How should organisations handle EU AI Act compliance when deadlines are split across different obligations?
• How should organisations build an AI compliance strategy across multiple jurisdictions?
• How should security teams structure EU AI Act compliance for AI systems?