Most AI failures at law firms are not serious incidents under Article 26(5). An API outage is not a serious incident. A hallucinated case citation caught by HITL review is not a serious incident. But you need a documented procedure to make that determination — and a log that proves you made it.
Article 26(5) of Regulation (EU) 2024/1689 requires deployers of AI systems to notify the provider of the system "without undue delay" when they become aware of a serious incident. A serious incident is one that causes or risks causing significant harm — personal injury, property damage, financial harm, fundamental rights violation, or breach of law. The notification obligation is narrow but real. PROC-AIMS-EUINC-001 provides the three-type classification framework, the four-severity response matrix, the Supabase incident log, and the n8n workflow that fires a COLP notification the moment any Type B or Type C incident is logged.
Sophie Chen was reviewing a GPT-4o generated case summary for a commercial litigation matter. The summary cited Smith v. Jones [2019] EWHC 1234 as the leading precedent for reasonable foreseeability. Sophie, familiar with the area, knew this was wrong — the correct precedent is Smith v. Barker Holdings [2022] EWCA Civ 567. She rejected the HITL sign-off, corrected the citation manually, and then logged INC-2026-001 in PROC-AIMS-EUINC-001. The incident was assessed as Type B: the AI produced a quality failure, but it was caught before client impact. No regulatory notification was required. Root cause: GPT-4o hallucination of a plausible but incorrect case reference. Corrective action: citation verification step added to fee earner AI usage guidance.
INC-2026-001 demonstrates the procedure working as designed. The HITL review caught the error. The incident was logged, classified, and assessed. The notification assessment concluded that Art. 26(5) was not triggered — because no harm occurred. The corrective action was documented. The incident is closed with a full audit trail.
The alternative — not logging the incident — would mean that Priya Anand has no visibility of AI quality failures, no pattern data, no evidence that the HITL review procedure is catching errors, and no documented assessment that Art. 26(5) was considered and found inapplicable. The procedure costs thirty minutes to complete. The absence of it costs the firm its ability to demonstrate proactive governance.
"Deployers shall inform the provider or distributor where relevant and the relevant national competent authority without undue delay when they become aware of any serious incident. In the event of a serious incident, deployers shall immediately discontinue use of the high-risk AI system."
Article 26 principally applies to deployers of high-risk AI systems. However, Article 26(5)'s notification obligation — and the spirit of the EU AI Act's broader incident management requirements — applies as a matter of good governance to all AI systems, including Not High-Risk systems classified under Bridge 03. PROC-AIMS-EUINC-001 is designed for all AI systems in the register, regardless of classification. A Not High-Risk AI system can still produce a serious quality failure requiring provider notification under general contract law and professional regulatory obligations (SRA Code of Conduct) even where the Art. 26(5) statutory obligation is not technically engaged.
"Providers of high-risk AI systems referred to in Annex III, and deployers of high-risk AI systems, shall report any serious incident to the market surveillance authorities of the Member States where that incident occurred."
Two notification obligations must be distinguished. Article 26(5) is the deployer-to-provider notification — the law firm tells OpenAI or Microsoft that a serious incident occurred involving their AI system. Article 73 is the deployer-to-authority notification — the firm tells the national competent authority. For UK firms, the "national competent authority" question depends on whether the EU AI Act's extraterritorial provisions apply; for SRA-regulated firms, the SRA incident reporting obligation under the Code of Conduct applies in parallel as a domestic obligation.
Under ITIL 4, Incident Management focuses on restoring normal service operation as quickly as possible. Problem Management focuses on identifying and eliminating the root cause to prevent recurrence. PROC-AIMS-EUINC-001 runs both practices in parallel: every incident is closed through the incident lifecycle, and any incident that reveals a systemic root cause (a pattern of hallucinations from the same AI system, a consistent failure in a particular use case) generates a Problem record in the inc_problem table — preventing the same incident from recurring.
AI system failure, API outage, workflow error. No quality impact — the system failed to function, not functioned to fail. Art. 26(5) not triggered. ITIL Incident Management only.
AI output that is incorrect, misleading, biased, or hallucinatory. The system functioned but produced a defective output. Assessment required: does this quality failure rise to the level of a serious incident?
A quality failure that caused or risks causing significant harm — personal injury, financial damage, fundamental rights violation, or regulatory breach. Art. 26(5) provider notification and Art. 73 / SRA authority notification required without undue delay.
The key analytical step is the Type B to Type C assessment. Every Type B incident requires a COLP seriousness assessment within 5 working days of detection. That assessment answers one question: did this AI quality failure cause, or does it risk causing, significant harm to a natural person or organisation? If the answer is yes — or if the COLP cannot rule it out — the incident is reclassified as Type C and the notification obligations engage.
If no (caught by HITL review or pre-use check): likely remains Type B. If yes: proceed to Q2.
If no: likely Type B. If yes: proceed to Q3.
If no: Type B — close with corrective action. If yes or cannot rule out: Type C — notify provider under Art. 26(5) and authority under Art. 73 / SRA Code without undue delay.
The highest-risk incident type for law firms is not an API outage — it is an AI-generated legal opinion or case citation that passes HITL review and is sent to a client, who then acts on it. If the advice is wrong and the client suffers loss, the incident is Type C: professional duty breach causing financial harm. Art. 26(5) applies; the SRA Code incident reporting obligation applies; and a professional indemnity claim may follow. The HITL procedure (PROC-AIMS-HITL-001) is the primary prevention mechanism. PROC-AIMS-EUINC-001 is the detection and response mechanism for when prevention fails.
The EU AI Act does not merely require firms to respond to serious incidents — it requires them to be able to demonstrate that they assessed every quality failure against the seriousness threshold. A firm that has a procedure but no log has no evidence that the procedure was followed. A firm that has a log with documented assessments — including assessments that concluded "Type B, not Type C, Art. 26(5) not triggered" — has demonstrated that it takes the obligation seriously, that it has a functioning detection mechanism, and that it is not simply waiting for a regulator to tell it something went wrong.
The inc_incident table in PROC-AIMS-EUINC-001 captures every incident with a mandatory seriousness assessment field. The inc_timeline table records every action taken on the incident. The inc_notification table records every external notification. Together they produce an audit trail that answers the question a regulator or panel client will ask: "When your AI produced a quality failure, how did you know about it, and what did you do?"
PROC-AIMS-EUINC-001 includes a direct detection path from PROC-AIMS-HITL-001: when a fee earner rejects an AI output during HITL review (outcome: REJECTED or AMENDED with significant changes), the n8n workflow automatically creates a Type B incident record with detection source "HITL Sign-Off Override." This closes the detection gap: without this path, a fee earner who catches and corrects an AI error has no mechanism to report it to the COLP. The automatic logging ensures that quality failures caught at the HITL gate are still recorded — even though no client harm occurred — because the pattern of errors informs both corrective action and AI system governance.
1. Supabase SQL schema — six tables (inc_firm, inc_incident, inc_timeline, inc_problem, inc_notification, inc_audit_log), three stored procedures (sp_log_incident, sp_assess_seriousness, sp_check_overdue_notifications), four compliance views. Deletion prohibited on incident and audit tables by RLS policy — the log is immutable by design. Two seed incidents pre-populate the register for testing: INC-2026-001 (Type B, closed, Art. 26(5) not required) and INC-2026-002 (Type A, technical, no quality impact).
2. HTML dashboard — three tabs: Incident Log (full register with status, notification status, and detail cards), Log Incident (form firing to n8n webhook), Classification Guide (type and severity reference with decision matrix). Summary cards show open incidents, overdue notifications, serious incidents, and client-affected count.
3. This article — published to unuslondon.com as the Bridge 05 educational anchor. Paired with the scorecard email capture funnel for lead generation.
PROC-AIMS-EUINC-001 completes the incident management gap in the EU AI Act Bridge Series. The final module — Bridge 06, GPAI Verification — addresses the obligations arising from the use of General-Purpose AI models under Articles 25 and 53 of the EU AI Act. This is directly triggered for Halstead & Cole LLP because GPT-4o (AIMS-SYS-001) is a GPAI model. Bridge 06 is the final governance layer that closes the series and brings the firm's EU AI Act compliance programme to a documented, auditable close across all six identified gaps.
All 10 gates pass. This record satisfies ISO 9001:2015 Clause 7.5.3 for the EU AI Act Bridge Series.
Governance Academy members receive the complete PROC-AIMS-EUINC-001 module: Supabase schema with immutable incident log, n8n workflow spec for COLP notification, HTML dashboard with classification guide, and two seed incidents pre-populated. One module per month. All infrastructure owned permanently. £97/month.
Join the Governance AcademyThis article is published for educational purposes only and does not constitute legal advice or advice on compliance with Regulation (EU) 2024/1689 (the EU AI Act), ISO/IEC 42001:2023, the SRA Code of Conduct for Firms 2019, or any other standard or regulation. The incident classification framework in PROC-AIMS-EUINC-001 is a structured governance tool — seriousness assessments for specific incidents shall be made by the COLP with qualified legal input where appropriate. Halstead & Cole LLP, Sophie Chen, Priya Anand, and all associated names are fictional constructs. Any resemblance to real persons or firms is coincidental. · Document ref: ART-AIMS-EU-005 v1.1 · Published 25 July 2026 · Next review: 25 October 2026 · Retention: 7 years · UNUS London Ltd. · unuslondon.com/legal/eu-ai-act-bridge-05-ai-incident-notification-procedure