Model Card

Structure (8 sections)

1. 1. 1. Model identity and version

   Maps to item 1 of Annex XII and item 1 of Annex XI: the tasks the model is intended to perform and the type and nature of AI systems into which it can be integrated; the acceptable use policies that apply; the date of release and methods of distribution; how the model interacts, or can be used to interact, with hardware or software that is not part of it (where applicable); the versions of relevant software related to its use (where applicable); the architecture and number of parameters; the modality (text, image, and so on) and format of inputs and outputs; and the licence. Practical point: the identifier must be a publicly verifiable name with a version, consistent with the weight release, the API endpoint name and the versioned model name in the GPAI training-content summary. If architecture and parameter count are withheld as trade secrets, state the scope of and reason for withholding rather than leaving the fields blank — both Annex XI and Annex XII list them as information to be provided, and a blank is a direct procurement obstacle for downstream providers.

   Evidence to attach

   • · Model version naming convention and the internal version register
   • · The acceptable use policy in full and where it is published
   • · The model licence (commercial use, redistribution, fine-tuning, ownership of outputs)
   • · Release records and distribution channels (weight download, API, on-premise)
   • · Decision record on disclosing architecture and parameter count, with the reason and scope of any withholding

   Common pitfalls

   • · A version in the card that matches neither the API’s reported version nor the weight repository tag;
   • · Architecture and parameter count left entirely blank with no explanation;
   • · An acceptable use policy that contradicts the licence, one permitting what the other forbids;
   • · A card frozen at the first release, with later fine-tuned variants having no card of their own.

2. 2. 2. Intended use, scope of application and prohibited uses

   Stating what the model is and is not for is the most valuable section for downstream users and the starting point for allocating responsibility along the value chain. Three parts. Intended use: the specific tasks, target users, typical integration patterns and typical deployment settings. Scope of application: languages, domains, input length and format, data recency cut-off, concurrency and latency assumptions, and the distributions under which performance degrades materially. Prohibited and discouraged uses: name the scenarios the model must not be used for, covering in particular the areas touched by the Art. 5 prohibited practices of the EU AI Act — materially distorting behaviour through subliminal or manipulative techniques, exploiting vulnerabilities, social scoring, profiling-based crime prediction, untargeted scraping of facial images to build databases, emotion inference in workplaces and education, biometric inference of protected attributes, and restricted real-time remote biometric identification in public spaces — and flag that high-risk use cases must not be put into service until the downstream provider has completed its own conformity assessment. Note Art. 25(1): a downstream actor becomes a provider if it places the system on the market under its own name or trademark, makes a substantial modification to a high-risk system, or changes the intended purpose so that the system becomes high-risk. A clear boundary statement helps downstream users see when they are about to cross that line.

   Evidence to attach

   • · Statement of intended use and target users
   • · Scope table (languages, domains, input specification, data cut-off, degradation zones)
   • · Prohibited-use list mapped against the Art. 5 prohibited practices
   • · High-risk use warning and a note on downstream responsibility under Art. 25(1)
   • · The clauses implementing these limits in the contract, licence and API terms

   Common pitfalls

   • · Prohibited uses reduced to "not for unlawful purposes", which gives downstream users no guidance at all;
   • · An intended purpose drawn so broadly to widen the market that you cannot later argue downstream use went out of scope;
   • · Limits in the card with no matching clauses in the contract or API terms, so they are unenforceable;
   • · No warning that changing the intended purpose may make the downstream actor a provider, leaving later disputes without a basis.

3. 3. 3. Training data and training process overview

   Maps to Annex XI items 2(b)–(e) and Annex XII item 2(c): the design specifications of the model and training process, including training methodologies and techniques, the key design choices with their rationale and assumptions, what the model is designed to optimise for and the relevance of the different parameters as applicable; information on the data used for training, testing and validation where applicable, including the type and provenance of the data and curation methodologies such as cleaning and filtering, the number of data points, their scope and main characteristics, how the data was obtained and selected, and all other measures to detect the unsuitability of data sources and methods to detect identifiable biases where applicable; the computational resources used to train the model (for instance floating point operations), training time and other relevant details; and the known or estimated energy consumption of the model, which may be based on information about computational resources where unknown. Keep this consistent with the public GPAI training-content summary and with the data card: the summary is the statutory public disclosure, the data card is the detailed internal and audit record, and this section is the downstream-facing overview. Three documents giving different numbers for the same fact is the contradiction diligence finds first.

   Evidence to attach

   • · Training configuration records (data mixture, stages, hyperparameters, checkpoints)
   • · Data provenance and curation description, cross-referenced to the data card
   • · Bias detection methods and results
   • · Compute and training-time records, with the FLOP estimation method
   • · Energy figures, or the compute-based estimation method and its assumptions
   • · Reconciliation table against the figures in the public GPAI summary

   Common pitfalls

   • · A training-data scale in the card that does not match the range ticked in section 1.3 of the public GPAI summary;
   • · Energy marked "unknown" without the compute-based estimate the text expressly allows;
   • · Bias detection reduced to "an assessment was carried out", with no method and no results;
   • · Training time and compute given in marketing terms ("thousands of chips for months") rather than checkable figures.

4. 4. 4. Evaluation methods, results and subgroup performance

   Give the triple of evaluation set, metrics and results, and state the limits of each. Evaluation set: provenance, size, construction, evidence of isolation from training data, whether it is public and reproducible, and the languages and populations covered. Metrics: capability (task accuracy, pass rates), safety (harmful-generation rate, jailbreak success rate, refusal and over-refusal rates), robustness (adversarial inputs, out-of-distribution inputs, prompt injection) and factuality (hallucination rate and how it is measured). Results: give confidence intervals or variance across runs rather than single points, report by language, region and population, and mark missing subgroups as not evaluated rather than letting silence imply a pass. For systemic-risk models, Annex XI Section 2 additionally requires a detailed description of the evaluation strategies including evaluation results, based on available public evaluation protocols and tools or other methodologies, with the strategy covering evaluation criteria, metrics and the methodology for identifying limitations; and, where applicable, a detailed description of the measures for internal and/or external adversarial testing such as red teaming, and of model adaptations including alignment and fine-tuning. Including the scope, participants, findings and remediation of red-team work is the single most credit-earning section in EU and Singapore customer diligence.

   Evidence to attach

   • · Evaluation-set description with isolation evidence (deduplication method, contamination checks)
   • · Full evaluation report with metric definitions, measurement methods, run counts and variance
   • · Subgroup results table by language, region and population, marking what was not evaluated
   • · Red-team plan, participants, findings and remediation records
   • · Description of alignment and fine-tuning measures for systemic-risk models
   • · How evaluation results map to release thresholds

   Common pitfalls

   • · Reporting public leaderboard scores only, with no safety or robustness metrics;
   • · Contamination between evaluation and training sets, with no deduplication or contamination check;
   • · Reporting only the languages that perform well and silently dropping the rest;
   • · Red teaming described as "conducted" with no findings list, so depth cannot be judged;
   • · Undefined metrics — "3% hallucination rate" with no account of how a hallucination is adjudicated.

5. 5. 5. Known limitations, failure modes and risks

   The value of this section is proportional to its honesty. Write four categories: capability limits (what it cannot do, where it is unstable); failure modes (how it goes wrong — hallucination, overconfidence, format collapse, long-context forgetting, multi-turn drift, tool-call errors); safety risks (harmful content, jailbreaks, prompt injection, data exfiltration, use for automated abuse); and sociotechnical risks (differential performance from training-data bias, stereotype reinforcement, under-representation of particular groups). For each, give the triggering conditions, the observed frequency or magnitude (data where you have it, flagged as qualitative judgement where you do not), and the mitigations you recommend downstream. Make the mitigations concrete — input length limits, system prompt templates, output filtering, human-review thresholds, rate limiting and abuse detection — because downstream providers build their own risk management on them. Note that Art. 13’s requirements for high-risk instructions for use overlap heavily with this section: the more solid it is, the cheaper it becomes for a downstream integrator to meet Art. 13, which is itself a competitive advantage.

   Evidence to attach

   • · Limitations and failure-mode list with triggers, frequency or magnitude, and the evidence behind each
   • · Safety test results (jailbreaks, prompt injection, data exfiltration)
   • · Quantified differences in subgroup performance
   • · Recommended mitigations and evidence they work
   • · Known-issues tracker (discovery date, status, fix version)

   Common pitfalls

   • · A limitations section written as a disclaimer ("outputs are for reference only"), carrying no actionable information;
   • · Listing only the limitations common to all large models, with nothing specific to this one;
   • · Avoiding jailbreaks and prompt injection, which customer security questionnaires always ask about;
   • · Mitigations that say "human review is recommended" without a threshold or a trigger.

6. 6. 6. Integration guidance and downstream obligations

   Maps to Annex XII items 2(a) and (b): the technical means (instructions for use, infrastructure, tools) required to integrate the general-purpose AI model into AI systems; and the modality and format of inputs and outputs and their maximum size, such as context window length. Beyond the technical content, flag the downstream actor’s own obligations — an expression of the cooperation duties in Arts. 25(2) and 25(4) and an effective way to avoid later disputes: if the model is integrated into a high-risk AI system, the downstream provider must meet the Chapter III Section 2 requirements and conformity assessment, and may need information, capabilities, technical access and assistance from the model provider under Art. 25(4); if the downstream service interacts directly with natural persons, Art. 50(1) disclosure applies; if the output is synthetic audio, image, video or text, Art. 50(2) machine-readable marking applies; and deepfakes or emotion recognition attract Art. 50(3) disclosure. Downstream actors serving users in China must also observe the content-labelling and algorithm-filing requirements. Provide a downstream-obligations table listing common integration patterns against the duties they attract, and state what cooperation materials you can supply (technical file extracts, labelling implementation notes, evaluation data, standard security-questionnaire answers).

   Evidence to attach

   • · Integration documentation (API specification, SDK, deployment requirements, context window and size limits)
   • · Downstream-obligations table mapping integration patterns to the duties they attract and the materials you can supply
   • · Written description of the Art. 25(4) cooperation arrangement and the response times committed to
   • · Technical description of synthetic-content marking, for downstream parties to inherit or verify
   • · Standard security-questionnaire answer pack and its update history

   Common pitfalls

   • · Supplying API documentation only and saying nothing about downstream duties, so customers discover after integration that they are providers;
   • · Implementing synthetic-content marking only in your own product, with nothing inheritable or documented for downstream;
   • · An Art. 25(4) cooperation commitment in the card with no matching contract clause;
   • · Omitting size limits such as the context window, so downstream hits truncation only in production.

7. 7. 7. Safety measures, governance and accountable owners

   Describe the safety measures built into the model and their limits: data filtering and alignment during training, input and output filtering at inference, refusal policies, rate limiting and abuse detection, and the conditions under which each fails. Distinguish clearly between what the model provides and what the downstream party must implement, so nobody assumes content safety is solved on the model side. For governance, record: the accountable legal entity; internal approval and release gates (which evaluations must pass before release); the intake and response channel for security incidents; the vulnerability disclosure policy (how researchers report, response times, whether a safe-harbour commitment applies); and the deprecation policy with its notice period. For systemic-risk models, summarise the arrangements under Art. 55 for evaluation, systemic-risk mitigation, incident tracking and reporting, and cybersecurity protection. The accountable owner and contact channel must be genuinely reachable — many model cards list a mailbox nobody reads.

   Evidence to attach

   • · Safety-measures inventory, marking what is model-side and what downstream must implement
   • · Release-gate configuration and gate-pass records for recent releases
   • · Vulnerability disclosure policy and historical response records
   • · Security-incident intake channel and committed response times
   • · Deprecation policy and past end-of-life notices
   • · Legal entity details and named contacts for the accountable owner

   Common pitfalls

   • · Presenting model-side filtering as a complete content-safety solution, so downstream implements no output-side protection;
   • · A vulnerability mailbox nobody reads, prompting researchers to disclose publicly instead;
   • · Release gates that business pressure can bypass, with no record of the bypass;
   • · Abrupt deprecation with no notice, breaking downstream production systems.

8. 8. 8. Version history, changelog and document maintenance

   A model card must stay in step with the running model, or its whole value is doubted. Record: the card version and the model versions it covers; a changelog of what each model version changed in capability, limitations and safety behaviour, and how the card was updated in response; update triggers (weight updates, a change of base model, materially different evaluation results, added or removed capabilities, new languages or modalities, revisions after a security incident, changes in applicable law); and the document owner and review cycle. Make "update the model card" a hard gate in the release process, alongside the evaluation report and safety testing. For models served by API, state the silent-update policy: will the model change without a version bump, and if so how downstream users find out — a question enterprise customers always raise in negotiation and a good test of the card’s credibility.

   Evidence to attach

   • · Card version history and the model versions each covers
   • · Changelog recording changes in capability, limitations and safety behaviour, with evidence
   • · Update trigger list and the release-gate configuration
   • · Silent-update policy and the downstream notification mechanism
   • · Document owner and review cycle
   • · An accessible archive of previous versions

   Common pitfalls

   • · A card still at the first release after several model iterations;
   • · Silent API-side updates with no notification, invalidating downstream evaluations overnight;
   • · A changelog that records "performance improvements" only, saying nothing about limitations or safety behaviour;
   • · Inaccessible previous versions, so downstream users cannot trace which version their risk assessment was based on.