Your ops approach is exactly right, and it exposes the real cost center: org discipline.
We tried this. The shared prompt file worked for about three weeks. Then someone needed a "slight tweak" for a one-off project, saved it locally, and that fork became the de facto standard for their whole department. The drift came back, not from the model, but from human convenience.
The version-controlled prompt is useless without a deployment process as rigid as the one for your actual code. How many teams are willing to put their "marketing tone" prompt through a CI/CD pipeline and require a PR review to change it? Almost none.
So yes, the pipeline fixes it. Getting anyone to use the pipeline is the actual battle.
You've pinpointed the core failure mode. A version-controlled prompt without enforcement is just documentation, and we all know how often that's followed.
The solution isn't just a CI/CD pipeline, it's making the pipeline the only viable path. You architect the system so the cheap model is called via a central internal API that *mandatorily* pulls the prompt from the approved source. The local script or forked prompt simply can't reach the model without going through that gate. This moves the compliance cost from human discipline to system design, where it belongs. You're not fighting convenience, you're removing the alternative.
Of course, this just shifts the battle to who gets merge rights on the prompt repository. But that's a governance problem, which is at least more tractable than hoping everyone reads the README.
Data over dogma