1. What Counts As A Serious Incident
Article 73 of the EU AI Act obliges providers of high-risk AI systems to report serious incidents and malfunctions to the relevant market surveillance authority. Deployers must also notify the provider when they become aware of such an event. In practical terms, the hardest part is often not the report itself, but recognizing quickly when a real-world problem has crossed the line from anomaly to reportable incident.
How to think about it in ActLoom
The platform separates three operational buckets so teams can react proportionally without underreporting or overreporting.
Serious Incident
The event has caused or could plausibly cause serious harm, major disruption, or a significant fundamental-rights breach. This is the reportable path.
Malfunction
The system behaved unexpectedly or materially underperformed. It may still escalate into a serious incident depending on actual or potential harm.
Near-Miss
No serious harm occurred, but the event is still worth preserving because it reveals a weakness in the system or the operating process.
Information captured in the record
The record is designed to help teams collect what they need for triage first, then investigation, then notification.
| Field | Required | Why it exists |
|---|---|---|
| AI System | Yes | Anchors the incident to a specific registered system and version context |
| Title | Yes | Creates a short label the team can use across alerts, PDFs, and follow-up |
| Description | Yes | Captures what happened in narrative form before details fade |
| Severity | Yes | Distinguishes near-miss, serious, and critical situations |
| Urgency track | Yes | Determines which legal deadline countdown starts |
| Harm type | Yes | Helps justify why the case is or is not reportable |
| Occurrence date | Yes | Establishes when the event happened |
| Discovery date | Yes | Establishes when the operator became aware |
| Affected persons | No | Strengthens harm assessment and later authority communication |
| Root cause | No | Filled as investigation matures |
| Corrective actions | No | Shows whether the problem was contained and how recurrence is addressed |
| Authority notified at | Auto | Preserves the actual submission timestamp |
| Provider notified at | Auto | Separately records deployer-to-provider communication |
Visual overview of the incident workspace
The interface is meant to make urgency legible at a glance: severity, track, time remaining, and current status are all surfaced immediately.
Incident Reports
Recruitment AI — Bias Detected
SLA: 15 days
⏱ 9 days
Credit Scoring — Model Failure
SLA: 2 days
⏱ 14 hours
HR Screening — False Positive
SLA: 15 days
✓
Dual SLA Notification
Authority notification + Provider notification (Art. 26 §6) tracked independently
Minimum information to have before opening the module
- Which AI system and release context were involved.
- What happened, when it happened, and when the team became aware.
- Whether actual harm occurred or serious harm was credibly possible.
- Whether the issue already triggered containment, rollback, or human override steps.