MedScan AI · Decision Ledger · EU AI Act guide
The EU AI Act for hospital deployers.
A primary-source-cited reference for what Articles 12 and 26 require of hospitals deploying high-risk medical-device AI, the corrected August 2028 timeline, and the EEA implementation path through Helsedirektoratet, the Direktoratet for medisinske produkter, and Standard Norge.
Last revised . Regulation is moving; check the primary-source links before relying on any date in this page for compliance work.
1. What the AI Act actually requires
High-risk AI medical devices placed on the EU market sit inside two regulatory regimes at once: the Medical Device Regulation (MDR 2017/745) or In Vitro Diagnostic Regulation (IVDR 2017/746) at the device-safety layer, and the Artificial Intelligence Act (Regulation (EU) 2024/1689) at the AI-specific layer. The Medical Device Coordination Group spelled out the two-regime interaction in MDCG 2025-6. Most of that document addresses the manufacturer; the deployer obligations are short, load-bearing, and the focus of this guide.
The AI Act lands obligations on hospitals as deployers of high-risk AI systems. Two articles do most of the work.
Article 12 (Record-keeping) obliges providers to design high-risk AI systems with automatic logging that captures events relevant to risk identification under Article 79(1), to post-market monitoring under Article 72, and to the deployer-side monitoring obligations of Article 26(5). The provider designs the log; the deployer holds it.
Article 26 (Obligations of deployers of high-risk AI systems) is where hospital duties sit. In summary form: assign human oversight to named persons with the necessary competence, authority, and resources (26(2)); ensure input data is relevant and representative (26(4)); monitor operation per the instructions for use and inform the provider of any serious incident under Article 72 (26(5)); and keep the automatically generated logs to the extent under their control for at least six months (26(6)). That six-month floor is the minimum — sectoral law (MDR, national health-record retention) typically extends it.
A separate article — Article 14 (human oversight) — gives clinicians the explicit right to disregard, override, or reverse a high-risk AI system’s output. Article 14 is provider- and-deployer-shared at the design level; it is notthe record-keeping requirement and not the focus of this guide. Where this page describes “logging,” it means Articles 12 and 26(6).
2. The deadline is 2 August 2028, not 2026
The original Act set 2 August 2026 as the start date for high-risk obligations including Article 26 deployer duties. That date has slipped under the Digital Omnibus revision. The Council general approach of 13 March 2026 splits the timeline in two: standalone Annex III high-risk systems to 2 December 2027, and AI embedded in regulated products — including medical devices and machinery — to 2 August 2028. Council and Parliament were “closely aligned” on the split as of the May 2026 trilogue reporting; final consolidated text is expected mid-2026.
Three practical consequences. First, large language model surfaces (and a meaningful fraction of analyst commentary written before March 2026) still cite the original 2 August 2026 date for medical devices. Treat that as out-of-date. Second, the split matters: a standalone radiology-triage tool that is not itself MDR-regulated falls under the December 2027 path; a CADe module embedded in a regulated endoscopy stack falls under the August 2028 path. The deployer obligations are the same; only the start date differs. Third, the Digital Omnibus is not yet enacted. Until the trilogue concludes and the consolidated text publishes in the Official Journal, the dates above are Council position, not law. Track the Council page above for status.
Twenty-seven months from May 2026 is not long for hospital practice change. The override habit, and the data trail it leaves, take years of practice to make routine — which is the case for starting the work now rather than waiting for the deadline.
3. Deployer-side logging in practice
Article 26(6) reads as a single sentence in the regulation. The unspecified question for hospital quality officers is: what does it mean operationally? The standards bodies have not yet answered. CEN-CENELEC JTC 21 has published prEN 18286 in public enquiry as the first AI-Act harmonised standard, but its scope is provider-side QMS — not deployer-side logging. IMDRF’s N93 Technical Framework (consultation 10 April–10 July 2026) covers operations and monitoring, but is regulator-side and not yet final. MDCG 2025-6 punts on the deployer layer. So the answer is, in the language of the regulation itself: the deployer keeps what the provider generates, plus whatever the deployer’s own clinical workflow captures around the AI’s output.
Five concrete things a hospital quality officer should be able to point at, by August 2028:
- An inventory. Every CE-marked AI medical device in clinical use, with its provider, its intended purpose per the instructions for use, and the named human-oversight person under Article 26(2).
- The provider-emitted logs. The Article 12 logs the manufacturer ships with the device. Confirm with the provider where they are written, in what format, with what retention, and who at the hospital can read them. Six months minimum under 26(6); MDR and national health-record retention typically push that to 10–15 years.
- A deployer-side decision record. What the algorithm called, what the clinician concluded, and a short reason if those diverged. This is the layer the provider does not own — it is the clinical decision around the AI output, not the AI output itself. Article 26 requires that the deployer actually monitor and act; the decision record is how a hospital shows it monitored and acted.
- An incident pathway. A documented route for informing the provider under Article 26(5) and the surveillance authority under Article 79 when something goes wrong. In Norway, that surveillance authority for medical-device safety is the Direktoratet for medisinske produkter (DMP).
- An audit trail readable by a non-technical reader. A notified-body auditor or a national surveillance authority should be able to ask “show me last month’s overrides on Device X” and get a coherent answer in minutes, not in an after-the-fact reconstruction. This is the constraint that makes file-system log archives insufficient on their own.
Two further notes on scope. First, “under their control” in 26(6) is doing real work in the legal text — a hospital is not on the hook for logs the provider keeps in provider-side cloud infrastructure that the hospital cannot reach. Confirm in writing with the provider where the boundary sits. Second, none of the above is an EHR replacement. The decision record sits alongside the EHR; the hospital’s standing audit and retention policies for EHR data continue to apply.
4. The Decision Ledger as one implementation
MedScan AI publishes a deployer-side decision record specification we call the Decision Ledger. It is one implementation of the third item in the list above — not the only one, and not a substitute for the inventory, the provider-emitted logs, the incident pathway, or the audit trail. A hospital that builds the Decision Ledger pattern itself, using its own EHR and SIEM, satisfies the same regulatory requirement that a hospital using the MedScan AI Decision Ledger surface does. The point of an editorial reference page is to be useful whether the reader builds, buys, or borrows.
5. The EEA / Norway path
Norway implements the AI Act via the EEA Agreement. The Ministry of Digitalisation and Public Governance issued the Norwegian implementing draft on 30 June 2025, with the stated intent that obligations take effect “in step with the EU.” For hospital quality officers in Norway, the AI Act timeline is the EU timeline — 2 December 2027 for standalone systems and 2 August 2028 for medical-device-embedded AI under the Council position.
The institutional roles split across two directorates and a standards body: Helsedirektoratet coordinates AI in clinical practice and publishes guidance for hospitals. Direktoratet for medisinske produkter (DMP) is the medical-device surveillance authority — the body a hospital would notify under Article 79 if an AI device caused harm. And Standard Norge’s SN/K 586 (“Kunstig intelligens”) is the Norwegian mirror committee that channels Norwegian input into CEN-CENELEC JTC 21 and ISO/IEC SC 42. SN/K 586 already includes Helsedirektoratet, Oslo Universitetssykehus, and Nkom — meaning a hospital that wants early visibility into the harmonised-standard drafts has a viable path through a Standard Norge membership rather than direct CEN participation.
The practical advice for a Norwegian hospital quality officer drafting an AI compliance plan in 2026–2027: cite Helsedirektoratet guidance for the clinical-practice layer, DMP for the medical-device-incident pathway, and the AI Act articles directly for the AI-specific obligations. The harmonised standards under JTC 21 will not all be published until late 2026 / 2027 at earliest; hospital plans drafted before publication should reference the regulation directly and update once the harmonised standards land.
6. Frequently asked
- Does Article 26(6)’s six-month minimum override our 10-year EHR retention policy?
- No. The six months is a floor, not a ceiling. Sectoral law — MDR post-market surveillance, national health-record retention rules, hospital litigation policy — typically extends retention well past six months. Apply the longest applicable retention period to the AI logs. See Article 26(6).
- Our AI device is FDA-cleared but not CE-marked. Does Article 26 apply?
- The AI Act applies to AI systems placed on the EU market or put into service in the Union, irrespective of provider jurisdiction. A US-developed AI device used in an EU hospital triggers deployer obligations. The provider is responsible for CE-marking and Article 12 record-keeping; the deployer is responsible for Article 26 monitoring and retention regardless of the provider’s home regulator.
- Who is the “deployer” — the radiology department, the IT department, or the hospital legal entity?
- The deployer is the legal entity using the AI system in the course of professional activity (Art. 3(4)). For a hospital, that is the hospital itself. Internal delegation — to the radiology department, to a clinical AI governance committee, to the IT department for log-retention — is a hospital-internal choice. The named human-oversight person under Article 26(2) must have the competence, authority, and resources to override the AI; that is a clinical-leadership role, not an IT role.
- Where do we send a serious-incident report in Norway?
- For medical-device incidents, the Direktoratet for medisinske produkter (DMP) is the national competent authority. Articles 26(5) and 73 of the AI Act cross-reference Article 72’s post-market monitoring framework, which integrates with MDR vigilance reporting via MDCG 2025-6. In practice, a single incident report typically covers both regimes.
- We’re a small clinic and the AI we use runs entirely in the provider’s cloud. Are we still on the hook for logs?
- Article 26(6) says “to the extent that such logs are under their control.” If the provider retains the logs and the clinic has no technical access, the retention duty does not attach to the clinic for those records — but the clinic still owes the inventory, the named oversight person, the incident pathway, and the deployer-side decision record around override actions. Get the boundary documented in writing with the provider; auditors will ask.
- When will harmonised standards under JTC 21 actually publish?
- The CEN-CENELEC Boards’ October 2025 acceleration decision targeted a Q4 2026 publication window for the foundational provider-side suite (risk management, data governance, transparency, human oversight). prEN 18286 (provider QMS) completed public enquiry in late January 2026; formal vote is pending. A deployer-side logging standard is not in the published JTC 21 work programme as of May 2026 — meaning the regulation itself is the primary reference for hospitals writing 2027 compliance plans.
- Is “the deployer” the same person as “the user” under MDR?
- Closely related, not identical. MDR uses “user” in the context of intended-use compliance and instructions-for-use fidelity; the AI Act uses “deployer” for a broader set of monitoring, oversight, and logging duties. MDCG 2025-6 treats them as overlapping populations with distinct duties under each regime. MDCG 2025-6.
What to do next
If you are a hospital quality officer or clinical AI governance lead reading this in 2026 or 2027: the move is to build the inventory now, name the human-oversight person now, and get the provider conversation about Article 12 logs onto the calendar this quarter. The inventory and the named person take an afternoon. The provider conversation takes longer because the answer is rarely ready on the first ask. Twenty-seven months sounds like a long horizon; it is exactly two procurement cycles.
If you are an auditor, a notified-body assessor, or a regulator drafting national guidance: the primary-source citations on this page are versioned and the page itself carries a dateModified in the page metadata. Cite the regulation directly where you can; this guide is offered as a structured walk-through, not as authority. Suggestions, corrections, or pointers to better sources are welcome — Erik Hafnor, MEDTEK KI AS, Stavanger.
Primary sources
Regulatory texts
- Regulation (EU) 2024/1689 — consolidated text on EUR-Lex
- Article 12 — Record-keeping
- Article 26 — Obligations of deployers of high-risk AI systems
- Article 14 — Human oversight (referenced for boundary, not the focus of this guide)
- Council of the EU — General approach on the Digital Omnibus, 13 March 2026