Input data and information sources
The caller alone determines what is said during the call. Emergency calls contain callers' and affected people's names, addresses and voices.
AI support for emergency call handling
Also known as: AI-assisted emergency call triage
The system listens during an emergency call and alerts dispatchers to signs of an emergency, such as cardiac arrest.
Understand the use case
What defines this use case?
Copenhagen's dispatch centre trialled it in live operation. Services in France, Italy and Scotland tested it on recorded calls; Wales has an ongoing research project.
This page describes a typical system design. Actual data flows and permissions depend on your implementation.
- System design
- Analysis and processing
- Ability to act
- Action permissions depend on integration
- Fields of use
- emergency medical services, emergency dispatch centres
- Also known as
- emergency call triage, cardiac arrest detection during emergency calls
How it works, step by step
System design and data flows
Input data
Audio from the ongoing emergency call reaches the system directly.
The caller alone determines what is said during the call. Emergency calls contain callers' and affected people's names, addresses and voices.
Processing
Speech recognition transcribes the call; a model continually checks the transcript for signs such as cardiac arrest.
The system processes information from the ongoing call, for example through speech recognition and analysis of relevant terms or patterns. It provides the control room with indications of a possible emergency. Decisions on follow-up questions, urgency and deployment of resources take place within the designated control-room process.
Results
An indication appears for the dispatcher while the call is still underway.
The result describes the defined model task. A match, category or forecast acquires its professional significance only in conjunction with the underlying data and intended use.
Use and impact
The centre determines urgency and whether to guide callers through resuscitation.
Integration determines whether the result is simply displayed, adopted after approval or written directly into a business application. These variants differ in their data flows and permissions.
Explore the system design: Select a component to see its task, incoming and outgoing data, and role in the use case. The guided walkthrough explains each phase. Then use Yes, Uncertain and No to represent your specific system variant.
7 review first9 clarify7 baseline threats
- Present
- Depends on your system
- Absent
- Review first
- To clarify
How to use the model
The diagram shows the typical architecture. Select a component to see what happens there and adapt its features to your system. Enable “Analysis guidance” to see which threats need reviewing for this architecture. The page's checklist continues to describe the typical case.
Changes from the typical case
None yet. Each change will appear here.
Where most threats arise
- 4 clarify
- 3 review first
- 1 review first, 2 clarify
- 1 review first, 1 clarify
In this system design: 7 to review first, 9 to clarify, 7 baseline threats.
Architecture as a list
External access: Depends on your system
To clarify
Input: Part of every AI system
Review first
Baseline for every AI system
Third-party content: Present
AI model: Part of every AI system
Review first
- Model Drift & Degradation Review priority
Provider service: Present
Review first
To clarify
Training and feedback: Present
Review first
To clarify
Result: Part of every AI system
Baseline for every AI system
Business application or equipment: Depends on your system
To clarify
person: Part of every AI system
Review first
- Overreliance Review priority
Affected person: Present
Unapproved AI services: Depends on your system
To clarify
Supply chain and technical foundations: 5 baseline threats applying to every AI system
Baseline for every AI system
How it differs from similar use cases
Speech recognition and transcription
Only transcribes conversations without checking for emergency signs
Customer service chatbots and voicebots
Answers and handles calls itself
Clinical decision support (such as early sepsis detection)
Analyses vital signs and patient records in hospitals
Data and information
Processing and operating environment
All documented uses rely on one manufacturer's system.
Storage and further use
In the pilots, the manufacturer trained the model on recordings from each dispatch centre. New recordings with confirmed diagnoses can improve the model later.
Results and data sharing
Depending on integration, it only displays the indication or sets an incident category or urgency in dispatch software itself. In the pilots, the manufacturer held the training recordings.
Using a provider does not automatically determine where processing takes place. Storage location, subcontractors, deletion periods and use for training must be checked for the specific deployment.
Assess risks and determine measures
From understanding the system to analysing risks
- Define the system boundary
Record data, participants, interfaces and permissions. Resolve uncertain characteristics in the model.
- Investigate threats
Relate review candidates to actual data flows: what could happen, and who would be affected?
- Assess risk
Assess impacts and likelihood in the deployment context. The number of review candidates is not a risk score.
- Provide evidence of measures
Select appropriate controls, assign responsibilities and define effectiveness checks. Document residual risks and approvals.
Key threats in the application context
- 3 particularly important
- 4 typical
- 9 depending on the system
- 7 additional threats for every AI system
A total of 23 threats from the threat catalogue may be relevant to this use case.
Also review: whether the outputs are substantively correct
Check probability reliability, possible test-data leakage into training and the consequences of an error in the business process.
Also review: whether the system disadvantages groups
Check whether selection, ranking or assessment disadvantages people with protected characteristics, such as sex, age or origin.
Also review: Safety of people and equipment
Check independent safety functions, intended operating limits and the safety evidence your sector requires.
Priority review points
A dispatcher relying on cardiac arrest alerts may stop asking targeted questions when none appears. Telephone resuscitation instructions then begin too late.
A model trained on one centre's calls performs worse with different languages, dialects or questioning practices. Pilots in France, Italy and Scotland therefore first trained it on local recordings.
Sensitive Information Disclosure
Real call recordings go to the manufacturer for training and evaluation. Unauthorised disclosure of voices and health information causes irreversible harm.
4 further review candidates in the typical design
Other relevant threats
Targeted Poisoning / Label Poisoning
Falsified training labels can deliberately shift model outputs.
Listed because of this characteristic
- Learns from examples with correct answers
Training data or an adopted base model can introduce hidden triggers for misbehaviour.
Listed because of this characteristic
- Uses another provider's model
Targeted queries can recover some personal or protected training data from the model.
Listed because of these characteristics
- Processes personal data
- Processes confidential data
Exfiltration from ML Application
Protected data can leak through tools, network connections, storage or insiders.
Listed because of this characteristic
- Processes confidential data
Up to 9 further threats may apply, depending on your system design. Nine threats need to be reviewed for every AI system. Two of these are particularly important here and are therefore listed above.
System features and open questions
Each Yes adds further threats to your checklist, up to 9 in total. If you cannot yet answer a question, include its threats in your review.
- Added by this Yes
- Also requires a Yes to another question
How your system is built
- Learns from your own data1 threat, plus 1 only in combination with other characteristics
- Changes data or triggers processes1 threat
- Learns in operation without renewed approval1 threat
- Uses operational feedback1 threat
How you operate the system
- Available to people outside the organisation5 threats
- Accepts queries directly through an interface4 threats
- Accessible over a network2 threats, plus 1 only in combination with other characteristics
- Incurs costs with each query1 threat
- Shares computing resources with other customers or applications1 threat
- Used alongside unapproved AI services1 threat
How your system is built
Can the system change things itself, such as storing data, sending messages, initiating transactions or granting permissions?
Depending on integration, it only displays the indication or sets an incident category or urgency in dispatch software itself.
If yes, add
Does your organisation train or fine-tune the model itself using its own data?
In the pilots, the manufacturer trained the model on recordings from each dispatch centre.
If yes, add
Does the system keep learning in operation and change its behaviour without renewed approval?
If yes, add
Does operational feedback or output later feed into analysis or training?
New recordings with confirmed diagnoses can improve the model later.
If yes, add
How you operate the system
These questions arise for almost every AI system.
Can people or programs query the model directly, for example through an interface?
If yes, add
Is the system accessible over a network or dependent on network services?
If yes, add
Do you pay per query or unit of computing time, so costs increase with use?
If yes, add
Does the system share servers or computing resources with other customers or applications?
If yes, add
Can people outside your organisation use the system, including without login?
If yes, add
Do staff also use AI services for this task that your organisation has not approved?
If yes, add
Controls and implementation
Measures for the priority review areas are expanded. Each linked measure explains how to implement it.
Review priorityOverreliance3 measures
Review priorityModel Drift & Degradation3 measures
Review prioritySensitive Information Disclosure3 measures
Targeted Poisoning / Label Poisoning3 measures
Backdoor ML Model2 measures
Privacy Attacks3 measures
Exfiltration from ML Application3 measures
Controls for the remaining threats are available on their pages in the threat catalogue.
AI Act provisions
-
Art. 4: AI literacy
For every AI system Applies since 2 February 2025.
-
Annex III no. 5 point d: Emergency calls and emergency care
In typical use Review trigger from 2 December 2027.
Applies to every AI system
Art. 4: AI literacy
Applies if staff or appointed representatives operate or use AI systems.
Applies since 2 February 2025.
Obligations and details for Art. 4: AI literacy
- Who bears the obligations
- Provider, Deployer, Product manufacturer, Provider of a general-purpose AI model
Detailed obligations
May apply in typical use
Annex III no. 5 point d: Emergency calls and emergency care
Applies if the system assesses calls during the conversation and gives dispatchers urgency indications, such as possible cardiac arrest.
Applies from 2 December 2027.
Obligations and details for Annex III no. 5 point d: Emergency calls and emergency care
- The general condition is
- Applies if the system evaluates or classifies emergency calls, dispatches responders or prioritises emergency patients.
- Who bears the obligations
- Provider, Deployer, Product manufacturer
Detailed obligations
Generally does not apply
Art. 50 para. 1: Disclosure of AI interaction
The caller speaks to a person at the centre rather than the system. The obligation to disclose AI interaction therefore generally does not apply.
Obligations and details for Art. 50 para. 1: Disclosure of AI interaction
- The general condition is
- Applies if people directly write or speak with the system and it is not obvious that they are interacting with AI.
- Who bears the obligations
- Provider, Product manufacturer
Detailed obligations
Classify your system with the quick checker All obligations in the obligations compass
Cross-cutting threats
Review these threats for every AI system, whatever its purpose.
Atypical system features
View 17 further questions
If any of these features does apply to your system, add the listed threats.
Does the system generate its own text, such as answers, drafts or summaries?
The system displays indications; a transcript only reproduces what was said.
If yes, add
Does the system generate or edit images, sounds, voices or videos?
If yes, add
Does the system create new content from open-ended requests that people read, see or hear directly? Translation, reading aloud and transcription do not count.
If yes, add
Can users give the system natural language tasks that it then performs?
The system listens and does not accept instructions.
If yes, add
Does the system search its own collection of documents or records for relevant content?
If yes, add
Does the system formulate answers from retrieved documents?
If yes, add
Does the system use a knowledge graph storing concepts and their relationships?
If yes, add
Does the system remember content from earlier conversations or tasks and reuse it later?
If yes, add
Does the system call other programs, interfaces or search services itself, even if only to read?
If yes, add
Does the system determine its next steps itself based on earlier results?
If yes, add
Does the system delegate tasks to other AI agents or incorporate their results?
If yes, add
Is the system connected to tools or data sources through the Model Context Protocol (MCP)?
If yes, add
Do documents from several customers, departments or permission groups share one search store?
If yes, add
Does the system process several input types together, such as text with images or speech?
The system analyses only the conversation.
If yes, add
Does the system generate code, scripts or database queries for further use?
If yes, add
Does the system execute programs, scripts or commands itself?
If yes, add
Is the system intended to maximise a specified metric, such as revenue, utilisation or clicks?
If yes, add
Sources
- Specialist study
With alerts, staff recognised 93.1 rather than 90.5 per cent of cardiac arrests, a non-significant difference; the model alone detected more but generated more false alarms.
- Specialist study
The trial register describes the Copenhagen study conducted in live dispatch operations.
- Report of a deployment
EENA and Corti, Detecting out-of-hospital cardiac arrest using artificial intelligence, Project report, 13 January 2020 According to the manufacturer
EENA and manufacturer Corti staff describe pilots at AREU (Lombardy) and SDIS-SAMU 74 (Haute-Savoie), which trained the model on their own calls.
- Report of a deployment
Scottish Ambulance Service, Emergency Call Artificial Intelligence Pilot Trial According to the deployer
The service describes a four-month Corti trial on copied calls without operational intervention; transferred data is deleted afterwards.
- Specialist study
University of York, Assuring Autonomy, ASSIST: AI in ambulance service 999 calls
The project adapts the Copenhagen platform for the Welsh Ambulance Service to support cardiac arrest recognition during call handling.
- Legislation, norm or standard
Regulation (EU) 2024/1689 (EU AI Act), Annex III, point 5(d)
Annex III lists AI systems evaluating and classifying emergency calls, dispatching responders or prioritising emergency patients.
Related use cases
Also in the field of Healthcare and emergency services
- AI-assisted medical image analysisThe system marks abnormalities on X-rays, CT, MRI or mammography images to help clinicians interpret findings.
- Clinical decision support (such as early sepsis detection)The system continuously analyses vital signs, laboratory values and patient records and alerts the care team to a possible deterioration.
Updated: 30 September 2026. Review checklist rules version 0.3.2, threat catalogue version 2026.10.24.2. How these pages are structured