CI/CD for models.

Where CI/CD for models fits on a long engagement.

Model deployment differs from application deployment in one decisive way: correctness is statistical rather than binary. Tests do not pass or fail; a model scores, and the pipeline needs a threshold policy deciding whether that score is good enough to promote.

Comparison against the current production model is the gate that matters. A new model must beat what is already deployed on the metrics that count, evaluated on the same held-out data, or promoting it is a change with no evidence behind it.

What an assigned team does with CI/CD for models.

Rollback needs to be as fast for models as for code. When a deployed model starts behaving badly, reverting to the previous version should be a single operation rather than a retraining exercise.

That means retaining previous model artefacts and keeping the deployment path reversible, which is part of the delivery standard agreed as a committed monthly capacity.

What we use CI/CD for models for.

• Promotion gated on evaluation A threshold policy, so a model reaches production on evidence rather than on schedule.
• Compared against what is deployed The incumbent as the baseline, evaluated on the same held-out data.
• Rollback as one operation Previous artefacts retained, so reverting does not mean retraining.

How CI/CD for models capacity is assigned.

Model delivery pipelines are assigned across AI and platform capacity, with rollback treated as a required capability rather than an aspiration.