What belongs in an AI incident and near-miss process?

An AI incident and near-miss process needs a clear route from a concern to an accepted responsibility. Let people report what they observed, preserve the relevant evidence safely, and give someone authority to decide what happens next. Include caught errors and uncertain exposure. The employee raising a concern should not have to establish the cause, classify every harm or find the right executive first.

For an operations or risk owner, the practical test is what happens after someone says, “This draft contains something it shouldn't.” Does a responsible person acknowledge it, assess whether the problem is continuing and return with a decision? A form that collects the concern without completing that handoff leaves the difficult work with the reporter.

Accept the report before demanding a final classification

Define the kinds of concern staff should raise, using examples from their work:

• An affected result. An incorrect decision has reached a customer.
• Unexpected information. Material appears where it does not belong.
• An unauthorized action. The system acts outside the agreed authority.
• A caught harmful result. Someone prevents the result from being used.

Tell people which urgent route to use when someone may already be affected.

The OECD's May 2024 definitions distinguish actual harm from potential harm and include near misses within AI hazards. These are shared definitions intended to help jurisdictions and organizations describe events consistently. They do not settle every company's reporting threshold.

Keep that distinction useful without making it an entrance exam. An employee may know that an address is wrong while being unable to tell whether anyone else received it. Accept the observation and record the uncertainty. The receiving owner can revise the classification as evidence arrives.

In their 2024 account of editing the AI Incident Database, Kevin Paeth and colleagues describe uncertainty about causes, affected people and system details as a recurring reporting problem. Their conclusions come from incident-cataloging practice, rather than a trial of workplace reporting procedures. The implication for intake is practical: preserve what is known and what still needs investigation instead of filling the gaps with a confident explanation.

Preserve a small, usable first account

Suppose Jamie Lee coordinates deliveries for an equipment hire company. An approved assistant drafts a delivery confirmation from the rental order and dispatch record. During checking, Jamie notices another customer's delivery address in the draft. This message has not been sent. Jamie does not know why the address appeared or whether previous confirmations contain the same problem.

That is enough to raise a concern. It is not enough to conclude that the entire issue was prevented, that information was disclosed externally or that a particular technical defect caused it.

The NIST generative AI risk-management profile, published in July 2024 for voluntary use, suggests minimum reporting information and mechanisms for sharing information and feedback. It also recommends recording reported errors and near misses. Use that guidance to design an initial account staff can actually supply, with authorized investigators adding detail later.

For Jamie, the first record could contain:

• The work and time. Which delivery confirmation was being prepared, when the draft appeared and when Jamie noticed the problem.
• The observed difference. The delivery address in the draft does not match the rental order and matches another customer's record.
• The known consequence. This draft was not sent. Whether other messages were affected is unknown.
• The action already taken. Jamie held this message and contacted the designated incident route.
• The evidence location and contact. Where an authorized reviewer can find the original draft and permitted source records, and how to ask Jamie a follow-up question.

Keep the original evidence under the organization's access and retention rules. Provide a safe way to submit or reference sensitive material, with a restricted destination for the fuller record. A general team channel may be suitable for asking where to report; it may be unsuitable for pasting a customer conversation or another customer's details.

Do not ask Jamie to reproduce the problem by trying more customer records, share credentials or investigate beyond the role's authority. Preserve the observation without creating another exposure. The receiving team should explain what additional evidence it needs and how to supply it safely.

Route by possible consequence and what remains unknown

Choose a person or team to accept incoming concerns and coordinate the next decision. Connect that route to existing security, privacy, safety, service and customer-correction responsibilities. Staff should be able to use the known urgent route without waiting for an AI committee meeting or a weekly enablement clinic.

The following distinctions can guide the equipment hire company's intake design. Confirm them against its actual authority and emergency procedures.

A concern can move between these routes. If Jamie later finds a sent confirmation with the same mismatch, add that evidence to the connected record and reassess urgency. Do not close the original concern merely because the first draft was unsent.

A September 2026 Reddit discussion about reporting AI concerns illustrates the handoff problem. The author described being redirected while trying to establish who should receive a report. Their underlying allegations were unverified, and a reply challenged how an event had been characterized. Those limits matter. A reporting route needs to accept a concern for assessment without promising that every allegation will be confirmed.

For the equipment hire company, that means naming an accepting owner, rather than giving Jamie a list of departments to try. If ownership transfers, the first recipient should confirm that the next one has accepted it. Keep related service, security and customer actions connected so each team can see who owns its part.

Separate containment from notification and explanation

Claire Bennett, the service owner, needs to decide how delivery confirmations can continue while the concern is assessed. Depending on the findings and available authority, that may mean holding the affected drafting task or using an approved manual preparation route. Jamie's decision to hold one message does not establish who can pause a wider service.

Before an incident, identify who can make each decision:

• Operating containment. Who can hold the affected task or authorize a supported alternative?
• Exposure and correction. Who establishes what information or recipients were affected and arranges the appropriate correction?
• Notification. Who determines which communications are required and approves them?

These decisions can proceed while the technical cause remains unresolved. Record the decision, its owner and its evidence.

In an October 2026 LinkedIn post, program manager Suraj Varma uses a hypothetical unauthorized supplier payment blocked before submission. He asks whether an organization records only the successful block or also investigates the attempted action. It is a practitioner's thought experiment, not a reported payment incident. The question transfers to Jamie's draft: a successful check is evidence about that check, while the condition that produced the draft still needs an owner.

Keep an internal concern, a supplier support request and a required external notification distinguishable. A supplier ticket does not establish that an internal response owner has accepted the issue. Equally, publishing a general account is not a substitute for an authorized notification. Have the relevant specialists maintain applicable recipients and timing requirements; do not ask frontline staff to derive them from a generic AI checklist.

Once the report is accepted, the approval-accountability guide explains how to assign corrections and recurring repairs to people who control the relevant conditions. Keep that investigation connected to this record.

Return a useful answer to the person who reported

The first reply should let Jamie act without searching for another recipient. Include:

• Acceptance and owner. What concern has been accepted, and who coordinates the response.
• Immediate instruction. What Jamie should do with the held confirmation.
• Next contact. When to expect an update, appropriate to urgency, and the alternative if that route is unavailable.

If the investigation is still open at the update point, say what remains unresolved. A ticket changing teams does not establish completion.

Reporting should be encouraged without turning the intake exchange into a public judgment about the employee. Explain who can see the record and the purpose of each later review. Do not promise complete anonymity, immunity from consequences or unrestricted confidentiality unless the organization can actually provide it. Necessary conduct, security and personnel processes retain their proper responsibilities.

At closure, return the decision and its scope. For example, Claire might be able to confirm that Jamie's held message was corrected while an authorized investigation into earlier confirmations remains open. Those are separate states. An employee should be able to add new information or question an inaccurate account without starting the whole route again.

Test the process with a permitted practice case before depending on it:

1. Submit the uncertain observation. Give the receiving team the unsent-draft facts without supplying a prewritten cause or severity label.
2. Check the handoff. Confirm who accepts the report, who can authorize containment and how an unavailable owner is covered.
3. Read the reply as the employee. Verify that it explains the immediate action, next update and route for further evidence.
4. Check the learning handoff. Separate unresolved investigation material from the account cleared for wider sharing.

Use the failure-sharing guide for that later learning record. A useful rehearsal result is finding and repairing an unanswered handoff. The number of forms submitted alone cannot show that concerns reached someone able to act.

Q&A

Must employees know what caused an AI problem before reporting it?

No. An employee should be able to report an observed problem, when it appeared, the affected work and what remains unknown. For an incorrect delivery-confirmation draft, preserve the mismatch and whether the message was sent. The receiving owner should arrange investigation rather than require the employee to diagnose a system outside their authority. The initial-account checklist shows the useful starting information.

Should a caught error still be reported?

Report a caught AI error when it reveals a plausible harmful condition under the organization's reporting rules. Say which consequence was prevented and avoid assuming every related risk was prevented too. Holding one confirmation does not establish that earlier messages were correct. Ask the receiving owner to assess whether the condition could affect other work, using the routing distinctions.

Can we promise that reporting will be anonymous and consequence-free?

Only promise protections the organization can provide through its actual policies and processes. Explain the audience, how follow-up questions work and the boundaries around necessary investigation or conduct review. Encouraging prompt, factual reporting does not require publishing employee names or deciding blame during intake. Check the proposed assurance with the people responsible for those processes before using it in staff guidance.

Can an existing helpdesk handle AI incidents and near misses?

Yes, if it can accept uncertain concerns, protect sensitive evidence, reach the appropriate urgent response owner and give the reporter a useful update. The helpdesk's name or ticket count does not establish those capabilities. Rehearse a concrete case with security, information and service owners, then repair any handoff that leaves the employee searching for the next recipient. Keep ordinary support and urgent incident responsibilities clear within that route.