AI FactSheets

Description

AI FactSheets is a documentation practice in which the developer or supplier of an AI model or service answers a structured set of questions about it, modelled on the supplier's declarations of conformity that industries such as telecommunications and transport use to give written assurance, with evidence, that a product meets stated requirements. The questions cover the service's purpose and its intended and unsuitable uses, the datasets it was trained and tested on, its test methods and results (reported for groups such as age bands or genders where relevant), checks for bias, explainability, behaviour on data unlike its training data and robustness to adversarial attack, how user data is secured, and its lineage, such as when and how its models were retrained; 'N/A' and 'Proprietary' are allowed answers. Facts are gathered from the people in each role across the lifecycle (business owner, data scientist, model validator and operations engineer), and any change to the service produces a new version of the FactSheet while earlier versions are kept. The originating group's seven-step method designs the template with its readers: interview the people who will read the facts and those who will produce them, draft and trial a template of questions, have the real producers complete it, evaluate the result with its readers for content and presentation, and build further templates for other audiences such as a review board or regulator. Unlike a model card, which reports one model's intended use and evaluation to the people choosing it, or a datasheet, which describes one dataset, a FactSheet may cover one model or a whole service built from several models and datasets (attaching their datasheets), gathers facts from each role in the lifecycle and has a different template for each audience; unlike a CycloneDX ML-BOM it is written for people to read rather than as a machine-readable parts list for software tools.

Example Use Cases

Transparency

A hospital trust buying a speech-to-text service for clinical dictation sends bidders a FactSheet template asking for intended and unsuitable uses, training data, retraining frequency, behaviour on noisy audio, and word error rates by speaker accent and age band on recordings the trust supplies. The panel compares the answers to shortlist bidders, re-tests the shortlisted services on its own recordings, and writes the confirmed error rates into the contract as service levels.

A bank's model risk team follows the seven-step method to design a FactSheet template for credit models: it interviews validators about the decisions they make and data scientists about the facts they can record, then has the scientists complete it for a new affordability model. Validators read the completed FactSheet's training data, performance, bias checks and known weak cases before deciding whether to approve the model for deployment.

A company selling a sentiment-analysis API publishes a short FactSheet for developers browsing its catalogue, giving the purpose, input and output formats, training data, accuracy and the kinds of text the service handles poorly. From the same facts it generates a longer FactSheet, with a different template, for enterprise customers' risk and compliance reviewers.

A city council's AI ethics review board asks each supplier for a FactSheet in a template written for the board, covering training and test data distributions, data handling, the inputs the service handles poorly and possible sources of unfair outcomes. The board reads them before deciding whether a photo-based street-repair reporting service may go live.

Limitations

A FactSheet is the supplier's own declaration. As with the declarations of conformity it imitates, the supplier runs the tests it reports and nothing in the format checks them, so it shows what was claimed rather than that the claims hold. A buyer who relies on a declared figure has to re-test the service or ask for third-party testing, which the original proposal expects only for the highest-stakes, regulated, enterprise and public-sector applications.
Facts not recorded while the service is built are hard to recover. In IBM's own trials, developers forgot how they had transformed training data or which settings they had tried, and recovering the training-data transformations for one FactSheet took several hours over two days although the dataset was small and its author was available. A FactSheet written after development is likely to have gaps or errors unless fact collection is part of the development process.
The format accepts 'N/A' and 'Proprietary' as answers. In IBM's trials most developers assumed bias would not be an issue and marked bias questions not applicable, even where further questioning showed it could be, and participants were unsure how much detail they could give without losing competitive advantage. An unchallenged 'N/A' can hide a risk nobody examined, and items withheld as proprietary are often the ones a buyer would need in order to check the self-declared results.
There is no single FactSheet. Its authors hold that one template cannot serve every audience and domain, and developers report the metrics conventional for their kind of model, so FactSheets from different suppliers often cannot be compared unless the buyer fixes the questions, metrics and test conditions in its own template.
Whether readers understand FactSheets and decide better with them is untested. Producers in IBM's studies found it hard to know what readers needed and often left out what a less expert reader would need. The design method checks a draft with a few intended readers, and the group's later case studies report that producers could follow it, but none of these sources tests whether buyers, validators or review boards read FactSheets correctly or make better decisions with them.

Resources

Research Papers

FactSheets: Increasing trust in AI services through supplier's declarations of conformity

M. Arnold et al.•Jul 1, 2019

Software Packages

ibm-aigov-facts-client

FactSheetService ML facts collection utility

Tutorials

A Methodology for Creating AI FactSheets

John Richards et al.•Jun 28, 2020

As AI models and services are used in a growing number of highstakes areas, a consensus is forming around the need for a clearer record of how these models and services are developed to increase trust. Several proposals for higher quality and more consistent AI documentation have emerged to address ethical and legal concerns and general social impacts of such systems. However, there is little published work on how to create this documentation. This is the first work to describe a methodology for creating the form of AI documentation we call FactSheets. We have used this methodology to create useful FactSheets for nearly two dozen models. This paper describes this methodology and shares the insights we have gathered. Within each step of the methodology, we describe the issues to consider and the questions to explore with the relevant people in an organization who will be creating and consuming the AI facts in a FactSheet. This methodology will accelerate the broader adoption of transparent AI documentation.

Documentations

Using AI Factsheets for AI Governance

Track a machine learning model from request to production by gathering metadata and facts about the model lifecycle using AI Factsheets. Use the detailed information in the factsheets to keep stakeholders informed and to meet your governance and compliance goals. Factsheets can be shared, archived, or printed as report.

Related Techniques

Name	Description	Assurance Goals
CycloneDX Machine Learning Bill of Materials	A CycloneDX ML-BOM (machine-learning bill of materials) is a machine-readable inventory of what a model is made of, written in the CycloneDX standard (ECMA-424) so that tools as well as people can check it. It applies the software bill of materials, a structured list of the components in a piece of software, to models: the model is declared as a component of type machine-learning-model with its identifiers, version, supplier, licence and file hashes, together with the base models it was derived from (its pedigree), the datasets used to train and evaluate it with their source, classification and owners, the libraries it depends on, and an optional structured model card giving its task, architecture, performance metrics, intended uses and known limitations. The BOM is written at release, by hand or with a generator that reads the model's repository and metadata, checked against the CycloneDX schema, and can be signed. Consumers then query it, for example to find every deployed model that uses a dataset or library found to be compromised, or to check a supplier's declared datasets and licences before purchase. Unlike a model card or datasheet, written for people to read, or an experiment log or data version history, which stay with the team that built the model, it is a parts list in a fixed schema that travels with the model and can be matched against vulnerability records and file hashes, but it records what its author declares and verifies none of it.	Security Transparency
UK Algorithmic Transparency Recording Standard Record	An Algorithmic Transparency Recording Standard (ATRS) record is a public account that a UK public sector organisation writes about one algorithmic tool it uses, on the UK government's standard template, and publishes in a central repository on GOV.UK. The template has two tiers: a short plain-language summary for the general public (what the tool is, why it is used and a contact), and eight further sheets for specialist readers such as journalists, researchers and civil society, covering who is accountable for the tool and which suppliers were involved, how it works and what it replaced, how its output feeds into decisions, when a person reviews that output, how members of the public can appeal, the system's and each model's inputs, outputs, architecture and performance (including any bias testing), the data used, and the impact assessments, risks and mitigations. Information that would be exempt under the Freedom of Information Act can be left out or summarised field by field, with the reason stated, and the record is cleared by the tool's team, its senior responsible owner (the role accountable for the tool) and the press office, checked for readability by the central ATRS team, and updated when the tool changes substantially or is retired. Publishing is mandatory for central government departments and for arm's-length bodies that deliver public or frontline services or deal directly with the public, for tools in beta, pilot or production that significantly influence decisions affecting the public or interact with it directly; other public bodies may publish voluntarily. Unlike a model card, written by a developer for people choosing a model, or a supplier's AI FactSheet for buyers, an ATRS record is written by the deploying public body for the public and describes the decision process, human review and appeal routes around the tool as well as the tool.	Transparency
Datasheets for Datasets	A datasheet for a dataset is a short document that accompanies the dataset and answers a set of questions about it, in the way an electronic component comes with a datasheet. Gebru and colleagues group the questions into seven sections: why the dataset was made, what it contains, how it was collected, how it was cleaned and labelled, what it should and should not be used for, how it is distributed, and who maintains it. Creators read the questions before collecting data, answer them when the dataset is finished, and update the sheet when the dataset changes. People considering the dataset read it to judge whether it suits their task and what risks it carries. The questions are a prompt rather than a checklist, and a datasheet records what is known without testing it.	General Safety Transparency