How to create an AI incident procedure

Your AI assistant just told a customer the wrong return policy — and the customer already acted on it. Or your automated credit-scoring model flagged a perfectly valid client as high-risk, and no one caught it for three days. These are not hypothetical edge cases anymore; they are the kind of incidents that land in real inboxes every week. This article gives you a concrete, step-by-step AI incident procedure — with defined roles, immediate actions, and a checklist — that your organization can adapt and use right now.

Why most organizations are unprepared for AI incidents

Companies invest heavily in deploying AI tools — chatbots, recommendation engines, document summarizers, automated workflows — but rarely define what happens when those tools go wrong. The result is improvised firefighting: the support team blames the tech team, the tech team blames the model vendor, and no one has a clear mandate to protect the customer or document the event.

This is a governance gap. And as regulators across the EU (via the AI Act), the US, and other jurisdictions increasingly require organizations to demonstrate oversight of automated systems, that gap is becoming a liability — not just an operational inconvenience.

An AI incident procedure closes that gap. It does not need to be a 50-page policy document. It needs to be clear enough that any employee, on a bad day, can follow it.

What counts as an AI incident?

Before you can respond to an incident, your team needs to agree on what one looks like. A useful working definition:

An AI incident is any event in which an AI system produces an output — a decision, recommendation, piece of content, or action — that causes or risks causing harm to a customer, employee, third party, or the organization itself.

Practical examples that fit this definition:

• A customer service chatbot quotes the wrong price, and a customer demands that price be honored.
• An AI document classifier misfiled a sensitive contract, causing it to be shared with the wrong party.
• An automated invoice-matching tool approved a duplicate payment because it misread a supplier name.
• An AI-generated summary of a legal clause omitted a critical exception, which a manager then relied on.
• A recommendation algorithm systematically excluded a protected demographic group from seeing a promotion.

Not every AI glitch is an incident. A spelling error in an AI-drafted email that a human catches before sending is a quality issue, not an incident. The threshold is actual or plausible harm — to people, to data, to compliance, or to trust.

The four severity levels you need to define

Not all incidents are equal. A tiered severity model lets your team allocate the right level of response without over-escalating minor issues or under-reacting to serious ones.

Level	Label	Description	Example
1	Critical	Immediate harm or legal exposure	AI-generated advice caused a customer financial loss; potential GDPR breach
2	High	Significant business or reputational risk	Wrong pricing quoted to 200+ customers via automated email
3	Medium	Operational disruption, limited external impact	AI workflow routed 50 orders to wrong fulfillment center
4	Low	Minor error, caught internally, no external impact	AI draft contained factual error, corrected before sending

Define these levels in your procedure document. Teams should be able to assign a severity level within the first 15 minutes of detecting an issue.

Who owns what: the roles you need in place

An AI incident procedure only works if specific people have specific responsibilities. These do not have to be full-time roles — in smaller organizations, one person can hold more than one — but the functions must be named.

AI Incident Coordinator (AIC) The person who activates the procedure, assigns tasks, and owns communication. In a small company, this is often the IT manager or operations lead. In a larger organization, it may be a dedicated AI governance officer.

Technical Investigator The person (or team) who digs into logs, model outputs, and system behavior to understand what actually happened. This is typically your in-house developer, data engineer, or the technical contact at your AI vendor.

Business Owner The manager responsible for the process or product where the AI operates. They assess business impact and approve remediation steps that affect operations.

Communications Lead The person who handles customer-facing or external communication. In regulated industries (finance, healthcare), this person also coordinates with legal and compliance.

Data Protection Officer (if applicable) Required under GDPR if the incident involves personal data. Must be looped in immediately for Level 1 and Level 2 incidents.

Step-by-step: the AI incident procedure

Step 1 — Detect and report (0–30 minutes)

Anyone in the organization can be the first to spot an AI incident — a customer service agent, a manager reviewing output, a developer noticing anomalous logs. The procedure must make it easy and expected to report it.

• Provide a single, simple reporting channel: a dedicated Slack channel, a form, or an email address. Remove friction.
• The first reporter documents: what they saw, when, in which system, and what the AI output was (screenshot or copy-paste).
• The report goes immediately to the AI Incident Coordinator.

Do not wait until you are certain it is a real incident. Report first, verify second.

Step 2 — Triage and classify (30–60 minutes)

The AI Incident Coordinator reviews the report and:

1. Assigns a severity level (1–4) based on your defined criteria.
2. Activates the relevant roles (Technical Investigator, Business Owner, Communications Lead, DPO if needed).
3. Opens an incident log — a shared document or ticket where all findings and decisions will be recorded.
4. Makes the first key decision: Does the AI system need to be paused or restricted immediately?

For a Level 1 or 2 incident, the default answer should be: yes, restrict or pause the system until you understand what happened. An AI tool that is actively producing harmful outputs should not keep running while you investigate.

Step 3 — Contain (first 2–4 hours)

Containment means stopping the bleeding — preventing the AI system from causing further harm while the investigation runs.

• If a chatbot gave wrong information: take it offline or switch it to a human-handoff mode.
• If an automated workflow approved bad transactions: freeze pending approvals and flag them for manual review.
• If personal data was exposed: follow your existing data breach procedure in parallel.
• Notify affected customers or internal teams as needed — factually, without speculating on cause.

Containment does not require a full explanation of what went wrong. It requires a decision to stop the harm.

Step 4 — Investigate (2–48 hours, depending on severity)

The Technical Investigator leads this phase. The goal is to answer four questions:

1. What did the AI system actually do? (Reconstruct the exact output and the context that produced it.)
2. Why did it do it? (Was it a prompt issue, training data issue, integration error, edge case, or model hallucination?)
3. How many people or transactions were affected?
4. Is this a one-time anomaly or a systemic pattern?

Document every finding in the incident log. Avoid drawing conclusions before the investigation is complete — premature explanations often turn out to be wrong and create a second communications problem.

Step 5 — Communicate (timed to severity)

Communication timing depends on severity and regulatory obligations:

• Level 1: External communication (to customers, regulators) within 24–72 hours, depending on your jurisdiction and industry.
• Level 2: Internal stakeholders within 4 hours; external communication if customers were directly affected.
• Level 3–4: Internal communication only, documented in the incident log.

For external communication, the message should include: what happened, what you have done to stop it, and what affected parties should do (if anything). Do not speculate about cause in external messages until the investigation is complete.

Under the EU AI Act (for high-risk AI systems) and GDPR (for personal data incidents), there are specific notification obligations. Know which apply to your systems before you need them.

Step 6 — Remediate (days to weeks)

Remediation is fixing the root cause — not just patching the symptom. Based on the investigation findings:

• If the issue was a prompt or instruction set: update, test, and version-control the new prompt.
• If the issue was a model behavior: work with your vendor on a fix, or add a human review layer for that specific output type.
• If the issue was an integration bug: fix and regression-test the connector.
• If the issue was a process gap (no human reviewed the output before it reached the customer): redesign the workflow to add that check.

Do not reactivate the AI system until remediation has been tested. Document what was changed and why.

Step 7 — Review and close (within 2 weeks of resolution)

Every incident — even low-severity ones — should end with a structured review:

• What happened and why (final version).
• What worked in the response and what did not.
• What changes were made to the system, process, or procedure.
• What monitoring or safeguards have been added to catch this type of issue earlier next time.

This review becomes the foundation of your AI incident log, which over time becomes one of the most valuable governance documents your organization has — a factual record of how your AI systems have behaved and how you have responded.

AI incident procedure checklist

Use this checklist to verify your procedure is complete before you need it.

Preparation (before any incident)

• AI incident severity levels defined and documented
• AI Incident Coordinator named
• Technical Investigator named
• Business Owner named per AI system
• Communications Lead named
• DPO looped in (if personal data is involved in any AI system)
• Reporting channel created and communicated to all staff
• Incident log template ready to use
• List of AI systems in use, with risk classification
• Regulatory notification obligations documented per system

During an incident

• Incident reported and timestamped
• Severity level assigned within 30 minutes
• Relevant roles activated
• Incident log opened
• Containment decision made
• Investigation questions assigned
• Communication timed and drafted
• Remediation tracked in incident log

After an incident

• Root cause documented
• System changes tested before reactivation
• Review meeting held within 2 weeks
• Lessons learned added to incident log
• Procedure updated if gaps were found

Frequently asked questions

Do we need a separate AI incident procedure, or can we extend our existing IT incident process? You can extend your IT process, but you will need to add AI-specific elements: severity definitions that account for model behavior (not just system downtime), investigation questions specific to AI output quality, and communication language that does not assume the issue is a technical bug (it may be a data or design issue). A pure IT incident template typically does not cover these.

What if the AI system is a third-party tool we do not control, like a vendor-provided chatbot? You are still responsible for how that tool affects your customers and your compliance obligations. Your procedure should include: a contact path to the vendor's incident response team, clarity on what data they hold, and a decision threshold for suspending the tool while the vendor investigates. Your contract with the vendor should also specify their incident response obligations — check this now, before an incident.

How do we handle an AI incident that also involves a data breach? Run both procedures in parallel. Assign a single coordinator who owns the link between them, so the two workstreams do not contradict each other in their customer communications. The GDPR 72-hour notification clock for data breaches starts from when you become aware — do not let the AI investigation delay the data breach notification.

How often should we test or review our AI incident procedure? At a minimum, review it annually and after every Level 1 or Level 2 incident. Run a tabletop exercise once a year: present a fictional AI incident scenario to your team and walk through the procedure out loud. You will find gaps in about 20 minutes that would otherwise only surface during a real crisis.

What documentation do regulators typically expect? Under the EU AI Act, for high-risk AI systems, you are expected to maintain logs of system operation, document serious incidents, and report them to national authorities. Even for systems that do not fall under high-risk classification, having a documented procedure and incident log demonstrates the kind of human oversight the regulation calls for. The incident log you build over time is your evidence of responsible governance.

Building this into a broader AI governance framework

An AI incident procedure does not stand alone. It is one component of a broader governance structure that also includes: an inventory of which AI systems your organization uses and how they are classified, a policy on acceptable use and human oversight, and a process for reviewing new AI tools before they go live. Think of the incident procedure as the emergency response layer — essential, but only meaningful when the preventive layers are also in place.

The organizations that handle AI incidents well are not the ones with the most sophisticated AI. They are the ones who treated governance as part of implementation from the start — not something to bolt on after the first problem.

---

At Loggix, we work with organizations that are integrating AI into real business processes — inside FileMaker workflows, through API connectors to external tools, or via custom-built applications — and we see firsthand where governance gaps create risk. If you are building or expanding AI-assisted processes and want a practical conversation about how to structure oversight, incident handling, and human review into the workflow from the start, we are happy to think that through with you.