# 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. Source playbook: https://aigovernance.com/playbook/ai-documentation-requirements --- ## Documentation requirements matrix _Required, 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". --- ## Model card template _The 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. --- ## Data governance record template _The 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. --- ## Bias assessment template _Method, 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 - **CMP-007**: The requirements matrix and templates cover the EU AI Act technical documentation set for high-risk systems. - **DGC-001**: The data governance record documents training and input data provenance and lawful basis. - **MON-003**: The bias assessment template plus its re-test schedule are the fairness monitoring record. - **ALC-004**: The model card is the explainability documentation for the system. - **HOC-001**: Applying the matrix requires a documented risk tier per system.