AI Act Records: Awareness Starts the Clock

“Deployers of high-risk AI systems shall keep the logs automatically generated by that high-risk AI system to the extent such logs are under their control, for a period appropriate to the intended purpose of the high-risk AI system, of at least six months, unless provided otherwise in applicable Union or national law, in particular in Union law on the protection of personal data.” That is Article 26(6) of the EU AI Act as the AI Act Service Desk gives it in the consolidated text of 27 July 2026, and Article 19(1) places the same duty on the provider for the logs under its control. Both bind providers and deployers of high-risk systems only, and under Article 113 as amended by the Digital Omnibus they bind from 2 December 2027 for the Annex III systems and from 2 August 2028 for the Annex I products. Outside the high-risk classes the Act sets no retention floor, whichever model the platform runs on, and most agent platforms sit there. What October 2026 showed is what authorities ask for wherever the floor sits.

The requests came in sequence. On 29 August 2026 the AI Office issued its first formal requests for information. The law firm Matheson described them on 25 September as two sets, one on general-purpose model safety, security, external evaluations and post-market monitoring, one on transparency and copyright sent to more than 30 AI companies, and noted that the Commission named no recipient. On 12 October the Commission published four recommendations from a special meeting of the AI Scientific Panel, held on 9 October about what it called recent loss-of-control incidents. The same page says that “the AI Office has already requested and received serious incident reports and sent requests for information on security practices”, and one recommendation asks the EU to “strengthen EU capabilities related to detection, evaluation and investigation of incidents of this nature”. It names no company.

On 14 October Henna Virkkunen, the Commission's Executive Vice-President for Technological Sovereignty, told the International AI Summit in Dublin that “our AI Office has started enforcing these rules, and sent requests for information addressing issues such as security, external evaluation and monitoring how models are used”. Euronews, which reported the line, wrote in its own voice that the AI Office is investigating OpenAI and Anthropic and sent its requests after judging that the documents the two companies had voluntarily disclosed were insufficient; neither Commission page about the panel meeting names a company or mentions the documents. The same report quoted an unnamed Commission official: “We won't enforce in the testing phase. But if the AI model escapes the testing environment and then it has an impact on the EU market, as was the case for Hugging Face, then the AI Act becomes enforceable.”

The United States asked in the same week. CBS News reported on 15 October that the Federal Trade Commission had sent civil investigative demands to Anthropic and OpenAI the day before, in a consumer protection probe opened in the summer, seeking records on safety incidents, privacy policies and safeguards. Axios reported the demands first, an FTC spokesperson confirmed them to CBS, and Engadget's account lists “documents regarding security incidents and safeguards”. Nothing has been found or charged; records were requested. On 19 October Jessica Rusu, the FCA's chief data, information and intelligence officer, said in a speech for the Bloomberg UK Policy Series, in the text the FCA published, that “our rules already require firms to report major incidents, and that must extend to significant AI failures and near-misses”.

Who answers whom, and from when

Article 75(1), as amended, makes the AI Office “exclusively competent for the supervision and enforcement” for two groups of systems, with exclusions. The first is systems “based on general-purpose AI models where the model and the system are developed by the same provider, or by providers forming part of the same undertaking as that provider”. The second is systems integrated into a very large online platform or search engine. It reaches deployers “only when they are also the provider or form part of the same undertaking as the provider”. A team building on a model it did not train is outside the first group, and outside the second unless its system sits inside a very large online platform or search engine; for everyone else the authority under Article 73(1) is the market surveillance authority of the Member State where an incident occurred.

• Provider of a high-risk system. Logs for at least six months under Article 19, documentation for ten years under Article 18, serious incident reports under Article 73.
• Deployer of a high-risk system. Logs for at least six months under Article 26(6), and on a serious incident the duty to “immediately inform first the provider, and then the importer or distributor and the relevant market surveillance authorities”. If the provider cannot be reached, Article 73 applies to the deployer directly.
• Provider of a general-purpose model with systemic risk. The one duty already in force, since Chapter V applied on 2 August 2025. Article 55(1)(c) says such providers “keep track of, document, and report, without undue delay, to the AI Office” relevant information about serious incidents. The Commission's 12 October sentence, that the AI Office has requested and received serious incident reports, reads as that article at work; the page does not say which provision it used.
• None of these. No retention floor and no reporting clock under the Act today. What binds is contract, sector rules such as the FCA's, and the customer who is a high-risk deployer and asks for the logs “under their control”.

Most agent deployments are not high-risk systems, and whether yours is one turns on Annex III and on counsel. The rest of this article is about what a team keeps so that a customer, an insurer or an authority gets a complete answer on the day the request lands.

Record the run as events, kept apart from the content

Article 12(1) frames the record as events: a high-risk system “shall technically allow for the automatic recording of events (logs) over the lifetime of the system”. Article 12(2) says what they are for: identifying situations that may present a risk under Article 79(1) or amount to a substantial modification, post-market monitoring under Article 72, and the deployer's monitoring under Article 26(5). Its one concrete field list, Article 12(3) for the biometric systems of Annex III point 1(a), reads as a pattern: when the system was used, against what, with which input, and which human checked.

The 16 October document from NIST's CAISSI, the NSA's Super Intelligence Security Center and CISA, “Key Practices for Incident Readiness and Response in Super Intelligence Training and Evaluation”, gives the same shape for agents. It is voluntary, it says it “does not constitute advice for compliance, regulatory, or legal purposes”, and it sets no retention period. Its practice 5.3 reads: “Retain tamper-resistant logs with reliable timestamps sufficient to reconstruct agent trajectories, tool calls, reasoning traces, user interactions, environmental states, and security-control decisions.” Practice 5.1 adds “sandbox and network logs, and rejected actions and tool calls”. Between the two texts the run record has four parts.

• Actor and principal. The agent identity that acted and the user, tenant or schedule it acted for, taken from the credential and never from a header the agent could write.
• Tool, target and scope. The tool called, the resource touched, the permission that allowed it, and the verdict of every control it passed, refusals included. The tool call policy guide covers writing that verdict before the effect.
• Egress. Every external destination the run reached, as the proxy saw it, which turns “what did the agent touch outside your estate” into a query.
• Versions and time. Model, prompt and policy versions, and a UTC timestamp from a clock you trust. The Hugging Face timeline is written to the minute in UTC, and yours will be read the same way.

Write these with the run, into a stream of their own, and keep the content (prompts, outputs and reasoning traces) in a second stream. Articles 19 and 26(6) both yield to Union data protection law, and the event stream, which carries identifiers and decisions rather than text, is the one you can defend keeping for the whole period. The content stream carries personal data by nature and runs on a shorter schedule, with one rule attached: the moment an incident is opened, the content for its window is exported and locked before the schedule reaches it, because the reconstruction needs the traces and the complete report under Article 73(5) needs the reconstruction.

Six months is the floor, and late detection sets the number

The Act's periods come in three sizes. Logs are kept “at least six months” and for a period “appropriate to the intended purpose” under Articles 19 and 26(6). The technical documentation and the other Article 18 documents are kept “for a period ending 10 years after the high-risk AI system has been placed on the market or put into service”. Financial institutions keep the logs inside the documentation they already hold under financial services law, under Article 19(2) and the last sentence of Article 26(6). Six months is the floor in the text. The number for a live system comes from how late an incident gets noticed.

Anthropic's own disclosure of 30 July 2026 is the plain case. After reviewing 141,006 evaluation runs it found three incidents across six runs that reached three organisations, notified them on 27 July, and wrote that “the two organizations we were able to reach had not previously detected the activity or contacted us”. A victim who first hears of an intrusion from the other side needs records that reach back further than its own alerting did. Hugging Face's technical timeline of 27 July covers an intrusion between 2026-07-09 02:28 and 2026-07-13 14:14 UTC. The team reconstructed it by retrieving the agent's logs from the external sandbox and correlating them with the platform's own, “in particular from the dataset processor nodes, API, and pod”; the sandbox egress guide tells that attack chain. The retention policy that allows for both cases is short.

# Loki 3.x: retention runs in the
# compactor; without this block the
# periods below are read and ignored
compactor:
  working_directory: /loki/retention
  compaction_interval: 10m
  retention_enabled: true
  retention_delete_delay: 2h
  delete_request_store: s3
  # needs a 24h index period and
  # store credentials at start

limits_config:
  # DEFAULT: everything unlabelled
  retention_period: 744h
  retention_stream:
    # EVENTS: the floor is 4416h,
    # six months; a year is safer
    - selector: '{class="event"}'
      priority: 2
      period: 8784h
    # CONTENT: prompts and outputs,
    # 30 days, exported on a case
    - selector: '{class="content"}'
      priority: 1
      period: 720h

Loki applies a stream's period only when the compactor has retention_enabled set; without that block the periods under limits_config do nothing. The event stream gets a year, 8784 hours, and an incident noticed five months late still has its records; the floor would be 4416, because six calendar months can run to 184 days. Content gets 30 days and a hold procedure. Loki offers no tamper evidence, and the hold is therefore an export of the case window to write-once object storage, hashed, with the hash written into the case file; that is what “tamper-resistant logs with reliable timestamps” costs in practice. Change records belong on the same footing: a dated, signed record of when a control landed is the first thing an investigator asks for after the timeline.

Awareness starts the clock

Article 73(2) sets the general deadline: the report is made immediately after a causal link, or its reasonable likelihood, is established, “and, in any event, not later than 15 days after the provider or, where applicable, the deployer, becomes aware of the serious incident”. For a widespread infringement, or for an incident under Article 3, point (49)(b), “a serious and irreversible disruption of the management or operation of critical infrastructure”, it is “not later than two days”. For the death of a person it is “not later than 10 days”. Article 73(5) allows an initial incomplete report followed by a complete one, and Article 3(49) lists the four classes: death or serious harm to health, the critical infrastructure disruption, an infringement of Union law protecting fundamental rights, and serious harm to property or the environment.

Every clock runs from awareness, which makes detection a reporting control. Hugging Face wrote that “the first signals came from several layers of our security stack at once: live runtime analysis, SIEM logs, and others”, and that its AI-based security agent stack “failed to correctly raise the alert's criticality and trigger the on-call team”. The post gives no detection timestamp, and nobody outside can say what that cost. The NIST practices speak to this step: 2.1 asks for “clear indicators, criteria, and severity scoring” for control incidents and near misses, and 6.2 for automatic shutdown of impacted agent trajectories when a control failure is detected.

• Classify in the alert, by the Act's classes. Tag each detection rule with the Article 3(49) class it could indicate and the clock that follows, and the on-call engineer reads “49(b), two days” instead of a severity number.
• Let automation raise severity and never lower it alone. An AI triage layer may escalate; a downgrade below the paging threshold needs a human, and that decision is itself written to the event stream, where practice 5.3 wants security-control decisions kept.
• Write the awareness time down. The first human acknowledgement is the timestamp the 15, 2 and 10 days run from, and the report cites it. For a regulated firm the FCA's 19 October line puts a sector entry on the same runbook page.

Watch the clock start

Press Start the clock below. Pick who you are and which Article 3(49) class the incident falls under, and the rail draws the event, the moment of awareness and the deadline the Act attaches to it. Drag awareness later and the records the report needs reach further back, until they cross the retention line and the timeline turns to narrative. The incidents are hypothetical; the clocks and the dates are the Act's own.

Rehearse the reconstruction before anyone asks

The second lesson in the Hugging Face timeline is about counting. “Our first automated scan of the raw capture found very few secrets”, the team wrote; once it replicated the attacker's own decoding and ran the scan again, it recovered roughly four times its initial findings. A report filed on the first count would have been contradicted by the second inside the same 15-day window. Practice 2.2 of the NIST document asks for drills and simulations covering detection, response, recovery and reporting, and 5.5 asks that key facts found with a model's help are verified by human review.

A drill a quarter covers it. Pick a past run, declare it an incident at a random hour, and measure the time to a complete timeline: every destination reached, every control decision, every secret in the egress, decoded the way an attacker would have encoded it. Then rehearse the handover. Article 74(12) gives market surveillance authorities access to the documentation and the training, validation and testing data sets, where appropriate “through application programming interfaces (API) or other relevant technical means and tools enabling remote access”, and says nothing about logs. The Commission's draft implementing regulation for Articles 75c and 75d, open for feedback until 9 November 2026, goes further for the Article 75(1) operators and contemplates “real or near real-time information shared through application programming interfaces”. Practice 8.2 asks for “detailed timelines and transcripts” for affected parties; 9.1 puts the legally required reports first; 9.3 holds the voluntary sharing with CAISSI and the NSA until those are done; 10.2 asks the operator to give third parties enough access and documentation to review the incident. One build answers all of them: a per-case export, scoped to one window, with integrity proofs, read through a credential that expires. The ICO's call for evidence on agentic AI closes on 20 November 2026. The questions are public, and a drill shows whether your records answer them.