Count the identifiers. A conventional service can be reconstructed from two, a commit and a container image [4]. The AI-enabled version of that same service, on the list devops.com publishes, needs five more: model version, feature definitions, inference configuration, policy rules and data schema [5]. Seven things instead of two [6], and they are not all moved by the same pipeline or held in the same store. The failure mode the piece names is specific and familiar to anyone who has run an AI incident: you can say which application image is running and not which model produced the output [7].
The test suite does less work here than the word "gate" implies. The stated objective is negative, catching changes that are clearly unsafe, incompatible or operationally unacceptable rather than proving a model correct [9]. Of the six checks suggested, four are plumbing (schema validation, feature availability, model load, inference latency) and only two look at what the model actually says (output-range checks and regression against representative scenarios) [21]. Correctness questions get tolerance ranges, quality thresholds or benchmark comparisons instead of exact expected values, and the CI system has to hold both patterns at once [10]. A green build then means the AI path is wired up and inside its budget. It does not mean the behavior is the one anybody approved.
So the evaluation moves downstream, which is why progressive delivery stops being a maturity nicety. A small share of traffic goes to the new version while latency, errors, fallback rates and business outcomes are compared against the incumbent [13]. The success criterion is no longer an HTTP 200 [19]. That is a quiet reassignment of ownership: the deploy decision now depends on numbers that live in analytics rather than in the pipeline.
There is a tension inside the argument worth sitting with. The piece wants AI assets treated as first-class production artifacts rather than attachments to the software release [20], and it also wants model serving separated from the business application when the two release on different cadences [18]. Both are sensible; they pull in opposite directions. One asks for a single record of what shipped, the other creates two release trains whose combinations were never tested together. What reconciles them is the knowledge of which assets must move together and which can be reverted alone, held as compatibility rules alongside a model registry and immutable artifacts [17]. That is the piece of infrastructure with no obvious owner. It is not in the repository and it is not in the registry, and it only gets written down when rolling back one layer has already produced an incompatibility [16].
This is a practice argument from one publisher, not a measurement. It offers no failure rates and no adoption data. The versioning claim, though, is cheap to check against an incident timeline you already have: either the timeline names the model version that served the request, or it names the image and stops there [7].
