Can you meet NIS2 24-hour incident reporting when AI is in the loop?

Only if you can see what the AI actually did. NIS2 requires essential and important entities to submit an early warning within 24 hours of becoming aware of a significant incident, an incident notification within 72 hours, and a final report within one month. When an AI system sits in the affected chain, many operators cannot reconstruct what the model saw or did inside 24 hours, because the evidence lives in a vendor's cloud logs behind a support queue. You can only report what you can see.

The question matters in 2026 because AI components now sit inside the operational chains NIS2 covers, from network management to customer-facing services, and the first incidents involving them are testing whether statutory reporting clocks survive contact with vendor dependencies.

What exactly does NIS2 require you to report, and when?

NIS2 is an EU directive covering essential and important entities across sectors such as energy, transport, health, digital infrastructure and manufacturing. For a significant incident it requires an early warning within 24 hours of awareness, indicating whether unlawful or malicious action is suspected and whether cross-border impact is possible; an incident notification within 72 hours with an initial assessment of severity and impact; and a final report within one month. Authorities can request intermediate updates at any time. The 24 hour early warning is deliberately light on detail, but it still requires knowing enough about the incident to characterise it honestly.

Does NIS2 apply to UK companies?

Not directly. NIS2 is an EU directive transposed into member state law; it is not UK law, and the UK is updating its own regime separately through the Cyber Security and Resilience Bill. UK companies meet NIS2 in practice through their EU operations, EU subsidiaries or EU customers: an entity in scope will pass reporting and security requirements down its supply chain contractually. A UK supplier whose service sits inside an EU customer's incident chain will be asked to deliver evidence on that customer's clock, not its own.

Why does an AI component break the 24 hour clock?

Because reconstruction depends on records the operator does not hold. When an incident touches an AI system, the questions are immediate: what data did the model ingest, what outputs did it produce, which systems consumed those outputs, and did its behaviour change. If the model runs in a vendor's cloud, the answers sit in the vendor's logs, filtered by the vendor's retention policy, reachable through a support process on the vendor's timetable. The operator's 24 hours start at awareness; the vendor's response time is not bound to that clock at all.

What must you be able to establish inside the first 24 hours?

We suggest four reconstruction questions every operator should be able to answer from its own records:

• What the AI system received: the inputs and data sources in the affected window.
• What it did: the outputs, actions and downstream systems it touched.
• Who and what drove it: which identities, human or machine, invoked it.
• Whether the record is trustworthy: proof the logs were not altered after the fact.

An operator that can answer these from local records can draft an early warning in hours. An operator that must open a vendor ticket cannot, and the gap between those two positions is architectural, not procedural.

How does a sealed local audit ledger change incident reporting?

It turns reporting from vendor correspondence into a database query. Mickai is a Sovereign Intelligence Operating System, a SIOS, that runs offline on operator-owned hardware. Every action in the system is recorded in an append-only audit ledger signed under FIPS 204 (ML-DSA), with FIPS 205 (SLH-DSA) as the second signature standard, so the record remains verifiable offline years later. Hardware-attested identity binds each entry to the machine and operator that produced it. A zero-egress inbound perimeter means there is no external log store to wait for: the evidence of what the AI layer saw and did is already inside the building, sealed at the moment it happened.

“An incident report can only move as fast as the slowest system you need evidence from.”

What should operators do before the next incident?

Run a reconstruction drill against the last significant near-miss. Pick a 24 hour window and attempt to answer the four questions above for every AI component in the chain, using only records you hold. Time the exercise. Note every point where the answer required a third party. Then fix the architecture rather than the ticket template: incident reporting speed is set by where the evidence lives, and no process document moves logs from a vendor's cloud into your hands faster than keeping them local in the first place.

How the whole system fits together is set out at /sovereign-ai, and the film at /film shows the interface in operation.

Frequently asked questions

What has to be reported within 24 hours under NIS2?

An early warning of a significant incident, submitted within 24 hours of the entity becoming aware of it. It must indicate whether the incident is suspected to result from unlawful or malicious action and whether it could have cross-border impact. Fuller detail follows in the 72 hour notification and the final report within one month.

Is NIS2 law in the UK?

No. NIS2 is an EU directive binding on member states, not on the UK. UK firms encounter it through EU operations, subsidiaries or customers, who pass its requirements down contractually. The UK is updating its own NIS 2018 regime separately through the Cyber Security and Resilience Bill.

Can I blame my AI vendor for a late NIS2 notification?

The reporting duty sits with the in-scope entity, not its suppliers. A vendor's slow evidence process may explain a delay but does not discharge the obligation, and relying on contractual response times to meet a statutory clock creates risk. Regulators assess the entity's own preparedness, including whether it could observe the systems it depends on.

What logs do I need from an AI system for incident reporting?

Inputs and data sources, outputs and downstream actions, invoking identities, configuration changes and model versions across the affected window, together with evidence the records were not modified afterwards. A signed, append-only ledger held locally satisfies both the speed and the integrity requirement; exported vendor summaries generally satisfy neither.

Does an on-premise AI deployment really report faster?

Yes, for a structural reason rather than a promotional one: the evidence never leaves the operator's control, so reconstruction is a local query rather than a support request. Speed still depends on discipline, which is why we recommend rehearsing the reconstruction drill before an incident forces the issue.