EU Cyber Resilience Act AI Audit Evidence: What the 24-Hour Clock Asks You to Produce

On 11 September 2026, the reporting duties in Article 14 of the Cyber Resilience Act start running. From that date a manufacturer that reaches a reasonable degree of certainty about an actively exploited vulnerability or a severe incident affecting the security of its product has 24 hours to file an early warning, 72 hours to file a notification, and 14 days after a corrective measure is available to file the final report. Reports go to ENISA and the designated CSIRT coordinator through ENISA's Single Reporting Platform, and they cover products already on the market, not only those shipped after full application on 11 December 2027.

Regulation (EU) 2024/2847 entered into force on 10 December 2024 and applies to products with digital elements. A product that calls a hosted model on behalf of its users is a product with digital elements whose behaviour depends on a third-party inference endpoint, which pulls the outbound AI call inside the scope of the essential requirements. I want to walk the Annex I points that call touches and name what each one asks you to hand over.

Annex I Part I (d): protection from unauthorised access

Point (d) requires protection from unauthorised access through appropriate control mechanisms including authentication, identity, and access management systems. A product that authenticates its users at the front door and then makes every model call with a single shared key satisfies the first half of that sentence and leaves the second half undone at the point where regulated content leaves the product.

The artifact an assessor asks for is a record binding a named principal to a specific inference request, showing that the access control mechanism reached the outbound call rather than stopping at the session. The design that produces it is set out in identity-aware AI gateway architecture.

Annex I Part I (e) and (g): confidentiality and data minimisation

Point (e) requires protecting the confidentiality of stored, transmitted, and otherwise processed data, including through encryption in transit. Point (g) requires processing only data that are adequate, relevant, and limited to what is necessary for the intended purpose.

TLS answers point (e) for the wire. Neither point is answered by the wire when the question is what went into the payload. A context window assembled from a retrieval store, a user message, and a system prompt frequently carries more than the intended purpose needs, and no catalogue label attaches to that assembled object. The evidence is a classification decision applied to prompt content before transmission, plus the redaction or block that followed, which prompt-level DLP produces at the boundary.

Annex I Part I (l): recording and monitoring relevant internal activity

Point (l) requires the product to provide security-related information by recording and monitoring relevant internal activity, including access to or modification of data, services, or functions, with an opt-out mechanism for the user.

A model call is access to a service and, through the retrieval layer feeding it, access to data. The demanding property is custody. An application that makes the model call and also writes the record is attesting to itself, and that record breaks in three specific ways: it logs the successes and misses the edge-case failures, it can be modified by the same component that failed, and a crash between the model response and the log commit leaves the action taken with the evidence gone. The artifact is an independently written, signed decision record, described in AI audit log immutability.

Annex I Part II: vulnerability handling and the software bill of materials

Part II covers the processes rather than the properties: identifying and documenting vulnerabilities and components, producing a software bill of materials in a commonly used machine-readable format, and running coordinated disclosure and security updates across the support period.

The AI-specific gap sits in the component inventory. An orchestration library, a vector store, and two model providers can sit behind what the bill of materials records as one dependency, and the model endpoints a product actually calls in production are frequently absent from it entirely. The artifact that closes this is a destination log naming every endpoint called during the period, reconciled against the declared component list. That reconciliation is the same exercise shadow AI discovery runs under a different heading, and it typically surfaces at least one endpoint nobody declared.

Article 14: what the 24-hour clock actually needs

The early warning at 24 hours is short by design. The 72-hour notification asks for the nature of the vulnerability or incident and the corrective measures taken, and the final report asks for the full account. Every one of those documents rests on a reconstruction: which requests, carrying which content, from which principals, reached which endpoints, during which window.

Picture the position of the on-call engineer at hour three of that clock, holding an application log that records that a call was made and nothing about who made it or what was in it. That reconstruction is either a query or it is a week of interviews compressed into 21 hours. The artifact is a retained, independently written request timeline, which is what an AI incident response playbook assumes exists before it runs.

The evidence map

Annex VII technical documentation has to be kept for ten years after the product is placed on the market, which sets the retention floor for anything referenced in it. AI audit log retention requirements covers how that compares with the other regimes a single product usually sits under.

Where teams are getting this wrong

A common CRA readiness pattern scopes the conformity assessment around the product's own code and treats the model call as an external service call, and therefore somebody else's control. My honest view: that scoping decision is the one that will fail first, because Annex I attaches to the behaviour of the product as placed on the market, and a product whose output is produced by an endpoint it chose, with data it assembled, is exercising that behaviour through the call. Treating the inference request as out of scope moves the paperwork, not the obligation.

The CRA controls mapping covers where each control fires in the request path, and the CRA compliance checklist covers the order to build them in before 11 September.

DeepInspect

Five of the six rows above produce their evidence at one place: the boundary between the product and the LLM APIs it calls. DeepInspect sits inline at that boundary. It binds identity to each request, classifies and redacts prompt content before transmission, enforces per-role and per-route policy with a fail-closed default, allowlists and records destinations, and writes a signed record of the decision before the response returns.

For an Article 14 report, that turns the reconstruction into a query against records the product never had custody over: the caller, the classification carried in the prompt, the endpoint and region, the policy revision in force, and the outcome. Book a technical deep dive at deepinspect.ai.