Document What Each System Is and What It Cannot Do
If someone had to understand this system in ten minutes, what would we hand them?
Baseline: 1Enhanced: 34 controls
Who it applies to
Enter for every AI system. Some of its controls apply only where you train or adapt the model (B1). Go as deep as your system letter, and implement in your mode.
Why it exists
Keep a plain factsheet for every AI system: what it is for, what it was built from, and — above all — where it fails. A model shipped without an honest account of its limits is a trap for everyone who later relies on it, because they will assume it works everywhere until it fails somewhere costly. Two short documents carry most of this: one describing the system — its purpose, its intended and unintended uses, its known weaknesses, how well it performs and on whom — and one describing the data behind it — where it came from, what it contains, what it leaves out. Make both mandatory for any deployed system that matters.
What to actually do
Write, for each significant system, what it is for and what it must not be used for. State the intended use plainly, and state the uses it must not be put to — the second is what stops a tool built for one purpose being quietly repurposed for another it was never validated for. This connects directly to the out-of-scope boundary of the initiative charter in Governance.
Be honest about where it fails and on whom. Record the system’s known limitations and how its performance varies across different groups of people, because a model that works well on average can work badly for a specific group — and if you have not measured and documented that, you will discover it as a fairness complaint. Honesty here is protection, not weakness.
Describe the data behind it. Record where the training and reference data came from, what it contains, and — crucially — what it under-represents, because the gaps in the data become the gaps in the system’s competence and fairness.
Controls
Baseline1 controls
Control 163
Keep a minimal training record for every model you train or adapt.
BaselinePreventivedeveloperper system
What it is
One page: purpose, data used, training method, evaluation result and known limitations.
How to implement it · Minimum structure
Purpose: what the model is trained or adapted to do
Data used: sources, volume, period covered, and whether it contains personal data
Training method: base model and version, adaptation approach, key settings
Evaluation result: test set used, main metric and score
Known limitations: where it performs poorly or must not be used
Owner, date and model version identifier
How to start
Fill the one-page record for the most recent model you trained or adapted, then make it a required step before any model is released.
Evidence
The training record for each model version.
Mode: light / standard / full
light
Whoever ran the training fills a one-page template and stores it with the model files.
standard
The technical lead requires a completed record before a model is promoted to use.
full
The record is generated from the training pipeline's metadata and reviewed by the model governance function before release.
Enhanced3 controls
Control 164
Maintain a system factsheet for every significant deployed AI system.
EnhancedPreventiveall rolesper system
What it is
Purpose, intended and prohibited uses, known limitations, and performance including across groups.
How to implement it · Minimum structure
Purpose and intended users
Intended uses and prohibited uses, matching the out-of-scope boundary of the initiative charter
Model, provider and version; data sources it consults
Known limitations and conditions under which it fails
Performance overall and across the groups of people it affects, where measured
Owner, contact for issues, and date of last update
How to start
Write the factsheet first for the significant system with most effect on people, then for each remaining significant system.
Evidence
The factsheet for each significant system and its update history.
Mode: light / standard / full
light
A two-page factsheet written by the tool's owner, using the provider's documentation for model details and performance.
standard
The system owner writes it before go-live and the governance lead checks the prohibited uses are stated.
full
Factsheets are held in the model and system register, drafted by the product team and approved by model governance.
Control 165
Maintain a data description for every system you build or adapt.
EnhancedPreventivedeveloperper system
What it is
Origin, contents, and what the data under-represents.
How to implement it · Minimum structure
Origin: sources, collection method, period, and permission or licence to use
Contents: record types, volume, fields, personal data present
Population: who is represented and in what proportions
Under-representation: groups, situations or periods that are missing or thin
Known quality issues: errors, inconsistent labels, outdated records
Write the description for the training and reference data of the system you built or adapted most recently, starting with origin and gaps.
Evidence
The data description for each dataset, versioned with the model it supports.
Mode: light / standard / full
light
A two-page template filled by whoever assembled the data and kept with it.
standard
The data owner writes it before training and the technical lead checks the under-representation section.
full
Descriptions are generated partly from data-catalogue metadata and completed and approved by the data governance function.
Control 166
Keep both current across the system’s life.
EnhancedPreventiveall rolesper system
What it is
Updated on model change and when new limitations are found.
How to implement it · Minimum rules
Update triggers: new model or version, new data source, new use, newly found limitation or incident
Planned changes: documents updated before release; unplanned findings within a set period (e.g. 30 days)
Each document carries a version and date, and its change history is kept
Release and change checklists include the factsheet and data description update
The owner confirms both are current at each periodic inventory review
How to start
Add "update the factsheet and data description" as an item on the release and change checklists.
Evidence
Versioned factsheets and data descriptions whose dates match the system's changes.
Mode: light / standard / full
light
The tool's owner updates both documents whenever the provider changes the model or a new limitation is noticed.
standard
The system owner updates them as a release condition and the governance lead spot-checks currency each quarter.
full
The release pipeline blocks deployment when the factsheet or data description version does not match the model version.
Evidence
The minimal training record per model; The system factsheets and data descriptions; their update history; evidence the prohibited-use statements are enforced.