EU Cyber Resilience Act AI Controls Mapping: Annex I Against the Outbound Model Call

Annex I of the Cyber Resilience Act divides into two parts: properties the product must have, and processes the manufacturer must run. For a product that produces its output by calling a hosted model, a surprising share of Part I gets exercised inside one HTTPS POST leaving the product boundary, carrying a context window the product assembled, addressed to an endpoint the product selected.

That request is the control point. It is where the caller is still known, where the payload is still readable, where the destination is still a choice, and where a record either gets written or stops existing. Regulation (EU) 2024/2847 entered into force on 10 December 2024, its Article 14 reporting duties commenced on 11 September 2026, and the essential requirements apply from 11 December 2027. This maps the Annex I points onto controls that fire in that request.

Annex I Part I (d): access control

Point (d) requires protection from unauthorised access by appropriate control mechanisms, including authentication, identity, and access management systems. Front-door authentication satisfies this for the session and says nothing about the outbound call, where a single shared credential typically grants permanent full access to every capability the model endpoint offers.

The control is identity binding at the boundary, carrying the authenticated principal into the policy decision for the inference request. It fires at request admission, before the payload is assembled. The evidence is an identity-bound per-request record, and the design is described in identity-aware AI gateway architecture.

Annex I Part I (e): confidentiality of processed data

Point (e) requires protecting the confidentiality of stored, transmitted, and otherwise processed data, including through encryption in transit. TLS covers the wire. The gap opens where the payload is composed, because encrypting a context window that should never have contained a patient identifier protects the identifier in flight and does nothing about the fact that it left.

The control is classification of prompt content with redaction applied before transmission. It fires after payload assembly and before the socket opens. The evidence is a per-request classification decision joined to the redaction outcome, produced by prompt-level DLP.

Annex I Part I (f): integrity of data, commands, and configuration

Point (f) requires protecting the integrity of processed data, commands, programs, and configuration against manipulation or modification not authorised by the user. For AI traffic the manipulation vector runs through the payload, where retrieved content and user content share one channel with the instructions.

The control is response-path inspection alongside request-path policy, plus stamping the model and version that served each call. It fires on both directions of the exchange. The evidence is a request and response record joined to the version that produced it, and the attack shape is covered in AI agent context window poisoning.

Annex I Part I (g): data minimisation

Point (g) requires processing only data that are adequate, relevant, and limited to what is necessary for the intended purpose. A retrieval layer that returns ten documents when the answer needs one is over-processing at the point of the call, and no downstream control recovers that.

The control is per-role policy on what may enter the context window for a given route, enforced at assembly. It fires in the same evaluation pass as classification. The evidence is a policy decision record naming the role, the route, and what the policy permitted.

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

Point (l) requires providing 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 control is write-path independence: the record gets produced by a component the application making the call has no ability to modify. It fires before the response returns to the caller. The evidence is an independently written, signed decision record, and the reasoning sits in AI audit log immutability and You Own the AI Liability, Not the Vendor.

Annex I Part II: vulnerability handling and component inventory

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

The control is destination allowlisting with a recorded endpoint for every call, so the component inventory can be reconciled against what production actually reached. It fires at routing, after policy evaluation and before the connection opens. The evidence is a destination log compared against the declared dependency list, the same reconciliation shadow AI discovery performs.

Article 14: the reporting duty

Article 14 attaches a 24-hour early warning, a 72-hour notification, and a final report to actively exploited vulnerabilities and severe incidents, filed with ENISA and the designated CSIRT coordinator. Every one of those documents rests on reconstructing which requests, carrying which content, from which principals, reached which endpoints, in a defined window.

The control is retention of the independent record across the investigation period. It fires long after the request, which is what makes it the hardest one to retrofit. The evidence is a reconstructable timeline, covered in AI audit log retention requirements.

The mapping at a glance

The row most mappings get wrong

Part I (l) is where CRA mappings tend to record a green status against an existing logging pipeline. The pipeline is real, the events reach the SIEM, and the row looks answered. What the row does not establish is who controls the write, and that property is the whole point of the requirement when the report you eventually file describes a failure in the component doing the logging.

My frank view: write-path independence is the single control on this list that cannot be added under time pressure, because retrofitting it means changing where the traffic goes, and nobody makes that change at hour three of a 24-hour clock. Every other row on the table can be tightened after an incident. That one has to exist before.

Scope changes, controls do not

Market surveillance authorities scope by product, notified bodies scope by conformity assessment route, and an Article 14 report scopes by incident. The same seven controls answer all three, examined under different headings. Building them once at the request boundary and presenting them against several scopes is what keeps the engineering work proportional. The CRA compliance checklist covers the build order, and the CRA audit-evidence view covers what each artifact looks like under questioning.

DeepInspect

Each row above resolves to an enforcement point, and DeepInspect is that point. It sits inline between the product and the LLM APIs it calls as a stateless proxy, evaluates identity, classification, and destination on every request, enforces per-role and per-route policy with a fail-closed default, inspects the response path, and writes a signed record of the decision before the response returns.

For a manufacturer scoping a CRA conformity assessment, that converts the Annex I rows from statements about the product into queries against records the product never had custody over. Book a technical deep dive at deepinspect.ai.