What exactly starts on 11 September 2026?

The Article 14 reporting obligations. From that date manufacturers report actively exploited vulnerabilities and severe incidents to ENISA and their designated CSIRT coordinator through ENISA's Single Reporting Platform, with an early warning inside 24 hours, a notification inside 72 hours, and a final report within 14 days of a corrective measure becoming available. The essential requirements, conformity assessment, and CE marking obligations follow on 11 December 2027.

Does the checklist apply to products already on the market?

The reporting duties do, which is the part teams miss. A product shipped in 2024 that calls a model endpoint carries the same 24-hour obligation from 11 September 2026 as one shipped afterwards. The essential-requirements items on this list become mandatory for products placed on the market from 11 December 2027, and building them earlier is what makes the reporting duty survivable in the meantime.

Who reports, the manufacturer or the model provider?

The manufacturer of the product with digital elements files the report for its own product. A model provider has its own obligations for its own products where the CRA reaches them. That split is precisely why a destination log matters: attributing an incident across the boundary requires knowing which endpoint served which request, and AI vendor due diligence covers what to ask for contractually.

How much of this overlaps with the EU AI Act?

The overlap between the two regimes runs deep. EU AI Act Article 19 logging requires automatic event recording for traceability, and CRA Annex I Part I (l) requires recording and monitoring for security. One identity-bound, classified, independently written per-request record answers both, alongside NIS2 AI logging requirements for entities in that scope.

Which item should we start with if we have four weeks?

Items 2 and 3. The endpoint inventory tells you what is genuinely in scope, and identity binding is the control every later artifact depends on, because a record that cannot name the caller answers nothing at hour three of a 24-hour clock. Item 9 follows immediately after, since a rehearsal is what converts the first two into a working reporting capability.

EU Cyber Resilience Act AI Compliance Checklist: Ten Items Before 11 September 2026

Article 14 of the Cyber Resilience Act gives a manufacturer 24 hours to file an early warning with ENISA and its CSIRT coordinator once it reaches a reasonable degree of certainty about an actively exploited vulnerability or a severe incident. Those duties commenced on 11 September 2026, fifteen months ahead of full application on 11 December 2027, and they attach to products already placed on the market rather than only to future releases.

Regulation (EU) 2024/2847 covers products with digital elements. A product whose output comes back from a hosted model endpoint it selected, carrying data it assembled, exercises its security-relevant behaviour through that outbound call. This list covers the ten actions that make Annex I answerable for that call. Each item names the point it serves and the artifact it produces, because a notified body reads artifacts rather than intentions.

1. Decide, in writing, whether the model call is in scope

Record the scoping determination for the inference endpoint and the reasoning behind it, including whether it counts as a remote data processing solution necessary for the product to perform its functions. Evidence is a scoping memo in the technical documentation set. Doing this first stops the remaining nine items from being scoped against a diagram that stops at your own repository boundary.

2. Inventory every endpoint the product actually calls

Pull 30 days of production traffic and list the model endpoints, regions, and providers behind them. Evidence is a destination inventory reconciled against the declared component list. Annex I Part II asks for a software bill of materials in a machine-readable format, and orchestration libraries plus model providers routinely sit behind what the bill records as one dependency.

3. Bind a named principal to every inference request

Annex I Part I point (d) requires protection from unauthorised access through authentication, identity, and access management mechanisms. Route AI traffic so the end user or agent identity travels into the policy decision rather than collapsing into one shared key. Evidence is an identity-bound per-request record, produced by the pattern in identity-aware AI gateway architecture.

4. Classify and minimise the payload before it leaves

Points (e) and (g) cover confidentiality of processed data and processing only what is adequate, relevant, and limited to the intended purpose. A context window assembled from a retrieval store, a user message, and a system prompt regularly carries more than the purpose needs. Evidence is a per-request classification decision plus the redaction or block that followed, which prompt-level DLP produces at transmission.

5. Move the record off the component that makes the call

Point (l) requires recording and monitoring relevant internal activity, including access to or modification of data, services, or functions. An application that makes the model call and writes its own record is attesting to itself, and that arrangement loses exactly the edge cases a report needs. Evidence is an independently written, signed decision record, and the property is set out in AI audit log immutability.

6. Give users the opt-out that point (l) requires

Point (l) attaches an opt-out mechanism for the user to the recording requirement. Design the record so the opt-out removes what it must remove and preserves the security-relevant fields you still need, rather than switching off the whole write path. Evidence is a documented opt-out behaviour with a worked example of what a record looks like on each side of it.

7. Fail closed on an unapproved destination

Route requests only to allowlisted endpoints, and reject rather than pass through when the destination, the classification, or the policy state is ambiguous. Evidence is a policy decision record showing the fail-closed outcome, which is the difference between a control and a preference. Fail-closed AI gateway covers the operational trade-off honestly.

8. Stamp the model, version, and policy revision onto each decision

Repointing a route from one model version to another changes production behaviour, and a report filed months later has to describe the configuration in force at the time rather than today's. Evidence is a version-stamped decision record joined to a change record, supported by AI policy versioning.

9. Rehearse the 24-hour reconstruction

Run the query you would need at hour three of an Article 14 clock: which requests, carrying which classifications, from which principals, reached which endpoints, in a named window. My honest take: this is the item every team defers, and it is the one that decides whether the 72-hour notification describes an incident or describes an investigation still in progress. Evidence is a reconstructable timeline, which is what an AI incident response playbook runs against.

10. Set retention against the ten-year documentation duty

Annex VII technical documentation has to be kept for ten years after the product is placed on the market or for the support period, whichever is longer. Anything the documentation references inherits a retention expectation. Evidence is a retention policy with the periods written down, compared across regimes in AI audit log retention requirements.

The checklist at a glance

What the sequence buys you

Items 3, 4, and 5 are load-bearing. Identity binding makes a record answer the question an assessor actually asks, classification makes it describe what left, and write-path independence makes it evidence instead of assertion. The other seven items are tractable once those three exist, and they stay expensive as long as any one of them is missing.

The CRA controls mapping covers where each control fires in the request path. The CRA audit-evidence view covers what each artifact looks like when a market surveillance authority asks for it.

DeepInspect

Items 3 through 9 produce their evidence at one place: the boundary between the product and the LLM APIs it calls. DeepInspect sits inline at that boundary as a stateless proxy. 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 with their regions, and writes a signed record of the decision before the response returns to the caller.

For a manufacturer working against the Article 14 clock, that turns the reconstruction into a query rather than a week of interviews compressed into 21 hours. Book a technical deep dive at deepinspect.ai.