SIRV / Operational AI / Incident reporting

Can AI improve incident reporting? Capture, context and quality

The objective is not simply to produce better-written reports. It is to make reporting easier, improve the information available for decisions and preserve the original account.

SIRV | Operational analysis

Artificial intelligence is exceptionally good at producing fluent text. That makes incident reporting an obvious area in which to consider using it. A security officer describes an event, AI writes up the account, and the organisation gets a more polished report with less effort.

But is a better-written report necessarily a better incident report? The value of an incident report depends on the quality of the information it contains. A well-written account can still be incomplete, misleading or wrong. More importantly, AI can introduce details or interpretations that the person reporting the incident never intended to provide.

There are three areas where AI could potentially improve incident reporting: making reports easier to capture, bringing in relevant operational context, and identifying missing or unclear information. Throughout all three, organisations need to preserve provenance: who supplied the information, where it came from and what was subsequently established.

1. Capture: making incidents easier to report

Before considering how AI might improve the quality of an incident report, it is worth asking why incidents sometimes go unreported, are reported late or arrive with insufficient information. Reporting is partly a human behaviour problem. People must recognise that something should be reported, decide to report it and find the time and means to do so.

Stanford researcher BJ Fogg's behaviour model provides a useful way of examining the problem. It describes behaviour as depending on three elements coming together: motivation, ability and a prompt.

In an operational setting, motivation might be influenced by whether the person believes reporting will make a difference. Ability depends partly on the effort required, while the prompt might be an instruction from a supervisor, an event that requires reporting or a reminder at the appropriate time. The model also describes how motivation and ability interact. When a task becomes easier, less motivation may be needed to complete it.

This suggests a useful starting point for AI-assisted incident reporting: reduce the effort involved in providing information, rather than simply adding more reminders.

For example, an officer might describe an incident verbally rather than completing a lengthy form. A conversational interface could ask for essential information using ordinary language and help the officer complete the relevant fields. It could also identify which questions apply to the particular incident type, avoiding unnecessary questions.

However, voice and conversational reporting introduce their own considerations. Speech recognition can mishear names, locations or times. Reporters need to see or hear what has been captured and be able to correct errors before their account is submitted.

AI could potentially help close the feedback loop as well. A reporter who submits information but never hears what happened afterwards may question whether reporting was worthwhile. Where appropriate, a system could help communicate that a report has been received, assigned for review or followed up.

These are potential improvements, not guaranteed outcomes. Whether AI increases reporting rates or improves reporting timeliness would need to be tested. Reporting must also remain possible when AI is unavailable, and urgent operational action should never be delayed by a lengthy reporting conversation.

2. Context: what else does the organisation know?

Consider a fictional incident report submitted by a security officer:

“A man was seen going through Gate 3 behind Sarah around 10:00 a.m.”

The officer is passing on information provided by another member of staff rather than describing something they witnessed personally. This is a useful starting point, but it leaves several questions unanswered. Who originally observed the event? Was the time approximate? Was the man carrying an access card? Did he enter the building? Was he an authorised visitor?

Some answers may be available from the person making the report or the original observer. Others might be found in operational systems. Depending on the organisation and its access permissions, relevant information could include CCTV covering Gate 3, access-control events, visitor records, previous incident reports and staff rosters.

An AI-assisted workflow could help an investigator identify which sources may contain relevant information and retrieve the records the investigator is authorised to access. Instead of manually searching several systems, the investigator might receive a list of potentially relevant events, with source references and timestamps.

The important distinction is between finding relevant information and establishing what happened. Suppose the access-control system shows that Sarah's credential was used at Gate 3 at 10:01. That may be relevant to the reported timing, but it does not establish whether someone followed her through the gate. The CCTV might help answer that question, subject to the coverage and quality of the footage.

Similarly, a visitor record may show that somebody was expected on site, but it does not necessarily establish that the person seen at Gate 3 was that visitor. AI can help bring these records together, identify possible connections and make gaps visible. It should not silently convert those possible connections into confirmed facts.

This contextual work may begin after the original report has already been submitted. It should not be necessary to complete an investigation before recording an initial observation. New information can be added as it becomes available, while remaining distinguishable from the original account.

Combining information from different systems also creates data protection responsibilities. CCTV, access-control records, staff rosters and incident reports may contain personal data. Organisations must consider the lawful purpose for using that information, whether combining the sources is necessary and proportionate, who should have access, and how long the resulting records should be retained. Access to a system does not, by itself, establish that every use of its information is appropriate.

The Information Commissioner's Office guidance on AI and data protection provides a starting point for considering lawfulness, accuracy, data minimisation and accountability. Requirements must be applied to the particular workflow and checked against current guidance.

3. Quality: identifying missing information without changing the account

It is tempting to judge an AI-assisted incident reporting system by how well it can rewrite a rough account into polished prose. This can be useful for some administrative documents, but incident reporting requires particular care.

Return to the Gate 3 example. Imagine that an AI system is questioning the original observer and asks:

AI: “Did the man push past Sarah?”

Observer: “Yes, I think so.”

AI-written record: “The man pushed past Sarah.”

This fictional exchange illustrates two distinct risks. First, the AI asks a leading question that introduces a possibility the observer had not previously described. The response may then be influenced by the way the question was asked. Secondly, the AI-generated wording removes the observer's uncertainty and presents the event as established fact.

The example is illustrative rather than a finding from a controlled study. It shows why conversational reporting systems need to be tested for suggestive questions, changes in meaning and loss of uncertainty when responses are recorded or summarised.

NIST's Generative AI Profile identifies risks associated with inaccurate or fabricated AI outputs. In incident reporting, the concern is not limited to obvious invention. Small changes in wording can alter the apparent meaning of an observation.

A more controlled approach is to use AI to identify information problems rather than supply the missing information:

AI: “The actions taken field has not been completed. Would you mind completing it?”

The reporter then provides the information in their own words. Other useful prompts might ask when an event happened, whether a time was approximate, who was informed or whether the reporter directly observed something or was told about it by another person.

Questions should be neutral, relevant to the incident type and tested for leading language. The person reporting the incident should be able to say that they do not know, did not see something or have nothing further to add.

That boundary does not exclude spelling assistance, transcription or creating a separate working summary. It means those operations should not quietly replace the original account. The reporter or reviewer must be able to distinguish original wording from any subsequent transformation.

4. Provenance: preserving who said what

Incident reports often develop after initial submission. A supervisor asks for clarification, CCTV is reviewed, access-control events are checked and an investigator reaches a conclusion. That development is normal. The problem arises when the resulting information is merged into a single account without distinguishing its source.

A useful reporting system should preserve the original submission where appropriate and record significant additions, corrections, evidence and conclusions separately. The following fictional example demonstrates how the Gate 3 report might develop.

All events and records in this table are fictional and provided for illustration.

Notice that the access-control event does not overwrite the reported time, and the CCTV interpretation does not become part of the original observer's account. Nor should a system automatically convert the security officer's second-hand report into a first-hand observation.

Preserving the original account does not mean leaving inaccuracies uncorrected or continuing to present disputed information as established fact. An organisation may need to retain the history of what was originally reported while ensuring that its current records clearly identify subsequent corrections, challenges and findings.

For example, if the observer later establishes that the incident occurred at Gate 2 rather than Gate 3, the organisation should correct the operational information used for subsequent decisions. Where justified, it may also retain the original submission with a clear record of the correction. The appropriate approach depends on the purpose of the information, applicable data protection requirements and the organisation's retention policies.

The objective is to preserve provenance without allowing an incorrect historical statement to mislead someone using the record later. The ICO's guidance on accuracy explains the importance of distinguishing facts, opinions, information sources and records of mistakes. Keeping a historical record may be appropriate where its status is clear and retention is justified, but inaccurate personal information must still be addressed.

This distinction is particularly important when information may affect employment decisions, investigations, contractual disputes or potential criminal proceedings. AI should help people understand the evidence. It should not obscure the difference between an observation, a second-hand account, a clarification, a system event and a human conclusion.

5. How would you measure whether AI actually improves incident reporting?

Before introducing AI into incident reporting, an organisation should define what improvement would look like. Faster report completion may be beneficial, but it is not sufficient evidence that reporting has improved.

A more useful evaluation would compare a defined reporting process before and after introducing AI, using similar incident types and reviewing the resulting information.

The first four measures may demonstrate operational benefits. The last two are particularly important safeguards. A faster reporting process that introduces unsupported assertions would be a poor trade-off.

Testing should also examine failures. What happens when the reporter gives contradictory times, speaks unclearly, uses an unfamiliar location name, refuses to answer a question or describes an incident outside expected reporting categories?

An appropriate test might begin with one bounded incident type. The organisation could compare the existing reporting method with an AI-assisted approach, assess resulting reports independently and identify which improvements are genuine.

Ten questions to ask before adopting AI-assisted incident reporting

Use this checklist to evaluate a proposed workflow.

• Original account: Can the system preserve and retrieve the original account, identify subsequent changes and ensure corrections are reflected in information used for decisions?
• Attribution: Are additions attributed to the person who supplied them?
• Neutral questions: Has the AI been tested for leading or suggestive questions?
• Uncertainty: Can reporters say they do not know without being pushed towards an answer?
• Information requirements: Does the workflow use requirements appropriate to the incident type?
• Evidence sources: Are external records identified with their source and timestamp?
• Access control: Can the workflow retrieve only information it is authorised to use for that purpose?
• Human review: Can a reviewer challenge, correct or reject AI-generated interpretations?
• Escalation: Can urgent incidents be escalated without waiting for AI questioning to finish?
• Measurable outcomes: Has the organisation defined useful benefits and unacceptable failure conditions?

A workflow that cannot satisfy the questions about original wording, neutrality, uncertainty and provenance needs further design and testing before it is suitable for consequential incident reporting.

6. Incident reporting is part of a larger operational process

Incident reporting does not end when somebody presses Submit. Incoming information may need to be classified, prioritised, investigated and connected to actions or later lessons. These are related but distinct tasks.

An AI-assisted reporting interface might help someone provide a clearer initial account. AI incident triage addresses what happens when incoming reports need to be assessed and routed. An unauthorised access investigation may require an investigator to bring together access-control events, CCTV, visitor information and previous incidents. A post-incident review examines what should happen afterwards and whether actions have been completed.

For guidance on essential content of an original report, see How to write a security incident report.

Organisations therefore have an opportunity to improve more than the document produced at the beginning. They can reduce the effort involved in finding and using relevant information while preserving the evidence needed for accountable decisions.

SIRV AI focuses on controlled operational workflows for safety, security and resilience teams. Its workflow families include knowledge access, document evaluation, intake triage, operational picture building and retained learning.

These capabilities are relevant to several stages of incident management, particularly assessing incoming information and bringing together relevant operational records. Conversational incident capture and the questioning techniques discussed here are potential applications requiring their own design, testing and validation. They should not be assumed to be established SIRV AI functionality.

For organisations considering AI-assisted incident reporting, the starting point should be the actual work: where reporting is difficult, what information reviewers repeatedly have to clarify, which sources they need to consult and where human judgement must be retained.

The objective is not to produce a more convincing account. It is to make reporting easier, improve the information available to those who need to act, and preserve a clear distinction between what was reported, what was subsequently found and what remains uncertain.