How often does the technical documentation have to be updated?

Article 11 requires the documentation to be kept up-to-date. The practical reading is that the file has to reflect the system as it currently operates. A model retrain, a prompt template change, a new training data source, a change in the policy enforcement layer, or a change in the supported hardware platforms triggers an update. The regulator does not specify a cadence in days or weeks. The cadence is driven by the system. A frozen system that does not change requires no updates. A system that ships weekly requires a documentation process that runs at that cadence.

Can the technical documentation be kept in pieces across different systems?

The regulation requires that the documentation be available to the national competent authority on request. Pieces across different systems are acceptable if the provider can produce the unified file on demand and the file references all nine Annex IV elements. Many providers will keep the design decisions in one system, the risk register in another, and the production telemetry in a third. The inspection-ready output is what matters. If producing that output takes weeks of cross-team work, the documentation process has failed Article 11 in practice even if the content is technically available.

What happens if a national authority asks for the file and we cannot produce it?

The market surveillance authorities have the power under Article 64 to demand the technical documentation and to investigate the system. If the provider cannot produce the file, the authority can presume non-conformity, which triggers the penalty tier under Article 99 for non-compliance with the high-risk requirements. The penalty for non-compliance with Article 11 specifically falls under the up-to-fifteen-million-euros or three-percent-of-global-annual-turnover tier. The reputational consequence of being unable to produce the file in front of a regulator usually outweighs the fine.

How does Article 11 differ from Article 12 logging?

Article 11 is about the documentation that describes the system. Article 12 is about the per-request logs the system produces while operating. The two work together. The technical documentation describes what the system is supposed to do, including the logging architecture. The Article 12 logs are the runtime evidence that the system actually does what the documentation says. A provider that has the documentation but not the logs cannot prove conformity. A provider that has the logs but not the documentation cannot explain the system to the regulator. Both are required, and they reference each othe

EU AI Act Article 11: What Technical Documentation Must Show for Your AI System

Article 11 of the EU AI Act requires providers of high-risk AI systems to draw up and keep current the technical documentation that demonstrates conformity with the high-risk requirements before placing the system on the market. The list of contents is in Annex IV and runs to nine elements covering system description, design choices, risk management, data governance, testing, performance metrics, post-market monitoring, and the conformity assessment record. The August 2, 2026 deadline triggers this obligation for every provider whose system falls into the high-risk categories.

The text of Annex IV reads like nine bullet points. The infrastructure to satisfy each one runs to dozens of artifacts that have to stay in sync with the live system.

I want to walk through what Article 11 requires, what Annex IV actually asks providers to keep on file, and where most engineering teams will fail the inspection.

Mandate

Article 11 has three operative obligations. First, the technical documentation must be drawn up before the system is placed on the market or put into service. Second, it must be kept up-to-date over the life of the system. Third, the documentation must contain enough detail for a national competent authority to assess the AI system's compliance with the high-risk requirements set out in Chapter III, Section 2 of the regulation.

The level of detail is meaningful. The documentation has to allow an outside reviewer to verify the system's conformity, not just summarize it. Annex IV's nine elements operationalize the requirement.

Annex IV element 1: general description

The provider must describe the intended purpose, the persons developing the system, the date and version, how the system interacts with other software or hardware, the form in which it is placed on the market, the supported hardware platforms, the user interface, and the instructions for use. This is the system card, at regulatory granularity.

Annex IV element 2: detailed description

The detailed description covers the design methodology, system architecture, key design choices and assumptions, the main classification choices, what the system was optimized for, and the trade-offs accepted during development. A high-risk system that was built and deployed without a written record of these decisions cannot pass this element.

Annex IV element 3: monitoring and control

The documentation must describe the relevant monitoring, functioning, and control characteristics of the AI system. Performance characteristics, including metrics on accuracy and resilience to adversarial inputs, are required. Article 15 governs the accuracy and resilience requirements; Article 11 requires those measurements to live in the technical file.

Compliance gap

Most engineering teams produce technical documentation as a one-time deliverable at release. The Article 11 requirement is for a continuously maintained file. The gap between those two states is where conformity fails.

Design decisions are recorded informally

Architectural decisions get captured in design review meetings, Slack threads, and JIRA tickets. None of those artifacts are admissible as part of the technical documentation file. When a market surveillance authority asks for the rationale behind a specific classification choice, the answer "we discussed it in a meeting last quarter" fails the inspection.

Risk management documentation lags the system

Article 9 of the AI Act mandates a risk management system that runs over the entire lifecycle. The technical documentation under Article 11 has to reflect the current state of that risk management system. Every time the model is retrained, the prompt template changes, or a new data source is connected, the risk register and the technical documentation are supposed to update. The reality in most deployments is that the risk register reflects the system as it was at launch.

Performance metrics drift from production reality

Annex IV requires performance characteristics to be documented. The metrics in the file are typically the metrics from the pre-launch evaluation. The metrics from production are kept in a different system, with a different methodology, and are usually higher fidelity. When the regulator compares the file to production data, the gap shows up.

Logging architecture is not described

Article 12 requires automatic logging. Article 11 requires the technical documentation to describe the logging architecture, including which events are logged, the retention period, and the integrity guarantees. Application-controlled logs fail this description because there is no architectural commitment behind them.

Mandate vs Compliance

Article 11's text reads as a content list. The infrastructure that lets a provider keep that content accurate over the life of the system is what passes the inspection.

What the regulator will request

The first question a market surveillance authority asks under Article 11 is for the technical documentation file. The file has to arrive with all nine Annex IV elements, dated and versioned. The next questions are specific to the system. Which version of the model is in production today? Which design decisions changed since the conformity assessment? Where are the performance metrics from production? How are the logging requirements under Article 12 satisfied at the architecture level?

What surviving the inspection actually requires

A technical documentation file that survives inspection has to be the output of a process, not a manually maintained Word document. The process records design choices at the time they are made, links every choice to a risk register entry, tracks model and prompt versions against the system description, and pulls performance metrics from the production telemetry. The file becomes a view over a system of record rather than a hand-written artifact.

The audit trail of the AI requests themselves is part of this story. Article 12 logs are evidence that the system operates as the technical documentation describes. Without the per-decision records, the technical file is a self-assessment that the regulator has no way to verify.

Vendor and embedded-AI usage shows up here too

Annex IV element 1 requires a description of how the AI system interacts with other software or hardware. When a high-risk AI system embeds a vendor LLM, the vendor's contribution has to appear in the technical file. The provider cannot point at the vendor's documentation and consider the obligation satisfied. The provider is the one whose conformity is being assessed, and the technical file has to describe the integration in enough detail for the regulator to evaluate it.

DeepInspect

This is the architecture DeepInspect supports for the runtime evidence Annex IV expects. DeepInspect sits at the AI request boundary as a stateless proxy between authenticated users or agents and any LLM endpoint. Every request that passes through is evaluated against identity-bound policy, and every decision produces a per-decision audit record containing the identity context, the policy version in effect, the data classification applied, the decision outcome, and a tamper-evident signature.

For Article 11, those records are the production-side proof that the system behaves as the technical documentation says it does. The policy version recorded with each decision links the request stream to the design choices captured in Annex IV element 2. The classification outcomes link to the data governance documentation required under Article 10. The performance characteristics drawn from the proxy's request log become the metrics that Annex IV element 3 requires.

If you are placing a high-risk AI system on the EU market and your technical documentation depends on artifacts the application produces, the file you submit will reflect what the application chose to record. Book a demo today.

Beyond Article 11

The technical documentation pattern Article 11 mandates appears under different names in adjacent frameworks. The NIST AI Risk Management Framework requires governance documentation that covers system context, risk decisions, and mitigations. ISO/IEC 42001 requires an AI management system with similar artifacts. The Fannie Mae LL-2026-04 governance framework requires lenders to keep documentation that explains how each AI tool is governed.

The architecture that produces an Annex IV-shaped file satisfies the documentation obligation under all of these regimes. The vocabulary differs across regulators. The infrastructure converges on the same pattern: a process that captures decisions at the moment they are made and a runtime log that proves the system behaves as documented.

The provider of the high-risk AI system is responsible. Under the EU AI Act, the provider is the entity that develops the system or has it developed and places it on the market under its own name. Deployers, who use a high-risk AI system in the course of their activities, have their own obligations under Article 26, but the Article 11 file sits with the provider. The line is important for B2B SaaS arrangements where one company builds the AI system and another company deploys it for an in-scope use case. In that arrangement, the SaaS company is the provider and owns the Article 11 file. The customer who deploys the system inherits the Article 26 deployer obligations and uses the provider's technical documentation as the basis for its own compliance work.