The EU AI Act, read from an ambulance

If you build or buy AI for emergency services in Europe, two texts define your next five years: the Medical Device Regulation and the AI Act. Most coverage of the AI Act is written for lawyers or for general-purpose model providers. This is an operator's and engineer's reading, focused on one question: what does it mean for intelligence that rides in an ambulance? It is our working understanding, not legal advice.

What the Act is

Regulation (EU) 2024/1689 entered into force on 1 August 2024. It is risk-based: a small set of practices is prohibited outright, a defined class of systems is "high-risk" and carries the heavy obligations, and everything else gets transparency duties or nothing. The Commission's AI Act Service Desk and the community-maintained AI Act Explorer are the two references we keep open.

The dates, as they stand mid-2026

The original schedule staged the obligations: prohibitions and AI literacy from 2 February 2025, general-purpose model rules from 2 August 2025, high-risk systems listed in Annex III from 2 August 2026, and AI embedded in products that already require notified-body assessment (Annex I, which includes medical devices under the MDR) from 2 August 2027.

Then the timeline moved. The digital omnibus package agreed in 2026 pushed the high-risk deadlines back: Annex III systems to the end of 2027, and Annex I product-embedded AI to August 2028, with the stated aim of letting standards and notified-body capacity catch up (Travers Smith, Gibson Dunn). Dates may still shift again; the direction of the obligations has not.

Where emergency AI lands

Two separate routes take a system like ours into the high-risk class, and it is worth being precise about both.

The first is Annex III itself: it explicitly lists AI used to evaluate and classify emergency calls, to dispatch or prioritise emergency first response, and emergency healthcare patient triage systems. The legislator named our field. Anyone selling "AI triage" or "AI dispatch" to a European service is building a high-risk system by definition, whatever their marketing says.

The second route is Annex I: when AI is a safety component of a product that already needs a notified body, such as a medical device under the MDR, the AI Act's high-risk regime attaches to that conformity assessment. This is the route that matters for clinical decision support.

SONARA's architecture takes this seriously by splitting the two. The core product captures, structures, computes validated scores and reports; the clinician authors and validates every record, and the system decides nothing. Active, patient-specific decision support is deliberately a separate, later module with its own regulatory pathway. That split is not a legal trick; it is what keeps the part crews rely on every day outside the blast radius of the longest certification cycles, while the decision-support module is built for them from the start.

What high-risk actually requires

Strip the legal language and the high-risk obligations (Articles 9 to 17) are a list any safety engineer recognises: a risk management system that lives across the product's life; governance over the data the models are trained and tested on; technical documentation before the system ships; automatic logging of events; instructions that let the user actually understand the system; effective human oversight; declared and tested levels of accuracy, robustness and cybersecurity; and a quality management system holding it all together.

Read that list twice and something stands out: almost none of it can be retrofitted. Logging, oversight, documentation and data governance are architecture, not paperwork.

How SONARA was built for the strictest reading

We made the expensive choices early, because the deadlines move but the direction does not:

• Human oversight by design. The clinician validates every record; nothing is acted on autonomously. Article 14 is a product feature, not a compliance memo.
• Data governance by architecture. Everything runs on the device; patient data is not sent to a cloud and is never used to train anything without authorisation.
• Logging as a first-class citizen. Every configuration change and every record edit leaves an auditable trail, because a service's medical direction needs to answer for its protocols.
• Robustness where it hurts. Offline is not a degraded mode; the declared performance is the field performance, sirens and basements included.
• Documentation first. The technical file, the quality system and the MDR pathway are built alongside the product, in the same repositories, so the handover record a hospital receives is backed by the same discipline that produced it.

The AI Act will keep moving through guidance, standards and, apparently, calendars. The systems that survive it will be the ones that treated its requirements as good engineering rather than as a deadline. That was the bet before the Act had a name, and it is cheaper than the alternative.