FactSheets: Increasing Trust in AI Services through Supplier's Declarations of Conformity

• High-stakes AI deployments require trust dimensions beyond accuracy, including fairness, explainability, safety, security, and transparency.Source: §1 · pp. 1–2
• FactSheets adapt supplier declarations of conformity to document an AI service’s intended use, performance, safety, security, creation, testing, deployment, and ethical concerns.Source: §1 · pp. 1–2
• FactSheets are intended to ground services in metrics and usage scenarios, helping prevent overgeneralization and unintended use.Source: §1 · p. 2
• The proposal focuses on the final AI service because developers consume an API that may combine multiple models and datasets.Source: §1 · pp. 1–2
• The authors present a starting point rather than a definitive item set, expecting requirements to vary by context and stakes and requiring multi-stakeholder standardization.Source: §1 · p. 2

2.1 Transparency in AI

• Prior AI transparency work documents datasets and models, whereas FactSheets target the final service and extend trust beyond ethical principles to robustness and reliability.Source: §2.1 · p. 3

2.2.4 Software

• Software certification precedents include security testing, developer questionnaires, reliability prediction, release-readiness reviews, compliance checks, and secure-coding audits.Source: §2.2.4 · p. 4

2.2.6 Human Subjects

• Human-subjects review boards provide structured requirements covering purpose, participants, procedures, harms, benefits, confidentiality, and consent.Source: §2.2.6 · p. 5

2.2 Enabling Trust in Other Domains

• Standards and trust mechanisms in other domains use voluntary declarations, mandatory disclosures, third-party validation, certification, or structured impact statements.Source: §2.2.1 · p. 3, §2.2.2 · p. 3, §2.2.3 · p. 4

2.2.7 Summary

• The related-domain survey suggests that voluntary disclosure may suit emerging requirements, while mature requirements may support mandatory external validation.Source: §2.2.7 · p. 5

3 Elements of Trust in AI Systems

• Trust requires lifecycle safety and reliability practices, AI-specific risk management, and standardized tests with transparent reporting.Source: §3 · p. 5

3.1 Basic Performance and Reliability

• Performance reporting should standardize metrics and testing conditions, while also covering consumer-relevant categories such as age, geography, and gender.Source: §3.1 · pp. 5–6

3.2 Safety

• Safety assessment must address epistemic uncertainty from mismatched training and operational distributions through strategies such as safe design, safety reserves, safe fail, and procedural safeguards.Source: §3.2 · p. 6
• Fairness evaluation depends on context-specific protected attributes and definitions, and fairness metrics lack immutable thresholds that apply independently of context.Source: §3.2 · p. 6

3.3 Security

• AI security concerns include adversarial perturbations, poisoned data or models, and information theft from service outputs.Source: §3.3 · p. 7

3.4 Lineage

• Lineage records should support auditing and reproduction by tracking service versions, retraining, hyperparameters, datasets, evolving metrics, feedback, and retraining triggers.Source: §3.4 · p. 7

• FactSheet items span purpose, performance, safety, security, lineage, data, algorithms, testing methods, results, deployment, and maintenance.Source: §4 · p. 7
• FactSheets should help users determine whether a service fits its intended application and understand its strengths and limitations.Source: §4 · p. 7
• The item set is non-definitive and may omit inapplicable questions or withhold proprietary algorithm details while still reporting algorithm class, outputs, and explanations.Source: §4 · p. 7
• Questions address intended use, algorithms, test datasets, testing methodology, test results, bias, explainability, unseen-data performance, adversarial robustness, and model-update timing.Source: §4 · p. 7
• As testing procedures become codified, FactSheets may reference standardized protocols instead of repeating descriptive testing details.Source: §4 · p. 8
• FactSheets are created once, augmented without deleting prior results, and versioned as immutable artifacts when services change.Source: §4 · p. 8

5 The Evolution of FactSheet Adoption

• FactSheets are initially voluntary so multiple parties can refine their items and format while balancing consumer needs with producers’ freedom to innovate.The authors expect market feedback from consumers to encourage producers to create them.Source: §5 · p. 8
• FactSheets could reduce information asymmetry by making intended use, performance, fairness, explainability, safety, and security easier for consumers to assess.The authors connect this transparency to better marketplace functioning and avoiding a market for lemons.Source: §5 · p. 8
• Adoption could eventually lead to third-party certification, especially for highest-stakes, regulated, enterprise, and public-sector applications.For regulated industries, FactSheets could also support compliance.Source: §5 · p. 8

6 Discussion and Future Work

• AI services create greater transparency demands than conventional software because generated code may be difficult to understand and lacks comparable supporting artifacts.The proposed FactSheets are intended to provide transparency about service intent and construction.Source: §6 · p. 8
• FactSheets cannot fully prevent consumers from using services for unintended purposes, although they can inform decisions and support service-level agreements.The limitation applies to both innocent and malicious misuse.Source: §6 · p. 8
• Composed services need FactSheets to incorporate information from external suppliers and track the provenance of that information across organizations.Component FactSheets could help composing organizations assemble a complete service FactSheet.Source: §6 · pp. 8–9

7 Summary and Conclusion

• FactSheets are proposed as voluntary, transparent declarations documenting AI service performance, safety, security, provenance, and maintenance to help people trust services.The proposal adapts supplier declarations of conformity from consumer products to AI services and requires further discussion to standardize testing protocols, items, and format.Source: §7 · p. 9

A Proposed FactSheet Items

• The proposed FactSheet questions are explicitly non-definitive, intended to open discussion about which aspects of an AI service should be documented.Two fictitious examples—a fingerprint verification service and a trending topics service—illustrate the information sought, rather than fully characterizing real APIs.Source: A Proposed FactSheet Items · pp. 11–12

Statement of purpose

• FactSheets ask suppliers to identify their service, outputs, algorithms, development team, releases, updates, intended use, operating procedures, and target users.They also accommodate answers such as “N/A” and “Proprietary” when information is inapplicable or cannot be publicly disclosed.Source: Statement of purpose · p. 12, General · p. 12

Domains and applications

• FactSheets document application domains, customer usage, human oversight, model training options, decision-making speed, prior applications, and key performance results.The questions distinguish cloud services from end-user applications and whether outputs are used directly, passed to another tool, or reviewed by humans.Source: Usage · p. 12, Domains and applications · p. 12

Basic Performance

• Performance questions require tested datasets, dataset documentation, train/test details, metric choices, results, and operational measures such as latency, throughput, and availability.They also ask whether datasets can support independent testing and whether third parties can verify metrics through APIs or public benchmarks.Source: Basic Performance · p. 13, Testing by service provider · p. 13, Testing by third parties · p. 13

Safety

• Safety questions address bias, ethical risks, consent, potential harms, redress, rights, withdrawal options, and mitigation of risks affecting individuals or groups.The declaration should identify where bias or unfairness arises and how trade-offs between individual rights and business interests are handled.Source: Safety · p. 13, General · pp. 13–14

Explainability

• Explainability questions require describing how outputs are explained, who explanations target, and whether humans validated the algorithms’ explainability.Possible approaches include directly explainable algorithms, local explanations, and example-based explanations.Source: Explainability · p. 14

Fairness

• Fairness questions require dataset bias checks, representativeness assessments, protected-attribute analyses, disparate error rates, and documentation of remediation before and after intervention.They also request the techniques used for remediation and links to relevant technical papers.Source: Fairness · p. 14
• FactSheets should state whether the service implements and performs bias detection and remediation.Source: Fairness · p. 14
• Providers should describe model-bias policies, checking methods, results, and references to corresponding technical papers.Source: Fairness · p. 14
• Providers should report bias estimates before and after remediation and explain how other performance metrics changed.Source: Fairness · p. 14

Concept Drift

• FactSheets should document testing for unseen or distribution-shifted data, including relevant test results and checks for differences between training and usage data.The questions also include checking whether outputs remain correct when new data is added.Source: Concept Drift · pp. 14–15
• FactSheets should ask how services are tested and monitored for model or performance drift over time.They also ask whether services update behavior from newly ingested data and whether guarantees or bounds exist.Source: Concept Drift · pp. 14–15
• FactSheets should report periodic testing for bias or fairness and describe mechanisms that alert users to relevant changes.The proposed questions also distinguish automated feedback or retraining loops from human-in-the-loop updates.Source: Concept Drift · p. 15

Security

• FactSheets assess susceptibility to deliberate harms by asking about adversarial robustness, attack methods, abuse scenarios, and security-breach response.They also ask suppliers to describe robustness policies, considered attacks, checking methods, and results.Source: Security · p. 15
• Suppliers should identify unsuitable applications and sensitive uses, plus procedures intended to prevent those uses.The questions explicitly connect misuse boundaries with access-control and other application scenarios.Source: Security · p. 15
• FactSheets document how user and usage data are secured, including sharing, access, storage, and retention practices.These questions make data-handling arrangements part of the service’s security description.Source: Security · p. 15

Lineage

• Lineage questions preserve details needed for third-party audits when harm or suspected harm occurs.The stated purpose is to keep track of service information that may be required during an audit.Source: Lineage · p. 15

Training Data

• FactSheets ask which datasets trained the service and whether they were built for purpose, repurposed, transformed, or supplemented with synthetic data.Suppliers should describe synthetic-data creation and properties and list the training datasets.Source: Training Data · pp. 15–16
• For each dataset, suppliers should report quality-assurance processes, public availability or sources, and whether a datasheet or data statement exists.These items expose dataset provenance and documentation status.Source: Training Data · p. 16
• FactSheets should attach dataset datasheets when available or answer corresponding datasheet questions as appropriate.This links service-level documentation to existing dataset documentation practices.Source: Training Data · p. 16

Trained Models

• The trained-model section asks how models were trained, including specific details, update timing, performance change, retraining frequency, and prior data weighting or knowledge.Together these questions describe model development and maintenance rather than only the final model output.Source: Trained Models · p. 16

Statement of purpose

• The service accepts 500 dpi fingerprint images and identities, returns a binary match label, and targets access-control manufacturers and related entities through a cloud API.The current algorithm v1.7 was created on April 12, 2010, and released as a cloud service on August 10, 2017.Source: General · p. 17

Usage

• In the stated use case, a user’s fingerprint and seven-digit identifier are sent through a RESTful API, and a positive match directly unlocks an access-control system.The service output is returned to the access-control system and can be fed directly into an actuator with only a small delay.Source: Usage · pp. 17–18, Domains and applications · p. 18

Domains and applications

• Testing covered fingerprint verification for call-center employees without domain-expert involvement, while prior applications included call-center and bank access control.The service is a cloud offering for access-control manufacturers; users rely on pre-trained models and upload identifier databases with fingerprints.Source: Domains and applications · p. 18

Testing by service provider

• EER = 3.7%, FMR100 = 6.0%, ZeroFMR = 12.4%, RejENROLL = 0.0%, RejMATCH = 0.0%, with average enrollment and matching times of 0.14 sec and 0.44 sec.Metrics were evaluated on a held-out set using FVC2002 evaluation measures, including EER, FMR100, FMR1000, ZeroFMR, RejENROLL, and RejMATCH.Source: Testing by service provider · pp. 18–19

Safety

• The FactSheet identifies poorer verification performance for manual laborers and children, inability to serve people without fingerprints, and no redress mechanism.These disclosures frame potential bias and safety risks affecting particular groups and individuals.Source: Safety · p. 19, General · p. 19
• Training data came from publicly available FVC2000, FVC2002, and FVC2004 fingerprint databases, without further due diligence.The provider identifies FVC2002 DB1 as independently testable, although it has no associated datasheet.Source: Testing by service provider · p. 18, General · p. 20

Explainability

• The FactSheet asks providers to explain how algorithms achieve explainability, identify the explanation’s target user, and describe human validation.Source: Explainability · p. 20

Fairness

• The FactSheet requests dataset and model bias policies, checking methods, disparate error rates, remediation procedures, before-and-after estimates, technical references, and resulting performance changes.Source: Fairness · p. 20
• The service showed no systematic differential performance across younger and older adults, male and female users, and varied skin tones; no bias remediation was performed.Source: Fairness · p. 20

Concept Drift

• Performance can degrade with different sensor types or with users whose hands have frequent cuts.The service description also states that general fingerprint characteristics do not change over time.Source: Concept Drift · p. 21
• The service plans to capture customer-deployment data and retrain the algorithm with additional images for v1.8.Earlier material states that no new data had been added through v1.7, making v1.8 the stated next update.Source: Concept Drift · p. 21
• The service is monitored through quarterly deployment spot checks, although metric evolution over time is confidential.The stated checks involve enrolling and testing a few people at customer deployments.Source: Concept Drift · p. 21

Security

• The service should be used only for access control, not crime investigation or prosecution, but no procedures prevent those prohibited uses.This example shows why FactSheets record both intended boundaries and enforcement arrangements.Source: Security · p. 21
• Usage data are generally not stored, except with explicit negative-feedback consent for retraining, after which samples are deleted.The security questions also ask how data are stored, for how long, shared, and accessed.Source: Security · p. 22
• The FactSheet security example reports that model-inversion and hillclimbing attacks were tested and that the service passed those tests.The tests used techniques from a cited fingerprint-verification security study.Source: Security · p. 22
• The security-breach response plan calls for immediately shutting down the service after a potential breach and restoring customer access only after site visits.Source: Security · p. 22

Lineage

• Lineage questions are intended to preserve details needed for third-party audits in cases of harm or suspected harm.This connects ongoing service records with accountability beyond performance monitoring.Source: Lineage · p. 22

Training Data

• FactSheets ask suppliers to identify training datasets, their sources, availability, and links to publicly accessible data.They also request datasheets or data statements for each dataset.Source: Training Data · p. 22
• A fictitious example reports internet-sourced FVC2000, FVC2002, and FVC2004 optical fingerprint databases, provider-led quality assurance, and purpose-built evaluation data.Source: Training Data · p. 22
• Suppliers should report whether datasets were transformed, synthetic, purpose-built, repurposed, and subject to quality assurance before use.Synthetic-data reporting includes when and how the data was created, its properties, and the datasets involved.Source: Training Data · pp. 16, 22, 23

Trained Models

• FactSheets ask how models were trained, including specific training details and any prior knowledge or data reweighting used.Source: Trained Models · p. 23
• Suppliers should report when models were last updated, how performance changed, and how often models are retrained or updated.Source: Trained Models · p. 23

General

• The service identifies, searches, and monitors trending topics across social media, news media, and scientific publications, returning ranked topics with triggering phrases, timestamps, and related topics.It was first released in January 2014, last updated in June 2018, and serves broad users including companies monitoring brands and media organizations modeling events.Source: General · p. 24
• DataTrendly combines common and proprietary techniques, including ARMA and neural networks for forecasting and proprietary sudden-change detection tailored to social media data.Users can select techniques and compare results; the known-technique implementation builds on Seabold and Perktold (2010).Source: General · p. 24
• The FactSheet is updated with every service update, typically every 6 months, covering changes to purpose, performance, safety, and lineage sections.Previous versions are available at a URL referenced by the provider.Source: General · p. 25

Usage

• Clients provide platforms and event-related key-phrases, receive relevant trending topics for each platform, and inspect related phrases, messages, and topics.A sports-tournament monitoring use case illustrates tracking different time intervals and attention patterns across multiple social media platforms.Source: Usage · p. 25

Domains and applications

• The service supports brand and event monitoring for media companies and is integrated into customers’ monitoring platforms, with qualitative validation encouraged before media, marketing, or crisis-management decisions.Customers understand brand and event context, while specific application details are customer-proprietary.Source: Domains and applications · pp. 25–26

Testing by service provider

• 2s is the service’s maximum latency between receiving a query and producing a result, with latency, throughput, and availability treated as critical metrics.The provider releases annual benchmarks and datasheets for popular trends, evaluates forecasts with scale-dependent, percentage, and scaled error metrics, and checks residuals for systematic trends and autocorrelation.Source: Testing by service provider · pp. 26–27

Testing by third parties

• Third parties can independently verify performance mainly as customers or through released year-end trend data, because customer work remains inaccessible for confidentiality and business reasons.The service does not report testing by named external parties in the supplied passage.Source: Testing by third parties · p. 27

Safety

• The safety section frames potential harms around bias, ethical issues, and other risks, including whether they originate in data, techniques, or other sources.The supplied passage introduces these questions but does not provide the provider’s substantive answers.Source: Safety · p. 27, General · p. 27

General

• The service analyzes content rather than individuals, blocks suspected harmful key-phrases, and acknowledges that evolving social-media biases limit interpretation of its outputs.The provider recommends qualitative analysis and comparison of trends across multiple platforms.Source: General · pp. 27–28

Explainability

• The service does not provide explicit explanations for its inferences.Source: Explainability · p. 28

Fairness

• The provider reports platform socio-demographic statistics and discusses output interpretation with customers but performs no independent bias checks.Source: Fairness · pp. 28–29

Concept Drift

• The service builds a different model for each customer query in real time and tracks performance metrics by use case to detect variations as social-media data characteristics change.Source: Concept Drift · p. 29

Security

• The subscription design controls traffic, rejects ethically questionable monitoring requests, stores tenant usage data for 2 weeks in encrypted form, and promises immediate notification after a breach.Source: Security · p. 30

Lineage

• The FactSheet’s lineage questions cover audit-relevant records of service and data provenance.Source: Lineage · p. 30

Training Data

• No fixed training dataset is used: models are built per use case and trend from time series generated by customer-submitted queries.Source: Training Data · p. 30
• The service does not release customer-engagement data, releases only year-end popular-trend data and results, and prepares datasheets for every release.The FactSheet also asks providers to link publicly available datasets or their sources and identify whether each dataset has a datasheet or data statement.Source: Training Data · pp. 30–31

Trained Models

• Forecasts use historical behavior from the target trend and related trends, with related-trend inputs automatically extracted, hand-selected by customer-team experts, or both; each use-case and trend receives a separate model.In some cases, models incorporate historical time series selected by domain experts because they are expected to relate to the trends of interest.Source: Trained Models · p. 31