What should be included in a model card for AI governance?

Short Answer

An AI Governance Model Card should not only describe which AI model is being used, but also provide structured documentation of what the model is used for, which version is in use, who the provider or operator is, which data sources are used, and what performance, bias, and risk information is available, what known limitations exist, how the model relates to a specific AI use case, what approvals have been granted, and when the next review is required.

To ensure that a Model Card remains reliable even during ongoing operations, it should not be treated as a static PDF attachment. As soon as the model version, data source, provider, purpose, metrics, or risk assessment change, the Model Card must also be updated, reviewed, and versioned.

Why a Model Card Must Be Maintained After Go-Live

In many organizations, model cards are still treated as a documentation attachment—something that is created once and then filed away. Such a document often contains some technical information about the model, details on training data, metrics, or known limitations, as well as a link to the Documentation of the provider. However, as soon as the AI use case is deployed in production, the very foundations on which the original Documentation is based on.

• The model is being updated.
• The provider is introducing a new version.
• A data source is being added.
• The department is using the output differently than originally described.
• New risks are being identified.
• A performance metric is changing.
• One monitoring issue remains unresolved.
• A release condition is about to expire.

If the Model Card does not reflect such changes, it no longer represents the current state of the model but only an earlier version. What matters, therefore, is not whether a Model Card was created at some point, but whether its contents continue to align with the actual use of the model. If this alignment is missing, a governance problem arises because reviews, approvals, and responsibilities may be based on outdated information.

Why Model Cards Must Be Understood Differently in AI Governance

AI governance is not just about describing a model from a technical perspective, but about ensuring that its use within the organization is manageable, verifiable, and accountable. A static document is not sufficient for this purpose because a model can be used in multiple use cases, the same provider may offer different model versions, an AI tool may use multiple models, and risk assessment varies significantly depending on the purpose, data source, or impact on decision-making.

A model card should therefore be understood within an AI governance platform as a dynamic operational object that links the model, provider, data, use case, risk, approval, monitoring, and review. It is only through this linkage that a technical description becomes an integral part of the ongoing governance process.

The Problem with Understanding PDFs

A PDF can certainly be useful for exporting, reviewing, or providing evidence to customers, auditors, or internal committees, or as a snapshot. As an operational model, however, it is only suitable to a limited extent because a static document does not automatically recognize whether the documented version is still active, whether a use case now accesses a different data source, whether a review has become necessary, whether an approval still matches the current model version, or whether risks and actions remain open.

Similarly, a PDF cannot reliably distinguish between a historical version and a production version, nor can it show who last reviewed a change. The key question, therefore, is not, „Do we have a model card as a document?“ but rather, „Is the model card maintained as part of the ongoing AI governance process?“

What a Model Card Must Do

In AI governance, a model card should fulfill at least five functions that go beyond a simple model description.

1. Structured Model Description: It documents the name, version, vendor, model type, purpose, operational limits, and basic technical information.
2. Connection to specific AI use cases: It establishes a connection to actual use, because a model risk can only be meaningfully assessed in the specific context of its application.
3. Documentation From reviews: Among other things, it measures performance, bias, interpretability, robustness, Data protection, Information Security, and Known Limitations.
4. Decision Support: It lays the groundwork for associating approvals with a specific model version and a specific use case.
5. Current Events at the Company: It provides a clear record of changes made to the version, data source, provider, purpose, metrics, or risk.

These features turn a Model Card into operational documentation that not only describes the current status but can also be integrated into testing, approval, and review processes.

Which fields are actually needed

A good model card should not consist primarily of free-form text, but should include structured fields so that information can be verified, filtered, reported, and updated. The specific fields required depend on the particular governance model; however, they typically include the following areas.

Model Identity

• Model Name
• Internal model ID
• Model Version
• Model type
• Provider
• Operator
• Hosting or Deployment Model
• Status
• Effective as of
• Last modified
• Next Review

Context of use

• Related AI Use Cases
• Purpose of the mission
• affected Business Processes
• User Groups
• Output Type
• Influence on Decision-Making
• human oversight
• Operating Limits
• Prohibited Uses

Data and Data Sources

• Training data, to the extent known
• Input data in the specific use case
• connected data sources
• personal data
• Special Categories of Personal Data
• confidential company data
• Data Source
• Data Quality
• Timeliness of the Data
• Data Flow and Storage Locations

Performance and Metrics

• relevant performance metrics
• Test Date
• Test Environment
• Test data set
• Known discrepancies
• Error Rates
• Threshold Values
• Monitoring Results
• Comparison with the Previous Version

Bias, Fairness, and Explainability

• known bias risks
• Tested groups or scenarios
• Fairness Ratings
• Explainability Approach
• Limits of Explanability
• common error patterns
• required human review

Risks and Controls

• Risk Classification
• Data Protection Risks
• Security Risks
• legal risks
• Operational Risks
• Reputational risks
• Control Measures
• Pending Actions
• Residual risk
• Risk Acceptance

Service Providers and Third-Party Sources

• Provider
• Legal Basis of the Contract
• Documentation of the provider
• Subcontractors or relevant third parties
• Locations of Storage and Processing
• Support and Change Information
• SLA or Operational Information
• Duty to inform in the event of model changes

Approval and Governance

• Owner
• Model Owner
• Use Case Owner
• Reviewer
• DPO / Data Protection Audit
• Legal Review
• IT Security Review
• Departmental Approval
• Management approval, if necessary
• Release Date
• Terms of Release
• Review Interval

Changes and Versioning

• Change History
• Before-and-After Values
• Reason for the change
• triggering person or role
• affected Use Cases
• Required re-approvals
• historical versions
• Current production status

The list is extensive, but that is not an end in itself. A model card is not a cover sheet, but rather an operational tool that consolidates information relevant to governance in a way that ensures it remains traceable and analyzable during day-to-day operations.

Why the Use Case Is Crucial

A model alone says little about the actual risk, because the same language model can be used, for example, for internal draft texts or for the preliminary assessment of complaints, job applications, customer inquiries, or risk cases. Although the technical model is identical or similar, the governance requirements vary significantly depending on the use case.

That is why a Model Card must always be linked to the specific use case—one in which it is relevant to know what data the model uses, what output it generates, how that output influences decisions, and who is responsible for it. Without this link, the Model Card remains purely technical; it is only through its operational context that it becomes suitable for governance.

Model variants are not a footnote

Many organizations underestimate the importance of model versions, even though a new version can already have technically relevant implications. It can improve response quality, but at the same time generate new error patterns, interpret existing prompts differently, require different thresholds, or include new safety mechanisms. Provider-Documentation, approvals, customer information, or internal policies may be affected.

A robust model card should therefore document not only the model name but also the production version and its change history. For audits, incidents, or future management decisions, it must be clear which version was reviewed and approved, which version was in production, which use cases depended on it, and which change triggered a new review.

Data sources affect risk

In addition to the model, a model card must also capture the data context of the specific use case, because the same model type can be evaluated in completely different ways depending on the data being processed. Therefore, it is relevant, among other things, whether the data consists of public product information, customer data, Employee Data, whether special categories of personal data or confidential company information are processed, whether retrieval-augmented generation is used, which internal systems are integrated, and whether data is used for training or fine-tuning or stored by the provider.

If a data source changes, the risk assessment may also change as a result. Therefore, it must be specified who will update the Model Card in this case and who will determine whether the change requires a new review or re-approval.

Provider information must be maintained

Many AI systems rely on external models, platforms, APIs, or embedded AI functions, which is why provider information should also be included in the Model Card. This includes, in particular, the provider, the contractual basis, and technical Documentation, version used, change information, Data Transmission, storage locations, security and privacy information, relevant sub-service providers, and operational and availability information.

Since providers may change models, features, terms of use, data processing options, security documentation, or interfaces, this information must also be updated. Otherwise, the Model Card loses its value because the documented conditions no longer match the service actually being used.

Performance is only relevant if it aligns with the use case

Model cards often include metrics such as accuracy, precision, recall, F1 score, error rate, robustness, hallucination rate, and false positives or false negatives. However, such metrics are only meaningful if it is clear what they refer to, because a global manufacturer benchmark is not automatically reliable evidence of performance in a specific business context.

For governance purposes, it is therefore crucial to determine which metric is relevant for the specific use case, on which test dataset and in which environment the measurement was taken, what thresholds apply, which errors are critical, who evaluates the results, and what actions are triggered if performance falls below a defined threshold. It should also be documented whether and how performance will continue to be monitored after go-live.

Bias and fairness don't belong in a footnote

In many AI applications, bias is not a theoretical issue but a concrete governance issue, because certain groups may be systematically disadvantaged, training or input data may be unbalanced, or results may be worse for specific groups. A Model Card should therefore document which bias risks are known, which groups or scenarios have been tested, what limitations the tests have, what safeguards are in place, and in which cases human review remains necessary.

This assessment is also not permanently valid. If data sources, model versions, threshold values, or the context of use change, it must be verified whether the previous bias and fairness assessment remains valid.

Explainability depends on context

Not every AI use case requires the same form of explainability. The requirements for an internal summarization tool differ from those of a system that prioritizes risks, prepares decisions, or treats people differently. A Model Card should therefore not merely state whether a model is „explainable,“ but should describe what kind of explanation is available, for whom it is intended, how results are validated, what limitations exist, and what human review is planned.

Explainability is therefore not a standalone checkbox, but rather an integral part of the operating model that must be tailored to the specific use case and its potential impact on decision-making.

Approval must be version-specific

An approval is only reliable if it is clear to which version it refers. If an AI use case is reviewed and approved based on a specific Model Card, it must be possible to unambiguously associate the model version, data sources, risk assessment, and approval conditions with that use case.

In the event of significant changes—such as a new model version, a new provider, an additional data source, a change in purpose, a different user group, a change in output, new bias disclosures, or pending security and data protection measures—it must then be determined whether the existing approval remains valid or whether a new review is required. The Model Card should therefore be integrated into the approval process and not merely serve as an attachment.

Reviews and Follow-ups

A model card remains reliable only if it is reviewed regularly; therefore, it must be possible to track when the last review took place, who conducted it, what changes were identified, what actions were taken as a result, and when the next review is due. Equally important is the process logic for overdue reviews, reminders, and escalations.

Many AI governance processes do not fail at the first Documentation, but rather on the fact that, after go-live, there is no clear accountability for ongoing maintenance. That is why a Model Card needs a designated owner, a review date, and a defined escalation process.

What Auditors and RFPs Really Want to Know

RFPs often ask whether Model Cards are supported, even though this question alone says little about how robust the governance process actually is. A more meaningful indicator is whether Model Cards are structured objects, can be linked to specific use cases, support versioning and reviews, map approvals to specific versions, and can trigger new checks when changes are made to model versions or data sources.

Equally important is whether provider information is maintained, whether bias, performance, and risks can be documented in a structured manner, whether review deadlines and reminders are in place, whether historical statuses remain traceable at the time of an audit, and whether pending actions are linked to the Model Card. Such questions distinguish operational AI governance from mere document storage.

Model Card as an Operational Object in Ailance AI Governance

In an AI governance platform such as Ailance, a Model Card should not be viewed in isolation but should be linked to the objects and processes relevant to actual operations. These include, in particular, AI use cases, AI tools, providers, data sources, risks, measures, approvals, reviews, policies, roles and responsibilities, evidence, versions, and monitoring results.

These links create a governance context in which different roles can each access the information relevant to them: The model owner sees the current model status; the legal team sees provider and contract information; the data protection team sees data protection-related aspects; IT security sees the technical and organizational requirements; and the business unit sees the applicable usage limits and approval conditions. For management, status, risk, and pending actions become transparent without having to piece together information from various documents.

A Simple Comparison

The comparison shows that a model card is only suitable for governance purposes if it is not only documented but also maintained during ongoing operations, linked to relevant processes, and reevaluated whenever changes occur.

The Most Important Management Question

The most important question regarding the Model Card is not whether an organization has one Documentation but rather who is responsible for keeping it up to date. This responsibility includes, among other things, updating the model when new versions or data sources become available, reassessing it when performance metrics change, reviewing existing approvals, and Documentation and the escalation of known risks.

If clear roles and processes are not defined for this purpose, the Model Card remains a document that, while it contains information, is not reliably integrated into the AI governance process.

Conclusion

In AI governance, model cards should not be viewed as static PDF attachments, but rather as operational documentation that is maintained after go-live. To ensure they retain their evidential value, they must be structured, maintained, versioned, and reviewable, and linked to use cases, data sources, providers, risks, approvals, and monitoring.

Only on this basis will it be possible later to trace which model version was in use, which data sources were utilized, which metrics applied, which bias or performance risks were known, which approval was granted, and which changes triggered a new review. It is precisely this traceability that distinguishes a robust governance—Documentation from a model description that was saved once.

Who updates the model card at your company when the data source or version changes?

Questions and Answers

What should be included in a model card for AI governance?

A model card should include the model name, version, provider, purpose, use case reference, data sources, performance metrics, bias and explainability information, risks, controls, approvals, owner, review date, and change history.

Why isn't a Model Card in PDF format sufficient?

A PDF can serve as a snapshot, but it does not manage an ongoing process. It does not trigger reviews, does not automatically display the production version, does not link risks to actions, and makes it difficult to track changes.

Why does a model card need to be maintained after the go-live?

Because model versions, data sources, provider information, performance, risks, and the operational context can change. Without updates, the documented model reality will no longer match the production model reality.

Who should be responsible for a model card?

As a rule, a model owner or someone in a similar role is needed responsible Role. Depending on the organization, other roles may include use case owners, data protection, legal, IT security, data science, and Compliance be involved.

How is a model card related to an AI use case?

Model risk arises in the context of use. Therefore, the Model Card should be linked to the specific use cases in which the model is used.

What role does versioning play in Model Cards?

Versioning shows which model version was tested, released, and deployed in production. It is essential for tracking changes and releases later on.

Which data sources should be documented?

In particular, the following should be documented: input data, connected internal systems, and training or fine-tuning data, as applicable, personal data, confidential data, data sources, and data quality.

What does "reviewability" mean in the context of a model card?

"Reviewability" means that a model card is reviewed regularly, has an owner, has a review date, changes are traceable, and open actions are tracked.

What should an RFP ask about model cards?

An RFP should ask whether model cards are structured objects, whether they can be linked to use cases, whether versioning and reviews are supported, whether approvals are version-specific, and whether changes to the model version or data source can trigger new validations.

How does Ailance support AI Governance Model Cards?

Ailance AI Governance should treat Model Cards as structured operational objects and link them to use cases, tools, providers, data sources, risks, approvals, reviews, actions, and evidence.