Day-one competence is not the same as ongoing reliability
A model can pass every pre-launch evaluation and still degrade in production as real user inputs diverge from the test set, as the underlying retrieval corpus changes, or as the model provider silently updates the model behind an API that looks unchanged from the outside.
Treat this the way you would a new hire's first quarter: a strong interview does not replace a 90-day check-in, and a strong launch evaluation does not replace ongoing review.
Build a standing review cadence, not just launch gates
A practical cadence: automated regression scoring on every model or prompt change, a monthly sample review by a human domain expert, and a quarterly adversarial re-test against the evaluation set built for exactly this purpose.
This is more process than most feature launches get, and that is appropriate — the system's behaviour is genuinely less predictable than a conventional feature's, so the review investment should be proportionate.
Manage model-provider changes like a vendor risk, not a free upgrade
When a model provider ships a new version behind the same API endpoint, your system's behaviour can shift without any code change on your side. Re-run your evaluation suite against every model version change before accepting it in production, the same way you'd regression-test a vendor library upgrade.
Teams that skip this step are often the ones surprised, months later, by a subtle behaviour change they can't trace to any commit in their own repository.
A model that passed evaluation once is a candidate who passed an interview once. Neither claim lasts forever unchecked.MNB AI Practice
Key actions
- Run automated regression scoring on every prompt/model change
- Schedule a recurring human domain-expert sample review
- Re-test adversarially on a fixed quarterly cadence
- Treat provider model updates as a vendor change requiring re-evaluation