Teams asked for "AI documentation" often produce one model card and assume it covers security, procurement and regulators, when a model card, a datasheet and an AI bill of materials (AI-BOM) each answer a different question and each leave gaps the others do not fill. A model card describes how a trained model behaves and where it should be used. A datasheet describes how a dataset was built and what is in it. An AI-BOM is a machine-readable inventory of the models, datasets and dependencies inside a system, with their versions and relationships. This guide treats them as a documentation set: what each proves, which fields matter for security, where they overlap, the formats that carry them, how regulators use them, and the gaps that remain even when all three exist. It is for AI governance leads, ML platform owners, supply chain security teams and assessors reviewing supplier evidence.
Key takeaways
- Three documents, three questions. The model card answers "how does this model behave and for what", the datasheet "what is in this data and how was it gathered", the AI-BOM "exactly which components and versions are in this system".
- None of them proves integrity on its own. All three are statements by their author. OWASP notes that model cards offer no guarantee of a model's origin; signatures and attestations are what bind a document to the artefact.
- The AI-BOM is the join. It is the only one built for machines, and it can carry or reference the other two, so automated policy checks start from it.
- Regulators ask for the content, not the label. The EU AI Act's Annex IV and Annex XI list information that maps across all three documents, with testing and data provenance carrying the most weight.
- The gaps sit between them. Prompts, tools, fine-tuning lineage and deployment identities often appear in none of the three unless you add them deliberately.
The short answer
- Model card: a short human-readable report on one trained model. Mitchell and colleagues proposed model cards in "Model Cards for Model Reporting" (FAT* 2019), to disclose the context in which a model is intended to be used and benchmarked performance across groups, with the evaluation procedures behind it. Model hubs now render cards from a README with YAML metadata.
- Datasheet: a structured description of one dataset. Gebru and colleagues proposed in "Datasheets for Datasets" (first version March 2018, v8 December 2021) that every dataset be accompanied by a datasheet, organised as questions under Motivation, Composition, Collection Process, Preprocessing/cleaning/labeling, Uses, Distribution and Maintenance. Hub "dataset cards" are a lighter relative.
- AI-BOM: a machine-readable inventory of an AI system's components. CycloneDX calls its version the Machine Learning Bill of Materials (ML-BOM); SPDX 3.0 adds AI and Dataset profiles. It lists models, datasets and software with identifiers, versions, suppliers, hashes and relationships.
The relationship between an SBOM and an AI-BOM is covered in SBOM vs AIBOM, and the wider AI supply chain in the AI Supply Chain and AI-BOM Guide. This page is about the three documents side by side.
Side-by-side comparison
| Dimension | Model card | Datasheet | AI-BOM |
|---|---|---|---|
| Subject | One trained model (or a system, as a system card) | One dataset | A system or release and all its AI and software components |
| Primary reader | Integrators, deployers, risk and ethics reviewers | Model builders, data protection and legal reviewers | Security tooling, procurement, vulnerability and licence management |
| Form | Prose plus metadata (for example Markdown with YAML) | Question-and-answer prose | Structured JSON, XML or RDF in CycloneDX or SPDX |
| Question answered | How does it perform, for what use, with what limits? | What is in the data, how was it collected, who may use it? | What exactly is in this build, from where, at which version? |
| Security value | Intended use, known limitations, evaluation results, safety testing | Sensitive data, consent, collection sources, labelling, update process | Provenance, dependencies, hashes, licences, relationships for automated checks |
| Who writes it | Model developer or provider | Dataset creator or curator | Build pipeline, ideally generated, then enriched |
| Update trigger | New model version, new evaluation, new known issue | New data release, correction, change of collection | Every build or deployment |
| Main weakness | Self-declared; evaluation numbers hard to reproduce | Often missing for scraped or internal data | Often thin: names and versions only, no evaluation or data detail |
What each document proves, and what it does not
For security purposes the useful question is not "do we have the document" but "what claim does it support, and how much can we rely on it".
Model card
A good model card supports claims about fitness for purpose: the intended uses and out-of-scope uses, the evaluation data and metrics, known limitations and, for larger models, safety and adversarial testing. It does not prove that the weights you downloaded are the model the card describes. OWASP's LLM03:2025 Supply Chain entry states that model cards and associated documentation offer no guarantees on the origin of the model, and that an attacker can compromise a supplier account on a model repository or create a lookalike. Hub metadata such as license, datasets, base_model and model-index evaluation results is entered by the uploader; Hugging Face's model card documentation describes how to set these fields, not any verification of them.
Datasheet
A datasheet supports claims about data lawfulness and quality: whether the data contains confidential information, whether individuals can be identified, whether it contains sensitive categories such as health or biometric data, whether people were notified and consented, and whether consent can be revoked. Those are the questions the original datasheet paper lists under Composition and Collection Process, and they are exactly what a data protection review needs. A datasheet does not prove the data was not altered after it was written, and it rarely covers poisoning risk unless the author was asked to describe sources and their trust level.
AI-BOM
An AI-BOM supports claims about composition and provenance: which model version, which base model, which datasets, which libraries, from which supplier, with which hashes. Because it is machine-readable it can drive policy: block a model with an unapproved licence, flag a dataset with sensitive personal information, alert when a component hash changes. It proves integrity only when its hashes are checked against the artefacts and the document itself is signed. The OpenSSF-linked model-transparency project, for example, signs a manifest of file hashes as an in-toto statement in a Sigstore bundle; verification recomputes the hashes and checks the signer's identity. See the Model Signing and OpenSSF Model Signing Guide.
Field overlap and gaps
The table maps the information security and assurance teams actually need against the three documents and the formats that carry it. "Card", "Datasheet" and "AI-BOM" show where each field naturally lives.
| Information | Model card | Datasheet | AI-BOM (CycloneDX / SPDX 3.0) |
|---|---|---|---|
| Identity and version of model | Name, version, developer | Not applicable | Component of type machine-learning-model with version, supplier, hashes; SPDX AIPackage |
| Base model and fine-tuning lineage | Hub base_model field | Not applicable | Dependency or pedigree relationships |
| Training and evaluation data | Names datasets used | Full description: composition, collection, labelling | Components of type data; SPDX DatasetPackage with dataCollectionProcess, knownBias |
| Sensitive and personal data | Sometimes | Composition and collection questions | SPDX hasSensitivePersonalInformation, anonymizationMethodUsed, confidentialityLevel; SPDX AI useSensitivePersonalInformation |
| Intended use and limitations | Core content | Uses section | CycloneDX modelCard.considerations; SPDX limitation, intendedUse |
| Evaluation results and metrics | Core content | Not applicable | CycloneDX modelCard.quantitativeAnalysis; SPDX metric, metricDecisionThreshold |
| Safety or risk assessment | Often summarised | Not applicable | SPDX safetyRiskAssessment, standardCompliance |
| Licence | Hub license field | Distribution section | Licence per component, used for automated policy |
| Data update and maintenance | Rarely | Maintenance section | SPDX datasetUpdateMechanism |
| Energy and compute | Sometimes | Not applicable | SPDX energy consumption properties |
| Prompts, tools and agent autonomy | Only in a system card | Not applicable | SPDX AI autonomyType; prompts and tools only if modelled as components |
| Runtime identities and credentials | Only in a system card | Not applicable | Not modelled; record in the AI register |
CycloneDX's 1.6 schema says the modelCard object should be specified for any component of type machine-learning-model and must not be specified for other component types, so a CycloneDX ML-BOM can embed the model card content alongside the inventory. SPDX 3.0 instead spreads the same content across AI and Dataset profile properties. Either way, the AI-BOM can carry the card, but only the datasheet tends to hold the deep data questions.
The last two rows are the most common gap for security. The documents describe a model and its data; an attacker targets the deployed system, its prompts, tools and the credentials it uses. Record those in a system card and the AI register. The Model and System Card Template has a section for integrations and identities, and the AI Register and AI Inventory Template holds the inventory record.
How regulators use the three
The EU AI Act does not require a document called a model card or an AI-BOM. It lists information that must appear in technical documentation, and that information falls across all three.
| EU AI Act requirement | Who it applies to | Best source document |
|---|---|---|
| Annex IV point 2(d): data requirements, where relevant "in terms of datasheets" describing training methodologies and datasets, their provenance, scope and main characteristics, how data was obtained and selected, labelling and cleaning | Providers of high-risk AI systems | Datasheet, referenced from the AI-BOM |
| Annex IV point 2(g): validation and testing procedures and data, metrics for accuracy, robustness and potentially discriminatory impacts, test logs and reports dated and signed by the responsible persons | Providers of high-risk AI systems | Model card evaluation section, backed by signed test reports |
| Annex IV points 3 and 4: expected accuracy, accuracy for specific persons or groups, and the appropriateness of the chosen metrics | Providers of high-risk AI systems | Model card |
| Annex XI section 1: general description, architecture and parameters, licence, training methodology, training data type, provenance and curation, compute and energy | Providers of general-purpose AI models, Article 53(1)(a) | Model card plus datasheet; AI-BOM for versions and components |
| Annex XI section 2: evaluation strategies and results, adversarial testing, system architecture | Providers of general-purpose AI models with systemic risk | Model card or system card, with test reports |
Two practical points follow. First, Annex IV asks for test logs dated and signed by responsible persons, which a model card summary cannot replace; keep the underlying reports and link them. Second, a deployer that integrates a third-party model usually receives the supplier's documentation rather than writing it, so supplier contracts should require it in a usable form. For the obligations themselves see the EU AI Act High-Risk AI Systems Guide and the EU AI Act GPAI Obligations Guide; for Article 10 data governance see the EU AI Act Article 10 Data and Data Governance Guide.
Threat model, failure modes and decision criteria by document
Model card
Threat model: a lookalike or tampered model published with a copied, convincing card (ATLAS AML.T0010.003 Model Repository, under AML.T0010 Supply Chain Compromise); a genuine card whose evaluation results no longer describe the deployed version.
Failure modes: evaluation figures copied from a leaderboard without the test conditions; no out-of-scope uses; card not updated after fine-tuning; safety testing described in one sentence.
Controls: require a card per model version, tie it to the model hash in the AI-BOM, keep the evaluation reports it summarises, and re-run key evaluations in-house before relying on supplier numbers. See the AI Security Evaluations Guide.
Datasheet
Threat model: poisoned or unlawfully collected data entering training (AML.T0020 Training Data Poisoning), and personal data used without a lawful basis.
Failure modes: no datasheet for internal or scraped data; a datasheet written once and never updated as new data is appended; sources listed without who controlled them; consent questions left blank.
Controls: make a datasheet a gate for any dataset entering training or retrieval, record source trust level and update mechanism, and hash dataset releases. See the AI Data Poisoning and Backdoors Guide and the AI Training Data Provenance and Copyright Exposure Guide.
AI-BOM
Threat model: a component swapped in the pipeline without the inventory noticing; an unvetted base model or dataset introduced through a dependency.
Failure modes: AI-BOM generated by hand and stale; models listed by name only, with no hash or supplier; datasets omitted; the AI-BOM never compared against what is actually deployed.
Controls: generate in the build pipeline, include hashes, sign the document, and verify on deployment. NIST SP 800-53 SR-4 Provenance and SR-11 Component Authenticity frame the requirement.
Worked scenario: a fine-tuned support model
A company fine-tunes an open-weights model on two years of support tickets and deploys it in a customer chat service. The supplier's model card covers the base model's evaluations and licence. The internal team adds a model card for the fine-tuned version, but nobody writes a datasheet for the ticket data, and the AI-BOM lists the base model by name only.
In review, the gaps show up quickly. The ticket data contains customer names and account numbers, which a datasheet's composition questions would have surfaced before training. The fine-tuned model card reports accuracy on a held-out set drawn from the same tickets, which says nothing about behaviour on abusive inputs. And because the AI-BOM has no hash for the base model, nobody can show that the weights fine-tuned are the ones the supplier documented. The fix is a datasheet for the ticket set with a decision on redaction, an AI-BOM generated by the training pipeline with hashes for the base model, dataset release and output model, and an updated model card that adds adversarial test results and links the reports.
Building the documentation set
- Set the rule. Every model in production has a model card per version, every dataset used in training, fine-tuning or retrieval has a datasheet, and every AI system release has an AI-BOM. Write it into the AI policy and the release checklist.
- Pick one AI-BOM format. Choose CycloneDX ML-BOM or SPDX 3.0 to match your existing SBOM tooling, so one pipeline produces both.
- Generate, then enrich. Have the build or training pipeline produce the AI-BOM with identifiers, versions and hashes; let owners add card and datasheet content or links.
- Link the three. The AI-BOM references the model card and each datasheet by version and hash; the model card names the datasets by the same identifiers.
- Sign and verify. Sign model artefacts and the AI-BOM; verify at deployment and fail closed in production, after a period in warn-only mode.
- Require it from suppliers. Add documentation requirements to procurement: model card, data documentation sufficient for Annex IV or Annex XI purposes where applicable, and an AI-BOM in a named format.
- Review on change. A new model version, dataset release or fine-tune triggers updates to all affected documents before release. If a document cannot be produced, roll back to the last documented version.
Decision guidance
- Consuming a hosted model through an API: you need the supplier's model card and your own system card; an AI-BOM entry records the model and version you call. Datasheets matter only for data you add, such as retrieval corpora.
- Fine-tuning or training: you need all three, because you become the author of new model behaviour and new data use.
- High-risk use under the EU AI Act: structure the content so it can be lifted into Annex IV documentation; keep signed test reports alongside the model card.
- Small organisations: start with a model card and datasheet in Markdown in the repository, and one generated AI-BOM per release. Formal formats can come later.
- Large organisations: centralise AI-BOMs in the same repository as SBOMs, enforce policy on licence and sensitive data fields automatically, and track documentation coverage as a release gate.
Detection and measurement
Compare deployed model and dataset hashes with those in the current AI-BOM on every deployment and on a schedule, and alert on any component with no AI-BOM entry or no signature. Watch for model downloads from repositories outside the approved list, and for training jobs that read datasets without a datasheet record.
| Metric | What it shows |
|---|---|
| Production models with a current, version-matched model card | Card coverage and freshness |
| Training and retrieval datasets with a datasheet | Data documentation coverage |
| AI system releases with a generated, signed AI-BOM | Inventory automation and integrity |
| Deployed components whose hash matches the AI-BOM | Drift between documentation and reality |
| Supplier models received with usable documentation | Procurement control working |
| Days from model or dataset change to updated documents | Documentation keeps pace with change |
Common failure patterns
- Card as certificate: treating a supplier's model card as evidence the downloaded weights are genuine, with no hash or signature check.
- Datasheet skipped for internal data: documenting public datasets carefully while internal logs, tickets or emails go into training undocumented.
- Thin AI-BOM: names and versions only, no hashes, datasets or base model, so it cannot support provenance or incident response.
- Stale documents: the model was fine-tuned again, but card, datasheet and AI-BOM still describe the previous version.
- System blind spot: all three documents exist for the model, but prompts, tools and the system's credentials are recorded nowhere.
Framework mapping
| Area | NIST SP 800-53 Rev 5 | NIST CSF 2.0 | Threat reference |
|---|---|---|---|
| Component inventory (AI-BOM) | CM-8 System Component Inventory | ID.AM-02 | AML.T0010 Supply Chain Compromise |
| Data inventory and metadata (datasheet) | CM-8 System Component Inventory | ID.AM-07 | AML.T0020 Training Data Poisoning |
| Provenance and authenticity | SR-4 Provenance, SR-11 Component Authenticity | GV.SC-05 | AML.T0010.003 Model Repository; OWASP LLM03:2025 Supply Chain |
| Supplier documentation requirements | SA-4 Acquisition Process, SR-3 Supply Chain Controls and Processes | GV.SC-05 | OWASP LLM03:2025 Supply Chain |
Practitioner checklist
- Every production model version has a model card with intended use, limitations and evaluation results linked to reports.
- Every dataset used for training, fine-tuning or retrieval has a datasheet covering composition, collection, consent and maintenance.
- Every AI system release has a pipeline-generated AI-BOM in CycloneDX or SPDX 3.0, with hashes for models and datasets.
- The AI-BOM references the model card and datasheets by version and hash.
- Model artefacts and the AI-BOM are signed and verified at deployment.
- Supplier contracts require model documentation and an AI-BOM in a named format.
- Prompts, tools and runtime identities are recorded in a system card and the AI register.
- Annex IV or Annex XI content is traceable to these documents where the EU AI Act applies.
Standards and references
- EU AI Act: Annex IV Technical Documentation
- EU AI Act: Annex XI Technical Documentation for General-Purpose AI Models
- CycloneDX: Machine Learning Bill of Materials (ML-BOM)
- SPDX: Specification 3.0.1 AI Profile
- Mitchell et al.: Model Cards for Model Reporting
- Gebru et al.: Datasheets for Datasets
- OWASP: LLM03:2025 Supply Chain
- Hugging Face: Model Cards documentation
Related NHI Mgmt Group resources: SBOM vs AIBOM · AI Supply Chain and AI-BOM Guide · Model and System Card Template · Model Signing and OpenSSF Model Signing Guide · AI Training Data Provenance and Copyright Exposure Guide