AI in Emergency Dispatch and Triage: High-Risk Under Annex III Point 5(d) of the EU AI Act
AI that triages 112 calls or prioritises ambulance and fire dispatch is high-risk under Annex III point 5(d). The trigger, obligations, and 2026 deadline.
A model that scores incoming 112 calls for urgency, ranks the ambulance queue, or triages patients at an emergency department decides who gets help first — and under the EU AI Act, that makes it high-risk. Annex III point 5(d) of Regulation (EU) 2024/1689 names emergency-call evaluation, dispatch prioritisation, and patient triage explicitly — and a human pressing send does not change the classification.
The Trigger: What Annex III Point 5(d) Actually Classifies
Annex III point 5(d) of Regulation (EU) 2024/1689 names AI systems intended to evaluate and classify emergency calls, or to dispatch or establish priority in the dispatching of emergency first-response services — including police, firefighters and medical aid — and emergency healthcare patient triage systems. It captures the whole chain, from the call landing to a unit being assigned.
Intended-Purpose Test, Not Deployment Sector
Classification under Annex III turns on the system's intended purpose, not the sector you operate in or the technology you use. A call-urgency scorer, a queue-ranking engine, and a hospital triage model all fall in scope because their output shapes who receives first-response help and in what order. It does not matter whether the model is a neural network or a rules table, nor that a human handler presses send. If the output influences prioritisation, the system is in scope.
Where the Boundary Sits: Dispatch Decisioning vs Back-Office Tooling
Not every control-room tool is high-risk. Resource forecasting, shift rostering, and transcription that does not feed prioritisation sit outside point 5(d). But the moment a transcript is scored for urgency, the analysis flips: draw the line at the decisioning layer, not the sector. This is a stand-alone Annex III system, so the full high-risk stack applies directly — Articles 8 to 15, 16, 26, and 43 — with no intervening sectoral act, unlike the Annex I route.
Why Life-Safety Prioritisation Is Treated as High-Risk
Point 5(d) sits inside Annex III point 5, covering access to essential private and public services and benefits. Emergency response is the clearest example: its delay or denial directly affects health, safety and life.
Essential-Services Framing Under Annex III Point 5
The other limbs of point 5 — public benefits (5(a)), creditworthiness (5(b)), and life and health insurance pricing (5(c)) — share one logic: an automated output gates access to something a person depends on. A mis-ranked call or an under-triaged patient means a delayed ambulance or a deprioritised fire response — harm to physical safety and fundamental rights, which is why Article 6(2) lists these systems as high-risk in Annex III.
The Article 6(3) Filter and Why It Rarely Clears Here
Article 6(3) lets a provider self-assess an Annex III system out of high-risk where it poses no significant risk of harm — for instance because it performs only a narrow procedural task or merely improves a completed human activity. That filter is structurally available to point 5 systems but almost never clears for dispatch or triage: a system influencing life-safety prioritisation is, by definition, not narrow or cosmetic. A provider that invokes it still carries the documentation burden and must register under Article 49 either way.
How 5(d) Differs From the Point 2 Safety-Component Test
Separate point 5(d) from its critical-infrastructure sibling: Annex III point 2 turns on whether the AI is a safety component of physical infrastructure, while point 5(d) turns on prioritising access to an essential, human-facing service — same Annex, different trigger, and a different downstream duty for public deployers.
The Obligations Stack: Articles 9 to 15, Oversight, and Logging
The documentation backbone runs through Article 11 (the Annex IV technical file, before market placement), Article 13 (instructions for use covering limits and degraded-mode behaviour), and Article 15 (accuracy, robustness and cybersecurity for a life-critical, always-on system).
Article 9 Risk Management for Dispatch-Specific Failure Modes
Article 9 requires a documented, lifecycle risk management system. For dispatch and triage, map the harms specifically: systematic under-prioritisation of certain call types, demographic skew in triage scores, and degraded-mode behaviour when call volume surges past anything the model saw in training. The system must fail safe, defaulting to human escalation rather than silent misranking.
Article 10 Data Governance and Historical-Bias Risk
Article 10 demands training, validation and testing data that are relevant, representative, and examined for bias — load-bearing here. Historical dispatch logs encode past bias: if certain neighbourhoods or call types were historically under-served, a model trained on them learns to repeat the pattern.
Article 14 Human Oversight and Automation Bias in the Dispatch Loop
Article 14 is the linchpin. The call-handler or clinician must be able to understand the recommendation, intervene in real time, and override or de-prioritise it without friction. Automation bias — deferring to the score even when human judgment is better — must be designed out of the interface.
Article 12, 19 and 26 Logging Across Provider and Deployer
Article 12 requires the system to record events automatically by design; Article 19 obliges the provider to keep those logs; the deployer's own retention duty sits in Article 26. Together they create the evidential trail a market-surveillance authority asks for after a serious incident: what the system recommended, what the human decided, and when.
Who Is the Provider, Who Is the Deployer — and the Public-Authority FRIA
Provider Obligations (Article 16) for the Dispatch-AI Vendor
The vendor that builds and places the dispatch or triage system on the market is the provider under Article 16. It carries the Articles 9 to 15 stack, plus Article 43 conformity assessment, the Article 47 EU Declaration of Conformity, Article 49 registration, Article 72 post-market monitoring, and Article 73 serious-incident reporting.
Deployer Obligations (Article 26) for the Control Room
The control room, ambulance trust, fire service, or 112 answering point that runs the system is the deployer under Article 26: use within the intended purpose, maintain the oversight designed in, monitor performance, and retain the automatically generated logs.
Article 27 FRIA for Public-Authority Deployers
Here is the duty the critical-infrastructure sibling does not foreground. Most emergency dispatch deployers are public authorities or bodies providing a public service, so Article 27 is triggered: they must complete a fundamental rights impact assessment (FRIA) before first use. A system deciding who receives first-response help clears that threshold easily.
Article 25 Role Shifts and the Annex VI Assessment Route
Under Article 25, a control room that retrains the model on its own data, renames it, or changes its intended purpose becomes the provider and inherits the full Article 16 stack. Stand-alone Annex III point 5(d) systems use the Annex VI internal self-assessment under Article 43 — no notified body. Internal does not mean informal; the technical file must withstand a market-surveillance inspection at any time.
Obligations at a Glance: Provider vs Deployer
| Duty | Provider (Article 16) | Deployer (Article 26) |
|---|---|---|
| Risk management | Establish + maintain (Art 9) | Operate within scope |
| Data + documentation | Representative data (Art 10); Annex IV file (Art 11) | Keep instructions for use |
| Logging | Enable + keep (Art 12, 19) | Retain logs (Art 26) |
| Human oversight | Design it in (Art 13, 14) | Maintain it (Art 26) |
| Accuracy / robustness / security | Achieve + sustain (Art 15) | Monitor in context |
| Conformity + DoC + registration | Annex VI route (Art 43, 47, 49) | — |
| Fundamental rights | — | FRIA where public body (Art 27) |
| Post-market + incidents | Monitor + report (Art 72, 73) | Notify provider / authority |
| Penalty exposure | Article 99(4): €15 million or 3% | Article 99(4): €15 million or 3% |
| Applies from | 2 December 2027 (adopted) | 2 December 2027 (adopted) |
Worked Example: A Triage-AI Vendor and a Regional Ambulance Service
Consider Triadex, a 140-person Dublin-based health-tech vendor selling an emergency call-triage and dispatch-prioritisation engine to a regional EU ambulance service.
Mapping the Provider and Deployer Duties
Triadex is the provider: the engine influences who gets the next ambulance, so point 5(d) applies and the system is high-risk. Before market placement Triadex must run Article 9 risk management, build the Annex IV file under Article 11, self-assess via Annex VI under Article 43, draw up the Article 47 Declaration of Conformity, and register under Article 49; once live, Article 72 post-market monitoring and Article 73 serious-incident reporting follow.
The ambulance service is the deployer under Article 26. As a public-service body it must complete an Article 27 FRIA before going live, keep dispatchers able to override under Article 14, and retain logs.
Penalty Proportionality Under Article 99(6)
A breach exposes Triadex under Article 99(4) to up to €15 million or 3% of total worldwide annual turnover, whichever is higher. As a small company it benefits from Article 99(6), capping the fine at the lower of the two — relief on exposure, not on the obligation.
The Deadline: 2 December 2027, With the Digital Omnibus Now Adopted
What the Statute Read Before the Digital Omnibus
The statute as originally written set stand-alone high-risk Annex III obligations under Article 6(2) to apply from 2 August 2026.
The Digital Omnibus Deferral Is Adopted
The Digital Omnibus — passed by the European Parliament on 16 June 2026 and adopted by the Council on 29 June 2026 — defers Annex III high-risk obligations to 2 December 2027. It enters into force on publication in the Official Journal, expected before 2 August 2026; that publication is a formality, not an open step. The proposed open-ended "stop the clock" pause was rejected; the deferral is to a fixed calendar date — and not everything in the Act is delayed. Plan against 2 December 2027.
No Grandfathering — Start the Technical File Now
Systems already in use must be brought into compliance; there is no automatic grandfathering for dispatch or triage systems. Given how long an Annex IV file takes to build to an inspectable standard, start now.
How Confir Helps
Confir's classification engine walks the plain-English point 5(d) test and produces a documented, repeatable classification finding. The engine is deterministic and rule-based: no model inference, no hallucination.
Once a system is classified high-risk, Confir generates a pre-structured Annex IV documentation pack, an Article 47 Declaration of Conformity template, and a starting point for the Article 27 FRIA public-authority deployers must run.
Frequently Asked Questions
Is AI used for 112 emergency call triage automatically high-risk?
Yes, if it evaluates and classifies emergency calls or sets dispatch priority, it falls squarely within Annex III point 5(d) of Regulation (EU) 2024/1689 and is high-risk under Article 6(2). Classification follows the system's intended purpose, not the technology used, so a call-urgency scorer or queue-ranking model is in scope even when a human handler presses send. The narrow Article 6(3) non-high-risk filter is hard to invoke for a system influencing life-safety prioritisation, and the provider still carries the documentation and Article 49 registration burden if it tries.
How is emergency-dispatch AI different from critical-infrastructure AI under Annex III?
They sit in different Annex III categories with different triggers. Critical-infrastructure AI is point 2 and turns on whether the system is a safety component of physical infrastructure such as a grid, water supply or road traffic. Emergency-dispatch and triage AI is point 5(d), within the essential-services category, and turns on whether the system prioritises access to a life-critical human-facing service. The obligations stack (Articles 9-15) is similar, but the framing, the harm rationale and, for public deployers, the Article 27 fundamental rights duty differ.
Who carries the obligations — the AI vendor or the emergency service?
Both, in different roles. The vendor that builds and places the dispatch or triage system on the market is the provider under Article 16 and carries Articles 9-15, the Annex IV technical file, Article 43 conformity assessment, the Article 47 Declaration of Conformity and Article 49 registration. The emergency control room or ambulance service is the deployer under Article 26: use as intended, maintain human oversight, monitor performance and retain logs. If the deployer retrains, renames or repurposes the system, Article 25 converts it into a provider with the full stack.
Does a public ambulance service need a fundamental rights impact assessment?
In most cases, yes. Article 27 of Regulation (EU) 2024/1689 requires deployers that are public authorities, or private bodies providing public services, to carry out a fundamental rights impact assessment before deploying certain high-risk systems. An emergency dispatch or triage system that prioritises who receives first-response help typically meets that threshold, so the assessment should be completed before first use. This duty is distinct from, and additional to, the Article 26 deployer obligations and the provider's own conformity work.
When do the obligations apply — 2 August 2026 or 2 December 2027?
Plan against 2 December 2027. The statute originally set stand-alone high-risk Annex III obligations to apply from 2 August 2026. The Digital Omnibus, adopted by the European Parliament on 16 June 2026 and the Council on 29 June 2026, defers them to 2 December 2027, pending Official Journal publication as a formality. The open-ended pause was rejected and the deferral is to a fixed date — not everything in the Act is delayed.
What are the penalties for non-compliant emergency-dispatch AI?
Breaches of the high-risk obligations fall under Article 99(4) of Regulation (EU) 2024/1689, with fines up to €15,000,000 or 3% of total worldwide annual turnover, whichever is higher. This covers failures across Articles 9-15, provider obligations under Article 16 and deployer obligations under Article 26. For SMEs and start-ups, Article 99(6) caps the fine at the lower of the percentage or the fixed amount — meaningful relief on exposure, but it does not remove the underlying compliance obligation.
Related guides
- AI in critical infrastructure (Annex III point 2)
- Article 6 high-risk classification rules
- Article 14 human oversight requirements
- How high-risk AI is classified
- Healthcare AI compliance under the EU AI Act
Manage your EU AI Act compliance in one place
Confir automates risk classification, technical documentation, and audit trails for any company. No consultants. No 6-month projects. 14-day free trial.
Start free trial →