Deployment Corrections: An incident response framework for frontier AI models

TL;DR

This paper proposes a comprehensive incident response framework for deploying frontier AI models, emphasizing deployment corrections to mitigate catastrophic risks after deployment, inspired by cybersecurity practices.

Contribution

It introduces a toolkit and framework for AI developers to respond to dangerous AI behaviors post-deployment, and recommends industry-wide standards and practices.

Findings

Deployment corrections can mitigate risks from dangerous AI behaviors.

A structured incident response framework improves safety management.

Recommendations for industry collaboration and standardization.

Abstract

A comprehensive approach to addressing catastrophic risks from AI models should cover the full model lifecycle. This paper explores contingency plans for cases where pre-deployment risk management falls short: where either very dangerous models are deployed, or deployed models become very dangerous. Informed by incident response practices from industries including cybersecurity, we describe a toolkit of deployment corrections that AI developers can use to respond to dangerous capabilities, behaviors, or use cases of AI models that develop or are detected after deployment. We also provide a framework for AI developers to prepare and implement this toolkit. We conclude by recommending that frontier AI developers should (1) maintain control over model access, (2) establish or grow dedicated teams to design and maintain processes for deployment corrections, including incident response plans, and (3) establish these deployment corrections as allowable actions with downstream users. We also recommend frontier AI developers, standard-setting organizations, and regulators should collaborate to define a standardized industry-wide approach to the use of deployment corrections in incident response. Caveat: This work applies to frontier AI models that are made available through interfaces (e.g., API) that provide the AI developer or another upstream party means of maintaining control over access (e.g., GPT-4 or Claude). It does not apply to management of catastrophic risk from open-source models (e.g., BLOOM or Llama-2), for which the restrictions we discuss are largely unenforceable.