EU AI Act Art.17 QMS Documentation Requirements: Building the Annex IV Technical File (2026)

Post #2 in the sota.io EU AI Act Art.17 Quality Management System Series

Article 17 of the EU AI Act mandates a documented Quality Management System for every provider of high-risk AI systems. But "documented" is not the same as "filed in a folder." Art.17(1) specifies 13 distinct elements that the QMS must address in writing, and those written outputs feed directly into the Annex IV Technical Documentation that notified bodies and market surveillance authorities review. Understanding the link between Art.17 QMS procedures and the Annex IV Technical File is the fastest way to avoid duplicate work and audit gaps.

This post maps each of the 13 mandatory QMS elements to the corresponding Annex IV section, explains what evidence notified bodies look for, and gives software teams a practical template for structuring both the QMS manual and the technical file in a Git-native workflow.

Why Art.17 and Annex IV Are Inseparable

Art.17 governs how you work — the processes, reviews, and records that ensure your AI system stays compliant through its lifecycle. Annex IV governs what you document — the static snapshot of your system's design, capabilities, risks, and conformity status that accompanies a placing-on-the-market or putting-into-service decision.

The key insight: the Annex IV Technical File is the output of a functioning QMS. A QMS without a complete Technical File has no evidence of compliance. A Technical File without the underlying QMS procedures has no credibility — an auditor will ask "how was this produced?" and "who reviewed it?" For high-risk AI systems, the answer to both questions must trace back to Art.17 QMS procedures.

Providers who treat these as two separate documents to be assembled independently before audit day will find themselves doing the work twice. Providers who build Art.17 procedures as the engine that continuously produces Annex IV artifacts will have a living Technical File at every point in the development lifecycle.

The 13 Mandatory QMS Elements Under Art.17(1)

Art.17(1)(a) through (m) defines what the QMS documentation "shall comprise at least." Each element maps to one or more sections of Annex IV.

Element (a): Regulatory Compliance Strategy

What Art.17 requires: A written strategy for achieving and maintaining regulatory compliance, including how you manage conformity assessment procedures and handle modifications to the system.

Annex IV mapping: Section 1 (General description), specifically the description of the system's intended purpose and the applicable conformity assessment route (Art.43 self-assessment vs. notified body involvement).

What auditors look for:

• A documented decision on which conformity assessment procedure applies (Annex VI or Annex VII)
• A change management policy that defines what constitutes a "substantial modification" under Art.3(23) — triggering a fresh conformity assessment
• Version control policy showing how the strategy is maintained as regulations evolve

Git-native implementation: A compliance/strategy.md in your repository, reviewed via PR, with version tags corresponding to each conformity assessment checkpoint.

Element (b): Design, Design Control, and Design Verification

What Art.17 requires: Documented techniques and procedures for the design phase, including design controls (sign-off gates) and design verification (evidence that design outputs meet design inputs).

Annex IV mapping: Section 2 (Detailed description of design and development), which must include the design choices made, the rationale for those choices, and the verification activities performed.

What auditors look for:

• Architecture decision records (ADRs) for consequential design choices
• A design review checklist applied at specification sign-off
• Evidence that high-risk classifications, intended purpose, and reasonably foreseeable misuse were considered during design (Art.9 RMS connection)
• Traceability from requirements to design outputs

Git-native implementation: ADR templates in docs/decisions/, design review sign-off captured as PR approvals with mandatory reviewer roles, linked to issue trackers for requirements.

Element (c): Development, Quality Control, and Quality Assurance

What Art.17 requires: Procedures for development activities, ongoing quality control (in-process checks), and quality assurance (process-level verification that procedures are being followed).

Annex IV mapping: Section 2 again, specifically the description of development methods and the quality assurance processes applied.

What auditors look for:

• Definition of development stages (sprints, releases, milestone gates)
• Quality control activities at each stage (code review standards, automated lint/test gates)
• Quality assurance audits — evidence that the QC procedures themselves are periodically verified (not just trusted to happen)
• Role definitions for QA vs. QC responsibilities

Git-native implementation: Branch protection rules enforcing code review, CI/CD gates as QC checkpoints, quarterly internal audits documented in compliance/qa-audits/.

Element (d): Examination, Test, and Validation Procedures

What Art.17 requires: Documented procedures for examining, testing, and validating the AI system before, during, and after development — including the frequency of these activities.

Annex IV mapping: Section 3 (Information about the monitoring, functioning, and control of the AI system) and implicitly Section 4 (Risk management), since test scope must address identified risks.

What auditors look for:

• A test plan defining coverage for each high-risk classification criterion
• Pre-deployment validation checklist (accuracy, robustness, cybersecurity — Art.15)
• Statistical performance metrics with minimum thresholds
• Human oversight validation (Art.14) — evidence that override and intervention capabilities were tested
• Post-deployment monitoring triggers (connection to Art.72)

Git-native implementation: Test plans in compliance/test-plans/, automated test reports archived per release, performance dashboards with threshold alerts, test coverage for human-in-the-loop scenarios.

Element (e): Technical Specifications and Standards

What Art.17 requires: A documented list of technical specifications — especially harmonised standards — applied to the system. Where harmonised standards are not fully applied, a documented justification and alternative compliance means.

Annex IV mapping: Section 6 (List of harmonised standards applied in full or in part) and Section 7 (EU declaration of conformity), which references the standards basis.

What auditors look for:

• An explicit standards mapping: which harmonised standards are applied, which are partially applied, which are not applied and why
• For deviations from standards: a documented alternative approach showing equivalence
• Currency — standards evolve; the QMS must track whether applied standards remain current

Git-native implementation: A compliance/standards-matrix.md maintained alongside the Technical File, with dates of last review and responsible owner.

Element (f): Data Management

What Art.17 requires: Systems and procedures for every stage of data handling — collection, analysis, labelling, storage, filtration, mining, aggregation, retention — for data used before and for placing the AI system on the market.

Annex IV mapping: Section 2 (development description) including the description of training, validation, and testing datasets under Art.10 requirements.

What auditors look for:

• A Data Management Plan covering all dataset lifecycle stages
• Evidence of data quality controls (labelling standards, inter-rater reliability for annotation)
• Data provenance records — where did training data come from, who collected it, under what consent basis?
• Retention schedules: how long is training data retained, and how does deletion work? (GDPR Art.17 intersection)
• CLOUD Act analysis: if training data or model artefacts are stored on US-owned infrastructure, what is the jurisdictional exposure?

Git-native implementation: Dataset cards in data/ alongside training scripts, labelling guidelines versioned in the repository, data retention policy in compliance/data-management-plan.md. EU-hosted object storage (Hetzner Object Storage, Scaleway, or similar) for training artefacts prevents jurisdictional exposure.

Element (g): Risk Management System

What Art.17 requires: A cross-reference to and integration with the Art.9 Risk Management System. The QMS must incorporate the RMS — they are not separate documents.

Annex IV mapping: Section 4 (Description of the risk management system) — one of the most scrutinised sections in any Technical File.

What auditors look for:

• The RMS documentation itself (risk register, residual risk decisions, risk control measures)
• Evidence that QMS procedures (design review, test plans, data management) are informed by RMS outputs
• Traceability: how does a risk identified in the RMS translate into a test requirement in element (d)?

Git-native implementation: The RMS lives in compliance/risk-management/. Each risk control measure links back to a design control in element (b) or a test procedure in element (d). PRs that modify model behaviour require risk re-evaluation as a merge condition.

Element (h): Post-Market Monitoring System

What Art.17 requires: Procedures for setting up, implementing, and maintaining the post-market monitoring system under Art.72.

Annex IV mapping: Section 3 (monitoring, functioning, and control information) — specifically the description of monitoring tools, thresholds, and escalation paths.

What auditors look for:

• A PMS Plan specifying what metrics are monitored, at what frequency, against what thresholds
• Alert configurations for performance degradation, unexpected output distributions, or accuracy drift
• An escalation path from monitoring alert to incident review to potential safety action
• Evidence that PMS outputs feed back into the QMS (closed loop: monitoring → review → update)

Git-native implementation: PMS plan in compliance/pms-plan.md, monitoring dashboards (Grafana, Datadog EU region, or similar) with threshold alert documentation, incident log in compliance/incident-log/.

Element (i): Serious Incident Reporting

What Art.17 requires: Documented procedures for Art.73 reporting of serious incidents to national competent authorities.

Annex IV mapping: Not a direct Annex IV section, but the Technical File must reference the reporting procedures to demonstrate operational compliance readiness.

What auditors look for:

• A written incident classification guide: what constitutes a "serious incident" under Art.3(49)?
• A reporting timeline procedure: Art.73 requires reporting "without undue delay" — your procedure must define internal escalation within how many hours before NCA notification?
• Named contacts for NCA communication (element (j) intersection)
• A post-incident review procedure feeding back into the QMS

Git-native implementation: compliance/incident-response-plan.md with decision trees for classification, a communication template for NCA notification, and a post-incident ADR template.

Element (j): Communication with Authorities and Stakeholders

What Art.17 requires: Procedures for handling communication with NCAs, fundamental rights authorities, notified bodies, operators, customers, and other stakeholders.

Annex IV mapping: Referenced implicitly through the EU declaration of conformity (Section 7), which commits you to making the Technical Documentation available to authorities on request.

What auditors look for:

• A defined communication point-of-contact for regulatory authorities
• A procedure for responding to NCA information requests under Art.74 (market surveillance)
• Policies for communicating system limitations and incidents to downstream operators and users (Art.12/13 transparency requirements)

Git-native implementation: compliance/regulatory-contacts.md (non-public, kept in secure secrets manager), communication policy for user-facing incident notices.

Element (k): Record Keeping

What Art.17 requires: Systems and procedures for keeping all relevant documentation and information, covering both QMS records and the technical file itself.

Annex IV mapping: The entirety of Annex IV — the Technical File is the primary record. But Art.17(k) adds the requirement for QMS records: meeting minutes, audit reports, test results, non-conformance reports, and corrective action records.

What auditors look for:

• Retention periods defined for each document category (minimum: 10 years after placing on market under Art.18)
• Access controls — who can modify records? Is there an audit trail?
• Archiving procedure for superseded versions

Git-native implementation: Git history provides immutable record of changes to compliance documents. Tagging releases creates snapshot Technical Files. Archive policy in compliance/record-retention.md.

Element (l): Resource Management

What Art.17 requires: Procedures covering resource management, including security of supply — ensuring the people, tools, and infrastructure needed to maintain compliance remain available.

Annex IV mapping: Implicitly required in Annex IV Section 2 (development methods) when describing the team and infrastructure.

What auditors look for:

• Competency requirements for key QMS roles (who is qualified to review risk assessments? who can sign off on design?)
• Supplier/vendor dependency management — if a critical third-party library or cloud service fails, what is the impact on compliance?
• Infrastructure continuity — if the team loses access to training infrastructure, can compliance records still be accessed?

Git-native implementation: compliance/resource-management.md with competency matrix, vendor dependency register, and infrastructure continuity checklist.

Element (m): Accountability Framework

What Art.17 requires: An accountability framework defining the responsibilities of management and other staff for all aspects of the QMS.

Annex IV mapping: Section 2 (development methods) and implicitly Section 1 (general description of the provider).

What auditors look for:

• Named responsible persons (not just job titles) for each QMS element
• A documented escalation chain: who can make the decision to halt deployment if a critical risk is found?
• Management sign-off on the QMS manual itself — evidence that leadership has reviewed and approved the system

Git-native implementation: CODEOWNERS file for compliance documents (enforces that management reviews certain files). compliance/accountability-matrix.md with named owners per Art.17 element, updated at each conformity assessment.

Mapping Art.17 Elements to Annex IV Sections

The Annex IV Technical File Structure

Under Annex IV, the Technical Documentation for a high-risk AI system must contain:

Section 1 — General description: System name, version, intended purpose, categories of persons it may affect, deployment contexts, hardware requirements, and provider identification.

Section 2 — Detailed description of elements and development: Architecture, training methodology, datasets used (including provenance and quality controls), design decisions, development environment, and team competencies. This is the section most directly produced by Art.17 elements (b), (c), (f), (l), and (m).

Section 3 — Monitoring, functioning, and control: How the system operates post-deployment, human oversight mechanisms (Art.14), explainability capabilities (Art.13), and the post-market monitoring setup (Art.72).

Section 4 — Risk management system: The complete RMS output from Art.9 — identified risks, residual risks, risk control measures, and the relationship between risks and testing requirements.

Section 5 — Changes made through the lifetime: Log of modifications, including whether each modification constituted a "substantial modification" requiring fresh conformity assessment.

Section 6 — List of harmonised standards applied: Explicit list with standard numbers and application scope. Where not fully applied, documented justification and alternative compliance means.

Section 7 — EU declaration of conformity: The formal declaration committing the provider to the requirements of Chapter III, Section 2 of the EU AI Act.

What Notified Bodies Flag Most Often

Based on the structure of Art.17 and Annex IV, audit experience across comparable technical documentation frameworks (ISO 13485 for medical devices, ISO/IEC 27001 for information security) shows recurring gaps:

Gap 1 — Circular traceability. Risk controls in element (g) are listed, but element (d) test procedures do not explicitly verify those controls. The QMS says "risk mitigated by X" but the test plan doesn't test X.

Gap 2 — Modification records missing. Element (a) requires a change management procedure, but Annex IV Section 5 is empty or lists only version numbers without substantive change descriptions. Notified bodies will ask: was this change reviewed for substantial modification?

Gap 3 — Data provenance gaps. Element (f) data management procedures exist, but Annex IV Section 2 dataset description doesn't trace back to those procedures. The Technical File says "high-quality labelled dataset" with no evidence of the labelling quality controls.

Gap 4 — Management sign-off absent. Element (m) accountability framework names a QMS owner, but there's no evidence of management review (meeting minutes, approval signatures). The Annex IV Section 1 lists the provider but no internal approval chain.

Gap 5 — Post-market monitoring disconnected. Element (h) PMS plan exists in the QMS, but Annex IV Section 3 describes the monitoring system in isolation without referencing the PMS plan. Two documents that should be one.

Practical Implementation Path for Software Teams

Week 1: Audit your current state. Map each Art.17(1)(a)-(m) element against what documentation you have today. Use the mapping table above. Flag missing elements as gaps.

Week 2: Close documentation gaps. For each missing element, create the minimum viable artifact. Procedures first — they can be brief. A two-page data-management-plan.md is compliant. A 50-page document filed in a folder no one reads is not.

Week 3: Build the Annex IV shell. Create a Technical File template with all seven sections. Populate each section by pulling from your Art.17 procedures. Where a section is empty, trace back to which Art.17 element should produce its content.

Week 4: Establish the maintenance rhythm. Set calendar reminders for: quarterly QMS internal audit (element (c) quality assurance), annual standards review (element (e)), post-incident QMS review (element (i)), and pre-release Technical File update (element (k)).

CLOUD Act note for infrastructure: If your training data, model weights, or compliance records are stored on infrastructure operated by US-headquartered companies (AWS, Azure, GCP, Snowflake, Databricks), those records are reachable under the US CLOUD Act regardless of where the servers sit. For Annex IV record retention under Art.18 (10 years), jurisdiction matters. EU-native object storage (Hetzner, Scaleway, OVHcloud) eliminates this exposure.

The August 2, 2026 Deadline

The EU AI Act August 2026 obligation deadline applies to:

• Providers of high-risk AI systems listed in Annex III
• The obligation to have a QMS in place under Art.17
• The obligation to maintain technical documentation under Art.11 and Annex IV

53 days remain as of June 10, 2026. That is enough time to build a compliant QMS and Technical File from scratch if you start this week — but not if you wait for the August deadline to approach.

A QMS that exists on paper but has no record of having been followed will not survive audit. Notified bodies and NCAs will look for evidence of the QMS operating: design review records, test report archives, risk management outputs, PMS data. Building those records takes time — and the only way to have them by August is to start generating them now.

Up Next in This Series

Post #3 (Continuous Improvement): How Art.17 requires the QMS to improve over time — CAPA (corrective and preventive actions), internal audit cycles, management review, and how to run a QMS improvement sprint in a software team.

Post #4 (Supplier and Third-Party Oversight): How Art.17 applies to AI components, datasets, and services you source from third parties — supplier qualification, contractual QMS requirements, and audit rights.

Post #5 (Checklist Finale): A complete Art.17 QMS conformity assessment checklist for the August 2026 deadline — 78 items mapped to Art.17 elements, Annex IV sections, and NB audit criteria.

sota.io is an EU-native managed PaaS (Hetzner Germany). Deploy your high-risk AI system and its compliance infrastructure without CLOUD Act exposure. Get started.