Every notified body reviewing an Annex IV technical file in 2027-2028 will open the binder, turn to the model documentation section, and ask a single question: does this model card satisfy Article 11 and Annex IV §2(b)? The answer determines whether the conformity-assessment process proceeds smoothly or stalls in findings. The hard truth: most publicly available model cards in 2026, including the Anthropic Claude model cards, the Meta Llama model cards, the OpenAI GPT system cards, are insufficient as standalone Annex IV evidence. They are excellent at what they are designed for: vendor-side capability disclosure for a developer audience. They are not designed for, and do not satisfy, the regulator-facing technical-documentation expectations of Annex IV. This lesson reads three real 2026 model cards against Annex IV §2 expectations, names the specific gaps a deployer-side conformity assessment lead must fill, and ships the model-card-gap memo every L2 model-card author should keep open while drafting.

Why This Lesson Exists - The Vendor-Documentation Gap Problem

The model card concept comes from Mitchell et al. (2019), who introduced the model card as a structured documentation artifact for accountability in machine-learning systems. The original paper proposes nine sections: model details, intended use, factors, metrics, evaluation data, training data, quantitative analyses, ethical considerations, caveats and recommendations. Every major foundation-model provider in 2026 publishes some variant, Anthropic's Claude model cards, OpenAI's GPT system cards, Google DeepMind's Gemini cards, Meta's Llama model cards, Mistral's release notes, and each adds vendor-specific structure on top of Mitchell et al.

The EU AI Act Annex IV §2, referenced from Article 11, lays out a different and more demanding structure. Annex IV §2(b) requires for high-risk AI systems: "description of the elements of the AI system and of the process for its development, including: (i) the methods and steps performed for the development of the AI system, including, where relevant, the use of pre-trained systems or tools provided by third parties and how these have been used, integrated or modified by the provider; (ii) the design specifications of the system, namely the general logic of the AI system and of the algorithms, the key design choices, including the rationale and assumptions, including with regard to persons or groups of persons on whom the system is intended to be used; the main classification choices; what the system is designed to optimise for and the relevance of the different parameters; the description of the expected output of the system and the expected output quality; the decisions about any possible trade-off made regarding the technical solutions adopted to comply with the requirements set out in Chapter III, Section 2 (Articles 8-15)..." The list continues for several more sub-paragraphs covering data requirements, human-oversight design, lifecycle changes, validation testing, performance metrics, and more.

The gap between a Mitchell-et-al. model card and an Annex IV §2(b) technical file is substantial. A model card discloses what the model is. An Annex IV §2(b) technical file discloses how the model was built, why each design choice was made, what trade-offs the provider considered, and how the choices satisfy specific Chapter III Section 2 requirements. The two artifacts overlap; they are not the same document. For a deployer building a high-risk AI system on top of a foundation model, the gap is exactly the deployer-side technical-documentation burden, what the deployer must produce to fill the space between the vendor's model card and the Annex IV technical file the deployer signs.

Reading the Anthropic Claude Model Card Against Annex IV §2 Expectations

Anthropic publishes detailed model cards for the Claude family: Claude 3 (Opus, Sonnet, Haiku), Claude 3.5, Claude 4 family. The May 2026 Claude 4 Opus model card is the most comprehensive vendor model card on the market. Its structure typically includes: model overview, intended use, capabilities and limitations, evaluation results (including the Anthropic Responsible Scaling Policy AI Safety Levels), training data summary (high-level), safety mitigations, refusal training methodology, dangerous-capability evaluations (CBRN, cyber, autonomous replication, persuasion), and red-team contributor list.

What the Anthropic Claude 4 model card satisfies under Annex IV §2(b):

• Mitchell-et-al. coverage: Strong on model overview, intended use, capabilities/limitations, evaluation results, ethical considerations.
• Annex IV §2(b)(ii) general logic: Partial, the model card describes capabilities but does not name "the general logic of the AI system and of the algorithms" at the level Annex IV expects.
• Annex IV §2(b)(ii) design choices and rationale: Partial, the card describes safety design choices (RSP, Constitutional AI) but does not enumerate all key design choices with rationale and assumptions.
• Annex IV §2(b)(ii) classification choices, optimization target, trade-offs: Limited, the card describes high-level optimization targets (be helpful, be safe) but does not document the specific trade-offs Anthropic made in choosing those targets.
• Annex IV §2(c) data requirements: Partial: high-level training-data summary, but Anthropic does not disclose the specific dataset composition at the level Annex IV expects (training and validation and testing datasets, methodologies, data governance).
• Article 53(1)(d) public training-data summary: Covered by the Anthropic public summary published per the GPAI Code of Practice signatory commitment.
• Annex XII downstream-deployer information: Covered separately by Anthropic's developer documentation and enterprise documentation portal.
• Annex IV §2(g) validation and testing: Strong: the Anthropic dangerous-capability evaluations, the Constitutional AI evaluations, and the third-party red-team contributions provide substantial validation and testing evidence, though the deployer must still test the specific use case.

The gap for the deployer: the Anthropic Claude model card is necessary but not sufficient. A deployer building a high-risk Annex III system on top of Claude must supplement the model card with deployer-side documentation on the specific integration design, the deployer's intended-use scoping, the deployer's data-governance choices, the deployer's human-oversight design (Article 14), and the deployer's accuracy/robustness/cybersecurity claims (Article 15) specific to the deployed system. The Anthropic Annex XII receivable is the bridge for the GPAI-specific parts; the deployer's own technical documentation fills the application-specific gaps.

Reading the Meta Llama Model Card Against Annex IV §2 Expectations

Meta publishes detailed model cards for the Llama family: Llama 2, Llama 3, Llama 3.1 (8B, 70B, 405B), Llama 4 family. The Llama 3.1-405B model card is the most comprehensive open-weight model card published in 2024-2025. Its structure includes: model overview, intended use, training data (broader detail than typical closed-model cards because of the open-weight transparency commitment), evaluation results (including standard benchmarks and Meta's responsible-AI evaluations), bias and fairness analyses, environmental impact, and release notes.

What the Meta Llama 3.1-405B model card satisfies under Annex IV §2(b):

• Mitchell-et-al. coverage: Strong, with substantial transparency on training data composition.
• Annex IV §2(b) general logic: Partial, the open-weight release allows technical inspection, but the model card does not enumerate design choices and rationale at the Annex IV level.
• Annex IV §2(c) data requirements: Stronger than closed-model alternatives: Meta discloses dataset categories, source descriptions, filtering methodology, deduplication, language coverage. Still not at the Annex IV §2(c) level of formality.
• Article 53(1)(d) public training-data summary: Meta is a GPAI Code of Practice non-signatory. The public training-data summary is provided in Meta's own format, not aligned with the AI Office template. This is a real gap for deployers relying on Meta-aligned documentation.
• Annex XII downstream-deployer information: Provided through Llama community documentation, but less standardized than Code-signatory peers. Deployers must produce gap-fill documentation.
• Annex IV §2(g) validation and testing: Open-weight nature enables independent third-party evaluation; Meta's evaluations are substantial but the deployer must layer its own validation for the specific application.

The gap for the deployer is materially larger than for the Anthropic case. Meta's non-signatory status means the deployer cannot lean on a Code-of-Practice-aligned Annex XII receivable; the deployer must produce more documentation independently. The fine-tuning case adds further depth: if the deployer fine-tunes Llama 3.1-405B on internal data, Article 25(1)(b) substantial-modification transfer typically triggers, and the deployer becomes the provider of the fine-tuned model with full Article 16 obligations, including the Annex IV §2(b) burden that the original Meta model card did not satisfy. The deployer's Annex IV §2(b) for the fine-tuned model must address both the upstream Meta base-model derivation and the deployer's own fine-tuning design choices, data, evaluations.

Reading the OpenAI GPT System Card Against Annex IV §2 Expectations

OpenAI publishes "system cards" rather than "model cards" for the GPT family: GPT-4, GPT-4o, GPT-4.5, GPT-5 family. The system-card terminology reflects OpenAI's framing that the deployed system (model + safety mitigations + interface) is the unit of disclosure. The May 2026 GPT-5 system card structure typically includes: system overview, capabilities, limitations, safety evaluations (including the OpenAI Preparedness Framework risk levels), red-team findings (including external red-team contributions), training data (high-level), and policy on system updates.

What the OpenAI GPT-5 system card satisfies under Annex IV §2(b):

• Mitchell-et-al. coverage: Strong on system-level disclosure, especially safety evaluations and red-team findings.
• Annex IV §2(b) general logic: Partial, system-level focus means less detail on the underlying model's general logic.
• Annex IV §2(b) design choices and rationale: Partial, the OpenAI Preparedness Framework provides safety-design rationale; broader design rationale is limited.
• Annex IV §2(c) data requirements: Limited, high-level training-data summary; not at the Annex IV level.
• Article 53(1)(d) public training-data summary: Covered by the OpenAI public summary published per the GPAI Code of Practice signatory commitment.
• Annex XII downstream-deployer information: Covered through the OpenAI enterprise documentation and the Annex XII receivable workflow.
• Annex IV §2(g) validation and testing: Strong: external red-team findings, safety evaluations, and Preparedness Framework alignment provide substantial validation evidence.
• Vendor-concentration risk note: OpenAI's March 9, 2026 acquisition of Promptfoo creates eval-tool market concentration; deployers should document this concentration in the procurement file even if Promptfoo remains technically open-source.

The gap for the deployer parallels the Anthropic case. The OpenAI system card is necessary but not sufficient. The deployer must layer application-specific documentation. The vendor-concentration risk on eval tooling is a separate consideration for the procurement file.

Annex IV §2 Section by Section - What a Conformity-Ready Technical File Must Contain

The Annex IV §2 list, in operational paraphrase:

• §2(a) Methods and steps for development, including third-party pre-trained systems and how integrated/modified. This is the upstream-foundation-model provenance section. The deployer's Annex IV must name the GPAI model used (e.g., "Anthropic Claude 4 Opus, API version 2026-05"), the integration architecture, any fine-tuning performed, and the relationship to Article 25 transfer-of-obligations analysis.
• §2(b) Design specifications, including general logic, key design choices, rationale and assumptions, classification choices, what the system is designed to optimise for, expected output quality, trade-offs made regarding Chapter III Section 2 requirements. This is the design-rationale section. The deployer's Annex IV must document the deployer-side design choices that the vendor's model card cannot, e.g., why the deployer chose retrieval-augmentation, why the deployer set certain refusal thresholds, why the deployer's human-oversight design uses pre-action approval vs. post-action review.
• §2(c) System architecture and integration with other software/hardware. Block diagrams, data flow, dependencies, deployment topology.
• §2(d) Data requirements, including data sets used (training, validation, testing), provenance, scope, characteristics, examination for biases, identification of gaps. The deployer's Annex IV must document the deployer's data choices, not just the vendor's training data. For RAG systems, the retrieval corpus is in scope.
• §2(e) Human oversight measures (Article 14). Design, training, deployment of human oversight. The deployer's Annex IV must document the specific oversight design for the deployed system, not just inherit the vendor's general guidance.
• §2(f) Pre-determined changes and continuous-learning systems. This is the Article 43(4) substantial-modification carve-out section.
• §2(g) Validation and testing procedures, including metrics, results, and the safety/robustness/cybersecurity evidence under Article 15. The deployer's Annex IV must layer deployer-specific validation on top of the vendor's evaluations.
• §2(h) Cybersecurity measures under Article 15.

For each Annex IV §2 sub-paragraph, the deployer-side conformity assessment lead asks two questions: (1) What does the vendor's model card provide? (2) What gap-fill documentation must the deployer produce? The two-column answer is the Annex IV §2 readiness map.

CycloneDX 1.7 ML-BoM and the Supply-Chain Bridge

The CycloneDX 1.7 ML-BoM (March 25, 2026 release) provides the machine-readable supply-chain documentation that bridges vendor model cards and Annex IV technical files. An ML-BoM for a deployed high-risk system enumerates: the foundation-model identifier with version and provenance hash; the fine-tuning dataset identifier with version and lineage; the embedding model used; the vector store with version; the retrieval corpus reference; the agent toolset; the evaluation tool versions; the deployment-pipeline component versions. The CDXA (CycloneDX Attestations) extension provides cryptographically-signed claims on supply-chain integrity.

For the Annex IV technical file, the ML-BoM is the cross-reference artifact that links the vendor's model card (e.g., "Anthropic Claude 4 Opus") to specific deployment-time choices (e.g., "API version 2026-05-12, system prompt v3.2, retrieval index snapshot 2026-05-15"). The ML-BoM is also the artifact procurement and security use to track substantial-modification events; a change to any ML-BoM line item triggers an Article 43(4) substantial-modification review.

The Model-Card-Gap Memo - The L1 Artifact

The L1 artifact for this lesson is a model-card-gap memo: a per-system document that reads the foundation-model vendor's model card against Annex IV §2(a)-(h) expectations, names the specific deployer-side gap-fill documentation required, and assigns the gap-fill production to specific owners with target dates. A representative gap memo for an enterprise customer-service chatbot built on Anthropic Claude 4:

• §2(a): Vendor provides Claude 4 Opus model card v2026-05; deployer adds: integration architecture diagram, API version pinning, fine-tuning (none in this case), Article 25 analysis (no transfer triggered). Gap-fill production: integration architecture diagram by engineering; Article 25 memo by Legal+AI Officer.
• §2(b): Vendor provides RSP and Constitutional AI design rationale; deployer adds: refusal-threshold choices, system-prompt design rationale, retrieval-augmentation design choices, optimization-target trade-offs (helpfulness vs. accuracy for customer-service domain). Gap-fill production: design-rationale memo by AI Engineering+AI Officer.
• §2(c): Vendor provides API documentation; deployer adds: system architecture (chatbot UI → middleware → Claude API → response post-processing → audit log), data-flow diagram, dependency list. Gap-fill production: architecture documentation by engineering.
• §2(d): Vendor provides high-level training-data summary + public Article 53(1)(d) summary; deployer adds: retrieval-corpus characterization (FAQ database, product catalog, support-ticket history), data-governance for retrieval corpus, bias examination for retrieval corpus, gap identification. Gap-fill production: retrieval-corpus governance memo by Data team.
• §2(e): Vendor provides general human-oversight guidance; deployer adds: specific oversight design (human agent always available for escalation; supervisor review of confidence-below-threshold responses; weekly QA sampling of 100 random conversations), training for human agents, integration with Article 26 deployer monitoring runbook. Gap-fill production: oversight-design memo by Operations+AI Officer.
• §2(f): Vendor RSP covers continuous-learning; deployer adds: pre-determined-changes definition (model version updates, system-prompt patches, retrieval-corpus updates all trigger Article 43(4) review), change-control gate evidence. Gap-fill production: change-control documentation by Engineering+AI Officer.
• §2(g): Vendor RSP + external red-team contributions; deployer adds: deployer-specific evaluations (customer-service domain accuracy, refusal-appropriateness, OWASP LLM Top 10 coverage, MITRE ATLAS technique coverage, hallucination rate on domain queries), red-team report. Gap-fill production: deployer-side red-team report by Security+AI Officer.
• §2(h): Vendor cybersecurity baseline; deployer adds: deployer-side cybersecurity (API key management, rate limiting, audit logging, incident response, integration with broader SOC). Gap-fill production: cybersecurity documentation by Security team.

Eight Annex IV §2 sub-paragraphs; eight gap-fill production assignments. The memo is the L1 deliverable, the L2 model-card author's reference, and the L3 conformity-package assembly checklist.

Common Model-Card-Gap Mistakes

Mistake 1 - Treating the Vendor Model Card as Sufficient Annex IV §2(b) Evidence

The vendor model card is necessary but not sufficient. The deployer must produce gap-fill documentation for every Annex IV §2(b) requirement the vendor card does not satisfy. Treating the vendor card as sufficient leaves the deployer's Annex IV technical file weak in regulator review.

Mistake 2 - Treating a Fine-Tuned Model's Annex IV as a Vendor-Model-Card Extension

A fine-tuned model triggers Article 25(1)(b) substantial-modification transfer in most cases. The deployer becomes the provider of the fine-tuned model with full Article 16 obligations. The Annex IV §2(b) for the fine-tuned model must address both the upstream base-model derivation and the deployer's fine-tuning design choices, data, evaluations. It is not an extension of the vendor's card; it is a new Annex IV file for the fine-tuned model with the vendor's card as one input.

Mistake 3 - Skipping the ML-BoM

The ML-BoM is the supply-chain documentation that bridges vendor model cards and deployer-side Annex IV. Without an ML-BoM, the substantial-modification change-control gate has no machine-readable trigger artifact; the procurement file lacks supply-chain attestation; the audit-defensibility of the Annex IV §2(a) section is weak.

Mistake 4 - Skipping Retrieval-Corpus Documentation

For RAG systems, the retrieval corpus is a data requirement under Annex IV §2(d). The vendor's training data is one part; the deployer's retrieval corpus is another. Both must be documented with provenance, scope, bias examination, and gap identification.

Mistake 5 - Treating the Vendor's General Human-Oversight Guidance as Article 14 Evidence

Article 14 human oversight requires the deployer to design oversight measures appropriate to the system's risks and intended use. The vendor's general guidance is a starting point; the deployer's specific design is the Article 14 evidence. The model-card-gap memo must include the deployer-side oversight design.

Mistake 6 - Treating the Gap Memo as Static

The gap memo is a living document. Quarterly refresh plus triggered updates on vendor model-card updates, new application-specific evaluations, substantial-modification events, Commission interpretive notes on Annex IV expectations, and changes to the supply-chain ML-BoM. The gap memo is also the L2 model-card author's reference; it should integrate with the L3 capstone conformity-package process and the L4 governance operating plan.

Key Takeaways

• Vendor model cards are not Annex IV technical files. Mitchell-et-al. (2019) model cards are designed for developer-audience capability disclosure. Annex IV §2(b) is regulator-facing technical documentation with substantially more detail on design choices, rationale, trade-offs, and Chapter III Section 2 compliance.
• The Anthropic Claude model card is comprehensive but insufficient. Strong on Mitchell-et-al. dimensions; gaps on Annex IV §2(b) general logic, design choices, classification choices, trade-offs.
• The Meta Llama model card is open-weight-transparent but materially gapped. Stronger training-data transparency than closed alternatives; non-signatory Annex XII gap requires deployer-side gap-fill; fine-tuning typically triggers Article 25(1)(b) transfer.
• The OpenAI GPT system card is system-level focused. Strong on safety evaluations and red-team findings; gaps on underlying model general logic. Vendor-concentration risk from the March 9, 2026 OpenAI/Promptfoo acquisition is a separate procurement consideration.
• Annex IV §2 has eight sub-paragraphs. Methods and steps; design specifications; system architecture; data requirements; human oversight; pre-determined changes; validation and testing; cybersecurity measures. Each requires deployer-side gap-fill production.
• The model-card-gap memo is the L1 artifact. Per-system document reading the vendor's model card against Annex IV §2(a)-(h), naming gap-fill documentation, assigning production to owners with target dates.
• CycloneDX 1.7 ML-BoM bridges vendor cards and Annex IV. Machine-readable supply-chain documentation linking foundation-model identifier, fine-tune dataset, embedding model, vector store, retrieval corpus, agent toolset, evaluation tool versions.
• Fine-tuned models require new Annex IV technical files. Article 25(1)(b) substantial-modification transfer makes the deployer the provider of the fine-tuned model; the Annex IV is not an extension of the vendor card.
• For RAG systems, the retrieval corpus is Annex IV §2(d) data. Provenance, scope, bias examination, gap identification, all required, all deployer-side.
• The gap memo is a living document. Quarterly refresh + triggered updates on vendor card updates, substantial-modification events, Commission interpretive notes, supply-chain changes.