EU AI Act Art.11: Technical Documentation Lifecycle — Conformity Assessment Readiness, Annex IV Cross-References, and Substantial Modification Triggers (2026)

Article 11 of the EU AI Act is the technical documentation backbone of high-risk AI compliance. Every provider placing a high-risk AI system on the EU market must produce, maintain, and — critically — update technical documentation structured across 8 Annex IV sections. But Art.11 is not a one-time pre-market filing. It is a lifecycle obligation that runs from initial development through the 10-year post-market retention period.

The August 2, 2026 deadline applies: any high-risk AI system placed on the EU market or put into service on or after that date must have Art.11-compliant technical documentation before market placement. For systems already on the market before 2026 that receive substantial modifications, the documentation obligation resets.

This guide covers what Art.11 actually requires in 2026, how the four paragraphs create a lifecycle architecture, the Annex IV cross-reference map, when Art.11(4) substantial modification triggers a documentation update, how technical documentation feeds the three conformity assessment pathways, and how to build a documentation system that survives a market surveillance authority (MSA) audit.

What Art.11 Actually Requires: The Four-Paragraph Architecture

Art.11 is deceptively short — four paragraphs — but each creates a distinct obligation:

Art.11(1) — Pre-market obligation: Before placing a high-risk AI system on the EU market or putting it into service, the provider must draw up technical documentation in accordance with Annex IV. The documentation must be "drawn up" — not merely planned or outlined — before market placement.

Art.11(2) — SME simplification: Micro and small enterprises (fewer than 50 employees; annual turnover below €10 million) may provide elements of the technical documentation in a simplified form, without prejudicing the obligation to demonstrate compliance with Art.9–15. The Commission publishes specific guidance on what simplified means in practice for each Annex IV section.

Art.11(3) — 10-year retention: The technical documentation — and conformity assessment documentation — must be kept for 10 years after the last AI system or system component is placed on the market or put into service. This is the longest retention obligation in the EU AI Act and the single longest compliance horizon for most high-risk AI providers.

Art.11(4) — Lifecycle updates: Documentation must be updated whenever a "substantial modification" occurs. The definition of substantial modification (Art.1(1)(67)) captures changes that affect compliance with Art.9–15 or alter the system's intended purpose. Minor patches and performance improvements below this threshold require an amendment record but not a full documentation refresh.

The practical implication: your technical documentation system must support version control, modification classification, and long-term archival from day one.

The Annex IV Architecture: 8 Sections and Their Cross-References

Annex IV defines 8 mandatory sections. Each section is non-optional and connects to other Art.9–15 obligations. The table below maps each section to its primary cross-references:

Section 5 is the critical link: the full Art.9 risk management system documentation must appear in Annex IV, not just a summary. This means Annex IV is not independent from Art.9 — it is the final consolidated record of the entire compliance process.

Art.11(4) Substantial Modification Triggers

The Art.11(4) update obligation activates when a "substantial modification" occurs. Art.1(1)(67) defines substantial modification as a change "which affects the compliance of the AI system with this Regulation or results in a modification to the intended purpose for which the AI system has been assessed."

In practice, this creates three trigger categories:

Category A: Compliance-Affecting Changes (Always Substantial)

• Changes to the model architecture (new layers, attention heads, output modalities)
• Changes to the training data strategy that affect Annex IV Section 2 claims
• Changes to human oversight mechanisms required by Art.14
• Changes that cause the system to perform outside the validated accuracy range (Art.15)
• Adding new Annex III use cases to an existing system

Category B: Intended Purpose Changes (Always Substantial)

• Expanding deployment contexts beyond those documented in Annex IV Section 1
• Adding support for new user categories not in the original design
• Changing the decision-making role of the AI (from "advisory" to "automated")

Category C: Non-Substantial Changes (Require Amendment Record Only)

• Security patches and bug fixes that do not affect the AI decision logic
• UI/UX changes that do not modify how outputs are presented to decision-makers
• Infrastructure migration with equivalent compute resources
• Minor performance improvements within the validated operating range

from enum import Enum
from dataclasses import dataclass
from datetime import date
from typing import Optional

class ModificationType(Enum):
    SUBSTANTIAL_COMPLIANCE = "substantial_compliance"
    SUBSTANTIAL_PURPOSE = "substantial_purpose"
    NON_SUBSTANTIAL = "non_substantial"

@dataclass
class ModificationRecord:
    change_id: str
    change_date: date
    description: str
    modification_type: ModificationType
    annex_iv_sections_affected: list[str]
    triggers_reassessment: bool
    approver: str
    notes: Optional[str] = None

class SubstantialModificationClassifier:
    COMPLIANCE_TRIGGERS = [
        "model_architecture",
        "training_data_strategy",
        "human_oversight_mechanism",
        "accuracy_range_change",
        "annex_iii_use_case_added",
    ]

    PURPOSE_TRIGGERS = [
        "deployment_context_expanded",
        "user_category_added",
        "decision_role_changed",
    ]

    def classify(self, change_description: str, affected_components: list[str]) -> ModificationType:
        for component in affected_components:
            if component in self.COMPLIANCE_TRIGGERS:
                return ModificationType.SUBSTANTIAL_COMPLIANCE
            if component in self.PURPOSE_TRIGGERS:
                return ModificationType.SUBSTANTIAL_PURPOSE
        return ModificationType.NON_SUBSTANTIAL

    def requires_documentation_update(self, mod_type: ModificationType) -> bool:
        return mod_type in (
            ModificationType.SUBSTANTIAL_COMPLIANCE,
            ModificationType.SUBSTANTIAL_PURPOSE,
        )

The classifier output determines whether Art.11(4) triggers a full documentation refresh or an amendment record only.

Three Conformity Assessment Pathways and How Art.11 Feeds Each

Technical documentation is the evidentiary input for conformity assessment under Art.43–45. The three pathways have different documentation requirements:

Pathway 1: Third-Party Assessment — Art.43(1) (Default for Biometrics and Law Enforcement AI)

Required for biometric identification systems (Annex III categories 1 and 8) and law enforcement AI. A notified body assesses the technical documentation for:

• Completeness of all 8 Annex IV sections
• Adequacy of the Art.9 RMS (Annex IV Section 5)
• Validity of testing data (Annex IV Section 4)
• Alignment between intended purpose (Section 1) and risk evaluation (Section 5)

The notified body issues a certificate valid up to 4 years, renewable. Art.11 documentation must be available to the notified body throughout assessment and re-assessment.

Pathway 2: Internal Production Control — Art.43(2) (Default for Most Annex III Categories)

Available for most high-risk AI systems not covered by Pathway 1. The provider self-assesses conformity against Art.9–15 using the technical documentation as the evidence base. The assessment must demonstrate:

• Art.9 RMS documented in Annex IV Section 5 with full risk register
• Art.10 data governance choices documented in Annex IV Section 2
• Art.12 logging specification supporting human oversight (Section 3)
• Art.15 performance thresholds documented and tested (Section 4)

The EU Declaration of Conformity (Art.48, Annex V) is signed by the provider at the end of this process.

Pathway 3: Harmonised Standard Conformance — Art.40

If the provider's system conforms to harmonised standards published in the EU Official Journal (covering Art.9–15), conformity to those articles is presumed. Annex IV Section 7 must document which standards were applied, which parts apply, and any gaps where alternative solutions were used.

@dataclass
class ConformityAssessmentRecord:
    pathway: str  # "art43_1_third_party", "art43_2_internal", "art40_standards"
    assessment_date: date
    assessor: str  # notified body name or internal team
    annex_iv_version: str
    sections_assessed: list[str]
    findings: list[str]
    certificate_expiry: Optional[date]  # Art.43(1) only
    declaration_of_conformity_ref: str

class ConformityAssessmentManager:
    def __init__(self, system_id: str):
        self.system_id = system_id
        self.assessments: list[ConformityAssessmentRecord] = []

    def add_assessment(self, record: ConformityAssessmentRecord) -> None:
        self.assessments.append(record)

    def current_valid_assessment(self) -> Optional[ConformityAssessmentRecord]:
        valid = [a for a in self.assessments
                 if a.certificate_expiry is None or a.certificate_expiry >= date.today()]
        return max(valid, key=lambda a: a.assessment_date, default=None)

    def requires_renewal(self) -> bool:
        current = self.current_valid_assessment()
        if current is None:
            return True
        if current.certificate_expiry is None:
            return False
        days_remaining = (current.certificate_expiry - date.today()).days
        return days_remaining < 90

Art.11(2) SME Simplified Documentation

For micro and small enterprises (fewer than 50 employees; annual turnover ≤ €10 million), Art.11(2) permits simplified Annex IV documentation. The Commission has published implementing acts specifying what "simplified" means in practice:

Critical constraint: simplified documentation still must demonstrate compliance with Art.9–15. Simplified form does not mean reduced compliance. An MSA can still find non-compliance in simplified documentation if the underlying system does not meet Art.9–15 requirements.

The Art.11(3) 10-Year Retention System

Art.11(3) mandates 10 years of documentation retention. For a system placed on the market in August 2026 and withdrawn in 2030, documentation must be retained until 2040. This creates practical requirements:

Version control: Each Annex IV version must be timestamped and retained, including pre-update versions. If Art.11(4) triggers a documentation update in 2028, both the 2026 original and the 2028 update must be retained for the 10-year window.

Access during retention: MSAs can request documentation access during the retention period (Art.74(7)). Archived documentation must be retrievable within reasonable timeframes.

Format stability: Documentation stored in proprietary formats risks becoming unreadable over a 10-year horizon. PDF/A (archive-stable PDF) or structured data formats are appropriate.

import json
from pathlib import Path
from datetime import date, timedelta

class DocumentationVersionManager:
    def __init__(self, system_id: str, base_path: Path):
        self.system_id = system_id
        self.base_path = base_path / system_id
        self.base_path.mkdir(parents=True, exist_ok=True)
        self.retention_years = 10

    def commit_version(
        self,
        annex_iv_sections: dict,
        trigger: str,
        modification_type: str,
        market_placement_date: date,
    ) -> str:
        version_id = f"v{date.today().isoformat()}"
        retention_deadline = date(
            market_placement_date.year + self.retention_years,
            market_placement_date.month,
            market_placement_date.day,
        )
        record = {
            "version_id": version_id,
            "system_id": self.system_id,
            "committed_date": date.today().isoformat(),
            "trigger": trigger,
            "modification_type": modification_type,
            "market_placement_date": market_placement_date.isoformat(),
            "retention_deadline": retention_deadline.isoformat(),
            "sections": annex_iv_sections,
        }
        version_path = self.base_path / f"{version_id}.json"
        version_path.write_text(json.dumps(record, indent=2))
        self._update_index(version_id, trigger, modification_type)
        return version_id

    def _update_index(self, version_id: str, trigger: str, modification_type: str) -> None:
        index_path = self.base_path / "index.json"
        index = json.loads(index_path.read_text()) if index_path.exists() else {"versions": []}
        index["versions"].append({
            "version_id": version_id,
            "trigger": trigger,
            "modification_type": modification_type,
            "date": date.today().isoformat(),
        })
        index_path.write_text(json.dumps(index, indent=2))

    def list_versions(self) -> list[dict]:
        index_path = self.base_path / "index.json"
        if not index_path.exists():
            return []
        return json.loads(index_path.read_text())["versions"]

    def versions_approaching_retention(self, warning_days: int = 180) -> list[dict]:
        warning_date = date.today() + timedelta(days=warning_days)
        expiring = []
        for v in self.list_versions():
            version_path = self.base_path / f"{v['version_id']}.json"
            if version_path.exists():
                record = json.loads(version_path.read_text())
                deadline = date.fromisoformat(record["retention_deadline"])
                if deadline <= warning_date:
                    expiring.append({"version": v["version_id"], "deadline": deadline.isoformat()})
        return expiring

The Art.11 × Art.9 × Art.10 × Art.12 × Art.13 Documentation Matrix

Technical documentation under Art.11 is not a standalone document — it is the final consolidation of outputs from Art.9–15. The matrix below shows which article generates which documentation, and which Annex IV section it feeds:

The practical implication: Art.11 documentation cannot be produced in isolation. It requires upstream compliance with Art.9–15 to exist as a complete, auditable record.

What MSAs Actually Check

Market surveillance authorities conducting audits under Art.74 focus on:

1. Section completeness — Are all 8 Annex IV sections present and populated (not placeholder text)?
2. Internal consistency — Does the intended purpose in Section 1 match the risk scope in Section 5?
3. Testing integrity — Do Section 4 test results match the Section 1 deployment context?
4. Modification log accuracy — Does Section 6 capture all changes since initial assessment?
5. Current version currency — Does the documentation reflect the system's current state, or is it an outdated pre-market version?
6. 10-year retention compliance — Are older versions retained and accessible?

The most common MSA finding: documentation that was complete at market placement but never updated through Art.11(4) subsequent to substantial modifications.

Art.11 × Annex IV Section 2: The Design Documentation Standard

Section 2 (design and development) is the most technically demanding Annex IV section. It must cover:

• The methods used to develop the AI system
• The design specifications of the system, including general logic and algorithms
• The key design choices and assumptions made, including with regard to persons
• The relevant data requirements in terms of type, quantity, and completeness
• Relevant information about training data

For Art.10 integration: the Art.10 data governance record maps directly into Section 2. The dataset documentation produced under Art.10(2) is the Section 2 evidentiary input. Providers who treat Art.10 and Art.11 as separate compliance workstreams end up with duplicated, inconsistent documentation. The integrated approach treats Art.10 documentation as Section 2 input from the start.

@dataclass
class Section2DesignDocumentation:
    development_methodology: str
    algorithm_description: str
    key_design_choices: list[dict]  # {"choice": str, "rationale": str, "assumption": str}
    data_requirements: dict  # {"type": str, "quantity": str, "completeness": str}
    art10_reference: str  # reference to Art.10 data governance record

    def validate_art10_link(self, art10_governance_id: str) -> bool:
        return self.art10_reference == art10_governance_id

    def to_annex_iv_record(self) -> dict:
        return {
            "section": "2",
            "development_methodology": self.development_methodology,
            "algorithm_description": self.algorithm_description,
            "design_choices": self.key_design_choices,
            "data_requirements": self.data_requirements,
            "data_governance_cross_ref": self.art10_reference,
        }

25-Item Art.11 Implementation Checklist

Pre-Market Documentation

• All 8 Annex IV sections drafted and reviewed before market placement
• Section 1 intended purpose matches Art.9(2)(a) risk scope definition
• Section 2 references Art.10 data governance record by document ID
• Section 3 includes complete Art.12 logging event specification
• Section 4 contains statistical test results with significance levels, not just pass/fail
• Section 5 is the full Art.9 RMS, not a summary
• Section 6 initialized with initial assessment entry (Version 1.0)
• Section 7 lists applicable harmonised standards and documents any gaps
• Section 8 contains signed EU Declaration of Conformity per Annex V

Modification Management

• Substantial modification classifier implemented and tested
• Every change classified (substantial vs. non-substantial) before deployment
• Substantial modifications trigger Art.11(4) documentation update before deployment
• Non-substantial changes recorded in Section 6 amendment log
• Updated documentation reviewed for internal consistency after every refresh

Conformity Assessment

• Correct conformity assessment pathway identified (Art.43(1) vs. Art.43(2) vs. Art.40)
• Notified body engaged if Art.43(1) applies (biometrics, law enforcement)
• Certificate expiry tracked with 90-day renewal warning
• Internal assessment review scheduled annually for Art.43(2) systems

Retention and Access

• Version control system in place (each version timestamped and immutable)
• 10-year retention deadline calculated and tracked per system
• Documentation stored in format-stable format (PDF/A or structured data)
• MSA access procedure documented (who receives requests, response timeline)

SME Documentation (if applicable)

• SME eligibility confirmed (< 50 employees, ≤ €10M turnover)
• Simplified sections still demonstrate Art.9–15 compliance
• Commission guidance on simplified documentation consulted

Common Art.11 Failure Modes

Failure 1: Static pre-market documentation. Providers treat Art.11 as a one-time filing, deploy, and never update. The first substantial modification without documentation update is an immediate Art.99 penalty exposure.

Failure 2: Section 5 as summary. Providers insert a summary of the Art.9 RMS into Section 5 rather than the full risk register and RMS process documentation. MSAs specifically look for this — a Section 5 summary is non-compliant.

Failure 3: Art.10 and Art.11 as separate workstreams. Teams produce Art.10 data governance documentation and then produce Section 2 independently, creating internal inconsistency. Integrated tooling prevents this.

Failure 4: No modification classification process. Without a formal substantial modification classifier, changes accumulate without triggering Art.11(4) updates. A retrospective documentation refresh at conformity reassessment is more expensive and more legally exposed than incremental updates.

Failure 5: 10-year retention misunderstood. Providers interpret the 10-year period as starting from market placement rather than from the date the last unit is placed on the market or put into service. For systems with long deployment tails, the effective retention window can extend well beyond initial projections.

See Also

• EU AI Act Art.9: Risk Management System — the full Art.9 RMS whose documentation feeds Annex IV Section 5
• EU AI Act Art.10: Data Governance — the data governance record that feeds Annex IV Section 2
• EU AI Act Art.12: Logging Obligations — logging specification that feeds Annex IV Section 3
• EU AI Act Art.13: Transparency Disclosure Management 2026 — Art.11(4) substantial modification triggers that drive Art.13 IFU version updates; transparency documentation that feeds Annex IV Sections 1 and 3
• EU AI Act Art.43–45: Conformity Assessment Procedures — the assessment pathways that consume Annex IV documentation
• EU AI Act Art.48: EU Declaration of Conformity — the Annex V DoC that appears in Annex IV Section 8