Internal Model Card Infographic

How to Create an Internal Model Card for GenAI

Listen to this article

A GenAI model can support customer service, document analysis, coding, research, or internal knowledge tasks. Once that model becomes part of a business process, teams need clear information about how it works and where its risks lie. They also need to know who owns the system, what data it uses, and when it should be reviewed.

T3 helps organizations assess AI systems and manage the risks that can arise when AI is introduced into business operations. An Internal Model Card for GenAI gives teams a structured record of a model’s purpose, capabilities, limitations, testing, controls, and ownership.

This guide explains how to create one and how to make it useful throughout the model’s lifecycle.

Key Takeaways

  • The internal model card captures critical information relating to the GenAI model, such as its purpose, data, capabilities, limitations, risks, controls, and ownership.
  • An internally designed model card aids security, risk management, compliance, technical, and business personnel in understanding the use of the model.
  • Model Card Creation should include aspects of the model’s business purpose, data, testing, security controls, human oversight, deployment information, and approval status.
  • It is more effective for model cards to be linked to the AI governance, risk review, testing, monitoring, and approval process.
  • The document should be updated when the model, data, use case, integrations, risks, or controls change.

What Is an Internal Model Card for GenAI?

The internal model card provides an organization with a document that gives them an accurate description of how the GenAI model is utilized and managed.

The public model card is an overview of the capabilities and limitations of the model while the internal model card is more detailed in its description of the way that particular model is utilized within the organization.

Useful information can include:

Area

Information to Record

Model identityName, provider, version, release date
PurposeIntended business use
OwnershipBusiness and technical owners
DataInput, retrieval, and storage sources
CapabilitiesSupported tasks and functions
LimitationsKnown weaknesses and failure conditions
TestingEvaluation and security test results
ControlsAccess, monitoring, and human review
DeploymentEnvironment and connected systems
GovernanceRisk rating, approval, and review date

Why Do Enterprises Need Internal Model Cards for GenAI?

Generative AI models can analyze business data, communicate with applications, and impact decisions. In the absence of documentation, different groups of stakeholders might have varying perspectives on the way the model functions, on accountability, or on associated risks.

The internal model card would help companies:

  • Develop a uniform model profile for every Generative AI system.
  • Provide transparency to risk and compliance functions regarding model usage.
  • Outline the limitations of the model as well as related security issues.
  • Capture test results and evidentiary data.
  • Specify the model owner and accountability processes.
  • Facilitate EAIRM (Enterprise AI Risk Management) through tying risks to controls.
  • Make it possible to conduct an easy review when changes occur.

The document might assist teams in making a determination on the suitability of a specific model for a business purpose.

How to Create an Internal Model Card for GenAI

For one to construct a good model card, it needs to be done using information from technical, business, security, and governance teams.

Step 1: Identification of the Model

It includes writing the name of the model, provider, version number, deployment date and environment. It will also include whether it is deployed in-house, via the cloud or via external APIs.

Step 2: Business Purpose

It is necessary to clearly write down the business purpose of the model, the audience and the use cases. It will also include use cases not within the defined purpose.

Step 3: Mapping Data & Inputs

Information that goes into the model and the source of that data as well as any sensitive/confidential data.

Step 4: Model Capabilities & Limitations

It involves the capability of the model and where its output cannot be relied upon. For example, hallucinations, inconsistent outputs, bias, or knowledge restrictions.

Step 5: Documentation of Testing

Documentation should cover testing related to performance, safety, privacy, and security of the model. AI Model Assurance could be valuable documentation when determining if the model is performing within requirements.

Step 6: Documentation of Controls and Ownership

Documentation should cover access controls, monitoring, escalation processes, and owners. AI Human Oversight should also be included when there is human review needed before an action/decision.

Step 7: Documentation of Approval/Review Requirements

The documentation should include risk assessment rating, approved/active status, owner, lastest review date, and criteria for reassessment.

How Model Card Creation Fits Into a GenAI Governance Framework

A Model Card should be considered one component within an organization’s overall GenAI Governance Framework rather than a standalone document.

The model card can assist with a number of stages within the AI lifecycle:

Assessment → Testing → Approval → Deployment → Monitoring → Review → Retirement

At the Assessment stage, organizations can leverage the model card to gain understanding and identify risks. At the Deployment stage, organizations can leverage the model card to demonstrate approvals and controls. During later reviews, teams can compare the current system with its previous state.

This also makes it easier for governance, security, legal, compliance, and business teams to work from the same information.

How to Document GenAI Risks and Limitations

Risk information should help readers understand what could go wrong, who could be affected, and which safeguards are in place.

Common areas include:

  • Data leakage and unauthorized access
  • Prompt injection and malicious inputs
  • Hallucinated or inaccurate content
  • Bias and unfair outcomes
  • Privacy risks
  • Intellectual property concerns
  • Inappropriate use
  • Third-party dependencies

A simple record can use four fields:

RiskPotential ImpactControlRemaining Risk
Data exposurePrivacy or security issueAccess controlsReview required
Incorrect outputBusiness decision riskHuman reviewModerate
Prompt injectionUnsafe model behaviorInput filteringMonitor

Clear records like these can support AI Risk Management activities and help teams decide where further testing or controls are needed.

How to Make an Internal Model Card Useful for AI Transparency

A Good AI Transparency Documentation provides sufficient information about the model to the right people in such a way that they do not need to explain complex concepts.

The documentation should be clear and provide information about the purpose, data used, limitations, test results, ownership, controls, and approval of the model. The technical team can include additional information where necessary, whereas the business/governance team can summarize where necessary.

Who Should Own and Maintain an Internal Model Card?

Responsibility needs to be made clear. The use case can be documented by the owner of the business, while technical teams can manage the model and deployment details. The security, privacy, legal, risk, and compliance teams can make their evaluations as appropriate.

The card should be reviewed after major changes, such as a new model version, new data source, new integration, security incident, significant change in use, or regulatory update.

Common Mistakes When Creating an Internal Model Card

Several documentation gaps can reduce its value:

  • Treating the model card as a one-time document.
  • Copying information about public models without verifying their internal usage.
  • Not establishing the ownership responsibility.
  • Neglecting security, privacy, and other data concerns.
  • Listing risks without specifying appropriate controls.
  • Lack of documentation for testing.
  • Using terminology that is not easily comprehensible to business and governance professionals.
  • Forgetting to update the card after significant system changes.

Build Stronger GenAI Governance With T3

An Internal Model Card for GenAI gives an organization a clear picture of what its GenAI model does, how it is being used, what risks it presents, and who is responsible for it. When connected with testing, governance, security reviews, and approval processes, it becomes a useful record for managing AI throughout its lifecycle.

T3’s work across AI governance, assurance, and security reflects the need for organizations to understand and manage AI systems beyond their basic model capabilities. A well-maintained model card can give teams a stronger foundation for responsible AI deployment, risk management, and future reviews.

Ready to strengthen your GenAI governance? T3 can help your organization assess AI risks, establish effective controls, and build governance processes that support responsible AI adoption.

Frequently Asked Questions

What is an internal model card for GenAI?

This is an internal document that summarizes critical information about a GenAI model such as: its purpose, capabilities, limitations, data, risks, controls, ownership, testing and approval status.

It should include model identity, intended use, data, capabilities, limitations, testing, security, privacy, oversight by humans, deployment, monitoring, ownership and governance information.

Identify the model and its business purpose. Document its data, capabilities, limitations, testing, controls, ownership, risks, and approval.

They provide a common record for governance, security, risk, compliance and business teams on the use and management of an AI model.

It should be reviewed whenever there are material changes to the model, use case, data, integrations, controls, risks, or regulatory requirements, with periodic reviews consistent with the organization’s governance requirements.