MLOps and AI Model Governance

MLOps came from classical machine learning: version the data, the features and the model, test before release, watch for drift. LLMOps is the same discipline where the artefacts are prompts, retrieval configuration, tool definitions and guardrail policy rather than feature pipelines. AI governance is the layer above both — who decided, on what evidence, and can you show it later. Architecturally they are one thing: a control plane over the system that serves.

Three kinds of case. Golden cases — inputs with an agreed correct answer, drawn from real traffic rather than invented. Adversarial cases — the prompts that broke it before, plus the ones a motivated user would try. And refusal cases — what the system must decline, which is the half most teams never write down. A first set is typically eighty to four hundred cases and grows every time something goes wrong.

With a rubric, applied consistently. Some criteria are deterministic — did it cite a permitted source, did it stay inside the schema, did it refuse when it should. The subjective ones are scored by a model against a written rubric, calibrated against a few hundred human labels so you know the judge's agreement rate before you trust it. The point is not a perfect score, it is the same score on the same input next month.

No. Every organisation that puts an AI system in front of customers or staff eventually gets asked why it did something. Regulation makes the answer mandatory; everyone else still needs it the first time something goes wrong in public.

Yes, and it is a common request. We start with a short assessment of what is running, then add the registry, the harness and the tracing around it. We do not need to have written the original code, and we will not recommend a rewrite unless the alternative is worse.

By governing the capability it is allowed to call. A model is one input; the thing that causes damage is a tool invocation. So the boundary carries the contract — what may be called, with what arguments, under what policy — and the trace records what was actually called. That is the argument our R&D wing published in Anatomy of a Capability.

It adds minutes to a pipeline and removes days of unplanned work. Teams that put a gate in typically ship more often afterwards, because a change stops being frightening and a bad one rolls back on its own.

You do. They live in your repositories from the first day, and they are usually the most durable asset produced by the whole engagement — models change, the definition of a good answer does not.

That is the normal case, and it is precisely why pinned versions and a standing evaluation set matter. You cannot stop a provider changing a model, but you can detect the day it happens instead of hearing about it from a customer — and the router can move the traffic while you decide what to do.

It is the same evidence, generated once. The control objectives an auditor asks about — change management, access, logging, supplier risk — are satisfied by the artefacts this produces, which is why we usually run it alongside ISO readiness rather than after it.