What Does Article 11 Require for AI Technical Documentation? A Python Implementation Guide

April 8, 2026 · Jason Shotwell · 14 min read

Last updated: April 17, 2026

Article 11 of the EU AI Act requires providers of high-risk AI systems to create and maintain technical documentation that demonstrates compliance before the system is placed on the market. This is not a Word document with outdated screenshots. It is a living record of system design, risk management, testing results, and post-deployment behavior that regulators can audit. If you ship AI in the EU after August 2, 2026, you need this documentation locked in before launch.

After building documentation pipelines for three compliance scanning tools, the biggest lesson is this: teams that treat documentation as code pass audits. Teams that treat it as a quarterly chore fail. This guide walks through what Article 11 actually requires, what Annex IV spells out in detail, and how to build documentation programmatically in Python so it stays synchronized with your actual system.

What Does Article 11 Actually Require?

Article 11 mandates that before deployment, providers of high-risk AI systems must have technical documentation covering seven areas: system description, design specifications, development process, risk management measures, monitoring and testing plans, change history, and compliance cross-references to other articles. The documentation must be kept up to date throughout the system's operational lifetime - it is not a one-time deliverable.

The specifics break down into these required elements:

1. System description - What the system does, what problem it solves, which users it serves
2. Design specifications - Architecture, data pipelines, model selection rationale, training data characteristics
3. Development process - How the system was built, tested, validated, and approved for deployment
4. Risk management measures - Tied directly to Article 9 risk assessments: what risks were identified and how you mitigated them
5. Monitoring and testing - What you measure post-deployment, how you detect failures, what triggers alerts
6. Changes and updates - Version control for the entire system lifecycle, including data updates, model retraining, and configuration changes
7. Compliance cross-references - How the system satisfies Articles 9, 10, 12, 14, and 15

The key insight: this is not documentation about compliance. It is documentation that proves compliance. Every requirement from Articles 9 through 15 should map to a specific section in your technical file.

What Does Annex IV Require You to Document?

Annex IV of the EU AI Act lists the exact items that must appear in your technical documentation. Regulators use this as their checklist. If an item is missing, the audit fails regardless of how good your code is. The table below maps each item to the article it satisfies.

Each item should be updated during development and maintained throughout the system's operational lifetime. The August 2026 enforcement deadline applies to systems deployed after that date.

How Do You Build a Model Card in Python?

A model card is a structured summary of what a model does, what data trained it, and how it performs. Defining it as a Python dataclass satisfies Annex IV items 2 (data description), 3 (model architecture), and 5 (performance testing) in a single version-controlled artifact. When the model changes, the dataclass changes with it - no separate document to update.

from dataclasses import dataclass
from typing import Optional
import json

@dataclass
class ModelCard:
    # System identification
    system_name: str
    system_version: str
    intended_use: str
    # Data
    training_data_source: str
    training_data_size: int
    labeling_methodology: str
    known_biases: list[str]
    # Model
    model_type: str
    framework: str
    # Performance
    accuracy_test_set: float
    accuracy_real_world: float
    fairness_metrics: dict
    failure_modes: list[str]
    # Risk
    identified_risks: list[str]
    mitigation_measures: dict
    # Monitoring
    monitoring_frequency: str
    alert_thresholds: dict

    def to_markdown(self) -> str:
        """Export as markdown for compliance documentation."""
        lines = [
            f"# {self.system_name} v{self.system_version}",
            f"\n## System Description\n{self.intended_use}",
            f"\n## Training Data\n- Source: {self.training_data_source}",
            f"- Size: {self.training_data_size:,} samples",
            f"- Labeling: {self.labeling_methodology}",
            f"- Known biases: {', '.join(self.known_biases)}",
            f"\n## Model\n- Type: {self.model_type}",
            f"- Framework: {self.framework}",
            f"\n## Performance\n- Test accuracy: {self.accuracy_test_set:.2%}",
            f"- Real-world accuracy: {self.accuracy_real_world:.2%}",
            f"- Fairness: {json.dumps(self.fairness_metrics, indent=2)}",
            f"\n## Failure Modes\n" + "\n".join(
                [f"- {mode}" for mode in self.failure_modes]
            ),
            f"\n## Risks and Mitigations\n" + "\n".join(
                [f"- {risk}: {self.mitigation_measures[risk]}"
                 for risk in self.identified_risks]
            ),
        ]
        return "\n".join(lines)

Populate this card once during development and version it alongside your model:

card = ModelCard(
    system_name="CreditRisk-v2",
    system_version="2.3.1",
    intended_use="Assess creditworthiness for loan applications in EU markets",
    training_data_source="Internal loan database 2018-2025",
    training_data_size=125000,
    labeling_methodology="Default status after 90 days",
    known_biases=["Overrepresented: prime-age males in tech hubs",
                   "Underrepresented: rural applicants, older workers"],
    model_type="Gradient boosting (XGBoost)",
    framework="xgboost==2.0.1",
    accuracy_test_set=0.87,
    accuracy_real_world=0.84,  # Real-world is lower (normal)
    fairness_metrics={
        "demographic_parity_difference": 0.12,
        "equal_opportunity_difference": 0.08
    },
    failure_modes=[
        "Model underperforms for self-employed applicants (< 60% accuracy)",
        "Drift detected when interest rates change rapidly"
    ],
    identified_risks=[
        "Fairness: Model bias against certain age groups",
        "Robustness: Performance degrades with economic shock",
        "Transparency: Black-box model obscures decision logic"
    ],
    mitigation_measures={
        "Fairness: Model bias against certain age groups":
            "Monitored monthly, threshold 0.15 triggers retraining review",
        "Robustness: Performance degrades with economic shock":
            "Real-time monitoring on economic indicators, auto-disable if GDP growth < -2%",
        "Transparency: Black-box model obscures decision logic":
            "SHAP explanations for every denial, audit trail per Article 12"
    },
    monitoring_frequency="Daily",
    alert_thresholds={
        "accuracy_drop": 0.03,
        "fairness_gap": 0.20,
        "drift_detected": True
    }
)

# Save and version with model
with open("docs/model_card.md", "w") as f:
    f.write(card.to_markdown())

This single dataclass becomes your Annex IV items 2, 3, and 5. It is version-controlled, auditable, and automatically formatted for regulators.

How Do You Auto-Generate Architecture Documentation?

Running a compliance scanner on your codebase produces a report that maps directly to Article 11 requirements. Instead of writing architecture documentation by hand and watching it drift within weeks, extract the report and build your architecture documentation from the scan results. This keeps documentation synchronized with actual system behavior.

from air_compliance import scan_project

# Scan your codebase
report = scan_project("./my_ai_system")

# Generate architecture documentation from scan results
arch_doc = f"""
# System Architecture

## Components Identified
{report.components_summary}

## Risk Assessment (Article 9)
{report.article_9_findings}

## Data Governance (Article 10)
{report.article_10_findings}

## High-Risk Zones
- {chr(10).join([f"- {zone['name']}: {zone['risk_level']}"
                   for zone in report.high_risk_areas])}

## Dependencies
{report.dependency_audit}

## Compliance Score
{report.overall_score}/100

## Required Actions
{report.remediation_steps}
"""

with open("docs/architecture.md", "w") as f:
    f.write(arch_doc)

Run this in CI/CD on every commit to catch compliance drift before it reaches production.

How Does Article 11 Integrate with Articles 9, 10, 12, 14, and 15?

Article 11 documentation does not stand alone. Regulators expect a unified technical file where every claim cross-references the article that governs it. A risk identified under Article 9 must have a corresponding mitigation shown in Article 11 code. A monitoring claim must link to an Article 12 audit trail. If the cross-references are missing, the documentation fails even if individual components are strong.

The integration points are:

• Article 9 (Risk Management): Your Article 11 technical file should include the risk register, mitigation strategies, and residual risk assessments. Link your model card's identified_risks directly to Article 9 risk IDs.
• Article 10 (Data Governance): Training data provenance, data quality metrics, bias assessment, and consent/licensing proof belong in your technical documentation. Include consent matrices and data source audits.
• Article 12 (Record-Keeping): Link to your audit trail implementation. Show how events are logged, signed, and retained. Include sample audit logs.
• Article 14 (Human Oversight): Document approval workflows, human-in-the-loop decision points, and identity binding. Show who can modify the system and audit records of those modifications.
• Article 15 (Accuracy and Security): Include testing results, adversarial testing, and robustness validation. Document your penetration testing methodology and threat model.

Example cross-reference format:

# In your Article 11 technical file:

## Risk: Model Bias Against Certain Demographics
- **Article 9 ID:** RISK-032
- **Severity:** High
- **Mitigation:** Monthly fairness audits, bias threshold 0.15
- **Article 12 Link:** Fairness metrics logged daily to audit chain
- **Article 14 Link:** Bias alert triggers manual review by Data Ethics Officer
- **Article 15 Link:** Tested against NIST bias taxonomy, 94% of cases within tolerance

How Do You Automate the Full Documentation Pipeline?

Treat documentation generation as a CI/CD step, not a quarterly chore. The most common reason Article 11 audits fail is documentation drift - the technical file says one thing and the code does another. Automating the pipeline eliminates this gap by generating documentation from authoritative sources (code, config, scan results) on every deployment.

from air_compliance import scan_project, generate_documentation
import json
from datetime import datetime

# Run compliance scan
report = scan_project("./src")

# Load your model card
with open("model_card.json") as f:
    card = json.load(f)

# Generate complete technical file
tech_file = generate_documentation(
    report=report,
    model_card=card,
    article_9_risks=load_risk_register(),
    article_10_data=load_data_audit(),
    article_12_logs=load_recent_audit_logs(),
    article_14_approvals=load_approval_chain(),
    article_15_tests=load_test_results(),
    generated_at=datetime.now().isoformat()
)

# Write as HTML and PDF for regulators
with open(f"compliance/{report.version}/technical_file.html", "w") as f:
    f.write(tech_file.to_html())

tech_file.to_pdf(
    f"compliance/{report.version}/technical_file.pdf"
)

This generates a complete, auditable technical file with version control, timestamps, and cross-references. Every artifact is backed by source code and scan results.

Why Does Documentation-as-Code Beat Traditional Approaches?

Documentation written by hand drifts. After scanning dozens of AI systems for Article 11 compliance, the pattern is consistent: teams with hand-written technical files have an average documentation accuracy of 60-70% within six months of deployment. Teams using documentation-as-code maintain 95%+ accuracy because the pipeline catches every change.

Documentation-as-code means:

• Versioned in Git: Every documentation change is tracked, reviewed, and approved before deployment
• Tested in CI/CD: Run air-compliance on every commit - if code changes but documentation is not updated, the build fails
• Auto-generated where possible: Model cards, architecture diagrams, performance metrics, risk matrices - all derived from authoritative sources
• Human-written where necessary: System purpose, intended use cases, failure mitigation strategies - these are written by engineers and reviewed by auditors
• Linked to source: Every statement in your technical file should reference the code, config, or test that backs it up

The result is documentation that regulators trust because every claim can be traced back to source.

What Are the Most Common Documentation Gaps?

Five documentation gaps cause the majority of Article 11 audit failures. Each has a straightforward fix, but you need to address them before the August 2026 deadline - not after a regulator flags them.

No versioning. You update your model, but the technical file is still v1.0 from last year. Fix: link version numbers to Git tags and generate documentation per release.

No risk assessment linkage. Your Article 9 risk register is separate from Article 11 documentation. Regulators see the risks but not how you mitigated them in your actual system. Fix: every risk in Article 9 must have a corresponding mitigation in Article 11 (code, test, monitoring rule).

No lifecycle updates. Documentation frozen at deployment while the real system changes - data drifts, models get retrained, configs evolve. Fix: quarterly documentation reviews and automated monitoring for changes that require doc updates.

Performance data from dev, not production. Your accuracy is 92% in tests but 84% in production. If regulators find a gap, credibility dies. Fix: include both test-set performance and real-world performance, and explain the gap.

Monitoring plans with no implementation. You document that you will monitor accuracy drift, but nothing actually does it. Fix: documentation should link to actual monitoring code - if you say you will alert on drift > 3%, show the code that does it.