EU AI Act Article 12 in healthcare: what providers and deployers must log

01What Article 12 actually says

The mandate is short. Two paragraphs, with a third for biometric systems. What the brevity hides is that Article 12 is the operational hinge on which most of the AI Act's substantive obligations actually depend.

The full text of Article 12(1)–(2) — paraphrased here, with citations to the official register below — reads:

Two words do the heavy lifting. "Technically" means the logging capability must be built into the system — not satisfied by a human writing notes or an analyst exporting outputs into a spreadsheet at month-end. "Lifetime" means from the moment the system is placed on the market or put into service until it is decommissioned — not from the moment the deployer's compliance programme came online.

Article 12 is paired with three other provisions that complete the operational picture:

• Article 19 obligates providers to keep the automatically generated logs to the extent they remain under the provider's control.
• Article 26(6) obligates deployers to keep the automatically generated logs for at least six months, unless other Union or national law imposes a longer period.
• Article 18 requires deployers to keep the system's technical documentation accessible for ten years after the AI system is withdrawn from the market or service.

The six-month floor is what most analyses focus on. The ten-year ceiling on adjacent documentation is what carriers, hospital systems, and medical-device manufacturers actually have to architect for — because evidence preserved for six months while the underlying decision is challenged seven years later is evidence the deployer cannot produce.

02The two pathways into "high-risk" for healthcare AI

Healthcare AI reaches high-risk classification — and therefore Article 12 — through two distinct pathways with two distinct effective dates.

2.1 Pathway A — Annex III, point 5

Three of the points in Annex III category 5 ("access to and enjoyment of essential private services and essential public services and benefits") reach healthcare directly:

• 5(a) — AI systems used by public authorities or on their behalf to evaluate the eligibility of natural persons for essential public assistance benefits and services, including healthcare services. This captures NHS-equivalent eligibility decisioning, public-payer prior authorisation, and Member State health-fund coverage determinations.
• 5(c) — AI systems intended to be used for risk assessment and pricing in relation to natural persons in the case of life and health insurance. This captures private insurer underwriting AI and pricing AI directly.
• 5(d) — AI systems intended to evaluate and classify emergency calls or to dispatch or establish dispatching priority for emergency first-response services, including emergency healthcare patient triage systems.

The conservative posture for healthcare AI is to assume in-scope and document any Article 6(3) exemption claim. Article 6(3) exemptions are narrow — the system performs a narrow procedural task, improves the result of a previously-completed human activity, detects decision-making patterns without replacing human assessment, or performs a preparatory task — and require documented justification.

2.2 Pathway B — Annex I via Article 6(1)

Under Article 6(1), an AI system is high-risk if it is itself a product (or the safety component of a product) covered by Union harmonisation legislation in Annex I — which includes MDR (2017/745) and IVDR (2017/746) — and if the product requires third-party conformity assessment by a notified body. Under MDR Rule 11, almost all standalone medical software is classified Class IIa or higher, meaning the AI system is captured as high-risk under Pathway B.

2.3 Why the dual regime matters operationally

A medical-device AI under Pathway B is subject to two parallel regulatory regimes — the MDR/IVDR conformity-assessment framework administered by notified bodies, and the AI Act framework administered by market surveillance authorities. Article 11 and Annex IV allow AI-specific technical documentation to be integrated into the MDR/IVDR technical file rather than maintained separately, and Article 43 permits the notified body designated under MDR or IVDR to also assess AI Act conformity for the same product. This is an integration permission, not an exemption: the substantive obligations of Article 12 still apply.

03What must be logged, in operational terms

Article 12 specifies what the logs must enable — traceability for risk identification, post-market monitoring, and operational monitoring — but does not enumerate the specific events to log. The standards bodies are working on it (draft prEN 18229-1 on AI logging and human oversight, ISO/IEC DIS 24970) but neither has been completed as of mid-2026. The mature operational reading is that the log must enable an independent party to reconstruct, for any specific decision:

04Provider versus deployer — who carries what obligation

Buying high-risk AI from an external provider does not deflect the deployer's obligations. The deployer's six-month log retention obligation runs independently of the provider's obligations. The deployer's responsibility to produce logs on demand to its national market surveillance authority cannot be passed back to the vendor. The practical compliance posture this drives is one in which the deployer either ingests and retains the provider's automatically generated logs itself, or contracts for direct, durable, and audit-time access to the provider's logging infrastructure.

05The timeline, and the Digital Omnibus uncertainty

06The unwritten requirement: tamper-evidence

Article 12 does not contain the words "tamper-evident," "immutable," or "cryptographically protected." But the operational requirement is functionally equivalent.

Consider the position of a market surveillance authority investigating a complaint about a specific high-risk AI decision. The authority requests the logs. The deployer produces a file. There is no mechanism by which the authority can distinguish a faithful record from a curated one. The evidentiary value of the logs approaches zero.

Article 99(4)(c) makes the supply of incorrect, incomplete, or misleading information to authorities a separate violation — up to €7.5 million or 1% of turnover under Article 99(5)(c). A deployer that produces logs and cannot demonstrate their integrity is exposed to both the underlying Article 12 violation and the separate Article 99(4)(c) violation. The two penalties stack.

The practical reading taken by mature regulatory teams is that Article 12 logs must, at minimum, be:

• Append-only — records are written once and cannot be modified after generation
• Integrity-protected — each record is signed or hash-chained such that modification is detectable
• Independently verifiable — a third party can confirm that the logs presented today match the logs as they were when the decision was made, without trusting the deployer's attestation
• Sealed against the deployer — the signing key or chain anchor is held outside the operational trust boundary of the system that generates the logs

07Penalties, and the second violation hiding in plain sight

A single underlying failure can trigger penalties under multiple tiers. A deployer that fails to retain Article 12 logs (Article 99(4) violation) and then produces logs whose integrity it cannot demonstrate (Article 99(5) violation) faces both penalties. The penalties stack because the violations are conceptually distinct: failure to keep evidence is one violation; failure to produce verifiable evidence on request is another.

08What to do in the next 90 days

8.1 Build the Annex III / Annex I inventory

Begin with a documented inventory of every AI system in operation that touches a healthcare decision for natural persons in the EU. For each system, record: the intended purpose, the affected population, whether the system meets one of the Annex III point 5 healthcare descriptions, whether it is a medical device or IVD subject to third-party conformity assessment under MDR or IVDR, the provider, the deployer's internal owner, and any Article 6(3) exemption claim with documented justification.

8.2 Architect the logging infrastructure now, not after the standards land

prEN 18229-1 and ISO/IEC DIS 24970 will eventually specify the technical detail. They are not finalised. Healthcare deployers and providers building to the statutory text and to the practical reading of tamper-evidence outlined in Section 6 will produce architectures that conform when the standards arrive. The architectural decisions that matter most: where the log signing key sits (outside the operational trust boundary); how the six-month retention floor is reconciled with the ten-year technical documentation retention; how the log structure supports Article 27 FRIA population-characteristic recording; how the logging architecture composes across provider and deployer.

8.3 Resolve the provider-deployer contractual question

For every high-risk healthcare AI system deployed under a vendor agreement, the contract must explicitly address Article 12 logging: which party generates the logs; how the deployer obtains durable access for the six-month retention period; how the deployer can produce logs to a market surveillance authority on demand; what happens to log access if the contract terminates; and how the vendor's Article 19 retention complements rather than substitutes for the deployer's Article 26(6) retention.