When we started looking at where AI in emergency response could add value at AURA, we were not looking for somewhere to replace human judgment. We were looking for places where technology could give our people more time to use that judgment on live incidents.
That distinction is particularly important when you think about AI in emergency response. A controller handling a live incident is making decisions that affect people who may be in danger, and I don’t think AI should take them out of that process. Where it can help is by reducing the other work competing for their attention.
AI in emergency response means using software to handle supporting work around an incident while trained controllers keep every operational decision. At AURA, two AI agents do this: one suggests an incident type and category during a response, and the other drafts the incident report afterwards. This kind of AI incident reporting is reviewed by a controller, who decides whether to accept or reject each suggestion. Between June and August 2026, controllers accepted 92.2% of the incident-report suggestions where a decision had been recorded.
For us, one of the clearest opportunities was incident reporting.
AURA connects digital alerts to coordinated physical emergency response. Alerts can enter our platform through partner systems, apps, monitoring systems and connected devices. From there, our technology and 24-hour control rooms coordinate the incident, determine the appropriate response and dispatch suitable security or medical responders.
The work does not stop when the response ends, though. Controllers still need to gather information from calls, transcripts, responder updates and the event timeline, work out what happened, document the actions taken and prepare an accurate incident report. We estimated that this could take around 25 to 30 minutes per report.
The reports themselves are necessary, but every minute a controller spends piecing together an incident that has already happened is a minute they are not available for the next live emergency.
That gave us a fairly specific question to explore: could AI in emergency response take on some of that administrative work while operational decisions stayed firmly in human hands?
We introduced two specialised AI agents into the existing AURA workflow.
The first is a classification agent. During an active response, it can suggest an incident type and category based on the evidence available at that point. The second is an incident-report agent. Once the relevant evidence has been gathered, it uses the incident timeline, operational records and transcripts to create a structured draft report.
In both cases, the agent makes a suggestion and does not own the workflow. AURA retains control of the data, operational triggers, audit records and the application of any approved output, and controllers review each suggestion before deciding whether to accept or reject it.
We designed it that way deliberately. In an environment like ours, I think there is a useful distinction between using AI to support a decision and allowing AI to own the decision, and we were interested in the first. That is the idea behind human-in-the-loop AI: a person reviews each suggestion before it is applied. Voluntary guidance such as the NIST AI Risk Management Framework gives organisations a structure for managing the risks of AI systems.
Before introducing the agents into the live workflow, we ran them against real incidents for approximately six weeks without applying their outputs. Generated reports could be reviewed alongside the reports controllers had written, which allowed us to assess whether they were accurate, useful and appropriately structured before anyone was expected to rely on them. We were prepared to pay to observe the technology before asking operations to trust it.
That was valuable because testing AI on production evidence tells you things a clean demonstration environment does not. By the time we moved further into production, we were no longer evaluating the idea of an AI-generated report. We were evaluating what the system actually produced from real emergency-response data, with human review built in from the start.
One of the most useful lessons came from something that initially looked quite small: when the report was generated.
Our first approach used response lifecycle events as the trigger. That made sense technically, but it didn’t always match how controllers worked. They often kept gathering important information after those lifecycle events had taken place, which meant the agent could be asked to create an incident report while part of the story was still missing.
So we changed the workflow. Report generation now happens when a controller requests it: the controller decides when the evidence is complete enough, asks the agent to generate the report and then reviews the suggestion. Classification stayed available earlier in the incident because it supports a different decision at a different point in the response.
When people talk about introducing AI in emergency response or other operational environments, a lot of attention naturally goes to the model, but model performance is only one part of the problem. Where the AI enters the workflow, what information it receives, when it is triggered and who controls the next action can matter just as much. Emergency response technology has to fit the way the operation actually works.
Between June and August 2026, controllers accepted 40,508 incident-report suggestions and rejected 3,408. Of the suggestions where a decision had been recorded, 92% were accepted. Another 11,244 suggestions remained unresolved within the analysis window.
The acceptance rate was useful, but the rejections gave us a second source of information, because every rejected report required a reason. Across the 3,408 rejected reports:
That turned controller judgment into structured data our engineering team could use. Instead of simply knowing that a report had been rejected, we could see why, and feed that back into prompt design, evidence assembly and the workflow itself.
I think that feedback loop is an important part of putting AI into production. A rejected report should teach the system, and the people building it, something.
There was also an obvious economic question: what did the system cost to run, and was it creating enough value to justify that cost?
In August 2026, OpenAI transcription and inference cost approximately $2,520. During the same month, 15,435 callouts had an accepted report.
What we did not yet have was a direct measurement of how much time each accepted report returned to controllers. Rather than present estimated time savings as fact, we modelled several scenarios using a blended controller cost of $6.28 per hour.
These figures are not measured cash savings, and I would not describe them as a complete return-on-investment calculation. They are estimates of the capacity the system could return to the operation.
In an always-on emergency service, that capacity has value beyond the labour cost attached to a task. If an AI-generated report returns five or ten minutes to a controller, that time can go towards the next live incident. For us, that is the more important measure.
This project did not prove that AI should manage emergency response autonomously, and that was never the objective. What it showed was that AI agents can create useful capacity inside a sensitive production workflow while human judgment and the existing operational controls stay in place.
There are a few principles I would carry into future AI use cases:
Conversations about AI tend to focus on the biggest decision a model could possibly make. I am increasingly interested in a different question: what work can AI take on so that people have more capacity for the decisions we actually need them to make?
In our case, that meant helping controllers pull together evidence and produce incident reports faster, while the operational judgment stayed with them. It is a relatively contained use of AI in emergency response, but across thousands of emergency callouts each month, those minutes add up to more controller capacity for active emergencies, which is the outcome we care about.
.webp){kind=icon}
.webp)
.svg)
.svg)
.svg)
.svg)
.svg)
.webp)
.webp)
.webp)