# AI Model Card Template

**Version:** 1.0
**Last Updated:** 2025-01-13
**Source:** KLA Digital (kla.digital/resources/ai-model-card-template)

---

## About This Template

Model cards are standardized documentation for AI models. Originally proposed by researchers at Google in 2019, they have become an industry best practice for communicating what a model does, how it performs, and what its limitations are.

For organizations subject to the EU AI Act, model cards help satisfy transparency requirements under Article 13 and contribute to the technical documentation required by Annex IV. While the EU AI Act does not explicitly mandate model cards, the information they contain is required in various forms throughout the compliance framework.

### Model Cards vs. System Cards vs. Annex IV Documentation

| Document Type | Scope | Purpose | Audience |
|---------------|-------|---------|----------|
| **Model Card** | Single ML model | Technical documentation of model behavior | Developers, deployers, technical reviewers |
| **System Card** | Complete AI system | Documentation of full system including multiple models, integrations, workflows | Architects, compliance, auditors |
| **Annex IV Technical Documentation** | High-risk AI system | Comprehensive compliance documentation | Regulatory authorities, notified bodies |

A high-risk AI system might have:
- Multiple model cards (one per ML model component)
- One system card (describing the complete system)
- One Annex IV technical documentation package (comprehensive compliance artifact)

---

## How to Use This Template

1. **Read the guidance** explaining what information is needed and why
2. **Review the example entries** showing how completed sections might look
3. **Fill in the bracketed placeholders** with your model-specific information

If a section is not applicable, note this explicitly rather than leaving it blank. Auditors and reviewers need to know whether information was intentionally omitted versus overlooked.

Update model cards whenever:
- The model is retrained or fine-tuned
- Performance characteristics change materially
- New limitations or failure modes are discovered
- Intended use cases change

---

## Section 1: Model Details

**Purpose:** Provide basic identification and provenance information about the model.

### 1.1 Model Identification

| Field | Value |
|-------|-------|
| Model Name | [Official name of the model] |
| Model ID / Version | [Unique identifier and version number] |
| Model Type | [Classification, regression, generation, etc.] |
| Architecture | [Model architecture: transformer, CNN, gradient boosting, etc.] |
| Framework | [Training framework: PyTorch, TensorFlow, scikit-learn, etc.] |
| Model Size | [Parameters, layers, or other size metrics] |

### 1.2 Development Information

| Field | Value |
|-------|-------|
| Developed By | [Organization and team] |
| Development Date | [When model development was completed] |
| Last Updated | [Date of most recent update] |
| Contact | [Point of contact for model questions] |
| License | [License governing model use, if applicable] |

### 1.3 Model Lineage

| Field | Value |
|-------|-------|
| Base Model | [If fine-tuned or adapted, identify base model] |
| Training Data Reference | [Reference to training data documentation] |
| Training Code Reference | [Reference to training code repository] |
| Previous Versions | [List significant previous versions] |

---

## Section 2: Intended Use

**Purpose:** Define what the model is designed to do and, critically, what it is not designed to do.

### 2.1 Primary Use Cases

| Use Case | Description | User Type |
|----------|-------------|-----------|
| [Primary use case 1] | [Detailed description of what the model does in this use case] | [Who uses it: internal team, customers, etc.] |
| [Primary use case 2] | [Description] | [User type] |
| [Primary use case 3] | [Description] | [User type] |

### 2.2 Intended Users

| User Category | Description | Required Competencies |
|---------------|-------------|----------------------|
| [Primary users] | [Who are the primary users of model outputs?] | [What expertise do they need?] |
| [Secondary users] | [Who else interacts with the model?] | [Required competencies] |
| [Downstream consumers] | [Who consumes decisions based on model outputs?] | [Awareness requirements] |

### 2.3 Out-of-Scope Uses

| Use Case | Reason Not Supported |
|----------|---------------------|
| [Prohibited use case 1] | [Why this use is inappropriate: data limitations, ethical concerns, legal constraints, etc.] |
| [Prohibited use case 2] | [Reason] |
| [Use case not validated] | [Why this use has not been validated and should be avoided] |

### 2.4 Preconditions for Use

| Precondition | Description | Verification Method |
|--------------|-------------|---------------------|
| [Data requirements] | [What input data characteristics are required?] | [How to verify data meets requirements] |
| [Integration requirements] | [How must the model be integrated?] | [Integration checklist] |
| [Human oversight requirements] | [What human oversight must be in place?] | [Oversight verification] |

---

## Section 3: Training Data

**Purpose:** Document the data used to train the model. This section is critical for understanding model behavior, limitations, and potential biases.

### 3.1 Training Data Sources

| Source | Description | Volume | Collection Period |
|--------|-------------|--------|-------------------|
| [Data source 1] | [What is this data and where does it come from?] | [Number of samples] | [When collected] |
| [Data source 2] | [Description] | [Volume] | [Period] |
| [Data source 3] | [Description] | [Volume] | [Period] |

**Total Training Data Size:** [Total samples/records]

### 3.2 Data Characteristics

| Characteristic | Description |
|----------------|-------------|
| Geographic coverage | [What regions/countries are represented?] |
| Temporal coverage | [What time periods are represented?] |
| Demographic representation | [If applicable, describe demographic distribution] |
| Domain coverage | [What domains, categories, or types are included?] |
| Language(s) | [For NLP models, languages covered] |

### 3.3 Data Preprocessing

| Step | Description | Rationale |
|------|-------------|-----------|
| [Preprocessing step 1] | [What was done to the data?] | [Why this step was necessary] |
| [Preprocessing step 2] | [Description] | [Rationale] |
| [Filtering/exclusions] | [What data was filtered out?] | [Why these exclusions] |

### 3.4 Data Quality and Known Issues

| Issue | Description | Mitigation |
|-------|-------------|------------|
| [Known data quality issue 1] | [Description of the issue] | [How it was addressed or its impact minimized] |
| [Representation gap] | [Groups or scenarios underrepresented] | [Mitigation or disclosure] |
| [Historical bias] | [If data reflects historical biases] | [How this was addressed] |

**Detailed Data Documentation Reference:** [Link to full data documentation]

---

## Section 4: Evaluation Data

**Purpose:** Document the data used to evaluate model performance.

### 4.1 Evaluation Datasets

| Dataset | Description | Size | Relationship to Training |
|---------|-------------|------|--------------------------|
| [Validation set] | [Held-out portion of training data] | [Size] | [Same distribution as training] |
| [Test set] | [Separate dataset for final evaluation] | [Size] | [Describe relationship to training distribution] |
| [External benchmark] | [Standard benchmark dataset, if used] | [Size] | [Different distribution - describe differences] |

### 4.2 Evaluation Methodology

| Aspect | Description |
|--------|-------------|
| Evaluation protocol | [How evaluation was conducted: cross-validation, holdout, etc.] |
| Metric selection rationale | [Why these metrics were chosen for evaluation] |
| Statistical approach | [Confidence intervals, significance testing, etc.] |
| Temporal evaluation | [If applicable, how temporal aspects were handled] |

### 4.3 Evaluation Conditions vs. Production

| Factor | Evaluation Conditions | Expected Production Conditions | Gap Assessment |
|--------|----------------------|-------------------------------|----------------|
| Data distribution | [Evaluation data characteristics] | [Expected production data characteristics] | [How similar/different?] |
| Data quality | [Evaluation data quality] | [Expected production data quality] | [Impact of differences] |
| Volume/latency | [Evaluation batch size, timing] | [Production volume, latency requirements] | [Any performance implications?] |

---

## Section 5: Performance Metrics

**Purpose:** Report model performance quantitatively.

### 5.1 Overall Performance

| Metric | Value | Confidence Interval | Evaluation Dataset |
|--------|-------|--------------------|--------------------|
| [Primary metric, e.g., Accuracy] | [Value] | [95% CI] | [Which dataset] |
| [Secondary metric, e.g., Precision] | [Value] | [95% CI] | [Which dataset] |
| [Secondary metric, e.g., Recall] | [Value] | [95% CI] | [Which dataset] |
| [F1 Score or equivalent] | [Value] | [95% CI] | [Which dataset] |
| [AUC-ROC or equivalent] | [Value] | [95% CI] | [Which dataset] |

### 5.2 Disaggregated Performance

Report performance across relevant subgroups to reveal disparities.

| Subgroup | Metric 1 | Metric 2 | Sample Size | Notes |
|----------|----------|----------|-------------|-------|
| [Overall] | [Value] | [Value] | [N] | [Baseline] |
| [Subgroup A] | [Value] | [Value] | [N] | [Any notable differences] |
| [Subgroup B] | [Value] | [Value] | [N] | [Any notable differences] |
| [Subgroup C] | [Value] | [Value] | [N] | [Any notable differences] |

### 5.3 Performance Across Conditions

| Condition | Metric | Value | Notes |
|-----------|--------|-------|-------|
| [Standard conditions] | [Primary metric] | [Value] | [Baseline performance] |
| [Edge case condition 1] | [Primary metric] | [Value] | [How performance changes] |
| [Edge case condition 2] | [Primary metric] | [Value] | [How performance changes] |
| [Adversarial conditions] | [Primary metric] | [Value] | [If tested] |

### 5.4 Performance Over Time (if applicable)

| Time Period | Metric | Value | Notes |
|-------------|--------|-------|-------|
| [Initial deployment] | [Primary metric] | [Value] | [Baseline] |
| [Most recent measurement] | [Primary metric] | [Value] | [Current performance] |
| [Trend] | [N/A] | [Description of trend] | [Stable, degrading, improving] |

---

## Section 6: Ethical Considerations

**Purpose:** Document fairness analysis, bias testing, and ethical considerations.

### 6.1 Fairness Metrics

| Metric | Definition | Target | Actual | Status |
|--------|------------|--------|--------|--------|
| [Demographic parity] | [Positive rate equal across groups] | [Ratio > 0.8] | [Actual ratio] | [Met/Not met] |
| [Equalized odds] | [TPR and FPR equal across groups] | [Difference < 5%] | [Actual difference] | [Met/Not met] |
| [Predictive parity] | [Precision equal across groups] | [Difference < 5%] | [Actual difference] | [Met/Not met] |

### 6.2 Protected Characteristics Analyzed

| Characteristic | Groups Tested | Findings | Mitigation |
|----------------|---------------|----------|------------|
| [Characteristic 1] | [Groups within characteristic] | [Summary of findings] | [Any mitigation applied] |
| [Characteristic 2] | [Groups] | [Findings] | [Mitigation] |

**Note:** [Explain any characteristics not tested and why]

### 6.3 Bias Testing Results

| Test Type | Description | Result | Impact |
|-----------|-------------|--------|--------|
| [Training data bias analysis] | [What was tested] | [Finding] | [Potential impact on model behavior] |
| [Output bias testing] | [What was tested] | [Finding] | [Potential impact] |
| [Proxy discrimination testing] | [Testing for indirect discrimination] | [Finding] | [Potential impact] |

### 6.4 Ethical Considerations

| Consideration | Description | Mitigation/Decision |
|---------------|-------------|---------------------|
| [Potential harm 1] | [How could this model cause harm?] | [How this is mitigated or why risk is accepted] |
| [Dual use concern] | [Could the model be misused?] | [Controls in place] |
| [Privacy consideration] | [Any privacy implications?] | [How addressed] |

**FRIA Reference (if applicable):** [Link to Fundamental Rights Impact Assessment]

---

## Section 7: Limitations

**Purpose:** Clearly document what the model cannot do or does poorly.

### 7.1 Technical Limitations

| Limitation | Description | Impact | Mitigation |
|------------|-------------|--------|------------|
| [Input constraints] | [What input characteristics the model cannot handle] | [What happens with invalid input] | [How to prevent/handle] |
| [Domain boundaries] | [Where the model's domain expertise ends] | [Degraded performance outside domain] | [How to detect domain shift] |
| [Scale limitations] | [Volume, size, or complexity constraints] | [What happens at limits] | [How to monitor] |

### 7.2 Known Failure Modes

| Failure Mode | Trigger Conditions | Manifestation | Detection | Response |
|--------------|-------------------|---------------|-----------|----------|
| [Failure mode 1] | [What causes this failure] | [How it appears in outputs] | [How to detect it occurring] | [What to do] |
| [Failure mode 2] | [Trigger] | [Manifestation] | [Detection] | [Response] |
| [Edge case failures] | [Specific edge cases that fail] | [How they fail] | [Detection approach] | [Handling] |

### 7.3 Conditions Not Covered

| Condition | Reason Not Supported | Risk if Encountered |
|-----------|---------------------|---------------------|
| [Condition 1] | [Why this condition is not supported] | [What could go wrong] |
| [Condition 2] | [Reason] | [Risk] |
| [Future conditions] | [Conditions that may emerge and are not addressed] | [Monitoring needed] |

### 7.4 Uncertainty and Calibration

| Aspect | Current State | Guidance |
|--------|---------------|----------|
| Confidence calibration | [How well calibrated are confidence scores?] | [How to interpret confidence scores] |
| Uncertainty quantification | [Does the model provide uncertainty estimates?] | [How to use uncertainty information] |
| Out-of-distribution detection | [Can the model detect when it is out of domain?] | [How to handle OOD situations] |

---

## Section 8: Recommendations

**Purpose:** Provide actionable guidance for deployers and users of the model.

### 8.1 Deployment Recommendations

| Recommendation | Rationale | Priority |
|----------------|-----------|----------|
| [Integration requirement 1] | [Why this is necessary] | [Required/Recommended] |
| [Monitoring setup] | [Why monitoring is needed] | [Required/Recommended] |
| [Human oversight configuration] | [Appropriate oversight level] | [Required/Recommended] |
| [Input validation] | [What validation to implement] | [Required/Recommended] |

### 8.2 Monitoring Recommendations

| What to Monitor | Method | Alert Threshold | Response |
|-----------------|--------|-----------------|----------|
| [Performance metrics] | [How to measure in production] | [When to alert] | [What to do on alert] |
| [Input distribution] | [Drift detection approach] | [Drift threshold] | [Response to drift] |
| [Error patterns] | [Error analysis approach] | [Error rate threshold] | [Investigation process] |
| [Fairness metrics] | [Ongoing fairness monitoring] | [Fairness threshold] | [Response to fairness issues] |

### 8.3 Human Oversight Expectations

| Oversight Type | Description | When Required |
|----------------|-------------|---------------|
| [Review level] | [Expected human review approach] | [Conditions requiring this level] |
| [Override authority] | [Who can override model decisions] | [When override is appropriate] |
| [Escalation path] | [How to escalate model issues] | [Escalation triggers] |

### 8.4 Maintenance and Updates

| Activity | Frequency | Trigger Conditions | Responsible Party |
|----------|-----------|-------------------|-------------------|
| [Performance review] | [How often] | [Or when triggered by alerts] | [Who] |
| [Retraining consideration] | [How often evaluated] | [Performance degradation threshold] | [Who] |
| [Model card update] | [When updated] | [Any material change] | [Who] |

---

## Implementation Checklist

Use this checklist when completing a model card:

- [ ] Section 1: Model identification complete and accurate
- [ ] Section 2: Intended use defined, out-of-scope uses documented
- [ ] Section 3: Training data documented with known issues noted
- [ ] Section 4: Evaluation methodology documented
- [ ] Section 5: Performance metrics reported with disaggregation
- [ ] Section 6: Fairness analysis complete, ethical considerations documented
- [ ] Section 7: Limitations comprehensively documented
- [ ] Section 8: Deployment and monitoring recommendations provided
- [ ] Model card reviewed by development team
- [ ] Model card reviewed by compliance/ethics team
- [ ] Model card version controlled and linked to model version
- [ ] Update process defined and documented

---

## Related Resources

- [Model Card Glossary Definition](/glossary/model-card)
- [System Card Template](/resources/system-card-template)
- [Annex IV Documentation Guide](/resources/annex-iv-templates)
- [Post-market Monitoring Plan Template](/resources/post-market-monitoring-plan-template)
- [Human Oversight Procedure Playbook](/resources/human-oversight-procedure-playbook)

---

*KLA Digital integrates with your ML documentation workflow to automatically capture model metadata, performance metrics, and governance evidence. Our platform helps maintain living model cards that stay synchronized with production model behavior.*

*Template provided by KLA Digital. Fictional sample. Not legal advice.*