AI Model Card Template Document Every Model Before It Goes Live

An AI model card is a short, structured document that records what a model is, what it was built to do, what data trained it, how it was evaluated, where it fails, and who owns it. This AI model card template gives regulated businesses a format that satisfies ISO/IEC 42001 technical documentation, the NIST AI RMF Map and Measure functions, and EU AI Act transparency duties, whether the model is an open-weight LLM on your own GPUs or a vendor API behind a workflow.

In Business Since 2002/ BBB A+ Since 2003/ CyberAB RPO #1449/ Raleigh, NC

Request a Model Card Review See AI Governance Consulting

Key Takeaways

The model card is the unit of AI documentation. An AI inventory says which models exist. A model card says what each one does, on what data, with what measured limits, and who is accountable. Auditors, insurers, and enterprise customers now ask for both.
Three frameworks converge on the same document. ISO/IEC 42001 control A.6.2.7 requires technical documentation for each AI system, the NIST AI RMF Map and Measure functions expect the same facts to be recorded, and Article 11 of the EU AI Act makes technical documentation a precondition for placing a high-risk system on the market.
The format has a pedigree. The 2019 paper Model Cards for Model Reporting by Margaret Mitchell and colleagues defined nine sections, and the Hugging Face template extended them. This template keeps both and adds the security, deployment, monitoring, and ownership sections a regulated deployment needs.
A vendor's model card is not your model card. It describes the base model on the vendor's data. Your card must describe your fine-tune, your retrieval corpus, your system prompt, your access controls, and your evaluation on your data.
A model card is a living record. It changes whenever the weights, the prompt, the data, or the approved use changes, and the change log is usually the first page an assessor turns to.

Definition

What an AI Model Card Is, and What It Is Not

A model card is a standardized document, usually one to a few pages, that accompanies a trained machine learning model and reports its intended use, training data, evaluation results across the conditions that matter for its application, known limitations, and ethical considerations. The format was introduced in the 2019 paper Model Cards for Model Reporting, presented at the ACM Conference on Fairness, Accountability, and Transparency, and it has since become the default documentation convention for models published on Hugging Face and the reference point that AI governance frameworks lean on. For a business deploying AI, the model card is the artifact that turns "we use AI" into "here is exactly what this model does, on which data, with which measured limits, and who answers for it."

What a Complete Model Card Records

Model identity. Name, version, base model, architecture family, license, developer, release date, and the artifact hash that pins exactly which weights are running in production.
Intended and out-of-scope use. The tasks the model was built for, the users it serves, the decisions it informs, and the uses it must not be applied to, written specifically enough that a new employee could tell the difference.
Training and fine-tuning data. What data went in, where it came from, how it was cleaned and de-identified, what it deliberately excludes, and for retrieval-based deployments, what corpus the model reads at run time.
Evaluation and results. The test sets, the metrics, and the results broken down by the factors that matter for the use case: document type, language, customer segment, input length, or demographic group where relevant.
Risks, limitations, and mitigations. Known failure modes, bias findings, hallucination behavior, prompt injection exposure, and the specific control that limits each one.
Deployment, monitoring, and ownership. Where the model runs, who can reach it, what is logged, how drift is watched, who approves changes, and who to call when it misbehaves.

What a Model Card Is Not

It is not the vendor's README. The Hugging Face card for a base model documents the base model. Your card documents your deployment of it, and the two can disagree in ways that matter.
It is not an AI inventory. The inventory is the list of every AI system in use, one row each. The model card is the detail record behind a row. An AI governance framework needs both.
It is not an acceptable use policy. The AI acceptable use policy tells employees which tools they may use and how. The model card tells engineers, owners, and assessors what one specific model does.
It is not a risk assessment. An AI risk assessment scores the risk of a use case. The model card supplies the facts the assessment relies on, and the assessment's findings flow back into the card's risk section.
It is not a one-time deliverable. A card that has not changed since go-live, while the prompt and the retrieval corpus have, is evidence against you rather than for you.

Requirements

Where the Frameworks Require AI Model Documentation

None of the major frameworks uses the phrase "model card" as a mandatory term. All of them require the contents of one. The table below maps the documentation duty in each framework to what a model card has to contain to satisfy it.

Framework	Documentation Requirement	What the Model Card Has to Prove
ISO/IEC 42001:2023	Annex A control A.6.2.7, AI system technical documentation, and A.6.2.8, AI system recording of event logs	That documentation exists for each AI system covering its intended purpose, usage instructions, assumptions, limitations, and monitoring functions, in a form each audience (users, partners, auditors, regulators) can actually use, and that event logs are recorded at least during operation.
NIST AI RMF 1.0	Map function: context, purpose, capabilities, and impacts documented per system. Measure function: metrics selected, tests run, results tracked. Govern expects an inventory of AI systems.	That each system's context, intended use, and measured performance are written down and traceable. The model card is the natural artifact for the Map and Measure outputs, which is why the NIST AI RMF implementation work Petronella Technology Group does starts by producing one per system.
NIST AI 600-1 (Generative AI Profile, July 2024)	Suggested actions across Govern, Map, Measure, and Manage for generative AI risks including confabulation, information security, and data privacy	That generative-AI-specific risks such as hallucination and prompt injection are documented and measured for your deployment, not assumed away because the base model vendor tested something on its own benchmarks.
EU AI Act (Regulation (EU) 2024/1689)	Article 11 and Annex IV: technical documentation drawn up before a high-risk system is placed on the market and kept up to date. Article 13: transparency and instructions for deployers. Article 53 and Annex XI for providers of general-purpose AI models.	That a provider of a high-risk system holds a documentation package covering the general description, development process, monitoring, and performance of the system, and that deployers receive enough information to use it correctly. SMEs may provide the Annex IV elements in a simplified form, but the elements still have to exist.
CMMC Level 2 / NIST SP 800-171	3.4.1 baseline configurations and system inventories throughout the system development life cycle; the System Security Plan must describe the system boundary and its components	That an internal model or AI service that processes CUI is inventoried as a system component, its boundary is described, and its configuration is baselined. A model card is the cleanest way to hand the assessor that description alongside the System Security Plan.
HIPAA Security Rule	Risk analysis and risk management standards under 45 CFR 164.308(a)(1)	That any model touching electronic protected health information is covered by the risk analysis, and that its data handling, access controls, and logging are documented. The card is where a HIPAA-compliant AI deployment keeps those answers.
Customer questionnaires and cyber insurance	Contractual rather than statutory; increasingly ask whether documentation exists for each AI model in production	That you can answer in one attachment. The same questions appear in the AI vendor security questionnaire Petronella Technology Group recommends sending to your own suppliers, and a model card is the honest way to answer them when you are the supplier.

Petronella Technology Group has documented, secured, and prepared systems for assessment on behalf of regulated businesses since 2002, and has run an AI division since 2023 building private AI deployments on hardware the customer controls. Craig Petronella, author of Beautifully Inefficient and MIT-certified in AI, cybersecurity, blockchain, and compliance, leads that work as a CMMC Registered Practitioner and NC Licensed Digital Forensics Examiner. The model card template on this page is the format used in those engagements, because the same document has to satisfy the engineer who built the model, the executive who owns the risk, and the assessor who tests the controls.

The Template

The AI Model Card Template, Section by Section

The nine sections from the original model cards paper (model details, intended use, factors, metrics, evaluation data, training data, quantitative analyses, ethical considerations, caveats and recommendations) cover what a model is and how it performs. They were written for model developers publishing to the public. A regulated business deploying a model internally needs three more things the original format did not anticipate: the security controls around the model, the infrastructure it runs on, and the ownership and change history that make the card auditable. The twelve sections below are the result.

Section	What to Record	Who Owns It	Evidence It Produces
1. Model details	Name, version, base model and its license, architecture family, parameter count, quantization, release date, developer, artifact hash, card author, card date	ML lead or project owner	Pins exactly which weights are in production; anchors change control and license compliance
2. Intended use	Primary task, intended users, deployment context, the decisions the output informs, and the point where a human reviews it	Business owner	Scopes the risk assessment; feeds the acceptable use policy; the first thing an assessor compares against actual usage
3. Out-of-scope use	Explicitly prohibited uses: no clinical decisions without clinician review, no CUI outside the enclave, no personal data beyond the task, no customer-facing output without approval	Business owner with compliance	The instructions-for-deployers content the EU AI Act asks for; the enforcement basis for the acceptable use policy
4. Training and fine-tuning data	Sources, dates, volume, licensing, de-identification method, exclusions, retention; for retrieval-augmented deployments, the corpus, its refresh cadence, and its access controls	Data engineering	Answers "did our data train it" and "what does it know"; supports the data controls in ISO/IEC 42001 Annex A.7
5. Evaluation data and factors	Held-out test sets, how they differ from training data, and the factors results are split by: document type, language, input length, channel, demographic group where the use case warrants it	ML lead	Proves the model was tested on the conditions it actually serves rather than on the vendor's benchmark
6. Metrics and results	Chosen metrics with the reason for each, results per factor, variance or confidence intervals, comparison against the prior version and against the baseline you replaced	ML lead	The Measure output NIST AI RMF expects; the number the assessor asks to see
7. Bias, risks, and limitations	Known failure modes, bias findings, hallucination behavior on the evaluation set, what the model cannot do, and the recommendations users must follow	Sociotechnical reviewer with the ML lead	Feeds the risk register; the section assessors and customers read most carefully
8. Security controls	Prompt injection test results, red team findings and closure, input and output filtering, authentication and authorization, tenancy, secrets handling, model provenance and supply chain checks	Security	Maps to the NIST AI 600-1 information security actions and to the controls described in your SSP; the section LLM security work produces
9. Deployment and infrastructure	Where it runs (on-premises GPU, private cloud, vendor API), data residency, FIPS or FedRAMP posture where required, integrations, network placement, and egress rules	Infrastructure	The boundary description CMMC and HIPAA assessors need; supports the ISO/IEC 42001 deployment control
10. Monitoring and event logging	What is logged (prompts, retrieved passages, outputs, decisions, latency), where, retention period, drift metrics and thresholds, sampling review cadence, and the triggers that open an incident	Operations and the security operations center	ISO/IEC 42001 A.6.2.8 event logs; the input the AI incident response plan depends on
11. Change log	Every change to weights, system prompt, corpus, guardrails, integrations, or access, with the date, the approver, and the re-evaluation result that accompanied it	Change control	Proves the card is current; the first page an auditor flips to
12. Ownership and contacts	Accountable executive, technical owner, security contact, data owner, last review date, next review date	Governance function	The accountability line an AI management system requires; the name that goes on the risk register entry

The fillable skeleton below is the same twelve sections in the order an assessor expects to read them. Copy it into your documentation system, one file per model, and treat every bracketed field as mandatory. A field that honestly reads "not evaluated" is acceptable and auditable; a field that is silently missing is neither.

AI MODEL CARD  |  [model name]  |  version [x.y]  |  card date [YYYY-MM-DD]

1. MODEL DETAILS
   Base model / license:        [name, version, license]
   Architecture / parameters:   [family, size, quantization]
   Artifact hash:               [sha256 of deployed weights]
   Developer / fine-tuned by:   [organization, team]
   Card author / reviewer:      [name] / [name]

2. INTENDED USE
   Primary task:                [what it does]
   Intended users:              [roles, count]
   Decisions it informs:        [decision, and who makes the final call]
   Human review point:          [where a person checks the output]

3. OUT-OF-SCOPE USE
   Prohibited uses:             [list; be specific]
   Data classes it must not see: [PHI / CUI / PCI / personal data / other]

4. TRAINING AND FINE-TUNING DATA
   Base model data:             [cite the vendor card]
   Fine-tuning data:            [source, dates, volume, license, de-identification]
   Retrieval corpus (if RAG):   [source, size, refresh cadence, access control]
   Exclusions:                  [what was deliberately left out]

5. EVALUATION DATA AND FACTORS
   Test set:                    [source, size, how it differs from training data]
   Factors:                     [document type / language / length / segment / other]

6. METRICS AND RESULTS
   Metrics and rationale:       [metric: why it matters for this use]
   Results per factor:          [table or reference]
   Comparison:                  [prior version / baseline replaced]

7. BIAS, RISKS, AND LIMITATIONS
   Known failure modes:         [list]
   Bias findings:               [findings, or "not evaluated" with reason]
   Hallucination behavior:      [rate on the test set, typical pattern]
   User recommendations:        [what users must do to use it safely]

8. SECURITY CONTROLS
   Prompt injection testing:    [date, method, result, open findings]
   Red team:                    [date, scope, findings closed / open]
   Access control:              [authentication, authorization, tenancy]
   Provenance / supply chain:   [where the weights came from, verification]

9. DEPLOYMENT AND INFRASTRUCTURE
   Runs on:                     [on-premises GPU / private cloud / vendor API]
   Data residency / posture:    [location, FIPS / FedRAMP where required]
   Network placement / egress:  [zone, allowed destinations]
   Integrations:                [systems it reads from and writes to]

10. MONITORING AND EVENT LOGGING
   Logged:                      [prompts / retrievals / outputs / decisions]
   Log destination / retention: [SIEM or store, months]
   Drift metrics / thresholds:  [metric, threshold, review cadence]
   Incident triggers:           [what opens an incident, who is paged]

11. CHANGE LOG
   [date]  [what changed]  [approver]  [re-evaluation result]

12. OWNERSHIP AND CONTACTS
   Accountable executive:       [name, title]
   Technical owner:             [name]
   Security contact:            [name]
   Data owner:                  [name]
   Last review / next review:   [date] / [date]

Worked Example

A Model Card for a Private Contract-Review Assistant

The example below shows what the twelve sections look like when filled in for a common regulated deployment: a law firm running an open-weight language model on its own hardware to flag clauses in commercial contracts for attorney review. It is illustrative. The values are placeholders that show the level of detail expected, not measurements from a client engagement.

Section	Illustrative Entry
Model details	contract-review-assistant v2.1. Base model: an open-weight instruction-tuned model in the 70-billion-parameter class under a permissive license, 4-bit quantized for a single on-premises GPU server. Artifact hash recorded at deployment. No fine-tuning; behavior is set by the system prompt and the retrieval corpus.
Intended use	Summarize commercial contracts and flag clauses that deviate from the firm's clause library, for review by attorneys and paralegals. Every output is reviewed by an attorney before it influences advice. Informs the order in which a contract is reviewed, never the advice itself.
Out-of-scope use	No client-facing advice generated without attorney review. No use on matters under a protective order unless the matter has been approved for the environment. No personal data entered beyond what appears in the contract under review. No litigation strategy or privilege determinations.
Training and retrieval data	Base model training data: cited from the vendor's published card; not controlled by the firm. Retrieval corpus: the firm's clause library and negotiated positions, refreshed weekly from the document management system, with access scoped per matter so a user cannot retrieve passages from matters they are not assigned to.
Evaluation data and factors	A held-out set of contracts labeled independently by two attorneys, none of which appear in the clause library. Factors: contract type (NDA, master services agreement, lease), page count, and whether the source was a native PDF or a scanned image.
Metrics and results	Clause-flagging recall and precision, reported per contract type and per source quality, with the reason recall was chosen as the primary metric (a missed clause costs more than a false flag). Scanned sources performed measurably worse in the evaluation, so an OCR quality gate was added before the model sees the document, and the result after the gate is recorded alongside the result before it.
Bias, risks, and limitations	Misses cross-referenced definitions in long agreements. Occasionally paraphrases a clause instead of quoting it, so output must never be pasted as contract language without checking the source. Weaker on contract types under-represented in the clause library. Recommendation: reviewers open the cited passage for every flag.
Security controls	Single sign-on with multi-factor authentication. No internet egress from the model host. Prompt injection tested against the document ingestion path, since a contract drafted by an adversary is the obvious attack vector; findings closed before go-live and retested after the prompt change in v2.1. Weights verified against the publisher's checksum at download.
Deployment and infrastructure	On-premises GPU server in the firm's server zone, reachable only from the attorney workstation zone. Integrates with the document management system read-only. No data leaves the building, which is the reason the firm chose a self-hosted model over a vendor API.
Monitoring and event logging	Prompts, retrieved passages, and outputs logged to the SIEM with twelve-month retention. A paralegal reviews a weekly sample of flags against the source. Monthly drift check compares recall on a rolling sample to the go-live baseline; a drop past the threshold opens an incident.
Change log	v2.0 to v2.1: system prompt revised to require quoting the source passage; re-evaluated on the same held-out set; approved by the managing partner and the security contact on the recorded date.
Ownership and contacts	Accountable executive: managing partner. Technical owner: IT director. Security contact: the firm's virtual CISO. Data owner: records manager. Reviewed every six months and after any change.

Two things in that example carry most of the value. The evaluation was run on the firm's own contracts, split by the factors that actually vary in the firm's work, which is what makes the results defensible. And the security section documents a test against the realistic attack, a hostile document, rather than a generic statement that the model is secure. That is the standard Petronella Technology Group applies when it builds a custom LLM deployment or a retrieval-augmented assistant for a client, and it is the standard an assessor will apply whether or not the card was written with one in mind.

Common Mistakes

Four Assumptions That Fail at Audit

The same four beliefs show up in nearly every AI documentation review. Each one sounds reasonable and each one produces a card that describes a system other than the one in production.

The Assumption

"The vendor's model card covers us."

The vendor documented the base model on the vendor's data. It says nothing about your fine-tune, your retrieval corpus, your system prompt, your access controls, or how your users actually apply the output. An assessor reading it learns about the vendor, not about you.

"We only use ChatGPT and Copilot, so we have no models to document."

Every AI system in use belongs in the inventory, and each one that touches regulated data or informs a decision deserves a card, even when the model is somebody else's API. The card is shorter, but intended use, data handling, access, and ownership still have to be written down.

"The README in the repository is our documentation."

A README written for developers omits the intended use, limitations, and ownership that auditors and business owners need, and nobody outside engineering can find it or read it.

"We wrote the card at launch, so we are done."

The prompt changed in March, the corpus doubled in May, and a new department started using the tool in July. A card that predates all three describes a system that no longer exists.

What Holds Up

Your card cites the vendor's card, then documents your deployment.

Base model provenance is one field. The other eleven sections are about your data, your prompt, your evaluation, your controls, and your people.

Every inventory entry has a card proportional to its risk.

A public chatbot with no company data gets a one-page card. A private model processing protected health information or CUI gets the full template, security and monitoring sections included. The shadow AI detection sweep finds the entries the inventory missed.

Documentation is written for four audiences at once.

ISO/IEC 42001 A.6.2.7 asks for documentation each audience can use: users, partners, auditors, and regulators. The template separates the sections so each audience finds its part without wading through the rest.

The change log is enforced by change control.

No change to weights, prompt, corpus, guardrails, or access ships without a card update and a re-evaluation result, and the next review date is on the governance calendar with a named owner.

Get a Model Card for Every Model You Run

A model card review from Petronella Technology Group inventories your AI systems, identifies which ones need a full card, and produces the first one with you so your team can produce the rest. Call 919-348-4912 or schedule a consultation.

Schedule a Free Consultation Start With an AI Readiness Assessment

Model Cards, System Cards, Datasheets, and the AI Inventory

Model cards sit inside a small family of AI documentation artifacts, and teams regularly produce the wrong one. The distinctions below decide which document answers which question.

Document	Scope	Who Produces It	When You Need It
Model card	One trained model, or one deployment of it: purpose, data, evaluation, limits, controls, owners	The model developer, or the team deploying it	Every model in production or serving a regulated use
System card	A whole AI product: one or more models plus prompts, tools, retrieval, guardrails, and the behavior users actually see; a format frontier model developers popularized for their own releases	Product or platform team	When behavior depends on more than the model: agents, retrieval assistants, multi-model pipelines
Datasheet for a dataset	One dataset: motivation, composition, collection process, preprocessing, recommended uses, distribution, maintenance, following the format proposed by Timnit Gebru and colleagues in 2018	Data owner	Any dataset used to train, fine-tune, or evaluate a model, and any retrieval corpus
AI inventory / system registry	Every AI system in the organization, one row each: owner, data touched, approval status, risk tier, link to its card	Governance function	Always; it is the index the cards hang from
AI bill of materials	The components inside an AI system: models, datasets, libraries, services, with versions and licenses, in the same spirit as a software bill of materials	Engineering with supply chain security	When a vulnerability or license question needs "what is inside this system" answered in minutes

For most regulated small and mid-sized businesses the practical set is an inventory, a model card per deployed model, and a datasheet per proprietary dataset or retrieval corpus. System cards come later, when agents and multi-step pipelines make a single model card insufficient on its own. The AI bill of materials extends the software supply chain security discipline many defense contractors already run for SBOMs, and the model card's provenance field is where the two connect.

Comparison

Producing AI Model Cards: Three Approaches Compared

Organizations end up with model cards in one of three ways. The differences show up when an auditor, a customer, or an incident asks what the card actually proves.

Question	Internal Team Alone	General AI Consultant	Petronella Technology Group
What does the card describe?	The base model, copied from the vendor README	A generic template filled in during a workshop	Your deployment: your data, your prompt, your evaluation, your controls, and your owners
Who evaluates the model?	Whoever built it, on the data they trained it with	Often nobody; results are taken from the vendor's benchmarks	A held-out evaluation on your data, split by your factors; for open-weight model selection, the self-hosted LLM benchmarks Petronella Technology Group measures on its own GPU fleet
Who tests the security section?	Usually skipped, or a sentence saying the model is secure	Described, not tested	AI red teaming and prompt injection testing against the actual deployment, with findings closed before the card is signed
Where does the card live?	A wiki page nobody outside engineering can find	A slide deck from the engagement	In ComplianceArmor® alongside the AI inventory, policies, risk register, and audit evidence, with review dates on the calendar
What happens after a change?	The card silently goes stale	Nothing; the engagement ended	Change control requires a card update and a re-evaluation result before the change ships

One client review describes the approach this work depends on: "Craig takes the time to understand our business model, not just our technology stack. It makes his recommendations more strategic and tailored to our actual goals." (Daniel Lee, TrustIndex verified review; Petronella Technology Group is rated 4.7 across 92 verified TrustIndex reviews.) A model card is only useful when the intended-use section reflects how the business actually works, and that understanding is where the document starts.

Process

How We Produce and Maintain Model Cards

The sequence Petronella Technology Group runs for an AI documentation engagement. Each step produces a document or a test result, so the business can see progress and the assessor can see evidence.

Inventory: list every AI system in use, assign a risk tier, and decide which ones need a full card

Collect: gather model identity, data lineage, prompts, integrations, and the vendor documentation that already exists

Evaluate: build a held-out test set from your data, choose metrics, run the evaluation, and run red team and prompt injection tests

Write: complete the twelve sections with each audience's part clearly separated

Approve: business owner, security, and compliance sign the card, and it is filed in ComplianceArmor® with its risk register entry

Maintain: change control triggers updates, and a scheduled review confirms the card still describes the system

Ownership

Keeping Model Cards Current After Go-Live

Most model cards do not fail on the day they are written. They fail six months later, when the model has changed and the card has not. Six habits keep the document honest.

Tie the card to change control

Any ticket that changes weights, the system prompt, the retrieval corpus, guardrails, integrations, or access includes a card update as a required field. If the ticket cannot say which section changed, it is not ready to close. Petronella Technology Group builds this into the change procedure during AI governance consulting engagements so it does not depend on anyone remembering.

Keep the evaluation set versioned

The held-out test set is an asset. Version it, protect it from leaking into training or the retrieval corpus, and re-run it after every change so that the results in section 6 are comparable over time rather than a one-off number.

Log what the card says you log

Section 10 is a promise. If the card says prompts and outputs go to the SIEM with twelve-month retention, an assessor will ask to see last month's. The managed SIEM service confirms the feed exists and the retention holds.

Watch for deployments the inventory missed

New AI features arrive inside software the business already owns, and employees adopt tools without asking. A periodic shadow AI sweep finds them, and each one either gets a card or gets blocked.

Re-read the vendor's card when the vendor changes something

Base model versions change, retention terms change, and subprocessors change. The provenance field in your card cites a specific vendor card version; when that changes, sections 4, 8, and 9 need a look. The third-party risk management cycle is the natural trigger.

Put the review date on the governance calendar

Section 12 names a next review date and an owner. That date belongs on the same calendar as the policy reviews and the risk register review, which is how the AI governance maturity model distinguishes an operating program from a documented one.

FAQ

AI Model Card Template Questions, Answered

What is an AI model card?

An AI model card is a short, structured document that accompanies a trained machine learning model and records its purpose, the data it was trained or fine-tuned on, how it was evaluated and the results, its known limitations and risks, and who is responsible for it. The format was introduced in the 2019 paper Model Cards for Model Reporting by Margaret Mitchell and colleagues and is now the standard documentation convention for models published on Hugging Face. For a business deploying AI, the card is the document that lets an engineer, an executive, and an assessor agree on what a specific model does.

What sections should an AI model card template include?

The original paper defined nine: model details, intended use, factors, metrics, evaluation data, training data, quantitative analyses, ethical considerations, and caveats and recommendations. The Hugging Face template groups these into model details, uses, bias and risks and limitations, training details, evaluation, and environmental impact. For a regulated deployment, Petronella Technology Group adds security controls, deployment and infrastructure, monitoring and event logging, a change log, and ownership and contacts, for twelve sections in total. Those additions are what make the card satisfy ISO/IEC 42001 and hold up in a CMMC or HIPAA assessment.

Is a model card required by ISO 42001, NIST AI RMF, or the EU AI Act?

Not by that name, but each requires its contents. ISO/IEC 42001 Annex A control A.6.2.7 requires technical documentation for each AI system covering intended purpose, usage, assumptions, limitations, and monitoring, and A.6.2.8 requires event logs. The NIST AI RMF Map function expects each system's context and purpose to be documented and the Measure function expects metrics and results to be tracked. The EU AI Act's Article 11 and Annex IV require technical documentation before a high-risk system is placed on the market, and Article 13 requires information for deployers. A model card written to the twelve-section template is the single artifact that answers all three.

Do we need a model card if we only use a vendor API like ChatGPT or Copilot?

Yes, but a shorter one. The vendor's own documentation covers the base model, so your card cites it in the model details section rather than repeating it. What the vendor cannot write for you is the intended use inside your business, the data classes the tool may and may not see, who has access, what is logged, and who owns the deployment. Those sections are the ones a customer questionnaire or an auditor actually asks about, and they take a page to complete once the AI inventory exists.

What is the difference between a model card and a system card?

A model card documents one trained model or one deployment of it. A system card documents an entire AI product, which may combine several models with prompts, tools, retrieval, and guardrails, and describes the behavior users actually experience. Frontier model developers popularized the system card format for their own releases. For a business, the model card comes first; a system card becomes necessary when an agent or a multi-step pipeline behaves in ways that no single model card can explain.

Who should write and approve a model card?

Writing is shared. The ML lead or project owner fills in model details, evaluation, and results; the business owner writes intended and out-of-scope use; data engineering writes the data sections; security writes the security controls; operations writes monitoring. Approval belongs to the accountable executive named in section 12, with security and compliance signing alongside. The Hugging Face annotated template makes the same point by assigning sections to a developer, a sociotechnic, and a project organizer, because no single role knows everything a complete card needs.

How often should a model card be updated?

Whenever the model, the system prompt, the training or retrieval data, the guardrails, the integrations, or the approved use changes, and on a scheduled review regardless, typically every six or twelve months depending on the risk tier. The change log in section 11 records each update with the approver and the re-evaluation result. A card with an empty change log for a system that has been in production for a year is a finding waiting to happen.

Does a model card help with CMMC or HIPAA compliance?

Yes. Under CMMC Level 2, a model that processes CUI is a system component that must be inventoried, baselined, and described within the System Security Plan boundary, and the deployment and security sections of the card supply that description directly. Under HIPAA, a model touching electronic protected health information must be covered by the risk analysis, and the card's data, access, and logging sections are the evidence that it is. In both cases the card is the document that stops an assessor from having to reconstruct what the AI system does from interviews.

Related Services

Build the Rest of the AI Governance Program

AI Governance Consulting

→

ISO 42001 Certification

→

NIST AI RMF Implementation

→

AI Vendor Security Questionnaire

→

AI Security Assessment

→

ComplianceArmor® Platform

→

Document the Model Before the Assessor Asks

Petronella Technology Group has secured regulated businesses since 2002 and builds private AI on hardware its clients control. Bring the models you already run, and leave with a card for each one, a test set you can re-run, and a governance calendar that keeps them current. Call 919-348-4912 or schedule a consultation.

Schedule a Free Consultation Explore AI Services

Last Updated: August 30, 2026. Reviewed by Craig Petronella, MIT-certified AI and cybersecurity technologist, CMMC Registered Practitioner, NC Licensed Digital Forensics Examiner (License# 604180-DFE).