EU AI Act Technical Documentation: What Annex IV Requires Before Your Conformity Assessment

Post #1458 in the sota.io EU Regulatory Compliance Series — EU AI Act Conformity Assessment Sprint 2026 #2/5

Before you can issue an EU declaration of conformity or pass a notified body audit, you need to produce the technical documentation that the EU AI Act requires under Article 11. This documentation is not a summary slide deck or a one-page description. Annex IV of the regulation specifies ten categories of content that must be compiled, maintained, and made available to market surveillance authorities on request.

If your SaaS product deploys a high-risk AI system — in employment screening, creditworthiness assessment, biometric identification, or any other Annex III category — you have until August 2, 2026 to complete this documentation. This is the second post in our five-part conformity assessment series. We cover exactly what Annex IV requires and how SaaS providers should structure their technical documentation package.

Why Technical Documentation Is the Foundation of Conformity

Under Article 43, the conformity assessment procedure either runs through internal control (Annex VI) or through a notified body. Both paths share a prerequisite: the technical documentation specified in Annex IV must exist and be complete before the assessment can proceed.

For internal control (the path most SaaS providers take for Annex III systems), your technical documentation is the assessment. You compile it, your quality management system validates it, and you sign the EU declaration of conformity under Article 47 based on it. No external reviewer signs off — the documentation itself is your evidence of compliance.

For notified body assessment (required for Annex I product safety overlap scenarios), the notified body audits your Annex IV documentation. An incomplete or inconsistent technical documentation package is the most common reason notified body assessments fail or require costly re-audit cycles.

Under Article 18, this documentation must be kept for ten years after the high-risk AI system is placed on the market or put into service, and updated whenever the system changes in ways that could affect its compliance status.

The Ten Annex IV Documentation Categories

1. General Description of the AI System

This is your executive summary for regulators, not for customers. It must include:

• The intended purpose of the system (the use case as defined in your product specification, not your marketing copy)
• The version number and any other identifier that ties the documentation to a specific system release
• How the system interacts with hardware or software the provider does not supply
• The forms in which the system is placed on the market: embedded in a product, standalone SaaS API, white-labeled module, or other deployment form

The general description must be precise enough that a market surveillance authority reading it could determine which of the Annex III high-risk categories the system falls into and why your classification is correct.

Common failure: Providers write product descriptions that omit the specific decision or output the system produces. A recruitment screening tool that "helps HR teams evaluate candidates efficiently" is not a compliant general description. "Provides automated candidate scoring on a 0–100 scale used by HR teams to short-list applicants for human review" is closer to what Article 11 requires.

2. Detailed Description of the Development Process

Annex IV requires documentation of how the system was built, not just what it does. This includes:

Training methodology and data:

• The datasets used to train the model, including their sources, characteristics, and any known limitations
• How training data was collected, labelled, and pre-processed
• Statistical properties of the training dataset (class distribution, geographic coverage, temporal range)
• Measures taken to ensure the training data meets the data governance requirements of Article 10

Model architecture and design choices:

• The type of model (classification, regression, generative, reinforcement learning, ensemble)
• The architecture choices made and the rationale for them
• The computational methods used (gradient descent, tree-based methods, transformer-based architectures)

Testing and validation:

• The test dataset used, its relationship to the training data, and how it was kept separate
• All performance metrics measured and their values on the test dataset
• The metrics chosen to assess accuracy, robustness, and cybersecurity under Article 15, and the thresholds applied to determine whether the system is fit for deployment

This section is where most SaaS providers have the largest documentation gap. If your model was trained by a third-party foundation model provider or fine-tuned on a proprietary dataset, you need to document your access to that documentation and what you verified about the third party's training process.

3. The Risk Management System Documentation

Article 9 requires providers to implement, document, and maintain a risk management system throughout the lifecycle of the high-risk AI system. Annex IV requires that documentation of this risk management system be included in the technical documentation package.

The required content includes:

• The risk identification process: what risks were identified as reasonably foreseeable during intended use and reasonably foreseeable misuse
• The risk estimation and evaluation methodology applied
• The risk mitigation measures implemented and the residual risks accepted
• Evidence that the risk mitigation measures were tested and their effectiveness evaluated

For SaaS providers, the most significant risks typically fall into three categories:

Discriminatory outcomes: Does the system produce outputs that systematically disadvantage groups defined by race, gender, age, or other protected characteristics? You must document what tests you ran to detect this, what the results were, and what mitigations you applied.

Inaccurate outputs at decision points: What happens when the system produces a wrong output? You must document the failure mode, the probability of occurrence, and the measures your system takes to limit downstream harm.

Data poisoning or adversarial inputs: For systems that process user-provided data, you must document what tests were run for robustness against manipulated inputs.

4. Monitoring, Functioning, and Control

This section documents how the system behaves in production, not just in development. Required elements include:

• A description of the human oversight measures required under Article 14: who has authority to intervene, what controls are available to deployers, and how the system communicates its confidence level or uncertainty to humans in the loop
• The logging specifications: what events the system records automatically under Article 12 (automatically generated logs), including the minimum log retention period
• The monitoring plan required under Article 72 (post-market monitoring): what metrics are tracked, at what frequency, and what thresholds trigger a re-assessment or corrective action

For SaaS products, this section must address a specific question that many providers overlook: when a deployer customises the system's behaviour through configuration or fine-tuning, does the monitoring plan cover the customised version, or only the default configuration? If deployers can materially change how the system makes decisions, your Article 72 monitoring plan must account for that.

5. Appropriateness of Performance Metrics

Annex IV requires specific documentation of why the performance metrics you chose are appropriate for the intended purpose and risk profile.

This is not a list of your metrics. It is a justification for your choice of metrics given the specific harms the system could cause.

For example: if your system is a CV screening tool used in recruitment, accuracy on the overall test dataset is a poor primary metric because it can mask systematic underperformance on demographic subgroups. Your documentation must explain whether you used disaggregated performance metrics, which subgroups were evaluated, and what the results showed.

Market surveillance authorities have been explicit in guidance that providers who document high overall accuracy while ignoring subgroup performance will not satisfy this requirement.

6. Risk Management Through the Lifecycle

This is distinct from the upfront risk assessment. Annex IV requires documentation of:

• The process for monitoring risks that emerge after deployment
• The process for updating the risk management documentation when changes are made to the system
• The criteria for triggering a new conformity assessment (under Article 43, a substantial modification to a high-risk AI system requires a new assessment)

What counts as a substantial modification: Under Article 6 and Recital 66, a modification is substantial if it affects the compliance of the system with the requirements of Articles 9 through 15, or if it changes the intended purpose of the system. For SaaS providers who release updates continuously, you need a documented process for determining whether each update crosses this threshold.

7. Applicable Harmonised Standards

If you applied any harmonised standards in developing your system, Annex IV requires a list of those standards with the applicable sections identified.

As of August 2026, the European Commission has published a limited set of harmonised standards under the EU AI Act, primarily through CEN/CENELEC. Where harmonised standards do not yet cover a specific requirement, you must instead document the common specifications or technical standards you applied and explain how they satisfy the relevant Article 9–15 requirements.

For most SaaS providers, this section currently contains either:

• Reference to ISO/IEC 42001 (AI management systems) if the provider is certified
• Reference to internal technical standards, with documentation of how those standards map to the regulatory requirements
• An acknowledgment that applicable harmonised standards are not yet published, with documentation of the alternative approach taken

8. EU Declaration of Conformity

The technical documentation package must include a copy of the EU declaration of conformity under Article 47. The declaration must be signed by an authorised representative of the provider and must identify:

• The provider's name and address
• The system name, version, and intended purpose
• A statement that the system complies with the requirements of the EU AI Act applicable to it
• Reference to the conformity assessment procedure used (Annex VI internal control, or the specific notified body procedure)
• The notified body's name and identification number, if applicable
• The place and date of issue, and the signature of the authorised representative

A common mistake: Some providers draft the declaration of conformity before the technical documentation is complete. The declaration is a representation that the documentation exists and is accurate. If the documentation does not support the declaration, the entire conformity assessment is invalid.

9. Post-Market Monitoring Plan

Article 72 requires providers to actively monitor the performance of high-risk AI systems after deployment. The Annex IV technical documentation must include the post-market monitoring plan specifying:

• The data sources and methods for collecting post-market performance data (user feedback systems, log analysis, periodic audits)
• The performance indicators monitored and their target values
• The frequency of monitoring and reporting cycles
• The process for analysing monitoring results and determining whether corrective action is required
• Integration with the serious incident reporting process under Article 73

For SaaS providers, the post-market monitoring plan typically overlaps with existing observability infrastructure (logging, alerting, performance dashboards). The documentation task is making that infrastructure explicit and connecting it to the Article 72 requirements.

10. Changes Made Through the System Lifecycle

For systems that have been in development or production for some time before the August 2026 deadline, Annex IV requires documentation of significant changes made during the lifecycle and whether any of those changes required a re-assessment.

This is particularly relevant for SaaS providers who have been iterating on AI features for years before the EU AI Act applies to them. You need to:

• Identify significant changes made since the system was first developed
• Determine which of those changes would have triggered a new conformity assessment had the system already been subject to the regulation
• Document those changes and explain why each change either did or did not constitute a substantial modification

Common Gaps in SaaS Provider Documentation

After reviewing conformity assessment preparation across multiple SaaS providers, the most consistent gaps are:

Missing training data documentation: Many providers use third-party models or datasets without documenting the characteristics of those inputs. If you fine-tuned a foundation model, you need documentation from the foundation model provider describing the training data characteristics — or a substantiated risk assessment explaining why that information is not accessible.

Undocumented human oversight mechanisms: Article 14 requires that deployers have the capability to intervene, override, or disable the system. Many SaaS products include these features in their UI without documenting them as the required oversight mechanisms. The documentation must be explicit.

Version-locked documentation: Technical documentation tied to a version number that does not match the current production release is a significant finding in any audit. If your system releases weekly, your documentation process must keep pace.

Inadequate subgroup performance analysis: Documenting overall accuracy without subgroup analysis will not satisfy the Article 10 data governance and Article 15 performance requirements for most high-risk use cases.

How to Structure Your Annex IV Documentation Package

A practical structure for most SaaS providers:

technical-documentation/
├── 1-system-description/
│   ├── intended-purpose.md
│   ├── version-history.md
│   └── deployment-forms.md
├── 2-development-process/
│   ├── training-data-documentation.md
│   ├── model-architecture.md
│   └── test-validation-results.md
├── 3-risk-management/
│   ├── risk-register.md
│   ├── risk-mitigation-measures.md
│   └── residual-risks.md
├── 4-monitoring-controls/
│   ├── human-oversight-mechanisms.md
│   ├── logging-specification.md
│   └── post-market-monitoring-plan.md
├── 5-performance-metrics/
│   └── metrics-justification.md
├── 6-lifecycle-risk-management/
│   └── substantial-modification-assessment.md
├── 7-standards/
│   └── applicable-standards.md
├── 8-declaration-of-conformity/
│   └── eu-doc.pdf
└── 9-changes/
    └── lifecycle-change-log.md

Keep this documentation in a version-controlled repository, not a shared drive. You need to be able to demonstrate which version of the documentation corresponded to which version of the system at any given point in time.

Timeline for SaaS Providers

If you are starting from scratch, a realistic timeline for complete Annex IV documentation:

This assumes an AI system already in production with existing internal technical documentation. If the system is newly developed, technical documentation should be produced in parallel with development rather than compiled afterward.

Next in This Series

In the next post, we cover Article 17 Quality Management System requirements — what QMS documentation high-risk AI system providers must maintain, how it relates to the Annex IV technical documentation, and the controls that auditors look for during conformity assessment review.

Previously in this series:

• Post #1/5: Which High-Risk AI Systems Need Conformity Assessment Before August 2026

EU AI Act Conformity Assessment Sprint 2026 series: helping SaaS developers complete high-risk AI compliance before the August 2, 2026 deadline.