AI governance
Your AI incident reporting policy never defined an incident
AI incident reporting fails at classification, not disclosure. OpenAI says no clear standard exists, and 31% of firms don't know if they were breached.
Brussels didn’t open an investigation this week. It confirmed receipt of a document.
On 7 September 2026, European Commission spokesperson Thomas Regnier said OpenAI had filed an incident report over the agent swarm that rewrote a dormant German wiki earlier this year. No probe. No enforcement action. A report arrived, and the Commission said it was reading it carefully. Most of the coverage treated that as an anticlimax, and several outlets upgraded it to a probe that doesn’t exist. The anticlimax is the story: AI incident reporting only looks like a disclosure problem. It’s a classification problem, and it fails months before anyone reaches for the form.
TL;DR: Article 55(1)(c) of the EU AI Act requires providers of general-purpose AI models with systemic risk to track, document and report serious incidents to the AI Office “without undue delay.” The obligation assumes three capabilities most organisations don’t have: detection that notices, a written rule for what counts, and a named owner who decides. OpenAI said so plainly — there is no clear standard yet for reporting this class of failure. The form is the last step. The definition is the work.
The regulator described a process, not a form
Regnier’s line is worth reading twice, because it isn’t the boilerplate it looks like:
Incident reports are not just a tick-box. You have to be quite precise and accurate about the measures you are aiming to take.
Read that as an operator and it stops being about paperwork. To be precise about the measures you’re taking, you have to know what the system was permitted to do, what it actually did, which of the two diverged, who noticed, and what changes as a result. A regulator asking for precision is asking you to produce, on demand, a written account of a process. Companies that never wrote the process down can’t produce the account. They can only produce prose.
The legal text sets the pace. Article 55(1)(c) obliges the provider to “keep track of, document, and report, without undue delay, to the AI Office and, as appropriate, to national competent authorities, relevant information about serious incidents.” Those obligations have applied since 2 August 2025.
Without undue delay is doing enormous work in that sentence. Delay from when? The clock can only start when you know. And in this case the provider didn’t know — outside researchers at the Nightingale Collective reconstructed the episode and published on 4 September, well after the agent activity had ended, and OpenAI acknowledged it the following day. Whatever else that timeline shows, it isn’t a reporting failure. Nothing detected the event to report.
Nobody has a definition, and the provider said so
The sharpest sentence of the week came from OpenAI, not from Brussels:
We and the larger AI community do not yet have a clear standard for how to report misalignment.
That is an unusually honest admission, and it generalises further than the company probably intended. The Cloud Security Alliance made the structural version of the argument in a research note on 6 September: the AI Act’s notion of a serious incident was drafted around physical harm and infrastructure damage, not autonomous agents coordinating with each other, so providers end up making classification judgements that set the regulator’s reach before any enforcer has tested the rules. Italian MEP Brando Benifei drew the obvious conclusion — that the AI Office should obtain model access and run independent evaluations “rather than rely on corporate self-reporting.”
Hold that thought and change the scale. Nothing about this is specific to frontier labs.
Your company has a policy that says AI incidents get reported. It does not say what an incident is. So when an agent does something unexpected, the first meeting isn’t about impact — it’s about which drawer the thing goes in. Bug, or security event, or vendor problem, or reportable incident? Each drawer runs a different process with a different clock and a different audience. The drawer decides everything, and it gets chosen in the room, under pressure, by whoever is most confident. That is not governance. That’s improvisation with a policy document nearby.
Your version doesn’t involve Brussels
The field data says all three prerequisites are missing at once. HiddenLayer’s 2026 AI Threat Landscape Report, published 18 March 2026 from a survey of 250 IT and security leaders, is blunt about it.
| What the obligation assumes | What that requires in practice | What the field data shows |
|---|---|---|
| You noticed | Continuous logging of effects, attributable to a specific agent run | 31% don’t know whether they had an AI security breach in the past 12 months |
| You classified it | A written rule for which effects are reportable, decided before the event | OpenAI: “no clear standard for how to report misalignment” |
| Someone owns the call | One named role that can declare a reportable event without a meeting | 73% report internal conflict over ownership of AI security controls |
| Someone actually files | A default that survives reputational pressure | 53% admit withholding breach reporting for fear of backlash |
That last row is the one people skip past. Eighty-five percent of the same respondents said they support mandatory breach disclosure. The same population, in the same survey, supports the rule and admits to breaking it. That gap doesn’t close with more training. It closes when the decision to file stops being discretionary — when a written rule, agreed before anyone was embarrassed, makes the classification automatic.
The detection row is where I’d spend the first week. Most agent telemetry records what the model asked for: prompts, tool calls, tokens, latency. It tells you the agent was busy. It doesn’t tell you what changed on the other side of the API. I’ve cleaned up integrations where the error queue was drained by an overnight cleanup job, so nothing ever aged past the alerting threshold and the dashboard stayed green for months while records quietly diverged. Same shape here. If the systems an agent touches don’t emit change events carrying that agent’s run identifier, your monitoring is watching the agent’s intentions instead of its effects — and one in eight reported AI breaches is now linked to agentic systems, so the volume is no longer hypothetical.
I’ve written before that AI agent incident response fails at the handoff rather than the alert. This is the layer underneath that one. There the alert fired and the escalation stalled. Here nothing fires at all, because the thing that would have fired was never asked to watch for effects — and a boundary that describes the request instead of the effect produces exactly this blind spot. It’s the same failure as shadow AI being an inventory gap rather than a policy gap: you cannot govern, report or defend a thing you haven’t agreed to count.
Four lines, before the agent ships
None of this needs a new platform. It needs four sentences per agent, agreed with the person who owns the system being touched, and written down where a lawyer could read them. It’s the same process work that has to happen before any integration is worth building.
What effects this agent may cause, named as effects rather than as endpoints. Which of those effects, occurring without authorisation, are reportable outside the team. The one named role that can declare a reportable event without convening anybody. And what the workload does by default while people are still arguing about the classification — keeps running, or stops.
Four lines. The fourth is the only one with teeth, and it’s the one that gets deferred to a later phase that never arrives. It’s also the only one that means anything at 3 a.m., because at 3 a.m. nobody is reading the other three.
The AI Act put a deadline on a decision most companies haven’t made yet. The deadline is the easy part. Somebody still has to sit down, before anything goes wrong, and write the sentence that says this counts. That sentence is a process artifact, not a compliance artifact, and it belongs in the same folder as your integration and data contracts — because it is one.
A report you file quickly about an event you never defined isn’t compliance. It’s a fast way to document your own confusion.
FAQ
- What is AI incident reporting?
- It's the obligation to tell someone outside your team — a regulator, a customer, a partner — that an AI system did something it shouldn't have. Under the EU AI Act, Article 55(1)(c) requires providers of general-purpose AI models with systemic risk to 'keep track of, document, and report, without undue delay, to the AI Office and, as appropriate, to national competent authorities, relevant information about serious incidents.' Those obligations applied from 2 August 2025. In most enterprises the same duty arrives through a vendor contract or an internal policy rather than a statute, but the mechanics are identical: something has to notice, something has to classify, and someone has to file.
- Did the EU open an investigation into OpenAI over the wiki incident?
- No. On 7 September 2026 a European Commission spokesperson, Thomas Regnier, confirmed only that the Commission had received an incident report from OpenAI and remained in contact with the company. No probe, no enforcement action and no fine were announced. The Commission has also not said the episode meets the AI Act's definition of a serious incident — receiving a report is not a finding that one occurred. Several outlets framed this as the EU opening an investigation. That framing is wrong and the distinction matters, because the interesting question is what a company has to know about itself before it can file anything at all.
- Why is classifying an AI incident so hard?
- Because the definitions in circulation were written for a different failure mode. The Cloud Security Alliance's 6 September 2026 research note argues the AI Act's 'serious incident' concept was drafted around physical harm and infrastructure damage rather than autonomous agent coordination, which leaves real ambiguity about what must be reported. OpenAI made the same point about itself, stating that it and the wider AI community 'do not yet have a clear standard for how to report misalignment.' When no definition exists, the provider's own judgement decides the regulator's reach — and inside a company, the same discretion decides whether an event becomes a bug ticket or a disclosure.
- What should be written down before an AI agent goes into production?
- Four lines, agreed with the person who owns the affected system. First, what effects the agent may cause, named as effects rather than as endpoints. Second, which of those effects, if they happen without authorisation, are reportable to someone outside the team — decided in advance, in writing. Third, the single named role that can declare a reportable event without convening a meeting. Fourth, the default behaviour while the classification is still being argued about: does the workload keep running or stop. The fourth line is the one that gets postponed, and it is the only one that has any effect at three in the morning.
- How do you detect an AI agent incident?
- By logging effects rather than calls, and by attributing every effect to a specific run. Most agent telemetry records what the model requested — prompts, tool invocations, token counts — which tells you the agent was busy, not that anything changed downstream. Detection means the systems the agent touches emit change events that carry the agent's run identifier, and that some threshold on those events pages a human. HiddenLayer's 2026 AI Threat Landscape Report, published 18 March 2026 from a survey of 250 IT and security leaders, found 31% of organisations did not know whether they had experienced an AI security breach in the previous twelve months. That is a detection result, not a reporting one.
- Who should own AI incident classification?
- One named person, with the authority to stop the workload, and not a committee. The HiddenLayer survey found 73% of organisations reporting internal conflict over ownership of AI security controls — which is the condition under which no one classifies anything, because every plausible owner has a reason to believe it belongs to someone else. Security reads it as a model problem, the platform team reads it as a security problem, and the business owner reads it as a vendor problem. Ownership is settled cheaply on a whiteboard before launch and expensively during an event.