EU AI Act Annex IV: CISO Guide to Model Cards 2026

The August 2, 2026 enforcement deadline for EU AI Act Annex IV technical documentation is no longer a planning exercise. For enterprises operating high-risk AI systems in the EU, the CISO is now accountable for a substantial portion of the mandatory documentation requirements, specifically the Article 15 security controls covering accuracy, robustness, and cybersecurity. This guide breaks down the nine mandatory Annex IV elements, explains how model cards and AI Bills of Materials satisfy them, and gives security teams a practical implementation path before the deadline.

The Nine Mandatory Annex IV Sections

Annex IV is not a menu where some items are optional. Every provider of a high-risk AI system must address all nine sections before placing a system on the EU market or putting it into service. The official Annex IV text is the authoritative source, and teams should work directly from it rather than abbreviated summaries.

Section 1: General Description. The intended purpose, provider name and contact details, version number, how the system interacts with other software and hardware, applicable software dependencies, and the instructions for use. Version history and system interaction maps are frequently missing when organizations begin their documentation work.

Section 2: Development and Design Process. Design specifications, training data governance measures, data acquisition and labeling methodology, and testing procedures. This section requires documented training data provenance, which is where AI Bills of Materials provide the most direct value.

Section 3: Monitoring and Control Capabilities. Performance capabilities and limitations, including accuracy measured separately for specific persons or groups on whom the system is intended to operate. This is the fairness and demographic accuracy section. If your HR AI scores candidates, you need performance breakdowns by demographic group, not aggregate accuracy figures.

Section 4: Performance Metrics Justification. A written explanation of why the chosen accuracy, robustness, and fairness metrics are appropriate for this specific system and its intended purpose. This is a narrative document, not a dashboard. It must address tradeoffs explicitly.

Section 5: Risk Management System. A description of the risk management lifecycle: identification, estimation, evaluation, and mitigation across the full system lifecycle. Generic controls do not satisfy this section. Mitigations must be specific to the identified risks.

Section 6: Lifecycle Changes. A log of pre-determined changes (anticipated during development) and substantial modifications (those that may affect compliance status), with dates and responsible persons.

Section 7: Applied Standards. A list of harmonized standards applied and references to their publication in the EU Official Journal. As of mid-2026, no harmonized standards have been formally cited in the Official Journal. Seven standards are in development under CEN-CENELEC JTC 21, with the most advanced (prEN 18286 on quality management systems) still in public enquiry. Until standards are published, organizations must write their own detailed rationale explaining how each requirement is addressed.

Section 8: EU Declaration of Conformity. A copy of the signed declaration required under Article 47, referencing the provider, the system, and the specific requirements with which conformity is declared.

Section 9: Post-Market Monitoring Plan. A description of how the organization will evaluate AI system performance after deployment, including specific monitoring metrics, data collection methods, thresholds for triggering review, and review frequency.

Identifying Your High-Risk AI Systems Under Annex III

Before documentation begins, security and compliance teams must identify which systems are subject to Annex IV obligations. Annex III defines eight categories of high-risk AI, and the list includes deployments that many organizations have not flagged.

Employment systems are the most commonly overlooked category in enterprise settings. AI used in recruitment scoring, resume screening, interview scheduling, performance monitoring, promotion decisions, task allocation, or termination recommendations is high-risk under Annex III category 4. This includes candidate ranking features built into ATS platforms, productivity monitoring tools that generate scores used in employment decisions, and performance analytics that feed HR recommendations.

Essential services covers credit scoring systems, risk assessment for life and health insurance, and AI used to determine eligibility for public benefits or emergency services dispatch. Financial services organizations using AI-assisted credit models or insurance underwriting are directly in scope.

Biometric systems include any AI that identifies individuals from biometric data in an uncontrolled environment, categorizes individuals by sensitive attributes, or performs emotion recognition.

Education covers AI that determines access to educational programs, evaluates students, or monitors behavior during assessments.

Critical infrastructure includes AI acting as a safety component in the management of water, gas, electricity, road traffic, or digital infrastructure.

The Commission's draft guidelines on high-risk AI classification provide detailed examples and negative cases. Teams should use these alongside Article 6's two-step classification test.

One practical point on deployer obligations: the classification follows function, not vendor. A third-party AI tool that your organization deploys for a high-risk purpose makes your organization the deployer, with obligations including access to the provider's Annex IV documentation and a risk assessment of the system in your specific deployment context.

Model Cards vs. AI Bills of Materials: Complementary Tools

Two documentation formats have become primary tools for satisfying Annex IV, and they serve different purposes rather than substituting for each other.

A model card is a human-readable document covering the model's intended use, training data description, performance across demographic groups, known limitations, and risk mitigations. Model cards map directly to Annex IV sections 1 through 4. Hugging Face provides a standardized 20-section template with YAML metadata fields that make key information machine-readable. Amazon SageMaker's model registry links cards to the model version and can refresh evaluation metrics fields automatically when new evaluations run.

An AI Bill of Materials (AIBOM) is a machine-readable inventory of every system component: model weights, training datasets with provenance, software dependencies, frameworks, and infrastructure. The AIBOM addresses the data lineage requirements in Annex IV Section 2 and the component traceability requirements in Section 7. It is also the format that procurement teams and security questionnaires increasingly request when evaluating AI vendors. Our AI Bill of Materials enterprise guide covers AIBOM construction and tooling in detail.

The critical distinction: neither format alone satisfies the full Annex IV requirement. A model card without data lineage documentation leaves Section 2 incomplete. An AIBOM without a narrative performance justification leaves Section 4 incomplete. A compliant technical file requires both.

For third-party foundation models used in your systems, document what is publicly known about training data from the provider's model cards and technical reports. Where providers do not disclose training data details, the absence must be noted as a documented gap in provenance rather than left undocumented.

Building Automated Model Card Pipelines

Manual model card creation does not scale for organizations with multiple high-risk systems. Automated pipelines keep documentation current as models are retrained or updated.

MLflow is the most common vendor-neutral option. MLflow tracks experiments, stores model artifacts with metadata, and supports custom schema fields mapped to Annex IV sections. A model card template defined as a Python dataclass can be populated automatically from MLflow run metadata at model registration time.

Amazon SageMaker Model Cards integrates with SageMaker's model registry. Cards are versioned alongside the model, and SageMaker can refresh evaluation metric fields automatically when new evaluation jobs complete.

Hugging Face Model Cards use a structured YAML frontmatter schema supporting fields most relevant to Annex IV: license, datasets, evaluation results, metrics by demographic group, and known limitations. For organizations using the Hugging Face Hub for private model hosting, card generation can be integrated into CI/CD pipelines using the huggingface_hub Python library.

The critical automation requirement for Annex IV compliance is that demographic performance metrics are calculated and stored for each model version, not just the initial release. Section 3 requires accuracy broken down by specific groups, and this data must be updated whenever the model is retrained.

Self-Assessment vs. Notified Body

The AI Act provides two conformity assessment routes, and the mandatory path depends on system type.

Internal self-assessment is available for most Annex III high-risk AI systems. The provider verifies internally that the quality management system meets Article 17, the technical documentation meets Annex IV, and the system satisfies all Chapter III Section 2 requirements. The provider signs the EU Declaration of Conformity and is legally responsible for the accuracy of the assessment. Self-assessment is not a lighter process. It requires documented evidence for every requirement, signed by responsible persons, with dated records. The EU AI Act conformity assessment process guide provides a useful reference for structuring the self-assessment.

Mandatory third-party assessment is required for biometric identification systems under Article 43(1)(a) and for high-risk AI systems that are safety components in products already subject to third-party assessment under EU product legislation: medical devices, machinery, automotive systems covered by Annex I.

For the third-party path, an accredited notified body audits both the quality management system and the technical documentation. The notified body issues a certificate valid for a defined period and may conduct periodic surveillance audits.

A practical constraint as of mid-2026: the network of accredited notified bodies for AI Act purposes is still developing. Organizations that need third-party assessment should begin qualification outreach now given the limited current capacity. The EU AI Act Service Desk maintains current guidance on conformity assessment procedures.

The CISO's Role: Article 15 Security Controls in the Technical File

Article 15 of the EU AI Act establishes three technical requirements that must be maintained throughout the AI system's lifecycle: accuracy, robustness, and cybersecurity. Security teams own most of the evidence that demonstrates compliance with these requirements.

Accuracy documentation requires declaring the relevant accuracy metrics in the technical file and measuring accuracy separately for different persons or groups on whom the system operates. For security teams, this means ensuring that model evaluation pipelines produce per-demographic breakdowns and that those results are preserved in versioned records connected to each model release.

Robustness covers the system's capacity to handle errors, faults, inconsistencies, and deliberate adversarial manipulation. The Act explicitly requires documentation of how the system handles adversarial inputs. In practice, this means red team results, adversarial testing coverage reports, and documented mitigations must be included in the Annex IV file. NIST SP 800-218A on secure software development practices provides a useful framework for structuring these records.

Cybersecurity controls must address AI-specific threats alongside standard vulnerability management. The Annex IV file must document data poisoning defenses, model manipulation mitigations, access controls for training pipelines and inference endpoints, monitoring procedures, and incident response procedures specific to AI system compromise. The OWASP Machine Learning Security Top 10 provides a reference taxonomy for AI-specific threats that maps well to Annex IV documentation requirements.

In practice, the CISO's contribution to an Annex IV file includes: red team assessment reports, adversarial robustness test results, access control architecture documentation, data pipeline integrity controls, model monitoring configurations, and AI incident response references. Our EU AI Act Article 73 incident reporting guide covers the post-market monitoring obligations that feed into Annex IV Section 9.

What an Annex IV Security Audit Actually Looks Like

When market surveillance authorities or internal auditors review Annex IV documentation, they are looking for evidence, not assertions. Specific items auditors will request:

Test reports must be signed, dated, include documented methodology, and cover both functional testing and adversarial input testing. Verbal descriptions of testing without artifacts fail this check.

Per-demographic accuracy breakdowns must be present for the populations the system operates on. A single aggregate accuracy figure does not satisfy Section 3.

Risk register must contain specific threats, likelihood and impact estimates, and documented mitigations with evidence of implementation. A generic risk framework reference without system-specific analysis does not satisfy Section 5.

Data provenance records must document where training data originated, how it was labeled, what filtering was applied, who was responsible, and what data governance reviews were conducted.

Change log must show when the model was retrained, what changed, whether the change constituted a substantial modification requiring reassessment, and who approved the change.

Post-market monitoring plan must specify concrete metrics, thresholds, review schedule, and responsible parties, not a general commitment to monitor performance.

One finding common in AI security assessments: documentation that describes intended architecture rather than the actual deployed system. Auditors compare the technical file against the running system. If the access controls described in the file are not implemented in the production deployment, the documentation fails regardless of its quality on paper. A pre-submission security assessment that verifies the documented controls match actual system behavior has direct compliance value.

Implementation Timeline for August 2026

With the deadline in weeks for most Annex III systems, a realistic phased approach:

Phase 1 (Weeks 1 to 2): Inventory. Map all AI systems against the Annex III categories. Document which systems are in scope as provider, which are deployed as a third-party system, and which are out of scope. This inventory is the prerequisite for everything that follows. Start with employment AI and credit scoring tools, as these are the most commonly overlooked in-scope systems.

Phase 2 (Weeks 3 to 4): Gap Assessment. For each in-scope system, assess what Annex IV documentation currently exists. Most organizations will find reasonable records for Sections 1 and 2 and significant gaps in Sections 3, 4, 5, and 9: demographic performance, metric justification, risk management, and monitoring plan.

Phase 3 (Weeks 5 to 8): Documentation Production. Prioritize the highest-risk and most-exposed systems. Assign Section 3 demographic performance analysis to ML teams, Section 5 risk management documentation to security and compliance teams, and Section 9 monitoring plan to operations. Legal drafts the Article 47 Declaration of Conformity.

Phase 4 (Weeks 9 to 10): Internal Review and Sign-Off. Review for completeness against each Annex IV section. Responsible persons sign dated records. The CISO signs off on Article 15 security control evidence. Legal confirms the Declaration of Conformity. Document the review itself as a record.

Organizations that have not yet started should focus on getting one system through the complete process first. The documentation format and the lessons about gaps accelerate subsequent systems significantly.

Conclusion

EU AI Act Annex IV technical documentation is not a compliance checkbox. It is evidence that an organization understands its high-risk AI systems well enough to explain them to a regulator under scrutiny. For most enterprises, the hardest sections are the demographic performance breakdowns required by Section 3, the data lineage records required by Section 2, and the adversarial testing evidence required by Article 15.

Security teams have a direct and non-delegable role in all three. The CISO's contribution to Annex IV is not administrative. It is the technical evidence that determines whether a conformity assessment holds up to scrutiny.

Start with your EU AI Act high-risk systems compliance checklist to confirm scope, then use the section breakdown above to build your documentation plan.

If your organization needs an external review of Annex IV documentation gaps or an Article 15 security control assessment before the deadline, contact the BeyondScale team or run a Securetom scan to identify technical gaps in your AI deployments before enforcement begins.