Back to Dashboard
Operationalization / 7.2

7.2 Deployment Corrections

2026 Governance Status: Narrowly operationalized

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 unobserved capabilities or post-training enhancements. O’Brien et al. call these post-deployment responsive actions “deployment corrections”; the paper sees “scope for much greater exploration from a technical perspective.” Open problems: feasibility of user restrictions, access-frequency limits, capability/feature restrictions, use-case restrictions, model shutdown; minimize disruption if shutdown is necessary; reconcile corrections/model changes with stability/backward compatibility for reproducibility 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, staged release, ASL/CCL thresholds, model-specific safeguards, usage-policy enforcement, and release decision committees. However, corrections remain narrow, provider-specific, and mostly voluntary outside EU post-market/incident obligations; there is no general technical science of safe rollback/shutdown for API ecosystems, open weights, fine-tuned derivatives, or third-party dependencies. Verified evidence through 2026 shows more frameworks and safeguards, but not validated cross-provider correction playbooks or disruption-minimizing shutdown protocols.

Deployed / Operationalized

  • NIST GenAI Profile explicitly includes procedures for unknown-risk response, incident recovery, supersede/disengage/deactivate mechanisms, stakeholder communication plans, deactivation criteria, regular monitoring, post-mortems, and reporting incidents under legal requirements.
  • OpenAI Preparedness Framework operationalizes deployment gating: only post-mitigation medium-or-below models can be deployed; safety advisory group and scorecards track pre/post-mitigation risk categories.
  • Anthropic Claude 4 system card operationalizes RSP/ASL release decisions, ASL-3 safeguards for Opus 4, monitoring systems, incident response protocols, automated/human monitoring, and bug bounty/external validation.
  • Google DeepMind Frontier Safety Framework operationalizes early-warning evaluations and mitigation plans with security/deployment mitigations when capability levels are approached or crossed.
  • EU AI Act requires post-market monitoring and serious incident/malfunction reporting for high-risk systems and systemic-risk assessment/mitigation for GPAI.

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 and fallback paths.
  • Use incident databases and structured user feedback to trigger targeted corrections rather than full shutdowns.
  • Benchmark safeguard deltas before/after correction, e.g., 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: proving a patch removed 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