EU AI Act Art.11 Technical Documentation 2026: What High-Risk AI Providers Must Create

Post #3 in the sota.io EU AI Act Provider Sprint 2026 Series

Article 11 of the EU AI Act imposes a specific obligation on providers of high-risk AI systems: you must draw up comprehensive technical documentation before your system is placed on the EU market or put into service. Not after. Not during the first audit. Before.

This documentation is not a summary slide deck or a wiki page. Article 11, read together with Annex IV, specifies eight categories of information that must be present, accurate, and current throughout the lifecycle of your system. Market surveillance authorities can demand it within ten days. Notified bodies review it during conformity assessment. Deployers rely on it to fulfill their own Art.26 obligations.

This guide covers exactly what that documentation must contain, how to maintain it, and how it connects to the Art.9 risk management system and Art.10 data governance obligations you have already implemented as part of this series.

Who Art.11 Applies To

Article 11 obligations fall on providers — organizations that develop high-risk AI systems and place them on the EU market or put them into service under their own name or trademark. If you:

• Build a high-risk AI system listed in Annex III (recruitment tools, credit scoring, education assessment, law enforcement tools, critical infrastructure components, etc.)
• Make it available to others (deployers) or operate it yourself in the EU
• Develop it as a component integrated into another system marketed under your brand

…then Article 11 applies to you.

Deployers are different. Deployers must maintain a copy of the technical documentation they receive from you (Art.26(6)), but the obligation to create comprehensive technical documentation sits with the provider. If you are both developing and deploying your own high-risk AI system, you carry both sets of obligations.

The threshold: Article 11 applies to all high-risk AI systems falling under Annex III, with very limited exceptions for AI systems already covered by other EU harmonization legislation (medical devices, machinery, etc. — where sector-specific documentation requirements already exist under those regimes).

What Technical Documentation Must Contain: Annex IV

Annex IV of the EU AI Act defines eight categories of information that your technical documentation must contain. This is a legal floor, not a suggested checklist — missing items constitute a non-conformity that can block market access.

Category 1: General Description of the AI System

The general description section covers the entire footprint of your system at a high level. It must include:

1.1 Intended purpose and version information

• The intended purpose of the system (exact statement, matching what you use in marketing and user-facing materials)
• The specific persons or classes of persons the system is intended to be used by, with reference to intended operational context
• Version number and date of the system covered by this documentation

1.2 Hardware and software context

• Specification of the hardware the AI system is intended to run on (on-premises deployment requirements, cloud configuration, GPU/CPU requirements)
• Software dependencies, runtime environment, operating system requirements
• Integration points with other software or hardware systems that affect functioning

1.3 Deployment forms

• All forms in which the AI system is made available: SaaS API, embedded component, standalone application, mobile app
• Any configuration variations that change system behavior materially (different model configurations, feature flags that affect high-risk functionality)

1.4 Operational procedures

• Step-by-step description of how the AI system is started, operated, and shut down
• Description of how the system interacts with human operators during normal functioning
• Description of override and intervention capabilities (directly connects to Art.14 human oversight obligations)

Why this matters operationally: The general description section is typically what market surveillance authorities read first. Inconsistencies between what this section says and what your system actually does — or what you tell customers — trigger deeper review. Keep it synchronized with your marketing materials, API documentation, and user agreements.

Category 2: Development Process Detail

This is the most technically demanding section of Annex IV. It requires detailed documentation of your development methodology with enough specificity that an auditor could understand, replicate key elements of, and evaluate the quality of your development decisions.

2.1 Design choices and trade-offs

• Rationale for the chosen model architecture (transformer, CNN, ensemble, etc.)
• Trade-offs considered between different design approaches: accuracy vs. explainability, performance vs. privacy, automation vs. human oversight
• Justification for decisions that increased risk (e.g., choosing a less explainable model for higher accuracy) alongside the mitigations implemented

2.2 Training methodology

• Description of the training methodology and techniques used (supervised learning, fine-tuning, reinforcement learning, federated learning, etc.)
• Training objectives, loss functions, and optimization approach
• Hardware and infrastructure used for training
• Approximate compute resources consumed

2.3 Training, validation, and test data This subsection directly bridges to your Art.10 data governance documentation:

• Full description of training datasets: source, size, format, date range
• Description of validation datasets and split methodology
• Description of test datasets and how they differ from training data
• Data collection methodology: how data was gathered, from what sources, under what conditions
• Data annotation methodology: who labeled the data, what instructions were given, how inter-annotator agreement was measured
• Data exclusion criteria: what data was intentionally excluded and why (connects to bias examination under Art.10)
• Limitations of the training data and known gaps

2.4 Accuracy and performance characteristics

• Accuracy metrics used: precision, recall, F1, AUC, or domain-specific metrics
• Performance benchmarks against established baselines or prior versions
• Breakdown of performance across demographic subgroups where applicable (anti-discrimination implications under Art.10)
• Limitations in accuracy: known edge cases, distribution shift risks, degradation conditions

2.5 Standards applied

• List of EU harmonized standards applied (EN standards for AI systems as published by CEN/CENELEC)
• Any common specifications applied
• Technical standards from non-EU bodies applied (ISO, IEEE, NIST)

Category 3: Monitoring, Functioning, and Control Information

This section describes how the system behaves in operation and what controls exist to ensure it continues performing as intended.

3.1 Capabilities and limitations during operation

• Performance specifications under normal operating conditions
• Known performance degradation scenarios (out-of-distribution inputs, unusual user behavior, adversarial inputs)
• Minimum performance thresholds below which the system should not be used
• Operating conditions outside which performance guarantees do not apply

3.2 Input data specifications

• Precise description of all inputs the AI system accepts: data types, formats, ranges, distributions
• Pre-processing steps applied to inputs before they reach the model
• Validation or sanitization applied to inputs
• What happens when inputs fall outside expected ranges

3.3 Training data characteristics (for monitoring purposes)

• Statistical properties of the training data distribution relevant to detecting distribution shift in production
• Expected input data distribution in production and how it was estimated
• Mechanisms for detecting when production data diverges significantly from training data

3.4 Robustness and security measures

• Technical measures implementing cybersecurity resilience (connects to Art.15 accuracy, robustness, and cybersecurity obligations)
• Protection against adversarial attacks, prompt injection (for LLM-based systems), model extraction, and data poisoning
• Testing methodology for robustness: red-teaming, adversarial testing, fuzz testing

3.5 Logging capabilities This subsection documents your implementation of Art.12 obligations. The technical documentation must specify:

• What events the system automatically logs (at minimum: operational state, input/output data or summaries, anomalies)
• Log retention period
• Log format and access controls
• How logs can be retrieved by deployers and by market surveillance authorities

3.6 Human oversight mechanisms A direct connection to Art.14:

• Technical mechanisms enabling human operators to understand system outputs
• Override capabilities: how an operator can stop, modify, or override system decisions
• Escalation paths when system operates outside expected parameters

Category 4: Risk Management Documentation

This section must include a description of the risk management system you have implemented under Article 9. You do not need to duplicate the full risk register here — a summary with reference to your standalone Art.9 documentation is acceptable, provided the Art.9 documentation is available to authorities upon request.

Minimum required elements:

• Overview of the risk management process implemented
• Key identified risks and their classification (based on probability, severity, reversibility)
• Risk mitigation measures implemented at design, training, and deployment phases
• Testing performed to validate that mitigations are effective
• Residual risks accepted and the basis for accepting them
• Any risks identified post-deployment and how they were addressed

For systems in sensitive categories (biometric identification, employment screening, creditworthiness assessment) the risk management documentation should also include:

• Assessment of fundamental rights impact
• Consultation process followed (who was involved in identifying risks)
• Escalation path if significant risks are identified post-deployment

Documentation format recommendation: Maintain a risk register with entries linking to specific Annex IV items. Each entry: risk description → probability assessment → severity assessment → mitigation measure → residual risk → review date. This format makes authority review efficient and demonstrates systematic process.

Category 5: Lifecycle Changes

The EU AI Act recognizes that AI systems change over time. Category 5 requires documentation of all significant changes made to the system during its operational lifecycle.

What constitutes a significant change?

The Regulation does not enumerate every scenario, but the following changes should be documented as a matter of course:

• Re-training on substantially different data
• Changes to model architecture or algorithm
• Changes to intended purpose or user group
• Changes that affect the system's behavior in ways that could affect compliance with Art.9-15
• Updates that address identified risks or vulnerabilities
• Changes made in response to market surveillance authority findings

Trigger for re-assessment: If a change is significant enough to "affect compliance of the high-risk AI system with this Regulation or results in a change to the intended purpose of that system," it triggers a new conformity assessment. Document which changes were assessed as triggering this threshold and which were not, with rationale.

Practical approach: Maintain a change log with version entries. Each entry: change description → date → rationale → assessment of compliance impact → decision (significant change requiring new conformity assessment: yes/no) → signatory. This log forms part of your technical documentation and should be updated with each material release.

Category 6: EU Declaration of Conformity

A copy of the EU Declaration of Conformity signed under Article 47 must be included in or attached to the technical documentation.

The EU Declaration of Conformity must include:

• Provider name and address
• AI system identification (name, model/version number)
• Statement that the system is in conformity with the EU AI Act
• Reference to standards or specifications applied
• Place and date of issue
• Identity and signature of the authorized person

This document carries legal weight. Signing an EU Declaration of Conformity for a system that does not actually meet the requirements creates direct liability — not just regulatory risk, but potential civil liability toward deployers and affected persons.

Timing: The declaration is drawn up and signed as part of completing the conformity assessment procedure. Technical documentation must be in place before this document can be legitimately signed.

Category 7: Testing, Validation, and Test Logs

All testing performed to demonstrate compliance with Art.9-15 requirements must be documented here. This includes:

Pre-market testing:

• Test plans and test methodology for each relevant obligation (accuracy, robustness, bias, human oversight)
• Test environments and configurations
• Test results: quantitative metrics where applicable
• Test date and personnel

Validation results:

• Cross-validation methodology
• Hold-out test set results
• Any external validation conducted (independent third-party testing, notified body review)

Test logs: The actual logs from automated test runs should be preserved. For LLM-based systems or systems where tests are probabilistic, document how repeatability is achieved (fixed seeds, deterministic evaluation frameworks, etc.).

Anti-bias testing: Document specifically:

• Protected characteristics tested for bias
• Methodology: disparate impact testing, equalized odds, counterfactual fairness, or other approach
• Thresholds used to define acceptable vs. unacceptable disparity
• Results by subgroup

Category 8: Post-Market Monitoring Plan

The final Annex IV category requires your post-market monitoring plan, implemented under Article 72. This plan must describe:

8.1 Active monitoring mechanisms

• How you continuously monitor system performance in production (not just alerts for failures, but proactive tracking of performance metrics)
• Frequency of monitoring reviews
• KPIs monitored and thresholds for review or intervention

8.2 Feedback mechanisms from deployers

• How deployers can report incidents, near-misses, or degraded performance
• SLA for responding to deployer reports
• Process for escalating deployer reports to your engineering team

8.3 Serious incident reporting pipeline Connection to Art.73 obligations (covered in detail in the previous series post):

• How serious incidents reported by deployers or identified internally are logged
• Reporting timeline: 2/10/15 day requirements for different severity levels
• Who is responsible for triggering regulatory notifications

8.4 Corrective action process

• What actions can be taken if monitoring identifies degraded performance or new risks
• Who can authorize corrective actions
• Timeline for implementing corrections
• How corrections are documented and whether they trigger a change log entry (Category 5) or new conformity assessment

Maintenance Obligations: Keeping Documentation Current

Article 11 requires that technical documentation be kept up to date throughout the system's lifecycle. This is an active obligation, not a one-time compliance exercise.

The 10-year retention minimum: Technical documentation must be kept for 10 years after the AI system has been placed on the market or put into service (whichever is later). For SaaS products with continuous deployment, the clock resets for each significant change — meaning documentation obligations extend well beyond product sunset dates.

When documentation must be updated:

Version control: Technical documentation should be version-controlled. Each version should reference the system version it applies to. When authorities request documentation, you must be able to provide the version that applied to the system as deployed at the time of the incident or inspection.

Providing Documentation to Authorities

Article 11 together with Article 74 creates the obligation to provide technical documentation to national competent authorities upon request.

Practical requirements:

Response time: Authorities can request documentation and expect access within a reasonable period. Ten working days is the standard interpretation for initial response — you cannot delay months. Maintain documentation in a format that can be exported and shared quickly.

Language: The regulation does not specify a single language, but authorities in different member states may request documentation in their national language. Consider maintaining English as the primary language (broadly accepted by EU technical authorities) with translation capability for key markets.

Format: No specific format is mandated by the Regulation. Standard practice is PDF export of version-controlled documents. Ensure documents include version numbers, dates, and author/reviewer signatures.

Confidentiality protections: Market surveillance authorities are bound by confidentiality obligations when handling commercially sensitive technical documentation. Document which sections contain trade secrets so you can assert protection if documentation becomes subject to disclosure requests.

Access by deployers: Under Article 13 (transparency obligations), providers must give deployers access to the information they need to fulfill their own obligations. This is not the full Annex IV documentation — it is a subset covering intended purpose, accuracy characteristics, human oversight requirements, and risk mitigations. Maintain a "deployer information package" distinct from the full technical documentation.

Integration with Art.9, Art.10, and Art.17

Technical documentation under Art.11 does not exist in isolation — it is the documentary spine that connects all the substantive obligations under Chapter III.

Art.9 → Art.11 connection: Your risk management system (Art.9) must be fully documented within Category 4 of Annex IV. The risk register, risk mitigation measures, and residual risk acceptances from Art.9 flow directly into the technical documentation. Maintain bidirectional references: each Art.9 risk entry should reference the documentation location, and the Annex IV Category 4 section should reference the live risk register.

Art.10 → Art.11 connection: Data governance documentation (Art.10) feeds Category 2.3 (training data description), Category 2.4 (accuracy characteristics by subgroup), and Category 7 (anti-bias testing). The training data documentation required by Art.10 — sources, preprocessing steps, bias examination results — must be summarized in the technical documentation and retained as part of it.

Art.11 → Art.17 connection: Your quality management system under Art.17 (the subject of the next post in this series) must govern the process of creating and maintaining technical documentation. Article 17 explicitly requires QMS to cover technical documentation — it is not enough to have good documents; you need a documented process for creating, reviewing, updating, and approving those documents.

25-Item Technical Documentation Checklist

Use this checklist before signing the EU Declaration of Conformity (Category 6) or submitting to a notified body.

General Description (Category 1)

• 1.1 Intended purpose statement — precise, matches marketing materials and user agreements
• 1.2 Intended user description — role, technical capability, operational context
• 1.3 Hardware requirements documented — GPU/CPU, RAM, storage, network
• 1.4 Software dependencies documented — runtime, OS, third-party libraries
• 1.5 All deployment forms listed — API, SaaS, embedded, mobile
• 1.6 Operational procedures written — startup, normal operation, shutdown, override

Development Process (Category 2)

• 2.1 Model architecture and design rationale documented
• 2.2 Training methodology described — algorithm, objective, optimization
• 2.3 Training dataset description — source, size, date range, annotation method
• 2.4 Validation and test dataset descriptions — split methodology, independence verification
• 2.5 Performance metrics defined and baseline results documented
• 2.6 Anti-bias testing methodology and results documented by demographic subgroup
• 2.7 Harmonized standards applied — list with version numbers

Monitoring and Control (Category 3)

• 3.1 Known limitations and degradation conditions documented
• 3.2 Input data specifications — types, formats, expected ranges
• 3.3 Logging capabilities described — events logged, retention, access controls
• 3.4 Cybersecurity measures documented — adversarial input testing, vulnerability assessment

Risk Management (Category 4)

• 4.1 Risk register summary included — key risks, mitigations, residual risks
• 4.2 Fundamental rights impact assessment included (for sensitive categories)

Change and Conformity Records (Categories 5-6)

• 5.1 Change log format established and initial version documented
• 5.2 Significance threshold defined for determining when changes trigger re-assessment
• 6.1 EU Declaration of Conformity drafted and reviewed by legal

Testing Evidence (Category 7)

• 7.1 Pre-market test plans and results included
• 7.2 Anti-bias test logs preserved and referenced

Post-Market Monitoring (Category 8)

• 8.1 Post-market monitoring plan documented — KPIs, review frequency
• 8.2 Incident escalation process documented — Art.73 pipeline
• 8.3 Deployer feedback channel defined and described

Common Implementation Failures

Failure 1: Documentation exists but is not version-controlled The most common gap found in informal audits: teams have documentation, but there is no clear version history, no indication of what system version the document applies to, and no audit trail for changes. Documentation that cannot be tied to a specific deployed system version has limited evidentiary value.

Fix: Implement documentation as code — store in a version control system, tag documentation releases to system releases, require sign-off from technical lead and compliance owner for each version.

Failure 2: Training data description is aspirational rather than factual Documentation describes the ideal dataset (representative, balanced, carefully annotated) but the actual dataset was assembled under different conditions. If market surveillance authorities compare the documentation to the actual training data, discrepancies are a significant finding.

Fix: Write the training data description after the dataset is finalized, not from the project plan. Document what you actually did, including shortcuts and limitations.

Failure 3: Anti-bias testing only covers protected characteristics mandated by local law Providers often test for gender and ethnicity but not for age, disability, or socioeconomic status because those are not always enumerated in the specific national law they are most familiar with. The EU AI Act's risk management obligations are broader.

Fix: Use the EU Charter of Fundamental Rights as the baseline for determining which characteristics to test — it has broader protection than most national implementation laws.

Failure 4: Post-market monitoring plan is a template with no operational owner A document describing monitoring procedures that no specific team has been assigned to execute is not a post-market monitoring plan — it is a word processing exercise.

Fix: Assign a named role (not a person — people change, roles are more durable) as monitoring owner. Define the specific dashboards, alert thresholds, and review calendar they are responsible for.

Failure 5: Technical documentation not updated after security patches Teams correctly update documentation after model updates but overlook security patches, infrastructure changes, and configuration changes that affect the cybersecurity section (Category 3.4). A security patch that changes how inputs are validated affects the technical documentation.

Fix: Include technical documentation review as a checklist item in your release management process for all production changes, not just model changes.

Failure 6: Deployer information package conflated with internal technical documentation The full Annex IV documentation contains trade secrets and proprietary methods. Teams sometimes provide this directly to deployers instead of maintaining a separate, curated deployer information package. This creates both confidentiality risk and a compliance gap if the deployer package is incomplete.

Fix: Maintain two distinct document sets: the full Annex IV technical documentation (internal + for authorities) and the deployer information package (for Art.13 compliance). Keep them synchronized but separate.

Implementation Timeline

With the August 2, 2026 enforcement deadline 64 days away, providers who have not started technical documentation should prioritize as follows:

Weeks 1-2 (now): Complete Categories 1 and 2. General description and development process documentation can be drafted from existing artifacts (architecture docs, model cards, training runbooks). This covers the largest share of total documentation volume.

Weeks 3-4: Complete Categories 3 and 4. Monitoring documentation requires input from engineering (logging) and risk management documentation requires input from your Art.9 process outputs. If you implemented Art.9 in the previous series post, pull from that work directly.

Weeks 5-6: Complete Category 7 — test logs — which requires running or confirming your testing suite and preserving results. Anti-bias testing should be completed and documented. Begin drafting the EU Declaration of Conformity.

Week 7: Complete Categories 5, 6, and 8. Establish the change log format. Draft and internally review the EU Declaration of Conformity. Finalize the post-market monitoring plan with assigned roles.

Week 8 (before August 2): Final documentation review. Legal sign-off on EU Declaration of Conformity. Version-control final documentation set. Verify documentation can be exported and provided to authorities within 10 working days.

Summary

Article 11 and Annex IV impose eight documentation categories on high-risk AI providers — general description, development process, monitoring and control, risk management, lifecycle changes, EU Declaration of Conformity, test logs, and post-market monitoring. Documentation must be complete before market placement, kept current throughout the lifecycle, and accessible to market surveillance authorities within ten working days.

The August 2, 2026 enforcement date means providers who are behind on documentation now have approximately eight weeks. The categories are sequential in the sense that each builds on prior work — start with the general description and development process documentation while your Art.9 risk management and Art.10 data governance implementations are still fresh.

The next post in this series covers Article 17: the Quality Management System obligations that govern how providers establish, implement, and maintain the processes that produce this documentation.

Upcoming in this series:

• Post #4: EU AI Act Art.17 Quality Management System 2026: Implementing QMS for High-Risk AI Providers
• Post #5: EU AI Act Provider Sprint Finale 2026: Complete Compliance Stack for August 2

Previous posts in this series:

• EU AI Act Art.9 Risk Management System 2026: Provider Requirements Guide
• EU AI Act Art.10 Data Governance 2026: High-Risk AI Provider Guide