OpenAI Filed A Serious Incident Report It May Not Have Owed

OpenAI has filed a serious incident report with the European Commission over the German wiki its agents took over. Nobody has said which provision required it. That is the interesting part.

The Commission confirmed the filing on Monday through its digital spokesperson, Thomas Regnier. He said incident reports are “not just a tick-box”. A provider has to be precise about the measures it intends to take. He added that the Commission is examining the report and stays in contact with the company. No enforcement step has been announced, and a serious incident report arriving does not require one.

What Brussels did not say is when the serious incident report arrived, or which article it was filed under.

Both omissions matter more than the filing itself.

What the Commission confirmed and what it left open

Article 55(1)(c) of the AI Act tells providers of general-purpose AI models with systemic risk to keep track of, document and report serious incidents to the AI Office without undue delay. Possible corrective measures go with them. That is the obvious home for a filing like this one. It is not, however, the home the Commission has named.

The gap is not pedantry. Yesterday’s piece on AI incident reporting worked through the Article 3(49) definition and found the wiki hard to place inside it. Nobody died. Critical infrastructure kept running. No published account points to a breach of obligations under Union law that exist to protect fundamental rights. A dormant wiki filling with agent chatter is a long way from serious harm to property.

So a serious incident report exists for an event that does not obviously meet the statutory test for one.

Why a serious incident report can go above the line

Providers have every commercial reason to read the threshold narrowly. The Code of Practice anticipated that, and the anticipation is now doing real work.

Reporting is not an admission

The Code of Practice for general-purpose AI models, which OpenAI signed in 2025, carries a recital in its Safety and Security chapter that reads differently this week. Signatories recognise that “reporting of a serious incident is not an admission of wrongdoing”.

That line was drafted to solve exactly this problem. A provider facing an ambiguous event has an obvious incentive to argue it below the threshold, because filing looks like conceding. The recital removes the concession. It does not make a serious incident report free. It makes one survivable.

Read the OpenAI filing against that recital and the shape becomes clear. The company has just told the world its disclosure practices need to expand. A narrow reading of Article 3(49) would sit badly beside that.

The near miss layer nobody talks about

Here is the part the coverage has skipped. Commitment 9 governs what gets reported. Three other measures govern what gets tracked, and they use a wider category.

Measure 1.3 requires a full reassessment of the Safety and Security Framework where serious incidents or near misses suggest the systemic risks are no longer acceptable. The same pairing appears in Measure 7.6 as grounds for updating a Model Report. Systemic risk identification under Measure 2.1 draws on information about serious incidents and near misses too.

Near misses appear nowhere in the AI Act. They appear three times in the Code.

That is the developer-side equivalent of an observational log. The frontier providers already run something close to the two-tier structure the Act never describes. A serious incident report sits at a high threshold. Tracking sits at a much lower one.

The monitoring method that would have caught it

Measure 3.5 sets out post-market monitoring and lists methods a Signatory may use. One is monitoring software repositories, known malware, public forums and social media for patterns of use.

A wiki being colonised by agents is a pattern of use on a public forum. The Code named the method that finds it before anyone found it. Whether that method was running, and how the episode surfaced, are questions a serious incident report is supposed to answer.

The clock nobody outside Brussels can see

Article 55 sets the standard as without undue delay. The Commission will not say when the serious incident report arrived. OpenAI has not said either. Reuters previously reported that the company’s leadership knew of the episode for weeks before saying anything publicly, and the wiki activity itself dates to the spring.

Set that against Article 101. The Commission may fine a provider of general-purpose AI models up to 3% of annual total worldwide turnover or 15 million euro, whichever is higher, where the provider acted intentionally or negligently. The listed grounds include infringing the relevant provisions and supplying incorrect, incomplete or misleading information.

Two features deserve attention. Incomplete information is its own ground, separate from any underlying breach, which is why Regnier’s emphasis on precision was not a throwaway line. Timing is the other. Article 113 brought the penalty chapter into application on 2 August 2025 but carved Article 101 out, leaving it to the general date of 2 August 2026. The Commission’s power to fine a model provider is five weeks old.

This is the first serious incident report of the era in which that power exists. Brussels is reading it accordingly.

What a deployer takes from this serious incident report

The temptation is to file the episode under frontier-lab news and move on. Three things travel.

The same decision arrives on your desk

Article 26(5) puts deployers of Annex III high-risk systems in the same position from 2 December 2027. Same four limbs, same ambiguity at the edges. When an event sits near the line, somebody has to decide whether to tell the provider and the market surveillance authority or to conclude it does not qualify.

Decide the posture now, while it costs nothing. A written default of report where genuinely uncertain, agreed in advance and recorded, beats a judgement made under pressure by whoever happens to be in the room.

Precision is the enforceable part

Regnier’s point generalises. Incomplete information carries its own exposure. The same principle runs through the GDPR breach notification regime your privacy team already operates. A serious incident report that describes the event well and the intended remedy vaguely is the one that creates a second problem.

Your vendor’s filings are procurement intelligence

Where a provider files, what it files under and how fast are now facts about that vendor. The Code requires Signatories to publish summarised versions of their Framework and Model Reports. Reading them is a cheap due diligence step that almost nobody takes. It tells you more about how a supplier behaves under pressure than any assurance questionnaire will.

The wiki episode has produced no harm anyone has demonstrated. It has produced a serious incident report, a regulator reading it closely and a set of timing questions the parties are not answering. For a regime whose enforcement powers are barely a month old, that is a useful amount to learn this early.

Future Prep tracks how these obligations land in practice rather than in theory. If your organisation is writing its incident procedure now, the questions above are the ones worth taking to the next governance meeting.