EU / European Union / revised 28 Oct 2026

EU AI Act Annex IV: Technical Documentation for AI Inference

Annex IV sets out the nine headings a provider of a high-risk AI system must cover in its technical documentation before placing the system on the market. It is not a residency rule, but the documentation has to describe where the system runs, what it logs and how it is monitored, which turns your inference topology into an audited artefact.

Test a sovereign route Talk to a sovereign architect

Citation: Regulation (EU) 2024/1689, Article 11 and Annex IV (with Articles 12, 18 and 19)
Regulator: National market surveillance authorities, notified bodies, and the European AI Office
In force: 1 August 2024
Maximum penalty: EUR 15 million or 3% of worldwide annual turnover, whichever is higher (Art. 99(4))

Statutory text

Article 11: documentation before market placement

Article 11(1) requires the provider of a high-risk AI system to draw up technical documentation before the system is placed on the market or put into service and to keep it up to date. The documentation must show that the system meets the requirements of Chapter III, Section 2 (risk management, data governance, record-keeping, transparency, human oversight, accuracy and cybersecurity) and give national authorities and notified bodies the information they need to assess that. Small and medium enterprises, including start-ups, may supply the Annex IV elements in a simplified form the Commission is to publish.

Article 18 requires the provider to keep the technical documentation at the disposal of national competent authorities for 10 years after the system is placed on the market or put into service.

The nine Annex IV headings

Annex IV lists the minimum contents. Points 1 to 3 carry most of the infrastructure detail: a general description including how the system interacts with hardware or software outside it and the hardware it is intended to run on; a detailed description of the elements and development process, including system architecture, computational resources, and the design choices made; and information on monitoring, functioning and control, including the system's limitations and the human oversight measures.

1. General description of the AI system, its intended purpose, versions and deployment forms
2. Detailed description of the elements and the development process, including architecture and data requirements
3. Monitoring, functioning and control of the system
4. Appropriateness of the performance metrics
5. The risk management system under Article 9
6. Relevant changes made through the lifecycle
7. Harmonised standards or other specifications applied
8. A copy of the EU declaration of conformity
9. The system used to evaluate performance in the post-market phase, including the post-market monitoring plan

Logging duties that feed the documentation

Article 12 requires high-risk systems to technically allow automatic recording of events over their lifetime. Article 19 obliges providers to keep the automatically generated logs under their control for a period appropriate to the intended purpose and at least six months, and Article 26(6) places a parallel six-month minimum on deployers. These logs are the raw material for Annex IV points 3 and 9.

Timing: the Digital Omnibus on AI, politically agreed in May 2026, moves the application date for stand-alone Annex III high-risk systems to 2 December 2027 and for systems embedded in Annex I products to 2 August 2028. The Annex IV content itself is unchanged by that deal.

Technical requirements for the inference path

01
Describe the inference topology as part of the system
If the model runs behind a gateway that selects regions, providers and fallbacks, that routing layer is software the system interacts with under Annex IV point 1. Document each resolved endpoint, provider region and model version, not just the model card.
02
Version every policy that changes system behaviour
A routing policy that redirects traffic to a different model or region changes the system's outputs. Treat policy pack versions as lifecycle changes for point 6, with a change log that records who approved the change and when.
03
Tamper-evident event logs
Article 12 logs are only useful in an audit if you can show they were not edited after the fact. Signed per-request receipts chained into a Merkle tree give an assessor an independent way to check completeness and ordering.
04
Retention split between logs and documentation
Keep request-level receipts for at least the Article 19 six-month floor and keep the Annex IV dossier for 10 years. Receipts can hold hashes rather than prompt content, so long retention does not mean long retention of personal data.
05
Human oversight hooks
Point 3 asks how oversight works in practice. Expose a kill switch per policy pack and per model route so an operator can halt or redirect a high-risk use case without a code deploy, and log every use of it.

Prescribed YTT Secunet routing rules

#	Rule	Legal rationale
01	Pin each high-risk use case to an approved model id and version; reject requests that resolve to any other model.	Annex IV point 2 documents a specific system. Silent model upgrades by a provider would make the dossier describe something you no longer run.
02	Fail closed rather than fail over to an undocumented region or provider.	A failover target that is not in the technical documentation is an undocumented change under point 6. Approved failover pairs must be listed in advance.
03	Attach the policy pack id and version to every proof receipt.	This lets the post-market monitoring system in point 9 tie any incident back to the exact rule set in force at the time.
04	Tag requests with the Annex III use-case identifier supplied by the deployer.	Deployers and providers both carry logging duties. A use-case tag lets each party extract its own Article 12 records without parsing prompts.
05	Export a monthly documentation bundle of endpoint inventory, policy diffs and Merkle roots.	Keeping the dossier up to date is a continuing Article 11 obligation; a scheduled export keeps the evidence current instead of reconstructing it before an audit.

Policy pack excerpt

eu-ai-act-high-risk

The rules above, written as Open Policy Agent Rego (v1 syntax). The gateway evaluates the pack in-process in every regional data plane before forwarding a request; YTT Secunet measures median evaluation under 3 ms in production.

Packs are versioned and signed. The version that decided each request is named in the residency receipt, so an auditor can match the decision to this exact text.

How the policy engine works

regoeu-ai-act-high-risk.rego

package yttsecunet.policies.eu_ai_act_high_risk

import rego.v1

default allow := false

approved_models := {"model-a-2026-03", "model-b-2026-05"}

approved_regions := {"eu-central-1", "eu-west-1", "eu-west-3"}

allow if {
	input.request.use_case_id != ""
	input.route.model_id in approved_models
	input.route.provider_region in approved_regions
	input.route.failover_pair_documented
}

reasons contains "model not in Annex IV dossier" if {
	not input.route.model_id in approved_models
}

reasons contains "missing Annex III use-case tag" if {
	input.request.use_case_id == ""
}

Audit checklist

Each item is verifiable against configuration, signed receipts or contract records. Tick through it with your DPO.

01Technical documentation exists for each high-risk system and covers all nine Annex IV headings.
02The architecture section names every inference endpoint, provider region and model version in production.
03Each routing policy change has a dated entry in the lifecycle change log with an approver.
04Automatically generated logs are retained for at least six months (Art. 19 and Art. 26(6)).
05The Annex IV dossier has a 10-year retention rule recorded in the document management system (Art. 18).
06An assessor can verify log completeness offline using published Merkle roots.
07Failover targets are pre-approved and listed in the documentation.
08The post-market monitoring plan names the metrics and log fields used for point 9.

EU AI Act Annex IV: frequently asked questions

Does Annex IV require EU data residency?

No. Annex IV is a documentation requirement. It requires you to describe where and how the system runs, and data governance rules elsewhere may push you to EU hosting, but the Annex itself does not prohibit non-EU inference.

Who writes the Annex IV documentation, the provider or the deployer?

The provider of the high-risk system. A deployer that substantially modifies a system or puts its name on it can become a provider under Article 25 and inherit the duty.

Can YTT Secunet produce the documentation for us?

YTT Secunet's Compliance Reports export the infrastructure evidence (endpoint inventory, policy versions, receipts and Merkle roots) for points 1, 2, 3, 6 and 9. The risk management, performance metrics and declaration of conformity remain yours to author.

Sovereign route ready

Stop risking 4% global turnover GDPR fines on AI inference.

Deploy sovereign, cryptographically proven AI routing in 15 minutes.

Schedule an architecture demo Start 14-day trial