This page is still being polished. If you have thoughts, please share them via the feedback form.
Data on this page is preliminary and may change. Please do not share or cite these figures publicly.
Cryptographic protections, access controls, and hardware security.
Also in Non-Model
Make alterations to AI hardware (primarily AI chips), that enable verifying or controlling the usage of this hardware.
Examples of on-chip mechanisms being researched are: - Chip odometers and auto-deactivation: Chips could record how much they’ve been used (e.g. how many floating point operations have been executed). They would stop working after a certain amount of use, and require reactivation with a cryptographic key. This key could be automatically issued if their usage is compliant with AI regulations. Such features could be useful for deactivating export-controlled chips that have been found to be smuggled to a prohibited party. - [Approximate location verification](https://www.iaps.ai/research/location-verification-for-ai-chips): Chips could solve timed cryptographic challenges to servers located at different points around the world, with their response times proving where roughly in the world they are. This could be used as part of chip reactivation criteria. - Usage logging: Secure logging of key events during AI model training and deployment could enable auditing of AI development processes. This could enable enforcement of future international treaties that might ban dangerous AI development (in the same way that advances in verifying compliance with the test ban enabled the [Comprehensive Nuclear-Test-Ban Treaty](https://en.wikipedia.org/wiki/Comprehensive_Nuclear-Test-Ban_Treaty)). One such scheme this could support is described in the [What does it take to catch a Chinchilla?](https://arxiv.org/pdf/2303.11341) paper. Sharing some usage logs could also be a condition of getting chips reactivated. - Model authentication: Chips could verify that only properly vetted AI models are executed on them, similar to [code signing](https://en.wikipedia.org/wiki/Code_signing). This could prevent the deployment of models that haven't undergone safety testing or certification. - Content provenance: See the [content provenance](https://adamjones.me/blog/ai-regulator-toolbox/#content-provenance) section.
Reasoning
Hardware modifications enable cryptographic controls and usage verification of AI chips through security mechanisms.
Compute goverance
Regulate companies in the highly concentrated AI chip supply chain, given AI chips are key inputs to developing frontier AI models.
3.1.1 Legislation & PolicyData input controls
Filter data used to train AI models, e.g. don’t train your model with instructions to launch cyberattacks.
1.1.1 Training DataLicensing
Require organisations or specific training runs to be licensed by a regulatory body, similar to licensing regimes in other high-risk industries.
3.1.4 Compliance RequirementsSafety cases
Develop structured arguments demonstrating that an AI system is unlikely to cause catastrophic harm, to inform decisions about training and deployment.
2.2.4 Assurance DocumentationEvaluations (aka “evals”)
Give AI systems standardised tests to assess their capabilities, which can inform the risks they might pose.
2.2.2 Testing & EvaluationRed-teaming
Perform exploratory and custom testing to find vulnerabilities in AI systems, often engaging external experts.
2.2.2 Testing & EvaluationThe AI regulator’s toolbox: A list of concrete AI governance practices
Jones, Adam (2024)
This article explains concrete AI governance practices people are exploring as of August 2024. Prior summaries have mapped out high-level areas of work, but rarely dive into concrete practice details. This summary explores specific practices addressing risks from advanced AI systems. Practices are grouped into categories based on where in the AI lifecycle they best fit. The primary goal of this article is to help newcomers contribute to the field of AI governance by providing a comprehensive overview of available practices.
Other (stage not listed)
Applies to a lifecycle stage not captured by the standard categories
Infrastructure Provider
Entity providing compute, platforms, or tooling for AI systems
Govern
Policies, processes, and accountability structures for AI risk management
