Implementation Kit
AI Documentation Requirements Matrix and Model Card Template
What documentation each system legally needs, and what you can skip. A requirements matrix by risk tier, plus the four templates that matter most: model card, data governance record, bias assessment, and human oversight arrangement.
Who this is for: The compliance owner deciding, per system, what to produce and what is genuinely optional.
1. Documentation requirements matrix
SpreadsheetRequired, recommended, or optional for each document type at each tier.
Template
| Document | High | Moderate (affects people) | Low |
|---|---|---|---|
| Model card | Required | Required | Optional |
| Data governance record | Required | Required | Recommended |
| Bias / fairness assessment | Required | Required | Not needed |
| Human oversight arrangement | Required | Required | Not needed |
| Decision log | Required | Required | Not needed |
| Risk assessment | Required | Required | Optional |
| Change / version history | Required | Required | Basic |
| Conformity assessment / FRIA | If triggered | If triggered | No |
Worked example
| System | Tier | Result of applying the matrix |
|---|---|---|
| Resume Screener | High | Every row required. FRIA triggered (Annex III use). |
| Support Copilot | Moderate (drafts refund decisions) | Model card, data record, bias assessment, oversight arrangement, decision log all required. |
| Ad Copy Generator | Low (no personal data, no decisions) | Model card optional, nothing else. "Why not" recorded in one line. |
Acceptance criteria
- ✓Each system has been placed in a tier and the matrix applied, with the result recorded.
- ✓Where a document is skipped, the reason is written down (one line is enough).
- ✓The matrix cites the regulation behind each "required".
2. Model card template
DocumentThe core system description. One per model, refreshed on material change.
Template
Keep current. A stale model card is a finding.
- Model name and version:
- Owner:
- Intended use, and explicitly out-of-scope use:
- How it works: model type, base model, key parameters
- Training or retrieval data: sources, cut-off, lawful basis, known gaps
- Performance: metrics with dates and the evaluation set
- Bias / fairness evaluation: method, results, thresholds, date
- Limitations and failure modes:
- Human oversight: where a person is in the loop and what they can do
- Monitoring: what is watched in production and at what cadence
- Change history: link to the version log
Worked example
- Model: Resume Screener v2.4.0
- Owner: D. Portillo, Head of Talent
- Intended use: rank inbound applicants 1-5 for recruiter triage. Out of scope: automated rejection, offer decisions.
- How it works: VendorLM-4 base, fine-tuned on 5 years of internal hiring outcomes; deterministic scoring head.
- Data: internal hiring records to 2026-06; lawful basis legitimate interest with applicant notice; known gap: thin data for niche roles.
- Performance: ranking accuracy 0.81 on the 2026-08 holdout set.
- Bias evaluation: adverse-impact ratio by sex and race/ethnicity; lowest 0.88 (2026-08); threshold 0.80.
- Limitations: degrades when a role's requirement mix changes; can over-weight tenure.
- Human oversight: recruiter sees the score, can ignore it; low scores are not auto-filtered as of v2.4.
- Monitoring: monthly adverse-impact check; quarterly accuracy review.
- Change history: registry mdl-resume-screen, version log.
Acceptance criteria
- ✓The card names both intended and out-of-scope use.
- ✓Every performance and bias figure has a date and an evaluation set.
- ✓The card is refreshed whenever the versioning policy creates a new version.
3. Data governance record template
SpreadsheetThe provenance and lawful-basis record for the data a system uses.
Template
| Field | Entry |
|---|---|
| System | |
| Data set / feed | |
| Data categories (incl. special category?) | |
| Source and provenance | |
| Lawful basis | |
| Consent / notice mechanism | |
| Minimization measures | |
| Retention period | |
| Cross-border transfer and mechanism | |
| Data subject rights handling (access, deletion) | |
| Last reviewed |
Worked example
| Field | Entry |
|---|---|
| System | Resume Screener v2.4 |
| Data set | Applicant submissions + 5-yr internal hiring outcomes |
| Data categories | Name, contact, work history, education; special-category data possible in free-text CVs |
| Source | Submitted by applicants via the careers site; HRIS for outcomes |
| Lawful basis | Legitimate interest (recruitment), with applicant notice |
| Consent / notice | Privacy notice section 4, shown at application |
| Minimization | Free-text CV parsed to structured fields; raw CV not used for inference after parsing |
| Retention | Applicant data 12 months post-decision; model training extract anonymized |
| Cross-border | Processing in EU; base model inference in EU region |
| Rights handling | Access and deletion via the DSAR process; model does not retain per-applicant state |
| Last reviewed | 2026-08-30 |
Acceptance criteria
- ✓Special-category data is explicitly flagged yes or no, not left blank.
- ✓The lawful basis is stated and matches the privacy notice.
- ✓The record has a review date and is refreshed when the data set changes.
4. Bias assessment template
DocumentMethod, findings, remediation, and a re-test schedule for any system that affects people.
Template
One per system that makes or informs decisions about individuals.
- System and version:
- Protected attributes assessed: and how they were obtained or inferred
- Metrics used: (e.g. selection-rate ratio, equal opportunity difference), with the threshold for each
- Evaluation data: source, size, time period, representativeness notes
- Results: per attribute, per metric, against threshold
- Findings: where disparity exceeds threshold, and the likely driver
- Remediation: actions taken or planned, with owners and dates
- Residual disparity accepted: by whom, with rationale
- Re-test schedule: cadence and trigger events
Worked example
- System: Resume Screener v2.4.0
- Protected attributes: sex and race/ethnicity, from voluntary EEO self-identification, held separately from the model inputs
- Metrics: adverse-impact ratio (threshold 0.80); score-distribution difference (flag if > 0.1 SD)
- Evaluation data: 12 months of scored applicants, ~38,000 records
- Results: adverse-impact ratio 0.88 (sex), 0.91 (race/ethnicity); score-distribution difference within flag
- Findings: no disparity above threshold this cycle; prior cycle (v2.3) was 0.83 for sex, improved after re-weighting tenure
- Remediation: none required this cycle; keep the tenure-weight cap from v2.3
- Residual disparity accepted: ratio between 0.80 and 0.90 accepted by D. Portillo pending the next cycle
- Re-test schedule: monthly, plus on any model change
Acceptance criteria
- ✓Every metric has a stated threshold set before results are read.
- ✓Findings above threshold have a remediation action with an owner and a date.
- ✓Any accepted residual disparity names who accepted it and why.
- ✓A re-test cadence and trigger events are set.
Governance controls this kit produces evidence for
Completing the artifacts above gives you a head start on the evidence requirements for these controls.
The requirements matrix and templates cover the EU AI Act technical documentation set for high-risk systems.
The data governance record documents training and input data provenance and lawful basis.
The bias assessment template plus its re-test schedule are the fairness monitoring record.
The model card is the explainability documentation for the system.
Applying the matrix requires a documented risk tier per system.
This kit backs one playbook. Read the full guidance for the reasoning behind each artifact.
Decide what to implement next
Assess your governance gaps, then create an action plan with owners and target dates. Build and export without an account; sign in when you want to save your plan.
Start the AI governance assessment →