Implementation guide
OWASP AISVS v1.01
Model Lifecycle Management & Change Control · Controlled Deployment & Rollback
Roll out with automatic rollback
Verify that production deployments implement rollout mechanisms with automated rollback triggers.
OWASP AISVS v1.01, requirement 3.3.1
In plain English
Release new models to a small share of traffic first, watch what happens, and roll back automatically if the signals turn bad. A person on call at 3am should not be the only thing between a misbehaving model and all your users.
What good looks like
- New models and prompt changes go to a limited share of traffic or users before everyone.
- Rollback triggers are defined in advance and cover error rates, latency, safety signals (such as guardrail block rate) and the main business metrics.
- Rollback fires without waiting for a person.
- The rollback path is exercised regularly.
How teams usually do it
- Canary or blue-green deployment in the serving platform, for example with Argo Rollouts, a service mesh or the traffic-splitting features of a managed endpoint.
- Alert rules wired to an automated rollback job.
- Feature flags for prompt and configuration changes, so they roll out and back the same way as model changes.
Suggested evidence
- Rollout configuration and trigger definitions.
- Records of a real rollback or a rollback drill.
Common mistakes
- Triggers based only on uptime, so a model that is up and misbehaving stays live.
- Canary periods too short to gather enough traffic to judge.
- Changing the system prompt directly in production, outside the rollout process.
Not sure which requirements apply to your system? Take the assessment, or browse every guide in this chapter.
Requirement text from the OWASP AI Security Verification Standard, licensed under CC BY-SA 4.0. This guidance is shared under the same licence.