Cluster 6 of 6 · Pillar Series26 min read

Forensic Ground Truth — Why an Audit Log Without a Forensic Layer Is Just a Paper Shield

Adil Ali named the discipline gap in one sentence on LinkedIn. The EU AI Act creates monitoring, logging and reporting obligations. It does not codify a forensic layer. The gap between them is where Annex III enforcement will land in December 2027 — and what governance product designers have to build for now.

Harish KumarHarish Kumar
··Part of: The EU AI Act Audit-Trail Stack

1. The Discipline Gap Adil Ali Named

In a single LinkedIn comment on the public exchange between senior practitioners that ran through the second week of May 2026, Adil Ali, Founder and CEO of Shadow AI Forensics, identified the discipline gap that closes the architecture-layer conversation and opens a different one. His full LinkedIn headline reads: “AI Exposure Forensics | Retrospective AI Risk Audits for Healthcare, Fintech & Legal | EU AI Act August 2026 Readiness”. The comment is reproduced below, verbatim.

“The hardest part for most vendors to answer is Question #5: ‘Show me the log’. If they can't, the firm has to be able to produce its own internal logs of AI interactions to survive an inspection. Governance without a forensic ‘ground truth’ is just a paper shield.”

Adil Ali— Adil Ali, Founder & CEO, Shadow AI Forensics, LinkedIn, May 2026.

The premise of this piece is that Ali is right about the gap and right about its operational consequence, and that the resolution requires precision about three distinct questions: which EU AI Act provisions actually create forensic obligations as opposed to audit obligations; whether the “forensics is different from auditing” framing survives the strongest counter-argument from the Regulation's own monitoring-and-reporting architecture; and which transitional evidentiary standard the first national competent authorities will use in the period between the December 2027 enforcement date and the eventual emergence of post-enforcement case law that settles what forensic readiness will actually mean for AI Act inspection.

This is the sixth and final cluster of the EU AI Act audit-trail pillar series. It closes with a cross-series synthesis of the GraQle-surfaced insights across all six clusters, organised into three categories: insights that the public LinkedIn thread already aligned on, insights GraQle surfaced that complement the public thread, and insights that the public thread and GraQle's reasoning have not yet aligned on. The synthesis is the feedstock for the next cycle of public discourse.

2. What the AI Act Actually Requires — and What It Stops Short Of

The starting point is the verbatim text. Five provisions in Regulation (EU) 2024/1689 form the audit-and-reporting architecture that an AI Act inspection will examine. Each is reproduced below from the verified source.

Article 26(5) — Deployer Monitoring of Operation

Deployers shall monitor the operation of the high-risk AI system on the basis of the instructions for use and shall inform the provider and (where relevant) competent authorities if they identify risks within the meaning of Article 79(1) or serious incidents within the meaning of Article 73. This is the continuous-monitoring duty under the verified text of Article 26, accessed 5 June 2026.

Article 26(6) — Deployer Log Retention

The deployer shall keep the logs automatically generated by the high-risk AI system for a period appropriate to the intended purpose, and in any event for at least six months, unless otherwise provided in applicable Union or national law. This is the clearest evidence-preservation hook in the Regulation. The substantive duty is a retention floor, not a custody or integrity standard.

Article 72 — Provider Post-Market Monitoring

Providers of high-risk AI systems are required to establish and document a post-market monitoring system that actively and systematically collects, documents and analyses relevant data on the performance of the system, provided by deployers or collected through other sources, allowing the provider to evaluate the continuous compliance of the AI system with the requirements set out in Chapter III, Section 2 (EU AI Act Article 72, accessed 5 June 2026).

Article 73 — Serious Incident Reporting

The opening sentence of Article 73, accessed 5 June 2026:

“Providers of high-risk AI systems placed on the Union market shall report any serious incident to the market surveillance authorities of the Member States where that incident occurred.”

The reporting time limits are specific and consequential: not later than 15 days after the provider or, where applicable, the deployer, becomes aware of the serious incident; not later than 2 days for widespread infringements or for serious incidents within the meaning of Article 3(49)(b); not later than 10 days where the incident has involved the death of a person. The primary obligor is the provider. The deployer reports where applicable. Article 73 does not cross-reference Article 79 directly but the substantive scope of both Articles overlaps where a serious incident also constitutes a risk at the national level.

Article 79 — Procedure for AI Systems Presenting a Risk

The opening sentence of Article 79, accessed 5 June 2026:

“AI systems presenting a risk shall be understood as a ‘product presenting a risk’ as defined in Article 3, point 19 of Regulation (EU) 2019/1020, in so far as they present risks to the health or safety, or to fundamental rights, of persons.”

Article 79 gives the market surveillance authority five operative powers: corrective action; withdrawal; recall; prohibition; restriction. The operator-compliance deadline is short of fifteen working days; the objection window is three months, reduced to 30 days for Article 5 (prohibited practices) violations. The procedural framework Article 79 incorporates is Article 18 of Regulation (EU) 2019/1020 — the EU's market-surveillance framework regulation.

These five provisions together compose the AI Act's operational accountability regime for high-risk systems after they enter the market. They establish monitoring duties, log-retention floors, hard reporting deadlines, and post-hoc enforcement powers. They do not, on any verified reading, codify a separate forensic layer.

3. Where the Regulation Implies Forensic Readiness — and Where It Does Not

The distinction between an audit obligation and a forensic obligation is the structural pivot of this cluster. Auditing asks whether the records exist and whether they support the compliance narrative the operator presents. Forensics asks whether the records would survive adversarial inspection — whether they are provenance-tagged, tamper-evident, chain-of-custody-preserved, and reconstructable into a defensible account of what the AI system actually did at the time of the consequential decision. The audit question is answered by the records that exist; the forensic question is answered by the discipline that preserved them.

The verified provisions of Articles 26(5), 26(6), 72, 73 and 79 imply forensic readiness wherever they require a party to be able to produce, preserve, or explain evidence later. The Article 26(6) six-month log retention floor implies that records have to survive long enough to support post-hoc review. The Article 73 fifteen-day, two-day and ten-day reporting windows create pressure to reconstruct facts quickly enough to file an accurate report under a hard deadline. The Article 79 fifteen-working-day operator compliance window assumes the operator can produce the relevant evidence to a market surveillance authority within that period.

What none of the provisions states explicitly is the operational discipline that turns retention into preservation. The Regulation does not, on any verified reading, require:

  • Immutable or cryptographically signed logs.
  • Provenance metadata identifying which system component, on which version, under which configuration, produced each record.
  • Documented chain-of-custody from the moment a record is created through to its production to a regulator.
  • Tamper-evidence procedures that allow an external party to detect modification of past records without trusting the operator.
  • Forensic collection procedures specifying how records are extracted, sealed, and submitted under conditions that preserve evidentiary admissibility.
  • Forensic reconstruction protocols allowing replay of the AI system's state at the time of the consequential decision.

Ali's formulation — governance without a forensic ground truth is just a paper shield — is therefore not a criticism of the Regulation. It is a description of the gap between what the Regulation requires (audit, monitoring, reporting) and what an adversarial inspection will demand (preservation, provenance, integrity, reconstructability). The gap is real, and it is structural.

4. The Counter-Argument the Forensics Framing Has to Address

A reasonable reader could object that Articles 72, 26(5) and 73 already function as the AI Act's forensic regime. Continuous monitoring by the deployer (26(5)), provider-side post-market monitoring (72), and hard reporting deadlines on serious incidents (73) together produce something that walks and talks like a regulatory incident-evidence regime. If that is true, the “forensics is different from auditing” framing is overstated.

GraQle reasoning chain

Counter-argument stress test

The AI Act monitoring/reporting regime is necessary but not sufficient. Forensic ground truth is the operational discipline that makes it usable under adversarial inspection.

The counter-argument is partly right. Articles 72, 26(5) and 73 do compose into something resembling a regulatory incident-evidence regime, and a deployer that has implemented those obligations conscientiously will, on paper, have the architecture an inspection assumes. The textual reading of the Regulation supports the counter-argument as far as it goes.

The reason the counter-argument does not settle the question is that the monitoring-and-reporting regime is operationally necessary but evidentially insufficient. The five properties that distinguish a forensic record from an audit record — evidentiary defensibility, provenance, tamper-evidence, reconstructability, and inspection readiness — are not produced by satisfying the verbatim text of any of the five Articles. They are produced by the operational discipline the operator builds on top of the Regulation's text. Ali's framing identifies that operational discipline as the gap; the verbatim Regulation does not close it.

The defensible synthesis is therefore narrower than “the Regulation already requires forensics” and stronger than “forensics is outside the AI Act's scope”: the Regulation creates a compliance environment that requires evidence to exist and be producible, but does not itself define the forensic discipline or impose a full forensic standard. Forensic ground truth is the missing operational discipline that turns audit logs into defensible regulatory evidence.

Analytical method: the strongest version of the “Articles 72 + 26(5) + 73 already constitute a forensic regime” objection was stress-tested against the verbatim text of Articles 26(5), 26(6), 72, 73 and 79 fetched and verified against the artificialintelligenceact.eu source using the GraQle reasoning substrate (synthesis confidence 82 %). The reconciliation framing is the author's; the substrate identified the five forensic properties (defensibility, provenance, tamper-evidence, reconstructability, inspection readiness) that the verbatim provisions do not produce on their text alone.

5. The Second-Order Observation: The Transitional Evidentiary Standard

If the AI Act does not codify forensic readiness, and harmonised standards under Article 40 are not scheduled for availability until Q4 2026 under the CEN-CLC/JTC 21 deliverables target, what standard will national competent authorities use in the period between the December 2027 Annex III enforcement date and the eventual emergence of post-enforcement case law? The question has not been raised on the public LinkedIn thread that produced the forensics-versus-audit framing. It has a defensible operational answer.

GraQle reasoning chain

Second-order observation

The transitional-borrowing hypothesis · not raised on the public LinkedIn thread · defensible operational prediction, not yet a verified fact from published NCA guidance

In the absence of AI-specific harmonised standards under Article 40, the first wave of national competent authorities running 2027 AI Act inspections will most plausibly default to adapting three existing sectoral incident-evidence frameworks by analogy: GDPR Articles 33–34 breach-notification jurisprudence under the European Data Protection Board; the ICT-incident-reporting framework of the Digital Operational Resilience Act (DORA) Articles 17–23; and the cybersecurity-incident-handling framework of NIS2. The transitional-borrowing pattern is a defensible operational prediction; it is not yet a verified fact from published NCA guidance as of mid-2026.

The mechanism is structural rather than speculative. National competent authorities responsible for AI Act enforcement are, in most Member States, the same authorities responsible for adjacent regulatory regimes. The competent person at the supervisory authority who will examine a deployer's AI Act compliance file is, in many cases, the same competent person who has spent the last five years examining the deployer's GDPR breach-notification practice, the last three years preparing for DORA, and the last two years implementing NIS2 cybersecurity-incident handling. The familiar concepts in those adjacent regimes — incident timelines, internal escalation, evidence preservation, root-cause analysis, supervisory reporting, documentation of remedial action — will be the conceptual scaffolding the authority uses to assess an AI Act incident in the absence of harmonised AI-specific forensic standards.

The European Union Agency for Cybersecurity (ENISA) Multilayer Framework for Good Cybersecurity Practices for AI, published on 7 June 2023 (ENISA Multilayer Framework, accessed 5 June 2026), establishes a three-layer cybersecurity model for AI systems across the lifecycle from conceptualisation to decommissioning. While the Framework is a cybersecurity guidance document rather than a forensic standard, it provides the closest European-level reference for the operational discipline an AI Act inspection regime will materially expect. The ENISA Threat Landscape 2025 (October 2025), analysing 4,875 incidents between 1 July 2024 and 30 June 2025, reports that more than 80 percent of global phishing campaigns now use AI-generated or AI-enhanced content — reinforcing the operational urgency of the forensic-readiness question (ENISA Threat Landscape 2025, accessed 5 June 2026).

For AI governance product designers, the practical implication is operational. Build for the transitional standard, not for the harmonised one. Designs that satisfy the GDPR breach-notification + DORA ICT-incident + NIS2 cybersecurity-incident operational discipline will land closest to what first-wave NCAs are most likely to demand under AI Act Articles 73 and 79 in the period between the December 2027 enforcement date and the eventual settlement of AI-specific forensic standards. Specific design properties include: immutable or tamper-evident logs; precise timestamps and time synchronisation; exportable incident records; role-based access controls; retention policies exceeding the Article 26(6) six-month minimum where feasible; documented incident playbooks; chain-of-custody metadata; system, version and model provenance; and the ability to reconstruct AI interactions retrospectively to the standard of the GDPR Article 33 seventy-two-hour breach-notification timetable. The orientation is to build as if the regulator will not ask “did you log it” but “can you prove the log is complete, authentic, and reconstructs the event.”

Analytical method: the transitional-borrowing hypothesis was surfaced through GraQle's reasoning substrate during a structured query that included the verified text of Articles 26(5), 26(6), 72, 73 and 79, the ENISA Multilayer Framework (7 June 2023) and Threat Landscape 2025 (October 2025), and NIST SP 800-86 “Guide to Integrating Forensic Techniques into Incident Response” (Kent, Grance et al., August 2006) (synthesis confidence 82 %; novelty score 0.836). The substrate confirmed the hypothesis is plausible from the regulatory text architecture but flagged that the supplied evidence does not include published mid-2026 NCA guidance settling the borrowing pattern. The framing is therefore presented as a defensible operational prediction for governance product designers, not as a verified fact about regulator behaviour.

6. What This Means for an Enterprise Reader

For a CRO, CISO, Head of AI Risk, or General Counsel preparing for the December 2027 enforcement date, the practical consequences of the forensics-versus-audit distinction fall into three working requirements that have to be reflected in the deployer's control framework regardless of which AI Act provision the framework is being assessed against.

  1. Treat the Article 26(6) six-month log retention floor as a starting point, not a ceiling. The Regulation's minimum retention is a duty floor; the operational forensic-readiness standard the transitional-borrowing pattern will impose is materially higher. Logs that survive only six months may satisfy Article 26(6) on its text and fail the transitional regulator's evidence-preservation expectation derived from GDPR breach-notification practice, where supervisory authorities routinely require records spanning years where adjudication is in progress.
  2. Build the audit trail to a forensic standard, not an audit standard. The five forensic properties not produced by the verbatim Articles — evidentiary defensibility, provenance, tamper-evidence, reconstructability, and inspection readiness — have to be designed into the deployer's control framework operationally even though the Regulation does not require them textually. The cost is engineering discipline up front; the alternative is reconstruction discipline under adversarial conditions when an Article 73 incident occurs and the fifteen-day, two-day or ten-day reporting deadline starts running.
  3. Map the deployer's AI Act incident-response playbook against GDPR Article 33, DORA Article 17, and NIS2 incident-reporting concepts. If the deployer is already operating those regimes, the AI Act incident-response architecture should compose with them, not duplicate them. The competent person at the supervisory authority who will eventually conduct the inspection will recognise the borrowed conceptual scaffolding and assess against it. The deployer that has aligned its AI Act forensic readiness to the regime the same authority already uses for adjacent cases will be assessed against a familiar standard. The deployer that has built a parallel AI Act-only architecture will be assessed against a standard the authority is constructing in real time.

For the architecture-layer reading of how the substrate has to be built to support forensic readiness, see Cluster 1 on recall versus verifiability. For the procurement-side reading of how to evaluate vendors against this discipline, see Cluster 2 on the five-question procurement diagnostic. For the operational-control reading of the five dimensions that compose to produce forensic readiness, see Cluster 3 on the five dimensions. For the layer mapping showing where the forensics layer sits alongside methodology, architecture and standards, see Cluster 4 on the three layers most platforms conflate. For the director-attestation layer that closes the personal-evidence question, see Cluster 5 on director attestation under Articles 26 and 27.

7. Cross-Series Synthesis — What the Six Clusters Surfaced

This is the final cluster in the six-piece series. The pieces composed against a single public LinkedIn exchange between senior practitioners that ran from 11 to 17 May 2026. Across the series, the GraQle reasoning substrate was used to stress-test the strongest counter-arguments and surface second-order observations that the public thread had not raised. The synthesis below organises the substrate's outputs into three categories.

7.1 Insights Aligned With the Public Thread

Five observations emerged on the public LinkedIn thread and were independently confirmed by GraQle's reasoning against the verified regulatory text. These form the foundational layer of the series and should be treated as the settled common ground.

  • Recall is not verifiability. Peter Borner's formulation that “architecture solves the recall problem; it does not solve the verifiability problem” reflects a real architectural distinction the AI Act's Article 12 text does not itself codify but the post-Omnibus inspection regime under Articles 72 and 26(5) will functionally test. Confirmed at synthesis confidence 75% in Cluster 1.
  • Methodology cannot be back-filled. Andrii Matiash's formulation that a vendor can generate logs retroactively but cannot retroactively claim a documented scoring methodology existed before deployment is operationally consequential and aligned with the Article 17(g) and (h) sub-paragraphs of the QMS obligation. Confirmed in Clusters 1, 4.
  • The procurement diagnostic exceeds the regulatory floor. Antra Picard's five-question pre-onboarding legitimacy test asks vendors to demonstrate operational reality, not statutory compliance. Confirmed by GraQle at 86% synthesis confidence in Cluster 2; the diagnostic is defended on procurement-discipline grounds, not legal-citation grounds.
  • The director's personal verifiability is not the system's verifiability. Guy Miller's formulation that no governance platform today answers the fourth question one layer up is structurally correct: Articles 26, 27 and 99 regulate the deployer organisation, not the named director as a separate AI Act subject. Confirmed at 87% in Cluster 5.
  • Governance without forensic ground truth is a paper shield. Adil Ali's formulation reflects a real discipline gap: the Regulation creates monitoring and reporting duties without codifying forensic readiness as a separate layer. Confirmed at 82% in this Cluster 6.

7.2 GraQle-Surfaced Insights That Complement the Public Thread

Six observations emerged from the GraQle reasoning substrate that the public LinkedIn thread had not raised. Each is anchored in verified regulatory text. Each is presented in its respective cluster as a defensible second-order observation rather than a settled fact. Together they form the moat of the series — the material no other AI governance vendor on the European market is currently publishing with the underlying reasoning trail disclosed.

  • Evidence-portability procurement at fleet scale. The composition of Articles 26(5), 72 and 79(1) at the scale at which national competent authorities will inspect across thousands of deployments produces a procurement pattern in which the winning vendor is not the one with the best governance story but the one whose evidence survives comparative regulatory sampling across multiple vendors and staff turnover at the deployer. Surfaced at synthesis confidence 91% in Cluster 2.
  • Question 5 is the one a vendor can legitimately decline. Under Article 26 the live production audit log is the deployer's record, not the provider's. A vendor that returns Question 5 to the deployer is correctly respecting EU AI Act value-chain role allocation rather than exhibiting weak architecture. Surfaced at 81% in Cluster 2.
  • LLM governance decomposes by invocation, not by model version. For traditional ML the unit of governance is the model artefact; for LLM-based deployments the unit shifts to the decision event. The five operational dimensions of regulator-grade governance still apply but have to be satisfied per invocation, requiring a per-inference evidence-binding architecture the model-centric vendor stack does not produce. Surfaced at 74% in Cluster 3.
  • Bundling under information asymmetry. The conflation of methodology, architecture and standards into a single “compliance platform” is economically attractive for vendors because buyers cannot reliably price the three layers separately. The regulator's tool is not to ban bundling but to force separability in proof through Article 17 documentation, the Article 40 conformity-presumption pathway, and disaggregated procurement specifications under Article 26. Surfaced at 78% synthesis with novelty 0.85 in Cluster 4.
  • The Article 27 FRIA as the closest existing director-attestation primitive. The Fundamental Rights Impact Assessment is, on its statutory text, an organisational artefact. With six governance controls added — named signatory, personal certification, evidence pack, retention beyond departure, independence from vendor artefacts, audit-trail linkage — it becomes the closest available statutory analogue to the director-personal-attestation primitive Miller identified as missing. Surfaced at 87% synthesis with novelty 0.86 in Cluster 5 — the highest novelty score in the series.
  • The transitional-borrowing hypothesis. Between the December 2027 Annex III enforcement date and the eventual emergence of post-enforcement case law, first-wave national competent authorities are most plausibly going to apply GDPR Article 33–34, DORA Article 17–23 ICT-incident, and NIS2 cybersecurity-incident frameworks by analogy to AI Act serious incidents, because the same competent persons run all four regimes within the same national authority. Surfaced at 82% with novelty 0.836 in this Cluster 6.

7.3 Where the Public Thread and GraQle Have Not Yet Aligned

Three open questions remain on which the public LinkedIn thread and the substrate's reasoning have not converged. These are the areas where the next cycle of public discourse will have the most to add.

  • The agentic-systems boundary. The series' analytical frame assumes a discrete decision (traditional ML) or a discrete invocation (LLM-based) as the unit of governance. For agentic AI systems that take multi-step action chains with behavioural drift, the unit of governance is neither. The Nannini et al. working paper “AI Agents Under EU Law” (arXiv:2604.04604, submitted 6 April 2026) flags that high-risk agentic systems with untraceable behavioural drift cannot currently satisfy the AI Act's essential requirements. The series has identified the boundary repeatedly; neither the public thread nor the substrate has yet proposed an operational decomposition. This is the highest-value open question for the next cycle.
  • The personal-liability case-law vacuum. The series has identified five distinct national-law routes through which personal director exposure may attach to an AI Act compliance failure, while observing that the published case-law base is empty because Annex III enforcement begins 2 December 2027. The public thread has stated that personal director liability will attach; the substrate has stated that the legal mechanism is not yet settled. The first directors to face inspection in early 2028 will, in practice, be the test cases that resolve the gap.
  • The harmonised-standards-availability gap. CEN-CLC/JTC 21 deliverables under M/593 (amended by M/613 of 14 January 2025) target Q4 2026 availability. The Annex III enforcement date is 2 December 2027. The window between the standards being available and the enforcement starting is narrow, and the standards-layer ownership in the OATS framework is therefore in a transitional state neither the public thread nor the substrate has resolved.

These three open questions are the natural feedstock for the next cycle of public discourse on the EU AI Act audit-trail framework. They are also the research backlog the next iteration of the GraQle substrate should be calibrated against.

GraQle reasoning chain

What is GraQle, and why does it appear in the footnotes of this piece?

A reasoning substrate, not an oracle. Used here as the stress-test the argument was put through before it was published.

GraQle is the open developer-side reasoning substrate built by Quantamix Solutions B.V. It operates at the architecture layer of the EU AI Act audit-trail stack described in the pillar piece for this series. The SDK organises a project's documented sources — regulatory text, named-contributor quotations, internal architecture decisions, prior published pieces — into a knowledge graph against which structured reasoning queries can be run.

For this piece, GraQle was used in two specific ways. First, to stress-test the strongest counter-argument that Articles 72, 26(5) and 73 already constitute a forensic regime, against the verbatim text of those Articles and the verified ENISA and NIST forensic-readiness sources. Second, to surface the transitional-borrowing hypothesis in Section 5 from a structured query about which evidentiary standard NCAs are most likely to apply before AI-specific harmonised standards exist; the resulting framing entered the piece only after the underlying regulatory composition had been verified by hand.

The confidence figure cited (82 %) is the synthesis-level confidence reported by the substrate after multi-agent reasoning over a verified corpus. The accompanying novelty score (0.836 on the transitional-borrowing observation) indicates the observation is genuinely not present in the prior public discourse. Both figures are diagnostic, not authoritative. Every legal conclusion and every editorial judgement in this piece is the author's, and every regulatory citation has been verified independently against the source text (Article 73 reporting time limits, Article 79 procedural framework and authority powers, ENISA Multilayer Framework 7 June 2023 publication date, NIST SP 800-86 August 2006 authorship). The substrate's contribution is to make the reasoning trail inspectable rather than tacit — the same posture this series argues procurement teams should require of any AI governance vendor under inspection.

GraQle is EU AI Act–aligned by design, not certified, and is itself the substrate that the architecture-layer analysis in this series describes. The vocabulary discipline governing every external statement about GraQle is recorded in ADR-MARKETING-001 in the project's decision archive. More on the technical architecture is in the GraQle intelligence engine for governance and the TAMR+ research paper that underlies the substrate.

GraQle SDK:pip install graqlegithub.com/quantamixsol/graqleEU AI Act compliance docs

Frequently Asked Questions

What is forensic ground truth in the EU AI Act context?

The body of evidence that survives adversarial inspection — not because a system logged something, but because the log is provenance-tagged, tamper-evident, chain-of-custody-preserved, and reconstructable into a defensible account of what the AI system actually did at the time of the consequential decision. The framing was named publicly by Adil Ali on LinkedIn in May 2026: governance without a forensic ground truth is just a paper shield.

What does Article 73 of the EU AI Act require?

Providers of high-risk AI systems placed on the Union market shall report any serious incident to the market surveillance authorities of the Member States where the incident occurred. Time limits: 15 days standard; 2 days for widespread infringement or Article 3(49)(b) serious incidents; 10 days where the incident has involved the death of a person. Primary obligor is the provider; the deployer reports where applicable.

Does the EU AI Act require chain of custody for AI audit logs?

Not on its verified text. Article 26(6) requires log retention of at least six months. Article 26(5), Article 72, Article 73, and Article 79 create monitoring, reporting and enforcement duties. None of these provisions explicitly requires chain-of-custody preservation, tamper-evident records, provenance metadata, or forensic evidentiary admissibility standards. Forensic readiness is implicit in the Regulation's architecture, not codified by it.

What transitional evidentiary standard will NCAs likely use before AI Act case law settles?

National competent authorities are most plausibly going to apply GDPR Article 33–34 breach-notification jurisprudence, DORA Article 17–23 ICT-incident-reporting frameworks, and NIS2 cybersecurity-incident handling by analogy to AI Act serious incidents in the period between the December 2027 Annex III enforcement date and the eventual emergence of AI-specific case law. The transitional-borrowing pattern is a defensible operational prediction, not yet a verified fact from published NCA guidance as of mid-2026.

What is the ENISA Multilayer Framework?

The European Union Agency for Cybersecurity (ENISA) released its Multilayer Framework for Good Cybersecurity Practices for AI on 7 June 2023. It establishes a three-layer cybersecurity model addressing AI system lifecycle from conceptualisation to decommissioning. While not a forensic-readiness standard, it provides the closest available European-level reference for the operational discipline an AI Act inspection regime will materially expect.

Sources cited above (all verified and accessed 5 June 2026):

  • EU AI Act Article 3 — Definitions (particularly Article 3(49) on serious incident) — artificialintelligenceact.eu/article/3/
  • EU AI Act Article 26 — Obligations of Deployers (particularly 26(5) and 26(6)) — artificialintelligenceact.eu/article/26/
  • EU AI Act Article 72 — Post-Market Monitoring — artificialintelligenceact.eu/article/72/
  • EU AI Act Article 73 — Reporting of Serious Incidents (15/2/10 day reporting windows verified verbatim) — artificialintelligenceact.eu/article/73/
  • EU AI Act Article 79 — Procedure for AI Systems Presenting a Risk at National Level (cross-references Reg (EU) 2019/1020 Article 3(19); 15 working days operator deadline; 3-month / 30-day objection window) — artificialintelligenceact.eu/article/79/
  • EU AI Act Article 99 — Penalties — artificialintelligenceact.eu/article/99/
  • Regulation (EU) 2019/1020 — Market surveillance and compliance of products (referenced by Article 79) — EUR-Lex
  • GDPR Articles 33 and 34 — Personal data breach notification — gdpr-info.eu
  • Regulation (EU) 2022/2554 (Digital Operational Resilience Act, DORA) — Articles 17 to 23 on ICT-related incident management and reporting — EUR-Lex
  • Directive (EU) 2022/2555 (NIS2) — Cybersecurity incident-handling framework — EUR-Lex
  • ENISA — Multilayer Framework for Good Cybersecurity Practices for AI — published 7 June 2023 — enisa.europa.eu/publications/multilayer-framework-for-good-cybersecurity-practices-for-ai
  • ENISA — Threat Landscape 2025 — October 2025 — 87 pages, 4,875 incidents analysed 1 July 2024 to 30 June 2025 — enisa.europa.eu
  • NIST SP 800-86 — ‘Guide to Integrating Forensic Techniques into Incident Response’ — Karen Kent, Tim Grance (NIST), Suzanne Chevalier, Hung Dang (BAH) — August 2006 — csrc.nist.gov
  • Nannini, L. et al., ‘AI Agents Under EU Law’, arXiv:2604.04604 (submitted 6 April 2026)
  • Orrick, ‘EU's Digital Omnibus on AI: 7 Key Changes You Need to Know’, 7 May 2026 — orrick.com
  • All contributor quotes are reproduced verbatim from public LinkedIn posts and comments published in May 2026. Each contributor is named with their full name, role and LinkedIn profile URL at first mention. The Adil Ali Q10 quote contains the word “Question” rendered verbatim from the LinkedIn corpus extraction (the raw OCR rendering “Quesshiel” in the DOCX export is an extraction artefact; the intended word is “Question” per the Adil Ali source-quotes file and Adil's reply context).

Method note: the counter-argument analysis in Section 4 and the second-order observation in Section 5 (transitional-borrowing hypothesis) were stress-tested against verbatim EU AI Act text of Articles 26(5), 26(6), 72, 73 and 79 fetched and verified against the artificialintelligenceact.eu source, the ENISA Multilayer Framework publication metadata, and the NIST SP 800-86 authorship and publication date. The full method, including what GraQle is and how confidence figures should be read, is in the explainer above the citations.