AI incident management is the process a business follows when an AI assisted decision causes harm. It means containing the damage, establishing what happened, assessing the impact and any legal duties, then recording the findings so the same failure cannot repeat. In an Irish SME this fits into a five step post mortem that runs on the people you already have.
AI incident management sounds like something that belongs to enterprises with a security operations centre, and almost everything written about it assumes exactly that. The situation it actually describes is far more ordinary. An AI drafted quote goes out at the wrong price, a chatbot promises a refund the terms do not actually offer, or a demand forecast orders stock that ends up sitting unsold for months. Each of those leaves someone dealing with an unhappy customer, someone else worried about being blamed for it, and a genuine question about whether any of it needs to be reported to anyone. The OECD counts an event like this as an AI incident once it leads to actual harm [1], and where personal data was caught up in it, GDPR puts a clock on part of your response. This guide walks through a five step post mortem an MD or team lead can run inside a week, moving through isolate, identify, trace, assess, and document in turn. Do you know which AI tools sit inside your customer facing workflows right now, and who checks their output? An AI Readiness Assessment maps exactly that before the next surprise.
What counts as an AI incident in a small business?
An AI incident is an event where the development, use or malfunction of an AI system leads, directly or indirectly, to actual harm, including injury or harm to someone's health, a breach of legal obligations that protect fundamental rights, or harm to property, communities or the environment [1]. The OECD published that definition in May 2024, roughly sixteen months after its expert group on AI incidents began work in January 2023, and it is deliberately broad [2].
Translated to a business of fifty or a hundred people, harm usually looks commercial. A quote honoured at a loss. A key account told a delivery date the schedule cannot meet. An AI summary that misstated a contract term and shaped a decision nobody would have made with the accurate version. Each of those is real damage flowing from an AI assisted step in your workflow, and each deserves the same structured response.
Then there is the error someone caught at their desk before it went anywhere. The OECD has a name for that too. It calls it an AI hazard, the same event pattern where harm was plausible but did not land [1]. Most of what goes wrong with AI in a small business is caught in time and quietly forgotten. That is a wasted asset. Near misses carry the same information as incidents.
In summary
Run the same review for the near miss as for the hit. The information is identical and the tuition is free.
What should you do first when an AI decision goes wrong?
When an AI drafted quote goes out to your largest customer at well below cost and they accept it by return, the first move is a phone call, not an investigation into the software. Ring the customer, own the error, and decide the commercial question on its merits, whether that means honouring it, renegotiating it, or absorbing it this once. Your reputation is decided in that phone call, and no post mortem will win it back later.
The second move is containment. Pause the AI step that produced the error. Take the automation out of the workflow, put a person back in the seat it occupied, and let the rest of the business run on the manual process that was in place before the tool was adopted. Then stop. Nothing useful gets investigated right after it happens, while everyone involved is still rattled.
The EU AI Act hard wires this same instinct for the heaviest category of system. A deployer of a high risk AI system who has reason to think its use presents a risk must inform the provider or distributor and the market surveillance authority without undue delay, and suspend use of the system [3]. Your invoice drafting assistant is very unlikely to sit in that category. The sequence is still the right one for any tool. Flag it, stop it, then look at it.
One instinct does need resisting. A blanket ban on AI after one bad week sends the tools underground, where staff keep using them on personal accounts with no logs and no warning before the next failure. Pause the workflow that failed. Leave the rest alone until the review reports.
In summary
Fix the customer first. Pause the tool second. Leave the investigation until both are done.
How do you find out what actually happened?
A tidy explanation usually starts circulating within a day or two, and it usually has a colleague's name attached. Treat it with suspicion. AI incidents almost never reduce to one person's mistake, and settling for that story guarantees the real cause survives to run again.
Start by reconstructing the sequence as bare fact. What went into the tool, what the tool produced, who saw the output, what review happened or was skipped, what left the building, and when. Timestamps matter, so pull the tool's logs before they age out. Retention varies widely between products and price tiers, so find out yours before a crisis needs the answer, not during one. For genuinely high risk systems the EU AI Act settles the question. Deployers must keep automatically generated logs under their control for at least six months, unless a shorter or longer period is required elsewhere in Union or national law, in particular data protection law [3].
Only then trace causes, plural, because there is nearly always a chain. The data the tool was fed sits at the top of the list, and the state of the data the tool was working from is a more common culprit than the model itself. After that comes the prompt or configuration, the review step that existed on paper and was skipped under deadline, and the prior question of whether the task was worth automating in the first place. A wrong quote might involve all four. Write the timeline on one page. If it does not fit on one page, the picture is still incomplete.
In summary
What did the process allow to happen that a second pair of eyes would have caught?
What are your legal obligations after an AI incident?
For most everyday AI incidents in an Irish SME there are two possible notification duties and one documentation duty, and a single question decides which apply. Was personal data compromised? Wrong customer's details in a mail merge, an AI output that exposed one client's records to another, a tool that leaked what it was fed. If the answer is yes and the breach is likely to put people at risk, GDPR Article 33 requires you to notify the Data Protection Commission without undue delay and, where feasible, within 72 hours of becoming aware of it [4]. That clock starts at awareness, and it keeps running while the operational cleanup continues. Where the breach is likely to result in a high risk to the people affected, Article 34 adds a second duty. It requires you to tell them directly, in clear and plain language, without undue delay [4].
The AI specific layer applies only if the system involved is high risk under the EU AI Act, for example a system monitoring employee performance. There the Article 26(5) duties covered above apply in full. You must inform the provider and the market surveillance authority, and suspend use [3]. The Act also defines a serious incident as death or serious harm to health, serious and irreversible disruption of critical infrastructure, infringement of fundamental rights obligations, or serious harm to property or the environment [5]. Identify one of those and the provider must be told first, immediately. Most SME incidents will sit nowhere near this threshold, and your obligations differ depending on whether the decision affected your own staff or your customers.
A word of calm. The wrong price on a quote, with no personal data involved and no high risk system in the chain, triggers none of these notification duties. The assessment still belongs in your post mortem, in writing, because the decision that nothing was reportable is itself worth being able to show.
In summary
Ask on day one whether personal data was involved. Every legal clock starts from that answer.
How do you document an AI incident so the business learns from it?
The finished deliverable is one page with six headings. Each one covers what happened, the timeline, the causes, the impact, the notifications considered and the decision made on each, and the corrective actions. Every corrective action gets a named owner and a date, because an action without an owner is a wish. For anything involving personal data, GDPR already expects this record to exist. Article 33(5) requires controllers to document any personal data breach, its effects and the remedial action taken, whether or not it was notifiable [4].
Hold the review itself as a working session, a week or so after the incident, with everyone who touched the workflow in the room. Open it by saying plainly that the session hunts for causes, not culprits. The person closest to the error holds the most valuable information in the building, and they will share it exactly once before deciding whether honesty was safe. In a business of sixty people that reputation forms fast and lasts years.
Then put the page to work. If the missing review step was the cause, it goes into the workflow as a standing check. If staff misjudged what the tool could safely do, that is a gap AI literacy training under Article 4 is built to close. If the incident revealed that nobody could say which AI tools were in use at all, the fix is structural, built around a governance and workflow blueprint that names an owner for every tool, and the governance controls that stop the same class of failure before it starts. The post mortem record is the first document in that governance file, and a business that can produce one looks very different to a regulator or a large customer than a business that can only shrug.
In summary
One page, six headings, a named owner beside every fix. That is the whole deliverable.
If your business has just been through an AI incident, or you would rather have an incident procedure in place before one arrives, the AI Policy and Governance Pack is built to help with exactly this. A conversation costs nothing.