L8.2.2 — Article 11: the technical documentation package

Type: Theory · Duration: ~5 min · Status: Mandatory Module: Module 8 — AI Governance, Risk & Compliance Framework tags: EU AI Act Article 11 + Annex IV

Learning objectives

1. List the eight sections of the EU AI Act Article 11 / Annex IV technical documentation.
2. Identify which artifacts from earlier modules feed each section.

Core content

What Article 11 requires

For high-risk AI systems, Article 11 requires that technical documentation be drawn up before the system is placed on the market or put into service, and kept up-to-date throughout the system's lifecycle.

The documentation must contain, at minimum, the elements specified in Annex IV. Eight sections.

The eight Annex IV sections

Section 1: General description of the AI system. - Intended purpose - Provider name + version - How the system interacts with hardware or other software - Versions of relevant software / firmware - All forms the system is placed on market - Hardware on which it's intended to run - Photographs / illustrations showing external features - Description of the user interface - Instructions for use for the deployer

→ Feeds from: product spec; model card (L8.5.1).

Section 2: Detailed description of system elements. - Methods + steps for development, including pre-trained systems used and how they were modified - Design specifications including general logic, key design choices, classification choices, optimization - Architecture: software components, what they do, how they interact - Data requirements (re Article 10) - Human oversight measures (re Article 14) - Pre-determined changes and continuous learning

→ Feeds from: threat model (L2.6); model card; AI-BOM (L4.9).

Section 3: Monitoring, functioning, control. - Capabilities and limitations - Foreseeable unintended outcomes + risk sources - Specifications of input data - Pre-determined output thresholds - Metrics used to measure accuracy, robustness, cybersecurity (re Article 15)

→ Feeds from: eval reports; observability stack (L7.4.*); robustness measurements (L6.5.1, L7.7).

Section 4: Risk management system per Article 9. - Risk register (L8.1.1) - Risk mitigation measures - Residual risk acceptance

→ Feeds from: NIST RMF program (L8.1.1).

Section 5: Changes through lifecycle. - Description of changes; revised versions

→ Feeds from: change-log; AI-BOM update history.

Section 6: Standards and specifications applied. - Harmonized standards (if used) - Other standards used - Justification where alternative methods used

→ Feeds from: NIST AI RMF mapping (L8.1.2); industry standards adopted.

Section 7: EU declaration of conformity. - Copy of the declaration (after conformity assessment).

→ Feeds from: conformity assessment process; legal/compliance team output.

Section 8: Post-market monitoring plan. - How the system will be monitored after deployment - Data collection on incidents, malfunctioning - Corrective actions trigger criteria

→ Feeds from: IR playbook (L7.6.1); observability stack (L7.9).

What this package looks like in practice

A single PDF (or set of linked documents) typically 50-200 pages depending on system complexity. Versioned. Updated at every material change. Reviewable by EU authorities upon request.

Most providers structure as: - Cover sheet (system overview, version, dates). - Section 1-8 each as its own chapter. - Annexes: model card, AI-BOM, key technical specs, eval reports, threat model summary.

The artifact maps cleanly onto outputs the AI security engineer produces throughout the course; Article 11 is largely a consolidation exercise once those outputs exist.

Auditor / regulator perspective

When EU authorities review the documentation, they look for: - Completeness. All eight sections present. - Internal consistency. Risk register references match controls reference; model card claims match eval results. - Currency. Recent updates reflecting recent system changes. - Linkable evidence. Claims supported by underlying artifacts (eval reports, test results, incident logs).

The most common failure mode is Section 8 thin: post-market monitoring described abstractly, with no actual evidence of monitoring happening. Avoid by linking to L7.9 logging stack outputs explicitly.

When you need this done

For high-risk systems shipping in the EU, the documentation must be ready before market placement. The August 2026 EU AI Act enforcement deadline for high-risk obligations means many systems already shipping pre-2026 needed this work done.

In 2026 the work is largely catch-up for existing systems; new launches build it in from day one.

Lab L8.7 builds this for the M1 RAG

The lab walks you through assembling the eight sections — at light depth — for the Module 1 Asfela handbook RAG. End state: a real Article-11-shaped document you can use as a template.

Real-world example

Multiple EU-shipping vendors have published redacted versions of their Article 11 packages as customer-facing reference documents. The shape is consistent; the depth varies. Reading two or three publicly-available examples is the fastest way to internalize what "good" looks like.

Key terms

• Article 11 — EU AI Act provision requiring technical documentation for high-risk systems.
• Annex IV — specifies the eight required documentation sections.
• Conformity assessment — process producing the EU declaration of conformity (Section 7).
• Post-market monitoring — Section 8 obligation that often gets thin in practice.

References

• EU AI Act Annex IV (full text via EUR-Lex).
• European Commission AI Act technical-documentation guidance.

Quiz items

1. Q: Name the eight Annex IV documentation sections. A: (1) General description of the AI system; (2) Detailed description of system elements; (3) Monitoring, functioning, control; (4) Risk management system per Article 9; (5) Changes through lifecycle; (6) Standards and specifications applied; (7) EU declaration of conformity; (8) Post-market monitoring plan.
2. Q: Which Module 7 lab outputs feed Section 8 (Post-market monitoring plan)? A: L7.9 (prompt/response logging with PII redaction) and the abuse-detection queries built against the logs.
3. Q: What's the most common failure mode in Article 11 packages? A: Section 8 (post-market monitoring) described abstractly with no actual evidence of monitoring happening. Fix: link to logging-stack outputs explicitly.

Video script (~600 words, ~4.5 min)

[SLIDE 1 — Title]

Article 11: the technical documentation package. Five minutes.

[SLIDE 2 — What Article 11 requires]

For high-risk AI systems, Article 11 requires technical documentation be drawn up before the system is placed on the market or put into service, and kept up-to-date throughout lifecycle.

Documentation must contain at minimum the elements specified in Annex IV. Eight sections.

[SLIDE 3 — Section 1 + 2]

Section 1: general description. Intended purpose, provider name and version, how the system interacts with hardware or other software, versions of software and firmware, all forms placed on market, hardware on which it runs, photographs, user interface description, instructions for use for the deployer. Feeds from product spec and model card.

Section 2: detailed description of system elements. Methods and steps for development including pre-trained systems used and how they were modified. Design specifications including general logic, key design choices, classification choices, optimization. Architecture: software components, what they do, how they interact. Data requirements re Article 10. Human oversight measures re Article 14. Pre-determined changes and continuous learning. Feeds from threat model, model card, AI-BOM.

[SLIDE 4 — Sections 3 + 4]

Section 3: monitoring, functioning, control. Capabilities and limitations. Foreseeable unintended outcomes and risk sources. Specifications of input data. Pre-determined output thresholds. Metrics used to measure accuracy, robustness, cybersecurity re Article 15. Feeds from eval reports, observability stack, robustness measurements.

Section 4: risk management system per Article 9. Risk register, risk mitigation measures, residual risk acceptance. Feeds from NIST RMF program.

[SLIDE 5 — Sections 5 + 6]

Section 5: changes through lifecycle. Description of changes, revised versions. Feeds from change-log and AI-BOM update history.

Section 6: standards and specifications applied. Harmonized standards if used, other standards used, justification where alternative methods used. Feeds from NIST AI RMF mapping and industry standards adopted.

[SLIDE 6 — Sections 7 + 8]

Section 7: EU declaration of conformity. Copy of the declaration after conformity assessment. Feeds from legal and compliance team output.

Section 8: post-market monitoring plan. How the system will be monitored after deployment. Data collection on incidents and malfunctioning. Corrective actions trigger criteria. Feeds from IR playbook and observability stack.

[SLIDE 7 — In practice + auditor view]

In practice: single PDF or set of linked documents, typically 50 to 200 pages depending on complexity. Versioned. Updated at every material change. Reviewable by EU authorities upon request.

Auditor perspective. They look for: completeness — all eight sections present. Internal consistency — risk register references match controls; model card claims match eval results. Currency — recent updates. Linkable evidence — claims supported by underlying artifacts. Most common failure mode: Section 8 thin — post-market monitoring described abstractly with no actual evidence. Avoid by linking to L7.9 logging outputs explicitly.

[SLIDE 8 — L8.7 + up next]

Lab L8.7 walks you through assembling the eight sections at light depth for the Module 1 Asfela handbook RAG. End state: a real Article-11-shaped document you can use as a template.

Next: building an AI security program — org design, hiring, scope. Five minutes.

Slide outline

1. Title — "Article 11: the technical documentation package".
2. What it requires — large quote of the Article 11 obligation.
3. Sections 1 + 2 — two-card layout with content summary + "feeds from" line.
4. Sections 3 + 4 — same shape.
5. Sections 5 + 6 — same shape.
6. Sections 7 + 8 — same shape; highlight Section 8 as the common-failure section.
7. In practice + auditor view — sample PDF cover + auditor's-eye checklist.
8. L8.7 + up next — lab callout + next pointer.

Production notes

• Recording: ~4.5 min. Cap 5.
• Slides 3-6 follow same visual template; design once, reuse.