Emergency & non-emergency call triage assistant (112, police, control rooms)

Control rooms lose critical seconds to language barriers, noisy lines, free-form questioning and double data entry, and police non-emergency lines are swamped by calls that need information, not a patrol. An AI assistant transcribes and translates the call, fills the incident form, flags red-flag phrases and handles routine non-emergency contacts, while a human call-taker remains the decision-maker for every emergency. Because it evaluates and classifies emergency calls, this is an EU AI Act high-risk use case.

Problem & value

• Today: call-takers in public-safety answering points (PSAPs) interview callers by protocol, type into the CAD (computer-aided dispatch) system and judge urgency under stress. Calls in rare languages require an interpreter conference or are handled poorly. Police non-emergency lines (UK 101, German Polizei Notruf alternatives, local numbers) carry reporting, lost-property and advice calls that compete for the same staff.
• AI value: faster, more complete data capture; real-time transcription and translation; consistent protocol prompting; deflection of routine non-emergency calls; a transcript for quality review and training.
• Evidence (treat as indicative): the research project NotAs (Dortmund fire brigade institute IFR, DFKI, Eurofunk) built a multilingual digital call assistant combining language identification, speech recognition, machine translation and AI interpretation of call content that hands dispatchers a pre-filled deployment form [1]. EENA's AI Special Project piloted real-time translation and transcription, call triage and prioritisation, and noise cancellation with four vendors and PSAPs from eight countries [2]. Vendor-reported cardiac-arrest recognition figures (e.g. Corti's) come from specific trials and should not be generalised [4].

Variants

• Police non-emergency line voicebot: answers, collects report details for low-risk offences, gives advice, books callbacks; hands over on any risk cue. Close to CONV-002/CONV-011 but with hard escalation rules.
• 112 call-taker copilot (assist only): live transcript, translation, form pre-fill and protocol prompts; the human classifies and dispatches. The safest and most common pattern.
• Overflow/queue assistant: answers when all call-takers are busy, collects location and nature, and routes urgent calls to the front of the queue (high-risk, needs strict safeguards).
• Multilingual and accessibility channel: interpreting for foreign-language, deaf or speech-impaired callers via text/video channels (see SPEECH-003, LANG-009).
• Healthcare ambulance/116117-style lines: symptom triage with clinical protocols, overlapping CONV-010.

How it works

1. call/chat/NG112 session (+ caller location)
2. language ID + streaming ASR (stress, accents, noise-robust)
3. real-time translation (call-taker sees/hears own language)
4. extraction: location, incident type, people at risk, hazards
5. structured CAD record
6. red-flag & urgency suggestion (rules + classifier + LLM) with evidence snippets
7. HUMAN call-taker confirms/edits, dispatches via CAD
8. non-emergency branch: voicebot completes report / advice / callback
9. recording, transcript, audit log of suggestion vs decision

• Escalation logic is rule-based first: keywords, caller silence, distress, children, weapons, "not breathing" and any model uncertainty force immediate transfer to a human. The LLM never ends a call or downgrades urgency alone.
• Location comes from handset-derived data (AML) and CAD geocoding, not from the model; the model only reads back the address for confirmation.
• Human-in-the-loop points: urgency class, dispatch, any downgrade of a call, and review of every non-emergency auto-case sample.

Data preparation

Relevant data: call recordings and transcripts, CAD incident records, the incident catalogue and response-plan rules, address and geocoding data, and interpreter logs. In an authority these typically live in the CAD and recording systems, partly on paper protocols and in separate regional databases. Typical gaps: no consistent incident types across stations, noisy audio with dialects and panic speech, recordings without labels, rules held only in the heads of senior call-takers, and strict access rights and retention limits.

Preparation steps: - Map the incident catalogue and harmonise the categories before any classifier is trained (PREP-019). - Export CAD data through connectors (PREP-005) and pseudonymise recordings and records (PREP-022). - Check legal basis and purpose for reusing calls (PREP-025). - Build a test set of real, expert-labelled calls per language and urgency class (PREP-018). - Write down escalation rules as explicit, reviewable rule sets (PREP-016).

Data work is the largest block, roughly 40-60% of total effort, because labelled emergency audio is scarce and legally restricted. Use Whisper-based tooling for first-pass transcripts, but have call-takers verify every label.

Implementation paths

Which path for whom

• public: A. Control rooms need certified, supported CAD-integrated products with EU or on-prem hosting and AI Act documentation; procurement rules favour this route.
• enterprise: B. Operators of private security or corporate control rooms can build on EU-region APIs, but live emergency traffic needs a sovereign or on-prem option.
• developer: C. Open ASR and translation stacks on HW3 keep sensitive call audio in-house and let vendors validate their own components.

Path A — Buy (default for authorities)

• Control-room vendors with AI modules: Eurofunk (AT), Frequentis (AT), Hexagon Safety & Infrastructure, Motorola Solutions (VESTA, Command Center; acquired Hyper for AI handling of non-emergency calls in 2026 [3]), Axon, plus Systel (FR) integrating Corti (DK) call analysis [4]. Eurofunk, Frequentis, Systel and Corti are EU-based.
• Choose A when: you already run a vendor CAD; certification, support and integration matter more than customisation. Demand EU hosting, on-prem option, AI Act conformity documentation and an exit path.

Path B — Build on cloud APIs

• Streaming ASR and translation from EU-region services (Azure AI Speech, Google Cloud Speech, Deepgram, Speechmatics (UK), Mistral models via EU hosting) plus an LLM for extraction with schema-constrained output. Emergency data on public cloud needs a national security assessment and often a sovereign cloud; many authorities will exclude this path for live emergency traffic and use it only for non-emergency lines.

Path C — Self-host (open source)

• ASR: Whisper large-v3 / faster-whisper, NVIDIA Parakeet/Canary; translation: NLLB-200, MADLAD, or an open LLM; extraction/routing: Qwen, Llama or Mistral open-weight models served with vLLM and structured outputs; telephony: Asterisk/FreeSWITCH, LiveKit or Pipecat for voice agents.
• Hardware: HW3 (one 48 GB+ GPU) handles several parallel streams; redundancy (second node, failover to manual operation) is mandatory. Effort: 6-12 months incl. integration and validation.

Path D — Custom training

Fine-tune ASR on real, consented and pseudonymised emergency audio (dialects, noise, panic speech, rare languages) and an incident classifier on historical CAD records. This is where most accuracy gains come from, but data access requires legal basis, ethics review and strict retention rules.

State of the art (2026)

• Streaming multilingual ASR and speech-to-speech translation are good on clean audio; performance drops on stressed, overlapping, dialect and low-resource-language speech, which is exactly the emergency setting. Test on your own recordings.
• LLMs extract incident fields well from transcripts, but can hallucinate addresses, merge facts from different turns or miss negation. Keep the raw transcript visible and require confirmation.
• Vendors are moving from transcription to "agents" that interpret context and trigger preset actions under supervision [3]; regulators and EENA stress human control [2][5].
• Do not treat voice-emotion or stress scoring as ground truth; it is error-prone and legally sensitive (see below).

Shared resources & combinations

• Same speech stack (asr, translation, streaming, tts) as CONV-002, CONV-007 (agent assist), SPEECH-002 (call analytics), SPEECH-003 and SPEECH-005 (dictation of police reports).
• Citizen-facing front end shared with CONV-011; clinical triage logic with CONV-010; audio event detection (gunshot, glass break) is a separate, more sensitive case (SPEECH-009).
• One GPU voice server (HW3) can serve training transcription, quality review and non-emergency bots.

Effort, cost & KPIs

• Path A: quarters, driven by CAD integration, procurement and acceptance tests. Path B/C: 6-12+ months with a dedicated team.
• Cost drivers: telephony integration, redundancy, validation, retraining of staff, 24/7 support.
• KPIs: time to answer, time to dispatch, fields captured correctly, share of calls needing interpreters served in under X seconds, under-triage rate (most critical, must not worsen), over-triage, non-emergency deflection rate, call-taker workload and satisfaction, word error rate by language.

People & change

Involve management and the department lead (control-room chief) from day one; they own the risk decision. Bring in IT and information security for integration, redundancy and the sovereign-hosting question, and the DPO early for the DPIA (Art. 35 GDPR: special categories, systematic processing of callers) and processor agreements (Art. 28). Call-takers are the key users: involve them in test-set labelling and acceptance tests.

Works council: yes. Call analytics and AI suggestions logged per call-taker are suited to monitor behaviour and performance, so co-determination under §87(1) no. 6 BetrVG applies (the BAG requires only objective suitability); §90(1) no. 3 requires timely information about AI-supported work processes, and §80(3) allows an AI expert. In public bodies the staff council (Personalrat) under BPersVG or state law takes this role. Agree a works or service agreement that bans individual performance scoring.

AI literacy: support staff skills with training on failure modes, over- and under-triage and automation bias, as Art. 4 AI Act asks. Pilot with one shift on non-emergency lines in shadow mode. Typical concerns: job loss, blame for AI errors, surveillance. Address them by keeping the human decision on urgency and dispatch, publishing the audit rules, and letting call-takers override at any time.

See GUIDE-004, GUIDE-005 and GUIDE-008.

Risks, regulation & compliance

• EU AI Act: Annex III point 5(d) lists AI systems intended to evaluate and classify emergency calls and to dispatch or establish priority in dispatching emergency first response services (police, fire, medical) [5]. Treat as high-risk: risk management, data governance, logging, human oversight, accuracy/robustness testing, registration, and deployer duties (Art. 26, possibly a fundamental-rights impact assessment under Art. 27 for public bodies). Annex III obligations apply from 2 Dec 2027 under the Digital Omnibus on AI (Reg. (EU) 2026/1744, in force since 27 Jul 2026). A pure information bot for non-emergency lines that neither classifies emergencies nor sets dispatch priority is typically limited-risk (Art. 50 disclosure that the caller speaks to an AI).
• Art. 5 prohibitions to avoid: no social scoring of callers; no real-time remote biometric identification; no inferring emotions of people in workplace or education settings (affects call-taker monitoring); no predictive profiling of individuals based solely on personality traits. Keep voice biometrics and caller profiling out of scope.
• GDPR / LED: calls contain special-category data (health), third-party data and sometimes children's data. Public authorities act under national police or rescue-service laws, with the Law Enforcement Directive for police processing. Needs DPIA, strict purpose limitation, short retention, access control, and EU-only processing.
• Safety & resilience: the system must fail safe (fall back to the unaided call-taker), never delay answering, and be covered by incident reporting; EU electronic communications rules require reliable 112 access and caller location.
• Mitigations: assist-only default, conservative escalation, bias testing across languages and accents, shadow-mode pilots, regular audit of under-triage cases, staff training (AI literacy, Art. 4).

Getting started

1. Map call types and volumes; separate the non-emergency stream from true emergencies.
2. Run a shadow-mode pilot (no live influence) of transcription + translation on recorded, lawfully usable calls; measure WER by language.
3. Define escalation rules and fail-safe behaviour with call-takers, medical and legal advisers.
4. Perform AI Act classification, DPIA and (if applicable) fundamental-rights impact assessment before any live use.
5. Go live first with call-taker assist or non-emergency voicebot, then evaluate under-triage before widening scope.

Sources

1. DFKI — Multilingual digital emergency call assistant (NotAs) — https://www.dfki.de/en/web/news/a-multilingual-digital-emergency-call-assistant-for-emergency-call-centers-research-project-notas-la
2. EENA — AI Special Project — https://eena.org/ai-special-project/
3. Urgent Communications — Motorola Solutions buys Hyper to use AI for non-emergency calls — https://urgentcomm.com/ai-analytics/motorola-solutions-buys-hyper-to-use-ai-for-non-emergency-calls
4. Systel / Corti partnership (link no longer available)
5. European Commission AI Act Service Desk — Annex III — https://ai-act-service-desk.ec.europa.eu/en/ai-act/annex-3
6. EENA — How the AI Act will shape the future of emergency services — https://eena.org/blog/how-the-ai-act-will-shape-the-future-of-emergency-services/
7. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj