Back to Dashboard
7.2 Deployment Corrections
Original Problem in the Paper
Paper motivation/open problem: when flaws are found in a deployed model, it is beneficial to respond to identified risk from previously unobserved capabilities or post-training enhancements such as fine-tuning. O’Brien et al. call these post-deployment responsive actions “deployment corrections”; Reuel, Bucknall, et al. say the topic has “scope for much greater exploration from a technical perspective.” The paper lists open technical questions around five correction types: user-based restrictions, access-frequency limits, capability/feature restrictions, use-case restrictions, and model shutdown. It also highlights the need to minimize disruption if shutdown is necessary and to reconcile corrections or model changes with stability/backward compatibility for reproducibility, replicability, and downstream services.
July 2026 Update & Trajectory
Operational practices exist inside frontier-lab policies and NIST GenAI Profile actions: post-deployment monitoring, incident response/recovery, deactivation/disengagement criteria, release gating or iterative deployment, ASL/CCL or High/Critical capability thresholds, model-specific safeguards, usage-policy enforcement, and release decision governance. In the cited evidence, most non-EU correction practices are voluntary or provider-specific, while the EU AI Act creates binding obligations for covered systems: post-market monitoring and serious-incident reporting for high-risk AI systems, and risk-assessment/mitigation obligations for GPAI models that meet systemic-risk criteria. The sources reviewed here show deactivation and incident-response planning, safeguards, and frontier safety frameworks; they do not establish validated cross-provider correction playbooks or disruption-minimizing rollback/shutdown protocols for API ecosystems, open weights, fine-tuned derivatives, or third-party dependencies.
Deployed / Operationalized
- NIST GenAI Profile includes procedures for responding to and recovering from previously unknown risk; mechanisms and assigned responsibilities to supersede, disengage, or deactivate AI systems; stakeholder communication plans for deactivation/disengagement, including open-source models; criteria for deactivation; post-deployment monitoring; post-mortems; incident tracking; and reporting incidents under legal requirements.
- OpenAI’s Preparedness Framework operationalizes deployment gating through threshold-and-safeguard decisions. The 2023 beta framework used a pre/post-mitigation Scorecard and allowed deployment only at post-mitigation Medium-or-below risk; the April 2025 v2 framework instead focuses on High/Critical capability thresholds, Capabilities Reports, Safeguards Reports, and Safety Advisory Group review.
- Anthropic Claude Opus 4/Sonnet 4 system card operationalizes RSP/ASL release decisions: Opus 4 was deployed under ASL-3 and Sonnet 4 under ASL-2; Anthropic describes ASL-3 safeguards for Opus 4, monitoring systems, incident-response protocols, automated and human monitoring, external red-teaming/validation, usage-policy evaluations, and a bug bounty program.
- Google DeepMind Frontier Safety Framework operationalizes Critical Capability Levels, periodic early-warning evaluations, and mitigation plans when early-warning evaluations are passed; the described mitigations focus primarily on security and deployment restrictions for critical capabilities, and the framework is presented as exploratory rather than as a validated shutdown/rollback playbook.
- EU AI Act requires providers of high-risk AI systems placed on the Union market to establish post-market monitoring systems and report serious incidents, and requires providers of GPAI models with systemic risk to evaluate, assess, mitigate, document, and report systemic risks, serious incidents, and possible corrective measures.
- International AI Safety Report materials indicate that frontier safety frameworks became more common by late 2025, while sophisticated attackers can often bypass current defences and the real-world effectiveness of many safeguards remains uncertain.
New Tractable Vectors
- Define machine-readable deactivation/disengagement criteria tied to model telemetry, eval regressions, abuse rates, and risk thresholds.
- Design graceful degradation plans for API deprecation, feature restriction, and model-version rollback with downstream notification, workaround, and fallback paths.
- Use incident databases, structured user feedback, and post-deployment monitoring to inform targeted remediation, access changes, feature restrictions, or deactivation decisions where feasible.
- Benchmark safeguard deltas before/after specific corrections in narrow domains where reliable evals exist, such as biological-risk filters, jailbreak resistance, or content-policy enforcement.
Key Open Questions
- Reliable corrections for open-weight releases, copied weights, downstream fine-tunes, LoRA adapters, and self-hosted deployments.
- Backward compatibility versus safety: when to break model behavior used by downstream apps and research replication.
- User-specific/access-frequency restrictions under privacy, fairness, and evasion constraints.
- Correction verification: showing that a patch, safeguard, or deployment restriction reduced a capability or abuse path without creating hidden regressions.
- Governance of emergency shutdowns across multi-provider agent chains and critical infrastructure dependencies.
Evidence & Primary Sources
- Reuel, Bucknall, et al., “Open Problems in Technical AI Governance,” Section 7.2, describes deployment corrections as responses to flaws in deployed models arising from previously unobserved capabilities or post-training enhancements; cites O’Brien et al.’s five correction categories; and raises disruption-minimizing shutdown and backward-compatibility/reproducibility tensions. (arXiv v2 dated 16 April 2025): https://arxiv.org/pdf/2407.14981
- NIST GenAI Profile includes MANAGE actions for unknown-risk response/recovery, deactivation/disengagement/supersede mechanisms, deactivation communication plans including for open-source models, deactivation criteria, post-deployment monitoring, regular monitoring, post-mortems, incident tracking, user feedback, and legal/regulatory incident reporting; it is a voluntary AI RMF profile. (July 2024; approved 25 July 2024): https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf
- OpenAI Preparedness Framework v2 states that OpenAI tracks Biological/Chemical, Cybersecurity, and AI Self-improvement categories; will not deploy models reaching a High capability threshold until associated severe-harm risks are sufficiently minimized; requires safeguards during development for Critical thresholds; uses Capabilities Reports and Safeguards Reports; and has Safety Advisory Group review and governance. (15 April 2025): https://cdn.openai.com/pdf/18a02b5d-6b67-4cec-ab64-68cdfbddebcd/preparedness-framework-v2.pdf
- OpenAI Preparedness Framework beta is retained as historical evidence for the older Scorecard framing: it used pre/post-mitigation risk tracking and the post-mitigation Medium-or-below deployment rule, but it should not be treated as the current July 2026 framework. (18 December 2023): https://cdn.openai.com/openai-preparedness-framework-beta.pdf
- Anthropic Claude Opus 4/Sonnet 4 system card describes the RSP release decision process, ASL determination, Opus 4 under ASL-3 and Sonnet 4 under ASL-2, activation of ASL-3 safeguards for Opus 4, monitoring systems and incident-response protocols required for release decisions, automated and human monitoring, external red-teaming/validation partners, usage-policy evaluations, and a bug bounty program. (May 2025): https://www-cdn.anthropic.com/4263b940cabb546aa0e3283f35b686f4f3b2ff47.pdf
- Google DeepMind Frontier Safety Framework describes Critical Capability Levels, periodic early-warning evaluations, and applying mitigation plans when early-warning evaluations are passed; mitigations focus primarily on security and deployment restrictions, and the framework is described as exploratory and expected to evolve. (Published 17 May 2024; page metadata modified 6 July 2026): https://deepmind.google/blog/introducing-the-frontier-safety-framework/
- International AI Safety Report site lists the 2026 International AI Safety Report dated 3 February 2026 and the 25 November 2025 Second Key Update, whose summary says the number of companies publishing Frontier AI Safety Frameworks had more than doubled since the 2025 report, while sophisticated attackers can often bypass current defences and the real-world effectiveness of many safeguards is uncertain. https://internationalaisafetyreport.org/
- Regulation (EU) 2024/1689 (AI Act) requires post-market monitoring for high-risk AI systems in Article 72, serious-incident reporting and corrective action for high-risk AI systems in Article 73, and model evaluation, systemic-risk assessment/mitigation, serious-incident reporting, possible corrective measures, and cybersecurity obligations for GPAI models with systemic risk in Article 55. (Official Journal legal text, 12 July 2024): https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R1689
- European Commission AI Act page describes the AI Act as in force, notes high-risk AI-system obligations including post-market monitoring and serious-incident/malfunction reporting, and describes GPAI/systemic-risk implementation timing and obligations at a high level. (Page includes 2026 implementation updates): https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai