EU AI Act Art.11 Technical Documentation: The 7 Gaps NCA Inspectors Find Most Often

Post #1479 — EU-AI-ACT-AUDIT-READINESS-SPRINT-2026 #3/5

The first post in this sprint mapped the 30 documents every high-risk AI provider needs before August 2, 2026. The second post covered how to handle an NCA inquiry when it arrives. This post drills into the document that NCA inspectors examine first and most carefully: your Art.11 technical documentation.

Art.11 requires every provider of a high-risk AI system to draw up technical documentation before placing the system on the market and keep it up to date throughout the system lifecycle. Annex IV specifies exactly what this documentation must contain across eight structured sections. In practice, inspection findings cluster around the same seven gaps — not because providers ignore Art.11, but because the Annex IV requirements are more demanding than a first reading suggests.

Closing these gaps before inspection is faster and less costly than explaining them during one.

What Annex IV Actually Requires

Before mapping the gaps, it is useful to enumerate what Annex IV demands. The technical documentation must contain eight categories of information:

Section 1: General description of the AI system — intended purpose, use case, version identifiers, how it interacts with hardware and software

Section 2: Detailed description of the elements and development process — design specifications, training methodology, training data sources, architecture, key design choices and their rationale

Section 3: Information on monitoring, functioning, and control — technical measures for human oversight, interfaces for deployer control, performance metrics and limitations

Section 4: Description of the risk management system — a summary of how you implemented Art.9, cross-referenced to your risk register and control evidence

Section 5: Changes to the system — a version history of all modifications made to the system throughout its lifecycle, including post-deployment changes

Section 6: Standards and specifications applied — which harmonised standards or common specifications you used, how they apply to your intended purpose, and where you deviated

Section 7: EU declaration of conformity — a copy of the Art.47 EU declaration of conformity, signed and dated

Section 8: Post-market monitoring plan — a description of your Art.72 post-market monitoring system and how monitoring data is collected and reviewed

NCAs access technical documentation primarily through the two mechanisms established in Art.74: formal document requests and on-site inspections. When an inspector reviews your technical documentation, they work through Annex IV systematically. Each gap they identify becomes a finding in their inspection report.

Gap 1: Section 1 Describes the System, Not the Intended Purpose

What providers submit: A general description of what the system does technically — model type, input/output formats, capability overview.

What inspectors look for: A precise statement of the intended purpose as defined in Art.3(12): the use for which the system is specifically designed and for which the provider declares it fit, including the context, category of persons, and specific outcomes it is meant to achieve.

The gap: Technical capability descriptions and intended purpose specifications are not the same thing. A system that "analyses employment application data using a classification model" has documented capability. A system designed "for use by HR departments to rank job applicants in the financial services sector, intended to produce a ranked shortlist for human review" has documented intended purpose. The difference matters because Art.9 risk assessment, Art.10 data requirements, and Art.14 human oversight obligations are all scoped to the intended purpose, not the technical capability.

How to close it: Rewrite your Section 1 intended purpose statement to explicitly answer: who deploys this system, in what sector, for what decision-relevant outcome, against what population of people. If your system has multiple intended purposes, document each separately with its deployment context.

Gap 2: Section 2 Omits Training Pipeline Documentation

What providers submit: Architecture diagrams and a description of the model training approach.

What inspectors look for: A complete account of the development process — including dataset selection decisions, preprocessing steps, validation methodology, test splits, and the rationale for each key design choice.

The gap: Training pipeline documentation is often treated as internal technical knowledge rather than compliance documentation. Providers document what the system is; they less often document how the training process worked, why specific datasets were selected, how validation was structured, and what was learned from test evaluations that influenced design decisions.

Annex IV Section 2 specifically requires documentation of "the design specifications of the system, including the general logic of the system and design choices; and the key design choices, including the rationale and assumptions made, also with regard to persons or groups of persons on which the system is intended to be used." Design choice rationale — why you made specific training, architecture, and evaluation decisions — is mandatory.

How to close it: Document the training pipeline as a process record, not just as a technical specification. For each major design choice (dataset selection, model architecture selection, hyperparameter configuration, evaluation approach), include a rationale entry explaining why this choice was made, what alternatives were considered, and how it relates to the intended purpose.

Gap 3: Section 3 Reports Accuracy Metrics but Omits Robustness and Limitation Documentation

What providers submit: Model performance metrics — typically accuracy, precision, recall, or task-specific scores on a held-out test set.

What inspectors look for: A complete picture of system performance including limitations, known failure modes, degradation conditions, and the measures taken to ensure robustness and cybersecurity as required under Art.15.

The gap: Performance documentation that shows only headline accuracy figures without documenting system limitations, distributional sensitivity, and failure conditions is incomplete under Annex IV. Section 3 requires documentation of "technical means ensuring that the AI system can interact with the tools and interfaces that are necessary to ensure human oversight and control" and "levels of accuracy for specific persons or groups of persons on which the system is to be used."

Inspectors specifically check for disaggregated performance metrics (performance by demographic subgroup where relevant to the intended purpose) and documentation of the conditions under which performance degrades. A system that performs well on aggregate metrics but has an undisclosed accuracy gap for a specific subgroup has an Art.10 bias problem and a Section 3 documentation gap simultaneously.

How to close it: Add a dedicated limitations and robustness section to your Section 3 documentation. Document: minimum performance thresholds by subgroup, known distributional shifts that affect performance, conditions under which the system should not be used, and how performance monitoring under Art.72 will detect degradation.

Gap 4: Section 4 References Art.9 But Does Not Cross-Reference Evidence

What providers submit: A summary of the risk management system — often a prose description of the risk management process or a pointer to the Risk Management Plan document.

What inspectors look for: Cross-references connecting each risk identified in the risk register to the specific technical documentation that evidences how it was mitigated and tested.

The gap: Section 4 is not a standalone document — it is a bridge between your risk management system (Art.9) and the rest of your technical documentation. Inspectors use Section 4 to navigate from a stated risk to the evidence that the risk is controlled. A Section 4 that describes the risk management process without providing cross-references to specific control evidence forces inspectors to conduct their own evidence hunt, which extends inquiry timelines and increases the probability that they miss evidence you intended to provide.

How to close it: Structure Section 4 as a cross-reference table. For each significant risk identified in your Art.9 risk register, include: the risk identifier, the control measure documented in the Risk Management Plan, and a pointer to the specific technical documentation that evidences the control (test records, architectural specifications, monitoring procedures). This makes your Section 4 an inspection navigation aid rather than a description of a process.

Gap 5: Section 5 Is Missing or Contains Undated Entries

What providers submit: Either no Section 5 at all (very common for systems that have not yet been modified post-deployment) or a change log with version numbers but no dates or rationale.

What inspectors look for: A complete version history with dates, specific changes documented, and the reason for each change — including changes made in response to Art.72 post-market monitoring findings.

The gap: Annex IV Section 5 applies throughout the lifecycle. For systems not yet deployed, it may be minimal. For systems that have been updated, it must capture every change — including model retraining, threshold adjustments, data pipeline modifications, and changes to the intended purpose scope. Undated entries are a common finding because internal engineering changelogs typically record what changed, not when and why in terms that connect to compliance obligations.

A specific pattern inspectors flag: monitoring-triggered changes that are recorded in engineering systems but not reflected in the technical documentation change log. If your Art.72 monitoring identified a performance issue and you retrained the model in response, that retraining must appear in Section 5.

How to close it: Establish a single authoritative Section 5 change log as a compliance document (distinct from your engineering changelog). Each entry must include: date, version identifier, summary of change, reason for change, and whether the change was triggered by Art.72 monitoring, an Art.73 incident, or a proactive development decision.

Gap 6: Section 6 Lists Standards Without Explaining Applicability

What providers submit: A list of harmonised standards applied — ISO 42001, ISO 27001, CEN standards where applicable.

What inspectors look for: An explanation of how each standard applies to the specific intended purpose, which provisions of each standard were applied, and where the provider deviated from the standard and why.

The gap: Listing a standard does not demonstrate conformity with it. Annex IV Section 6 requires documentation of "the list of harmonised standards applied in full or in part" and where harmonised standards are not available, "a description of the solutions adopted to meet the requirements." The phrase "in part" signals that partial application must be explained. Where a harmonised standard has provisions that do not apply to your system, you must document why they do not apply.

Common pattern: providers list ISO 42001 (AI Management Systems) as an applied standard without documenting which clauses are applicable, which were implemented, and how they map to the specific obligations of the high-risk AI category their system falls into.

How to close it: Replace your standards list with a standards applicability matrix. For each standard cited: list the relevant clauses, map them to specific Annex IV or regulatory requirements, note any partial application with explanation, and cross-reference to evidence of implementation.

Gap 7: Section 7 EU Declaration of Conformity Is Unsigned or Outdated

What providers submit: A copy of the EU declaration of conformity, often generated from a template at the time of initial conformity assessment.

What inspectors look for: A signed, dated declaration that remains current — specifically, one that reflects the current system version and has been reviewed following any post-deployment changes.

The gap: Art.47 specifies the required content of the EU declaration of conformity, including a statement that the system conforms to the requirements of the Act. If you have updated your system (Section 5 changes), your Art.47 declaration must reflect the current state. A declaration that was valid for version 1.0 may not be valid for version 1.2 if the changes affected the conformity assessment basis.

Inspectors also check that the declaration is signed by the authorized representative — not just stamped or generated by documentation software. For non-EU providers, the EU authorized representative must be the signatory.

How to close it: Review your Art.47 declaration for current accuracy against your system's current version. Establish a process that flags when a system change triggers a declaration review — in particular, changes to intended purpose, significant architectural modifications, and changes to the risk management baseline. Ensure the authorized signatory is the correct person under Art.3(4) (provider) or Art.25 (authorized representative).

Closing All Seven Gaps Before August 2, 2026

The seven gaps above are not exotic requirements — they are all derivable from a careful reading of Annex IV. They cluster in inspection findings because documentation that satisfies a first-pass reading often misses the cross-referencing, specificity, and lifecycle obligations that inspectors are trained to check.

A useful audit sequence:

Week 1: Section 1 (intended purpose specificity) + Section 7 (declaration currency and signature). These are the highest-visibility items and can be corrected without new technical work.

Week 2: Section 2 (training pipeline rationale) + Section 5 (change log completeness and dates). These require input from the technical team but no new testing.

Week 3: Section 3 (limitations and robustness documentation) + Section 4 (cross-reference table). These require the most coordination between technical and compliance teams.

Week 4: Section 6 (standards applicability matrix) + full internal review simulating an NCA document request.

The next post in this sprint covers Art.9 Risk Management System documentation — specifically what an NCA inspector means when they say your risk management system is "not continuous" and what evidence closes that finding.

Post #1479 in the EU-AI-ACT-AUDIT-READINESS-SPRINT-2026 series. Part of sota.io's EU compliance content library — 1479 guides for EU developers and compliance teams.