Incidents, the register and evidence

This page covers the tenant-wide side of governance: serious incidents (Art. 73), the AI register, the files you hand to an auditor, and how to keep an eye on gaps such as overdue reviews and unowned systems.

Serious incidents

A serious incident (Art. 3(49)) is recorded against one agent, MCP server or LLM gateway. The platform keeps the Art. 73 reporting clock, the evidence and your filing reference. It does not report anything to an authority: you file the report through the authority’s own channel and record the reference here.

Categories and deadlines

The category sets the clock: the report is due a fixed number of days after the awareness date.

Category	Shown as	Report within	Legal basis
`DEATH`	Death of a person	10 days	Art. 3(49)(a); Art. 73(4)
`SERIOUS_HARM_TO_HEALTH`	Serious harm to a person’s health	15 days	Art. 3(49)(a); Art. 73(2)
`CRITICAL_INFRASTRUCTURE_DISRUPTION`	Serious and irreversible disruption of critical infrastructure	2 days	Art. 3(49)(b); Art. 73(3)
`FUNDAMENTAL_RIGHTS_INFRINGEMENT`	Infringement of fundamental-rights obligations	15 days	Art. 3(49)(c); Art. 73(2)
`WIDESPREAD_INFRINGEMENT`	Widespread infringement	2 days	Art. 3(49)(c); Art. 3(61); Art. 73(3)
`PROPERTY_OR_ENVIRONMENT_HARM`	Serious harm to property or the environment	15 days	Art. 3(49)(d); Art. 73(2)

The Act asks for some reports “immediately”; the day counts above are the outer limits.

Statuses and the clock

Status	Meaning	Clock
Draft	Raised but not yet confirmed as serious — typically from a monitor alert	None
Open	Confirmed. Shown as Report due in N days, Report due today or Overdue by N days	Running: due = awareness date + category days
Reported	The report reached the authority; its reference and date are recorded	Stopped
Closed	Done, or dismissed as not serious after all	Stopped

Confirming a draft starts the clock from its awareness date, or from the moment of confirmation if no awareness date was entered.
Editing the category or the awareness date of an open incident recomputes the deadline.
Recording the report is only possible on an Open incident. Enter the authority’s reference and when it was filed (now by default). A report filed after the deadline is accepted and noted as late on the governance timeline.
Closing needs a reason. You can close a draft (not serious after all), an open incident (closed without a report, which the timeline says), or a reported one.
Every change is a governance event on the audit chain, so the record can be edited while live and still be shown to be unaltered.

Opening or confirming an incident does not suspend the system and does not notify anyone. If the system must stop, suspend it on its lifecycle page (reason Serious incident) or freeze it. If people must be told, tell them — the platform only records that the incident exists.

Opening an incident

Where	How
Govern › Incidents	Report an incident: choose the system, category, title, description and awareness date; confirm it now or keep it as a draft.
A system’s Governance › Governance lifecycle	Report incident… opens the same form for that system.
Observe › Alerts, on an alert about an agent, MCP server or LLM gateway	Open incident… creates an incident with the alert attached as evidence (alert id, detector, severity, detection time, summary and the alert’s own evidence).

An incident opened from an alert:

is a Draft unless you tick Confirmed serious incident, in which case it opens with the clock running from the alert’s detection time;
links back to the alert (Raised from: Monitor alert);
can be opened only once per alert;
needs Audit · Write (the other routes need Registry · Write).

Through the API: POST /registry/v1/governance/incidents to open one, or POST /audit/v1/monitors/alerts/{alertId}/incident with {"category": "SERIOUS_HARM_TO_HEALTH", "confirmed": false} to open one from an alert.

The Incidents page

Govern › Incidents lists every incident with the most urgent first: overdue, due within three days, running, drafts, then closed. Tiles across the top show Overdue, Due in 7 days, Awaiting confirmation, Open in total and Reported this quarter. Filter by status, category, system type and deadline (Overdue or due today, Due within 2 / 7 / 15 days), or search by title.

The AI register

Govern › AI register lists every agent, MCP server and LLM gateway in the tenant. It doubles as an AI asset inventory.

Column	Shows
System	Name and type
Risk classification	The effective tier, marked when a second signature is pending or when the tier is inherited from agents, and the own tier where it differs
Governance lifecycle	Draft, Assessed, In service, Suspended, Retiring or Retired
Incidents	Live incidents (draft or open) and the nearest report deadline
Role	Provider, Deployer or Both, from the latest classification
Accountable owner	The owner, marked Unconfirmed when inferred from the creator
Classified	When the latest classification was signed, or Never
Review due	The review date, marked overdue or brought forward (Art. 25)
Retention holds	Shown when any listed row is retired: logs and documentation kept until

Filters: system type, one or more tiers, lifecycle state, incidents (Open incidents, Report due within 2 / 7 / 15 days), Reassessment pending, Unclassified only, and a name search. The tier filter matches the effective tier; Unclassified only matches the system’s own tier. The seven tiles count the whole tenant, regardless of filters and paging:

Tile	Counts
Systems	Every agent, MCP server and LLM gateway
High-risk or above	Systems whose effective tier is High-risk (exempt), High-risk or Prohibited
Unclassified	Systems with no classification of their own
Pending approval	Systems whose latest classification is waiting for its second signature
Review overdue	Systems whose review date has passed, including brought-forward reviews
Owner unconfirmed	Systems without an assigned owner (inferred or missing)
Open incidents	Systems with at least one draft or open incident — not the number of incidents

The same data is available as GET /registry/v1/governance/register (with the filters as query parameters, plus ownerUserId and reviewDueBefore) and GET /registry/v1/governance/register/stats.

Exporting evidence

Evidence exports are on Govern › Compliance reports, in the EU AI Act evidence card. They need Audit · Read, and they read what the registry holds now — the date range at the top of the Compliance reports page does not apply to them.

Export	Format	Contents	Filter
AI register	CSV or JSON	One row per system: type, id, name, operational status, own and effective tier, role, approval pending, owner user id and whether confirmed, classified and review dates, inherited-from count, oversight count, oldest literacy attestation, review trigger, lifecycle state and retention holds	All systems, In service, Suspended or Retired
Serious incidents	CSV or JSON (the format chosen for the register)	Every incident with its category, awareness date, deadline, filing reference and outcome, soonest deadline first	All, Open, Awaiting confirmation, Reported or Closed
Evidence pack	JSON	Everything about one system — see below	Choose the system
Annex VIII extract	JSON	The EU database registration fields for one system — see below	Choose the system; not available for LLM gateways in the UI

API equivalents: GET /registry/v1/governance/register/export?format=csv, GET /registry/v1/governance/incidents/export?format=json, GET /registry/v1/agents/{agentId}/governance/evidence-pack and GET /registry/v1/agents/{agentId}/governance/annex-viii (or the mcp-servers / llm-gateways equivalents).

The evidence pack

One JSON document per system, holding what an auditor usually asks for:

the summary (tiers, owner, review date, lifecycle state) and the current state with any pending approval;
every classification, with its answers, legal basis, assessor and approver;
the current accountability assignments;
the linked documents with their status and SHA-256;
attestations;
readiness at the time of export, and the readiness recorded at each state change;
the governance state log;
the retirement case, if any;
every serious incident the system has had;
the Annex VIII Section A fields as far as the record holds them.

For a live system the pack is built from current data and carries generatedAt. For a retired system it is read from the immutable snapshot taken at retirement and carries sealedAt and the checkpointId of the audit integrity checkpoint that seals it, which you can verify under Govern › Immutable proof.

The Annex VIII extract

The Annex VIII extract (Art. 49) fills the sections that apply from the record and lists what is still missing for submission to the EU database:

Section	Applies when
A — provider of a high-risk system	Your role is Provider or Provider and deployer, and the effective tier is High-risk
B — provider of an Art. 6(3) exempt system	Your role is Provider or Provider and deployer, and the effective tier is High-risk (exempt)
C — deployer	Your role is Deployer or Provider and deployer, and the effective tier is High-risk or High-risk (exempt)

Each field says where its value came from (the classification, an assignment, a document, the lifecycle). Values the platform does not model — the Member States concerned, a notified body’s certificate number — are reported as missing, never guessed. The status fields follow the governance state and, once retired, the market action. The extract is a preparation aid; you still submit the registration yourself.

Governance checks

The platform includes five governance checks, each a monitor template in audit-service that reads the AI register:

Check	Looks for	Alerting behaviour
EU AI Act review due	A classification review due within the window (Low 7 days, Medium 30, High 90) or overdue	Once per due date
EU AI Act orphaned owner	An active system with no owner at all; at High sensitivity, also one whose owner is only inferred	At most once a day per system until fixed
EU AI Act unclassified agent	An active agent with no classification	At most once a day per agent until fixed
EU AI Act stale literacy attestation	A high-risk system whose owner, deputy or oversight persons lack an AI literacy attestation younger than 12 months	At most once a day per system until fixed
EU AI Act incident report due	A confirmed incident’s report due soon (Low: 1 day before; Medium: 5 and 1; High: 10, 5 and 1) or overdue	Once per reminder; daily once overdue

In this release these templates cannot be enabled. The Monitors page creates Threshold, Change and Outlier monitors only, and template monitors are not created automatically for a tenant. Until they can be, use the views below for the same conditions, and check them on a schedule — nothing will remind you.

Condition	Where to see it today
Reviews due or overdue	AI register: Review due column and Review overdue tile; tier and Reassessment pending filters
Missing or unconfirmed owners	AI register: Owner unconfirmed tile and Accountable owner column
Unclassified agents	AI register: Unclassified only with the type set to Agents
Lapsed literacy attestations	Each system’s Accountability page; the readiness item Oversight by persons with competence, training and authority
Incident reports due	Govern › Incidents: Overdue and Due in 7 days tiles, and the deadline filter

Monitors you create yourself still matter for governance: a high-risk agent’s Post-market monitoring in place obligation is satisfied by any enabled monitor whose filter names that agent, and alerts from such monitors can be turned into incidents.

Notifications

Two kinds of message leave the platform for governance, and both go through notification-service:

Monitor alerts are delivered to the notification channels selected on each monitor (configured under Manage › Notifications) by e-mail, Slack or Microsoft Teams. A Webhook destination can be saved but is not delivered in this release. A monitor with no channels selected only shows its alerts under Observe › Alerts. Monitors are only evaluated when ClickHouse is enabled.
Governance notices — a corrective retirement being opened, and every retirement completing — are e-mailed to the people affected, which needs SMTP.

On a self-hosted install, keep notification enabled in your values file and configure SMTP. With notification-service off, these messages are retried and then dropped without any visible failure; with SMTP off, e-mail is logged and dropped. The governance record still shows who should have been told. See Turning services off and SMTP.

Overview

Where things live, day one after upgrading, permissions.

Classification

Risk tiers, the wizard, second signatures and inherited tiers.

Governance record

Owners, oversight, documents, readiness and Art. 50 transparency.

Lifecycle and policy

States, suspension, retirement and the tenant governance policy.

Get Started

AI governance (EU AI Act)

Evaluations

Incidents, the register and evidence

Incidents, the register and evidence

Serious incidents

Categories and deadlines

Statuses and the clock

Opening an incident

The Incidents page

The AI register

Exporting evidence

The evidence pack

The Annex VIII extract

Governance checks

Notifications

Next

Overview

Classification

Governance record

Lifecycle and policy

​Incidents, the register and evidence

​Serious incidents

​Categories and deadlines

​Statuses and the clock

​Opening an incident

​The Incidents page

​The AI register

​Exporting evidence

​The evidence pack

​The Annex VIII extract

​Governance checks

​Notifications

​Next

Overview

Classification

Governance record

Lifecycle and policy

Incidents, the register and evidence

Serious incidents

Categories and deadlines

Statuses and the clock

Opening an incident

The Incidents page

The AI register

Exporting evidence

The evidence pack

The Annex VIII extract

Governance checks

Notifications

Next