Researchers from OpenAI, Google Brain, Intel and 28 other organisations proposed a practical “toolbox” for verifying AI ethics claims in April 2020. Their argument was straightforward: statements about fairness, safety and privacy meant little without mechanisms capable of testing them.
The paper moved the debate beyond voluntary principles. It asked what evidence a developer could provide when claiming that a system was safe, unbiased or responsibly governed.
Principles Needed Proof
The authors compared AI assurance with aviation. Passengers did not trust an aircraft manufacturer because it advertised safety; they trusted a web of standards, engineering practice, records and independent institutions.
AI required comparable infrastructure. A public commitment to avoid bias did not show whether a system had been evaluated across groups, whether developers had investigated failures or whether an external party could challenge the result.
Evidence had to be specific to the system and its intended use.
Bias Bounties Could Reward Discovery
One proposal adapted the cybersecurity bug bounty. Developers, researchers or users could be rewarded for identifying bias and safety problems in an AI system.
Such a programme created an incentive to find weaknesses before they harmed people at scale. It could extend to privacy, interpretability and security as well as discrimination.
A bounty required clear rules. Researchers needed safe-harbour protection, responsible disclosure channels and assurance that reporting a flaw would lead to remediation rather than retaliation.
Red Teams Could Challenge Assumptions
The paper also endorsed red teaming: assigning people to think like an attacker or adversarial user and search for vulnerabilities.
In AI, a red team might test prompt injection, discriminatory outputs, data leakage or dangerous instructions. It could examine not only a model but also the interface, access controls and organisational incentives around it.
Internal red teams were useful, but independent testing added credibility because an organisation had reasons to present its own work favourably.
Third-Party Audits Needed Access
External auditing could counter the limits of self-reporting, provided auditors had meaningful information. A review based solely on a vendor’s marketing materials could not verify much.
Auditors might need controlled access to documentation, evaluation data, model behaviour and incident records. Confidentiality and intellectual property were legitimate concerns, but they could not become blanket reasons to prevent scrutiny.
Standards for auditor competence and independence were still immature, making this an area for regulators, academia and professional bodies to develop.
Audit Trails Preserved the Decision History
The researchers recommended audit trails covering the development lifecycle. Like a flight recorder, a useful trail could show what data was used, which model version was deployed, who approved a change and what happened after an incident.
Records did not prevent failures. They made failures investigable and helped organisations correct them.
For high-risk systems, traceability also supported an affected person’s ability to challenge a decision.
Privacy-Preserving ML Offered Another Layer
The paper highlighted federated learning, differential privacy and encrypted computation. These methods could limit exposure of sensitive training or evaluation data.
They were not a substitute for lawful purpose, consent or good security. A privacy-preserving technique could still support an unfair or unnecessary application.
Used well, however, they allowed developers to test and learn while reducing some of the risks created by centralising personal data.
Assurance Had to Be Proportionate
Not every spelling suggestion required the same assessment as a medical triage system. The authors’ approach allowed safeguards to scale with consequence.
High-impact deployments could require external review, extensive testing and ongoing monitoring. Lower-risk tools could use lighter documentation and internal checks.
This avoided treating all AI as equally dangerous while still recognising that claims about ethics were strongest when independently tested.
A Toolbox Was Not a Compliance Shortcut
Any method could become a box-ticking exercise. A company might run a red team but ignore its findings, or publish a model card that omitted damaging results.
The value of the toolbox depended on incentives. Leaders needed to fund remediation, boards needed oversight, and regulators needed the ability to act when evidence showed a serious problem.
People affected by systems also needed routes to report harm that formal tests had missed.
The Paper Shifted Ethics Toward Assurance
The proposal’s lasting value was its insistence that trust required more than good intentions. Bias bounties, red teams, audits, audit trails and privacy methods gave organisations concrete ways to substantiate their promises.
No single tool could prove an AI system was ethical. Together, they could make claims more contestable and failures more visible.
The enduring lesson was that responsible AI needed infrastructure. Ethical principles became credible only when organisations were willing to expose them to evidence, external challenge and continuous improvement.
