A Thursday in October 2027. The Stage 1 notified-body auditor at TÜV SÜD opens the Annex IV technical binder for Acme.HireRank v2.1, Acme Corp's Annex III §4 resume-ranking system, and starts at the front. Section 1: general description and intended purpose. Section 2: elements of the AI system and development process. Section 3: monitoring, functioning, and control. Section 4: appropriateness of performance metrics. Section 5: risk management system. Section 6: changes through the lifecycle. Section 7: harmonized standards applied. Section 8: EU declaration of conformity. Section 9: post-market monitoring plan. Nine sections. The auditor reads each one in order. The Annex IV file is the load-bearing artifact of the entire EU AI Act conformity-assessment regime, every high-risk system needs one before being placed on the market or put into service; the notified body reads it Stage 1; the competent authority reads it on inquiry. This lesson walks all nine Annex IV sections with what each must contain, ships the worked example for Acme.HireRank, and is the L3 capstone reference every conformity-assessment lead keeps open on the desk.

Why Annex IV Is the Load-Bearing Artifact of the Entire High-Risk Regime

EU AI Act Article 11 makes the connection explicit: "The technical documentation of a high-risk AI system shall be drawn up before that system is placed on the market or put into service and shall be kept up-to-date." Article 11(1) refers to Annex IV for the minimum content; Article 11(3) authorises the Commission to amend Annex IV by delegated act to reflect technical progress. The technical documentation must demonstrate that the high-risk system complies with the requirements of Chapter III Section 2 (Articles 8-15) and must provide the competent authority and notified body the information needed to assess conformity.

The Annex IV technical file is the single artifact that ties every other conformity element together. The Article 9 risk management system flows into Annex IV §5. The Article 10 data governance flows into Annex IV §2(d). The Article 11 + Annex IV obligation flows into all nine Annex IV sections. The Article 12 logging architecture flows into Annex IV §3. The Article 13 transparency-to-deployers flows into Annex IV §2(e) and §3. The Article 14 human-oversight design flows into Annex IV §2(e). The Article 15 accuracy / robustness / cybersecurity flows into Annex IV §2(g), §2(h), and §4. The Article 17 quality management system references the technical documentation. The Article 27 fundamental-rights impact assessment for Annex III §4-§8 systems is the substantive risk source for Annex IV §5. The Article 43 conformity-assessment route selection (internal control vs. notified body) determines who reads the file but does not change what must be in it. The Article 47 EU declaration of conformity is Annex IV §8. The Article 72 post-market monitoring plan is Annex IV §9.

The retention obligation under Article 18 is ten years from when the high-risk AI system is placed on the market or put into service, and the file must be kept up-to-date through that period, which means substantial modification events trigger Annex IV refresh and the change log under Annex IV §6 documents the refresh. The Annex IV file is therefore not a one-time document drafted before market entry and shelved; it is a living regulator-facing artifact maintained across the system's deployment lifecycle. The deployer who treats Annex IV as a launch deliverable rather than an operating artifact will fail the Stage 1 notified-body audit two years after market entry when the file is no longer current.

Annex IV §1 - General Description and Intended Purpose

Annex IV §1 opens the file. It must contain: the intended purpose of the AI system; the name and contact details of the provider and, where applicable, the authorised representative; the version of the AI system; how the system interacts with hardware or software that is not part of the system itself; the relevant versions of software or firmware and any requirements related to version updates; a description of all forms in which the AI system is placed on the market or put into service; the description of hardware on which the system is intended to run; photographs or illustrations showing external features, marking and internal layout; basic description of the user-interface; and instructions for the use of the AI system and, where applicable, the installation instructions.

For Acme.HireRank v2.1, the §1 entries:

• System name and version: Acme.HireRank v2.1; built on Anthropic Claude 4 Opus with proprietary candidate-ranking head fine-tuned April 2027; deployed June 2027; v2.1 release notes August 2027.
• Intended purpose: Rank candidates against a posted job specification for human-recruiter review. The system surfaces top-N candidate matches with rationale citations to the resume text and job specification; the recruiter reads the ranked list and decides which candidates to advance.
• Provider identity: Acme Corp, Brussels, Belgium; AI Officer contact [email protected]; authorised representative N/A (provider is EU-established).
• Intended users: Acme Corp internal HR-recruiter staff trained on the Article 26(2) deployer-side user instructions; not customer-facing.
• Intended use cases: Initial candidate-shortlist generation from inbound applications to posted job specifications. The ranking output is one input to recruiter review; recruiters retain decision authority.
• Out-of-scope use: Final hiring decisions (recruiter and hiring-manager authority); compensation decisions; performance evaluation; promotion decisions; termination decisions; demographic-based screening; passive-candidate sourcing without applicant consent. Out-of-scope uses are prohibited by Acme's Acceptable Use Policy and are technically prevented by API access controls.
• System interactions: Resume intake from the Workday ATS via integration; job-specification intake from the Workday requisition module; ranked-list output presented in the Workday recruiter dashboard; audit logs to the Acme SIEM.
• Hardware and deployment: Anthropic API (managed inference); Acme middleware on AWS eu-west-1 (Frankfurt); no on-premise deployment.
• Prior versions / changelog summary: v1.0 deployed June 2026; v2.0 substantial-modification February 2027 (new model base, new ranking head); v2.1 minor release August 2027 (UI clarification, no model change). Detailed change log in Annex IV §6.

Section 1 is the section the auditor reads first and the section that frames every downstream section. A weak §1, vague intended purpose, missing out-of-scope use, absent version control, signals to the auditor that the rest of the file will also be weak.

Annex IV §2 - Elements of the AI System and Development Process

Annex IV §2 is the technical heart of the file. Eight sub-paragraphs (§2(a) through §2(h)) cover methods and steps, design specifications, system architecture, data requirements, human oversight, pre-determined changes, validation and testing, and cybersecurity. Lesson 016 walked the §2(a)-(h) gap-fill analysis for vendor model cards in detail; lesson 026 wrote the model card for a fine-tuned model with §2 cross-walks. This lesson assembles the §2 entries for the Annex IV file itself.

• §2(a) Methods and steps for development: Upstream foundation model: Anthropic Claude 4 Opus, API version pinned 2027-04 at deployment, vendor model card v2027-04 attached as Appendix A. Fine-tuning method, parameter-efficient LoRA adapters on Claude 4 Opus per Anthropic enterprise fine-tuning service; fine-tune date April 14, 2027; Article 25(1)(b) substantial-modification transfer triggered; Acme is the provider of Acme.HireRank under Article 16. Article 25(2) cooperation evidence with Anthropic, inter-company memorandum dated March 30, 2027.
• §2(b) Design specifications: General logic, embedding-based candidate-job match score combined with LLM-generated rationale; rank by composite score with diversity-aware tie-breaking. Key design choices, chose LoRA fine-tune over RAG-only for ranking-quality reasons documented in design-rationale memo (Appendix B). Optimization target, recruiter-shortlist precision @ 10, with fairness-constraint floor on demographic-parity ratio across protected categories (see Annex IV §4). Trade-offs against Chapter III Section 2, accepted longer inference latency (~1.2s per resume) in favour of higher precision and traceable rationale; documented in §2(b) design-rationale memo.
• §2(c) System architecture: Block diagram Appendix C; data-flow diagram Appendix D; component manifest Appendix E (CycloneDX 1.7 ML-BoM with CDXA attestations). Components - Workday ATS connector; Acme middleware (auth, rate-limit, prompt assembly, response validation); Anthropic API; embedding service (Voyage AI v3); ranking aggregator; Workday recruiter dashboard; SIEM audit log pipeline.
• §2(d) Data requirements: Training data for the LoRA fine-tune: 80,000 historical resume-shortlist pairs from Acme's 2022-2026 recruiting data, PII-pseudonymised, demographic identifiers removed prior to fine-tune (Article 10(5) carve-out applied for bias monitoring). Validation set, 10,000 stratified pairs held out. Test set: 5,000 stratified pairs, plus 2,000 synthetic stress-test pairs for fairness probing. Provenance documented; bias examination documented; gaps identified (limited representation of certain occupations, mitigated via stratified resampling). GDPR DPIA conducted under Article 35; Article 27 FRIA conducted; outputs cross-referenced.
• §2(e) Human oversight measures (Article 14): Recruiter is the always-on reviewer; ranked output is presented with per-candidate rationale and confidence band; recruiter must explicitly advance or reject each top-10 candidate; rejected-candidate justification logged. Recruiter training: mandatory 2-hour module on system limitations, automation bias, demographic-fairness considerations; quarterly refresher. Article 26(3) competence training records retained. Article 26(4) effectiveness monitoring, monthly review of recruiter override rates by job family and demographic strata; quarterly review by AI Governance Committee.
• §2(f) Pre-determined changes: Limited pre-determined-changes carve-out under Article 43(4) for routine threshold-recalibration within ±5% of baseline values; documented in change-control SOP. Any change beyond the carve-out triggers substantial-modification analysis and Annex IV refresh per §6.
• §2(g) Validation and testing: Pre-deployment evaluation suite: precision @ 10, recall @ 50, mean reciprocal rank, demographic-parity ratio per protected category, equalised-odds ratio, rationale-citation accuracy (LLM-as-judge with human spot-check). OWASP LLM Top 10 + MITRE ATLAS coverage report Appendix F. Adversarial robustness, prompt-injection resistance, resume-format adversarial testing. Article 15 thresholds and rationale Appendix G.
• §2(h) Cybersecurity measures (Article 15): API authentication via mutual-TLS to Anthropic; Acme middleware authentication via OAuth 2.1 with PKCE; rate limiting at 100 req/min per recruiter; audit logging to SIEM with 10-year retention per Article 18; incident response per Acme SOC runbook; integration with broader Acme cybersecurity programme; ISO/IEC 27001:2022 certified; penetration-test report Q3 2027 Appendix H.

Annex IV §3: Detailed Information About Monitoring, Functioning, and Control

Annex IV §3 covers post-deployment monitoring of the system. It must describe: the system's capabilities and limitations in terms of accuracy, including its level of accuracy for the specific persons or groups of persons on which the system is intended to be used and the overall expected level of accuracy in relation to its intended purpose; the foreseeable unintended outcomes and sources of risks to health and safety, fundamental rights and discrimination in view of the intended purpose of the AI system; the human oversight measures needed in accordance with Article 14, including the technical measures put in place to facilitate the interpretation of the outputs of AI systems by the deployers; and specifications on input data, as appropriate.

For Acme.HireRank v2.1, §3 entries:

• Production monitoring metrics: Precision @ 10 monitored weekly; recall @ 50 monitored weekly; demographic-parity ratio per protected category monitored monthly; equalised-odds ratio monitored monthly; recruiter override rate monitored weekly; rationale-citation accuracy spot-checked monthly. Dashboard accessible to AI Officer team and HR-Operations leadership; quarterly read-out to AI Governance Committee.
• Logging architecture per Article 12: Every ranking request logged with timestamp; job-spec identifier; candidate identifier (pseudonymised); model version; ranking score; rationale text; recruiter action (advance / reject); recruiter identifier (pseudonymised). Logs retained 10 years per Article 18. Log integrity via append-only WORM storage and quarterly cryptographic hash verification.
• Oversight mechanisms per Article 14: Recruiter dashboard surfaces ranking with per-candidate rationale, confidence band, and "review carefully" flag for low-confidence cases (below 0.6). Recruiter must explicitly action each top-10 candidate. Bulk-advance and bulk-reject are disabled, single-candidate action required. Recruiter override of ranking is logged with optional rationale field.
• Control parameters: Recruiter can adjust the protected-category-aware diversity tie-breaker weight within a documented bounded range; default values reviewed quarterly by AI Governance Committee; deviation outside the bound requires committee approval. Job-spec edit triggers re-ranking with audit-log entry.
• Drift-alert thresholds: Demographic-parity ratio deviation > 5pp from baseline triggers AI Officer review within 5 business days; deviation > 10pp triggers immediate AI Governance Committee escalation and recommendation pause-and-investigate. Precision @ 10 deviation > 10pp from baseline triggers ML Engineering investigation. Recruiter override-rate spike (>2σ from baseline) triggers fairness investigation.
• Specifications on input data: Resume format (PDF, DOCX, plain text), job-spec format (Workday requisition record), demographic identifier handling (suppressed before model input), language coverage (EU 24 languages plus English).

Annex IV §4 - Appropriateness of Performance Metrics

Annex IV §4 requires the provider to justify the selection of performance metrics used to assess the system. The notified body reads this section to test whether the provider has thought carefully about why the chosen metrics measure the right things, not just whether the metrics are reported.

For Acme.HireRank v2.1, §4 entries:

• Chosen metrics with rationale: Precision @ 10 (top-10 candidate review is the deployer's actual workflow; precision @ 10 measures recruiter-relevant accuracy). Recall @ 50 (measures whether deserving candidates are retained in a longer-list scenario; protects against tail-loss). Mean reciprocal rank (measures whether the best candidate is at the top of the list; correlated with recruiter time-to-shortlist). Demographic-parity ratio per protected category (Title VII / NYC LL 144 / EEOC alignment; measures disparate-impact ratio across selection rates). Equalised-odds ratio (measures whether true-positive and false-positive rates are comparable across protected categories conditional on outcome). Rationale-citation accuracy (measures whether the LLM-generated rationale accurately cites the resume and job-spec text the ranking depends on).
• Metric-selection trade-offs: Considered demographic parity vs. equalised odds vs. predictive parity per the impossibility-theorem trade-off; documented choice (demographic parity floor + equalised-odds monitoring) in fairness-metric-selection memo Appendix I per lesson 017 of the AI Governance track. Considered AUC vs. precision @ k; chose precision @ k for workflow alignment.
• Cross-walk to fairness-metric-selection memo: Per Acme's fairness-metric-selection memo dated Q1 2027 (refreshed Q3 2027), the Annex III §4 employment context drives the demographic-parity-floor + equalised-odds-monitor combination; the four-fifths rule reference applies; intersectional analysis required per NYC LL 144 (Acme has NY operations).
• Article 15 thresholds: Accuracy threshold, precision @ 10 floor of 0.78 (baseline 0.82 at deployment; floor allows for distribution shift). Robustness threshold, adversarial precision-@-10 degradation cap of 15% under documented adversarial test suite. Cybersecurity threshold, OWASP LLM Top 10 coverage ≥ 90% of applicable risks per AI-VSS scoring methodology. Thresholds documented with rationale in Article 15 evidence memo Appendix G.

Annex IV §5 - Risk Management System (Article 9)

Annex IV §5 describes the risk management system established under Article 9. Article 9(2) lays out the RMS process: identification and analysis of known and reasonably foreseeable risks; estimation and evaluation of risks that may emerge when the system is used in accordance with intended purpose and under conditions of reasonably foreseeable misuse; evaluation of other risks based on data analysis from the post-market monitoring system; adoption of appropriate and targeted risk-management measures.

For Acme.HireRank v2.1, §5 entries:

• RMS process per ISO 23894: Acme operates an AI-specific RMS aligned with ISO/IEC 23894:2023 within the broader ISO/IEC 42001:2023 AIMS. The RMS process runs quarterly with triggered refresh on substantial-modification events, serious-incident events under Article 73, and Commission interpretive notes affecting Annex III §4 systems.
• Identified risks: Disparate-impact risk on protected categories (high inherent risk for any Annex III §4 system); rationale-citation hallucination (LLM hallucinating job-fit reasons not grounded in resume / job-spec); over-reliance / automation bias by recruiters; data-poisoning risk on the LoRA fine-tune; prompt-injection risk through resume content; PII leakage in rationale text; vendor model behaviour change (upstream Anthropic update); cybersecurity risks per Article 15; GDPR risks (special-category data inadvertently surfaced).
• Treatment plan: Per-risk mitigation documented in Risk Register Appendix J. Disparate-impact risk, pre-deployment fairness evaluation + production monitoring + drift-alert thresholds + AI Governance Committee escalation; recruiter training; NYC LL 144 annual bias audit; Texas TRAIGA intent-based discrimination review. Rationale-hallucination, citation-accuracy monitoring; recruiter training to verify citations. Over-reliance, recruiter explicit-action requirement; bulk-action disabled; quarterly automation-bias refresher training. Data-poisoning, fine-tune dataset provenance attestation; CDXA supply-chain signature; fine-tune dataset diff monitoring on refresh. Prompt-injection, resume-content sanitisation; output validation; OWASP LLM01 monitoring. PII leakage, output filtering; periodic audit.
• Residual risks accepted: After mitigation, residual disparate-impact risk accepted at the level demonstrated by post-deployment monitoring (within drift-alert thresholds); residual rationale-hallucination accepted at < 3% per measurement; residual over-reliance accepted with monitoring; residual prompt-injection accepted with quarterly red-team refresh. Risk acceptance documented in Risk Acceptance Memo Appendix K; signed by AI Officer + Chief AI Risk Officer + AI Governance Committee chair.
• Integration with Article 27 FRIA + ISO 42001 A.6: Article 27 FRIA conducted Q1 2027 (refresh Q1 2028) for the Annex III §4 use case; FRIA notification submitted to the Belgian national supervisory authority; FRIA outputs feed §5 risk identification. ISO 42001 A.6.1.1 impact assessment + A.6.2 impact criteria + A.6.4 post-deployment monitoring controls operate per documented procedure; ISO 42001 Stage 2 audit certified June 2027.

Annex IV §6 - Changes Through the Lifecycle

Annex IV §6 documents the change-control regime, how the provider tracks changes to the system through its operational lifecycle and how Article 43(4) substantial-modification analysis is performed. Annex IV §6 is the section where many otherwise-strong technical files fall short; the deployer who treats Annex IV as a static document fails this section by definition.

For Acme.HireRank v2.1, §6 entries:

• Change-control gate: Every proposed change to the system (model version, prompt template, ranking-aggregator logic, threshold values, oversight design, dataset, evaluation suite, dependency version, deployment topology) routed through the Acme Change Advisory Board with an Article 43(4) substantial-modification analysis form. The form asks: does the change affect intended purpose? does it affect performance / robustness / cybersecurity? does it affect bias / fairness? does it affect human-oversight design? does it introduce new risks? The form output classifies the change as routine, minor, significant non-substantial, or substantial.
• Pre-determined-changes carve-out: Article 43(4) carve-out applies for documented pre-determined changes within the §2(f) defined envelope (routine threshold recalibration within ±5%). Carve-out invocation logged with justification; carve-out usage reviewed quarterly by AI Officer team to ensure the envelope is not stretched.
• Change log: Per-change entry with date, change description, classification, Article 43(4) analysis form reference, approver(s), and Annex IV section(s) refreshed. Excerpted change log Appendix L. Example entries: June 15, 2027 minor (UI tooltip clarification, §1 refresh); August 1, 2027 minor (recruiter dashboard layout, §3 refresh); August 10, 2027 v2.1 release (consolidated minor changes, full Annex IV review confirmed no substantial modification).
• Substantial-modification handling: A change classified substantial triggers full Annex IV refresh, new Article 47 declaration of conformity, re-conformity assessment under Article 43, and where applicable Article 49 EU database update. The v1.0 → v2.0 transition in February 2027 followed this full process; documentation in the v2.0 archive cross-referenced from the v2.1 file.

Annex IV §7 - Harmonized Standards Applied

Annex IV §7 lists the harmonised standards the provider has applied, full or partial application, and the references to where the standards' requirements are addressed in the technical file. Where harmonised standards under Article 40 are applied in full, a presumption of conformity attaches to the relevant Chapter III Section 2 requirements that the standard covers. As of late 2027 the CEN-CENELEC JTC 21 harmonised standards are partially published; providers cite a mix of fully harmonised, partially harmonised, and international standards (ISO 42001, ISO 23894, ISO 5338) for the gaps.

For Acme.HireRank v2.1, §7 entries:

• Harmonised standards under Article 40 (where published): hEN [reference] on AI risk management (where the CEN-CENELEC harmonised version of ISO 23894 is published); hEN [reference] on AI quality management (where the harmonised version of ISO 42001 is published); hEN [reference] on AI conformity assessment. Presumption of conformity claimed for Article 9 risk management and Article 17 quality management to the extent covered.
• International standards applied (where harmonised versions pending): ISO/IEC 42001:2023 Information technology, Artificial intelligence, Management system; ISO/IEC 23894:2023 Information technology, Artificial intelligence, Guidance on risk management; ISO/IEC 5338:2023 Information technology, Artificial intelligence, AI system life cycle processes; ISO/IEC 27001:2022 Information security management systems; ISO/IEC 29119 software testing; CEN ISO/IEC TS 12791 on bias.
• Reference industry frameworks applied: NIST AI RMF 1.0 (2023) Map / Measure / Manage; NIST AI 600-1 GenAI Profile (2024); OWASP LLM Top 10 (2025 edition); OWASP Agentic Top 10 (2026 edition); MITRE ATLAS (2026 edition); CycloneDX 1.7 ML-BoM (March 2026) with CDXA attestation.
• Presumption-of-conformity table: Per-Chapter-III-Section-2-article presumption claim with rationale and standards citation in Appendix M.

Annex IV §8 - Copy of EU Declaration of Conformity

Annex IV §8 contains a copy of the Article 47 EU declaration of conformity. The declaration is the provider's binding statement that the high-risk AI system complies with the requirements of the AI Act. Article 47 specifies the content: identification of the high-risk AI system; provider identity; statement that the system complies with the AI Act and any other relevant Union harmonisation legislation; references to harmonised standards or common specifications applied; reference to the notified body (where Annex VII applies); signature.

For Acme.HireRank v2.1, §8 entries:

• Article 47 declaration of conformity: Full declaration text Appendix N. Identifies Acme.HireRank v2.1 by name and version; identifies Acme Corp Brussels as provider; states compliance with Regulation (EU) 2024/1689 (AI Act); states compliance with GDPR Regulation (EU) 2016/679; states compliance with Directive 2000/78/EC equal treatment in employment; cites harmonised standards per §7; cites the notified body that conducted the Annex VII Module H assessment for Annex III §4 high-risk classification.
• Signing authority: Signed by the General Counsel (legally-binding signature) and counter-signed by the AI Officer and the VP HR (operational sign-off). Per Acme delegation-of-authority policy.
• Date of declaration: Original declaration June 1, 2027 (v2.0 deployment); revised declaration August 10, 2027 (v2.1 release; revised to reflect the minor change consolidation). Annex IV file always contains the current declaration.
• Retention: Declaration retained 10 years per Article 18 from when the system ceases to be made available on the market or put into service.

Annex IV §9 - Post-Market Monitoring Plan

Annex IV §9 contains the detailed post-market monitoring plan required under Article 72. The plan describes how the provider will collect, document, and analyse data about the operation of the high-risk system to allow the provider to evaluate continuous compliance with the Chapter III Section 2 requirements throughout the lifetime of the system.

For Acme.HireRank v2.1, §9 entries:

• Article 72 post-market monitoring plan: Full plan Appendix O. Plan elements, production metrics collection (per §3); drift-alert thresholds (per §3); fairness-monitoring cadence (monthly demographic-parity / equalised-odds / quarterly intersectional); user-feedback collection (recruiter feedback module; quarterly recruiter survey; quarterly HR-Operations interview); incident-detection pipeline (anomaly alerts to AI Officer team within 1 business day); periodic review (quarterly AI Governance Committee read-out; annual programme review).
• Serious-incident reporting cross-reference: Per Acme's Article 73 serious-incident reporting policy (skill.re lesson 029); reporting timeline 15 days to national supervisory authority for serious incidents (2 days for incidents involving widespread infringement; immediately for incidents involving death or serious health damage); single-point-of-contact AI Officer; chain-of-custody preservation; provisional report within 15 days with final report within 30 days where investigation pending.
• Periodic review: Quarterly review by AI Officer team of all production metrics, drift alerts, incidents, recruiter feedback; annual review by AI Governance Committee with full Annex IV refresh consideration; FRIA refresh annually (Q1) or on substantial modification.
• Drift-monitoring infrastructure: Production-metrics dashboard implemented in Acme's analytics platform; per-metric drift-alert subscriptions; alerts routed to AI Officer team Slack channel and quarterly committee read-out; alert investigation SLA 5 business days; closed-loop with change-control gate per §6.

Documentation Production Workflow, Retention, and Cross-Walks

The Annex IV file is a multi-team production. The 2026 best-practice RACI splits the work as follows. ML Engineering owns §2(a) methods (technical content), §2(b) design (architecture content), §2(c) system architecture (block / data-flow diagrams), §2(g) validation and testing (evaluation evidence), §2(h) cybersecurity (technical controls). The AI Officer owns §1 general description framing, §2(e) human oversight, §3 monitoring (operating evidence), §4 metric appropriateness rationale, §5 risk management system (with the Risk Manager), §6 change-control (operating evidence), §9 post-market monitoring plan. Procurement owns the upstream-provider attestation references (Anthropic Annex XII receivable in §2(a); CycloneDX 1.7 ML-BoM in §2(c) Appendix E; vendor contract terms cited in §5 vendor-update mitigation). Legal owns §8 EU declaration of conformity (drafting, signing-authority validation), reviews §1 (intended purpose framing), and reviews §6 (substantial-modification analysis form). The Chief AI Risk Officer accountable; AI Governance Committee approves before declaration signing. Retention 10 years per Article 18 from when the system ceases to be made available on the market or put into service.

The cross-walks the Annex IV file enables in a regulator review: EU AI Act Articles 9, 11, 12, 13, 14, 15, 16, 17, 18, 26, 27, 43(4), 47, 71, 72, 73 are each substantively addressed in one or more Annex IV sections, with cross-references in a master index at the front of the file. ISO 42001 Annex A controls A.6 (lifecycle), A.7 (data), A.8 (information for users), A.9 (operational), A.10 (third-party) each map to specific Annex IV sections; the cross-walk table in Appendix P makes the mapping explicit so the ISO 42001 Stage 2 auditor can use the Annex IV file as evidence without duplicate production. NIST AI RMF Map / Measure / Manage outcomes map to Annex IV §5 and §3 evidence. NIST AI 600-1 GenAI Profile risks map to §5 risk register entries. OWASP LLM Top 10 + Agentic Top 10 + MITRE ATLAS coverage maps to §2(g) and §2(h) evidence. The Annex IV file is therefore the single artifact that anchors the multi-framework compliance narrative.

Notified-Body Route vs. Internal-Control Route (Article 43 Preview)

Article 43 establishes two conformity-assessment routes for high-risk systems: internal control under Annex VI (provider self-assesses) and notified-body assessment under Annex VII Modules including Module H (quality-management system + technical-documentation review). The route depends on the high-risk category and on whether the provider has applied harmonised standards in full. For Annex III categories (most enterprise high-risk systems), internal control under Annex VI is typically available; for certain Annex I categories under sector legislation (e.g., medical devices under MDR), notified-body involvement is required by the underlying sector regulation. For Annex III §1 biometric systems, the route depends on whether the provider applies harmonised standards in full. Lesson 051 walks the Article 43 decision in depth. What matters for the Annex IV file is that the content does not change between routes, the same Annex IV sections are produced, but the audience (provider's internal QMS review vs. external notified-body Stage 1 review) and the audit-defensibility bar differ.

Six Common Annex IV Mistakes

Mistake 1 - Skipping §6 Lifecycle Changes (No Change Log)

Many otherwise-strong Annex IV files fail §6. The provider drafts the file at launch and never updates it; the change log is empty or covers only major releases; the substantial-modification analysis form is not used. The notified body opens §6 at the two-year audit and sees no change log; the file is by definition stale. Fix: implement the change-control gate as a procedural standing element with §6 refresh as a closing step of every change-advisory-board meeting.

Mistake 2 - Weak §3 Monitoring (Aspirational, Not Operating)

The provider drafts §3 monitoring as the dashboards the team intends to build; the auditor asks to see the dashboards and the operating evidence; the team produces screenshots from a single date or aspirational documentation. §3 must reflect operating evidence: monthly snapshots of the metrics, the drift-alert investigation history, the quarterly AI Governance Committee read-outs. Fix: §3 cites the operating evidence package maintained alongside the Annex IV file; auditor can sample any month.

Mistake 3 - Vague §4 Metric Rationale ("We Chose Accuracy")

The provider lists metrics without articulating why those metrics are appropriate to the intended purpose and the protected interests. The auditor reads "we chose precision @ 10" and asks "why precision and not recall? why @ 10 and not @ 5? why not AUC?" §4 must answer the trade-off questions the auditor will ask. Fix: §4 cites the fairness-metric-selection memo per lesson 017 and the metric-selection design-rationale memo with the trade-off analysis.

Mistake 4 - Missing §5 Risk Treatment Plan (Risks Listed, Not Treated)

The provider lists identified risks but does not document the per-risk treatment plan with residual-risk acceptance. The auditor sees the list and asks "and then what?" §5 must include the Risk Register with treatment plan and the Risk Acceptance Memo signed by senior leadership. Fix: §5 is anchored on the Risk Register + Risk Acceptance Memo with signed acceptance posture per risk.

Mistake 5 - Weak §9 Post-Market Monitoring Plan (Compliance Boilerplate)

The provider drafts §9 with boilerplate language about "ongoing monitoring" without specifying cadence, metrics, alert thresholds, escalation paths, or integration with the Article 73 serious-incident reporting policy. The auditor asks to see the post-market monitoring evidence at the two-year audit and the provider has no monthly snapshots, no incident log, no recruiter-feedback synthesis. Fix: §9 is the operating plan referencing the actual operating cadence and infrastructure; operating evidence is maintained alongside.

Mistake 6 - Static Document (No Refresh on Substantial Modification)

The provider drafts the Annex IV file at launch; substantial-modification events occur (model version update, ranking-aggregator logic change, fairness-threshold change) without triggering Annex IV refresh; the file at the two-year audit reflects the launch state and not the current production state. Fix: substantial-modification analysis form output that classifies an event as substantial triggers Annex IV refresh as a procedural standing step; the change log per §6 documents the refresh.

Key Takeaways

• Annex IV is the load-bearing artifact of the EU AI Act high-risk regime. Every high-risk system needs an Annex IV file before being placed on the market or put into service per Article 11; the notified body reads it Stage 1; the competent authority reads it on inquiry; retention 10 years per Article 18.
• Annex IV has nine sections. §1 general description + intended purpose; §2 elements and development process (eight sub-paragraphs); §3 monitoring, functioning, and control; §4 appropriateness of performance metrics; §5 risk management system (Article 9); §6 changes through the lifecycle; §7 harmonised standards applied; §8 EU declaration of conformity (Article 47); §9 post-market monitoring plan (Article 72).
• §2 has eight sub-paragraphs. §2(a) methods + third-party pre-trained systems; §2(b) design specifications; §2(c) system architecture; §2(d) data requirements; §2(e) human oversight (Article 14); §2(f) pre-determined changes; §2(g) validation and testing (Article 15); §2(h) cybersecurity (Article 15). Lesson 016 covers the §2 gap-fill against vendor model cards; lesson 026 writes the fine-tune model card.
• The Annex IV file is a living artifact. Annex IV §6 documents the change-control regime; substantial-modification events trigger §6 entry + Annex IV refresh + new Article 47 declaration + re-conformity assessment under Article 43.
• §5 risk management system anchors on the Risk Register + Risk Acceptance Memo. Per Article 9 + ISO 23894 + Article 27 FRIA integration; risks identified, treated, and accepted with signed acceptance posture.
• §4 metric appropriateness requires articulated trade-off rationale. Per the fairness-metric-selection memo and the metric-selection design-rationale memo; the auditor will ask "why this metric and not that one" and §4 must answer.
• §3 monitoring is operating evidence, not aspirational documentation. Production metrics with monthly snapshots, drift-alert investigation history, quarterly AI Governance Committee read-outs; auditor can sample any month.
• §7 lists harmonised standards under Article 40 plus international standards for the gaps. ISO 42001, ISO 23894, ISO 5338 cited where harmonised CEN-CENELEC versions are pending; presumption of conformity claimed per Chapter III Section 2 article in a cross-walk table.
• §8 EU declaration of conformity per Article 47 is signed at the level of the legally-binding authority. General Counsel typical; counter-signed by AI Officer and accountable business owner per delegation policy.
• §9 post-market monitoring plan per Article 72 is the operating plan, not boilerplate. Production metrics, drift-alert thresholds, fairness cadence, user-feedback collection, incident-detection pipeline, periodic review, integration with Article 73 serious-incident reporting policy.
• The Annex IV file enables multi-framework cross-walks. EU AI Act Articles + ISO 42001 Annex A + NIST AI RMF outcomes + NIST AI 600-1 risks + OWASP / ATLAS coverage all map to specific Annex IV sections; the cross-walk table in the file appendix anchors the multi-framework compliance narrative.
• The Article 43 route (internal control vs. notified body) does not change Annex IV content. The same nine sections are produced; the audience and audit-defensibility bar differ; lesson 051 walks the Article 43 decision in depth.