AI Model Version Control
Track model versions, configurations, prompts, and deployment history so that any production state can be reproduced and compared.
Objective
Enable rollback, reproducibility, and accountability for AI system behavior by maintaining a complete version history of all production-relevant artifacts.
Maturity Levels
Initial
Model versions are not tracked; it is not possible to determine what model version produced a given output.
Developing
Model versions are informally noted but prompts, configurations, and deployment history are not systematically tracked.
Defined
A version control system tracks model versions, system prompts, and configuration parameters with deployment timestamps.
Managed
Version history is linked to performance metrics; regressions can be attributed to specific version changes.
Optimizing
Version control is automated and integrated with deployment pipelines; every production artifact is reproducible.
Evidence Requirements
What an auditor or assessor would expect to see for this control.
- —Model registry showing every deployed version with model hash, training data reference, prompt version, and deployment timestamp
- —Source control records linking model artifacts to the commit, ticket, and approval event for each version
- —Reproducibility evidence: records confirming a past version can be rebuilt from logged artifacts
- —Change log linking each version to the change request, approval, and deployment event that created it
- —Access control configuration on the model registry confirming only authorized roles can publish new versions
Implementation Notes
Key steps
- Version control system prompts with the same rigor as application code — prompt changes can dramatically alter model behavior and must be tracked.
- Tag deployments with the model version, prompt version, and configuration hash so outputs can be traced to a specific system state.
- Treat third-party model version changes (e.g. OpenAI model updates) as deployment events requiring validation, not silent upgrades.
- Maintain a model card for each production model: intended use, known limitations, evaluation results, and approval status.
Example Implementation
ML platform team managing 6 production AI models across product and risk systems
Model Registry Entry — Customer Churn Predictor v2.3
| Field | Value |
|---|---|
| Model ID | churn-predictor-v2.3 |
| Base model | XGBoost 1.7.3 |
| System prompt version | N/A (non-generative) |
| Config hash | sha256:8f3a... |
| Training data version | customer-features-2026-Q1-v4 |
| Deployed to production | 2026-04-12T09:15Z |
| Deployed by | MLOps pipeline (approved by: J. Rivera, 2026-04-11) |
| Evaluation results | AUC 0.81 · Precision 0.76 · Recall 0.79 · Bias check: pass |
| Known limitations | Reduced accuracy for customers < 6 months tenure |
| Rollback target | churn-predictor-v2.2 |
| Status | Active |
Prompt tracking note: For generative models, prompt version is stored alongside model ID as a combined deployment artifact — a prompt change constitutes a new version.
Control Details
- Control ID
- CHM-001
- Domain
- Change Management
- Typical owner
- AI Engineering / MLOps
- Implementation effort
- Low effort
- Agent-relevant
- Yes