EU AI Act Art.11 & Art.18: Building Your QMS Documentation Infrastructure

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

Your Art.17 Quality Management System is only as strong as the documentation that underpins it. Two articles define the documentation obligations every high-risk AI provider must meet before August 2, 2026: Art.11 (technical documentation) and Art.18 (documentation keeping). Together, they specify not just what you must document, but how long you must keep it, who must be able to access it, and what happens when a notified body comes knocking.

This post walks through both requirements, maps them to the work your engineering team is already doing, and shows you how to build a documentation infrastructure that satisfies both the letter and the spirit of the regulation.

Why Documentation Is the Foundation of Your QMS

When the EU AI Act describes a Quality Management System under Art.17, every element it lists — design controls, testing procedures, post-market monitoring, corrective actions — requires documentation as its output artifact. Without a structured, auditable documentation system, your QMS exists only in your engineers' heads. That is not compliant.

Art.11 mandates that providers draw up and maintain technical documentation before placing a high-risk AI system on the market. Art.18 mandates that this documentation is kept for at least ten years after the system is placed on the market or put into service. These are not aspirational goals. They are enforceable obligations under Art.99.

Art.11 Technical Documentation: What the Regulation Actually Requires

Art.11(1) states that providers of high-risk AI systems must draw up technical documentation in accordance with Annex IV. Annex IV specifies seven categories of content:

1. General Description of the AI System

This covers: the intended purpose, the categories of persons affected, the hardware requirements, the forms in which the AI system is placed on the market (standalone software, API, embedded in hardware), and the AI system's version number. If you have a product brief and a README.md, most of this already exists — it just needs to be formalised into a maintained document.

Practical implementation: Create a docs/ai-system-description.md in your repository. Define a review cadence (before each major release). Assign ownership to a named product or compliance engineer.

2. A Detailed Description of the Elements and Development Process

This includes: the AI method used (supervised learning, reinforcement learning, etc.), the training methodology, the datasets used (with data governance documentation per Art.10), the labelling criteria, the feature engineering choices, and the architecture of the model. This is your technical design document, elevated to regulatory significance.

Practical implementation: Your model card (or its predecessor in your repository) is the natural home for this. Ensure it covers training data provenance, dataset composition statistics, and the labelling process. Link to your Art.10 data governance records here.

3. Monitoring, Functioning, and Control

This section documents how the AI system behaves in production: its performance metrics, the monitoring system connected to it under Art.72, the error-handling logic, and the human oversight measures required by Art.14. Operational runbooks and SLO dashboards are the starting material here.

Practical implementation: A docs/operations.md document that links to your monitoring dashboards, describes the alerting thresholds, and explains the incident escalation path. The key is that this document must be current — a stale runbook from 2024 is not a compliant operations document.

4. Risk Management System Documentation

The risk management system under Art.9 must be integrated with your technical documentation. This means your risk register, the residual risk assessments, and the risk management review cadence must be referenced from — or embedded in — your technical documentation package.

Practical implementation: Store risk management outputs in a docs/risk-management/ directory. Include a risk-register.md with assessed risks, mitigation measures, and residual risk ratings. Link the Art.9 risk management plan from the main technical documentation index.

5. Changes Made to the System Through Its Lifecycle

Art.11 requires documentation of every substantial modification to the AI system. What counts as substantial is defined in relation to Art.43 — if the change requires re-assessment, it is substantial. Your existing change management processes (pull requests, release notes, architecture decision records) provide the raw material. The gap is typically in completeness and retention.

Practical implementation: Tag pull requests with a label regulatory-significant for changes that affect model behaviour, training data, or system scope. Generate a quarterly changelog from these tagged PRs. Store in docs/changelog-regulatory.md.

6. Standards and Technical Specifications

List the harmonised standards, common specifications, or alternative technical solutions applied to demonstrate compliance. As of mid-2026, harmonised standards under the AI Act are still being finalised by CEN/CENELEC, but ISO/IEC 42001:2023 (AI management system) and ISO/IEC 23894:2023 (AI risk management) are widely used as reference frameworks.

Practical implementation: A docs/standards-register.md listing each standard, your compliance level (fully applied / partially applied / under review), and the evidence location.

7. Declaration of Conformity and CE Marking

Once conformity has been assessed under Art.43, the technical documentation must include the EU declaration of conformity under Art.47 and the registration confirmation from the EU database under Art.49.

Practical implementation: Store these as signed PDFs in docs/conformity/. These are legal documents — they require version control but also tamper-evident storage.

Art.18 Documentation Keeping: The Retention Obligation

Art.18(1) requires that technical documentation under Art.11 is kept by the provider for at least ten years after the high-risk AI system is placed on the market or put into service. For AI systems that are updated continuously (as most SaaS AI systems are), this means every documented version must be retained for ten years from when it was in production.

Three practical implications follow:

Implication 1: Git history alone is not enough. Git repositories are mutable — history can be rewritten, repositories can be deleted, and access permissions change over time. For regulatory retention purposes, you need an immutable archive. This could be a write-once object storage bucket (AWS S3 Object Lock, Azure Immutable Blob Storage, or a sovereign EU equivalent like Hetzner Object Storage), or a signed artifact store.

Implication 2: The retention period outlives your current tooling. Ten years is a long time. Infrastructure migrations, team changes, and tool deprecations will happen. Documentation must be in formats that remain readable over this timescale: plain text, Markdown, PDF. Vendor-specific formats (Notion exports, Confluence spaces) are not reliable ten-year archives.

Implication 3: Deletion policies must be explicitly disabled for regulatory records. If you apply automated retention policies (delete objects older than X days) to your storage, you need to exclude regulatory documentation. This is an infrastructure configuration change, not just a process change.

Building a Compliant Documentation Infrastructure

The following architecture satisfies both Art.11 and Art.18 without introducing significant operational overhead:

Layer 1: Living Documentation in Git

Store all mutable, evolving documentation in your primary repository under a docs/ai-compliance/ directory:

docs/ai-compliance/
  ai-system-description.md
  data-governance.md          # Art.10 records
  risk-management/
    risk-register.md
    risk-reviews/             # Dated review outputs
  operations.md               # Art.14 / Art.72
  standards-register.md
  changelog-regulatory.md

Review cadence: monthly for risk register, before each major release for system description and operations documents.

Layer 2: Immutable Snapshots for Release Events

At each significant release event — initial market placement, substantial modification, conformity re-assessment — generate a documentation snapshot. This is a PDF export or a signed archive of the entire docs/ai-compliance/ directory tree, plus the declaration of conformity.

Store these snapshots in an immutable object storage bucket with explicit retention lock. Tag each snapshot with: release version, date, and the SHA of the commit in Git.

Why this matters: If your systems are audited in 2033, you need to produce documentation showing what the system looked like in 2026. A Git SHA plus an immutable archive gives you that.

Layer 3: Audit Access

Art.21 requires providers to cooperate with competent authorities. This means documentation must be producible on request — ideally within days, not weeks. Structure your documentation index so that a single URL or file path leads to all required documents for a given system version.

A docs/ai-compliance/README.md that serves as the index, with a table of contents linking each Annex IV section to its document, is the minimum viable audit package.

The Connection to Art.19: Automatically Generated Logs

Art.19 requires that high-risk AI systems automatically log events relevant to their operation. These logs are part of your technical documentation package. In a SaaS AI system, this means your inference logs, human oversight intervention records, and anomaly alerts must be:

• Retained for the period specified in Art.72 post-market monitoring obligations (at minimum, for the duration of market presence)
• Structured so they can be exported and reviewed by competent authorities
• Attributable to specific system versions (so changes in behaviour over time can be traced)

Your existing logging infrastructure (structured JSON logs, retention in Elasticsearch or a managed cloud log service) can satisfy this if you apply appropriate retention policies and export capabilities.

Record-Keeping for Deployers

Art.26 imposes record-keeping obligations on deployers of high-risk AI systems, not just providers. If you provide a high-risk AI system as a service (SaaS), your deployers have their own documentation obligations. Your technical documentation must include enough information to enable deployers to meet their Art.26 obligations — this is part of the Art.13 transparency requirements.

Practical implementation: Include a "Deployer Documentation Checklist" appendix in your technical documentation that explains what records deployers must keep and what information your system provides to support that.

Common Documentation Failures to Avoid

Failure 1: Documenting the system you planned to build, not the system you built. Technical documentation must reflect the actual system in production. If a major training data change occurred in Q4 2025, it must be reflected in the documentation.

Failure 2: Treating documentation as a one-time activity. Art.18 requires documentation to be kept — not created once and filed. This implies a maintenance process, not just an initial creation event.

Failure 3: No clear ownership. Regulatory documentation must have a named owner who is responsible for keeping it current. In most engineering teams, this ownership is ambiguous. Assign it explicitly.

Failure 4: Conflating ISO 42001 documentation with AI Act documentation. ISO/IEC 42001:2023 specifies a management system for AI — its documentation requirements are similar to but not identical to Annex IV of the EU AI Act. ISO 42001 certification does not automatically satisfy Art.11. Map the gaps explicitly.

Connecting to the Full QMS

Technical documentation under Art.11 and record-keeping under Art.18 are inputs to, and outputs of, the Art.17 QMS. The QMS defines the processes that produce documentation. The documentation provides the evidence that the processes are operating. This circular relationship is intentional: it creates a continuous improvement loop where the quality of your documentation reflects the maturity of your quality management system.

The remaining posts in this series will cover: integrating QMS documentation into your CI/CD pipeline (Post #3/5), connecting Art.9 risk management records to your QMS (Post #4/5), and preparing a documentation package for a notified body audit (Post #5/5).

The August 2, 2026 deadline for high-risk AI system compliance under the EU AI Act is 58 days away. If your technical documentation infrastructure does not yet exist, building it now is the highest-leverage action your compliance and engineering teams can take this month.

sota.io is a European cloud platform built for EU-compliant deployments. If you are building a QMS documentation infrastructure on EU-sovereign infrastructure, try sota.io — your data stays in the EU.