Model Management
Model management refers to all organizational and technical processes by which a company keeps track of its AI models: which version is running where, who approved it, and when it will be replaced. It is the counterpart to building a model — not development, but the orderly operation over years.
An AI model is a computer program that has learned from many examples to perform a specific task. A company rarely operates only one of them. A bank might have a model for credit decisions, one for fraud detection, and several for customer service. Different versions of each exist over time, because they are continually improved. Model management is the orderly answer to the question of which of these versions is currently in use, and where. It records who created which model, with what data, and who granted permission for it to run.
When nobody knows anymore which model is deciding
Without management, a state arises that experts call shadow AI. Individual departments build their own models, put them live, and document nothing. Two years later, nobody knows anymore which program actually answered a given customer inquiry. This is not just messy — it is dangerous.
The concrete reason is liability. If a model rejects a loan, the bank must be able to explain why. To do so, it needs the exact version that was running at the time, along with the training data. The European Union’s AI Act requires exactly such evidence for high-risk applications. Without clean management, this evidence simply cannot be produced.
There is also an economic point. Models cost money to operate, because every request consumes computing time. Companies regularly discover, during an inventory, models that have been running for months but are no longer used by anyone. Management makes such dead weight visible.
Registry, version numbers, and approvals
The technical centerpiece is the model registry, a kind of catalog. Every finished model is entered there before it even goes to users. The entry contains a version number, the date, the person responsible, and the measurements from testing. Well-known tools for this are MLflow or the registries offered by the major cloud providers.
The underlying idea is familiar from software development. Program code is also versioned, so that one can return to an earlier version at any time. With models, however, this is not enough. A model additionally depends on the data it was trained on. That is why management must also track the datasets — otherwise a result can no longer be reconstructed later.
A staged system is typical. A new model is first placed at the Test stage, then Staging, and only afterward at Production. The move to Production requires explicit approval by a human. If a model later performs worse than expected, one switches back to the previous version at the push of a button. This path back is the actual value of the whole system.
From banking supervisory law to hobby projects
In business news, the term usually appears in connection with regulation. Banks and insurers have known it for a long time under the name Model Risk Management, because supervisory authorities demanded it even before the AI wave. With the AI Act, this obligation now also applies to industry, HR departments, and medical technology.
In the product space, providers such as Databricks, Amazon Web Services, or Google Cloud sell model management as part of larger platforms. There, it is a building block of MLOps, the discipline concerned with the ongoing operation of AI systems. Anyone reading job postings will frequently find the term in listings for machine learning engineers.
A common misconception is that model management is only something for large corporations. Chaos already arises with just three models and two developers, once files with names like model_final_new_v2 are lying around. Even on the Hugging Face platform, where developers share models publicly, there is therefore versioning and model cards with descriptions. The basic idea remains the same, whether a school project or a corporation is behind it.
