Model registry: why companies need a system for governing AI models

Machine learning development typically produces dozens or hundreds of model variants. They differ in training data, algorithm, parameters, source code, speed, cost and quality of results.

While this is only experimentation, part of that context can live in a notebook, a repository or the developer's head.

The moment a model starts influencing a real business process, however, the organisation has to answer concrete questions:

• Which version of the model is running right now?
• What data did it come from?
• How was it tested?
• Who approved it?
• Which applications use it?
• What are its known limitations?
• What changed compared to the previous version?
• Can a faulty version be pulled and replaced quickly?
• Who is accountable for its continued operation?

This is precisely the operational gap a model registry fills.

What a model registry is

A model registry is a central system for recording and managing models across their lifecycle.

Its job is not merely to store the file containing a trained model. It links a specific model artefact to the information needed to understand, validate, approve, deploy, monitor and eventually retire it.

A typical model registry records:

• the model's name and purpose,
• individual versions,
• model artefacts,
• the model's provenance,
• datasets and training runs used,
• evaluation results,
• metadata and documentation,
• approval status,
• the owner,
• production deployments,
• change history.

MLflow describes it as a centralised store, API and user interface for managing the model lifecycle. It supports versioning, lineage, aliases, metadata and a link back to the experiment the model came from.[1]

Comparable components are offered by AWS SageMaker, Microsoft Azure Machine Learning and Google Vertex AI.[2][3][4]

That points to something important:

Why storing the model as a file is not enough

Imagine a file called fraud_detection_model_v12.pkl.

From the name you can guess this is the twelfth variant of a fraud detection model. The file itself does not tell you:

• whether this is the twelfth experiment or the twelfth production version;
• which data version the model came from;
• which source code commit was used;
• what variables the model expects;
• what results it achieved;
• whether it passed independent validation;
• who authorised its deployment;
• whether an older version is still in use somewhere.

A file name is not a management system.

A model registry ensures the model is not merely a technical artefact but an identifiable, traceable and managed production asset.

Two meanings that must be distinguished

The term model registry today sits at the intersection of two related disciplines.

1. The technical model registry

In MLOps this is primarily about managing model artefacts and their versions.

It answers questions such as:

• Which model version is in production?
• Which experiment created it?
• Where is its artefact stored?
• What are its technical parameters?
• Which version should the application load?
• How can a rollback be performed?

This is the form used by MLflow and the major cloud ML platforms.

2. The enterprise model inventory

In model risk management and AI governance the scope is broader.

The record covers not only the model file but also:

• business purpose,
• owner,
• model criticality,
• permitted and prohibited uses,
• data sources used,
• validation status,
• known limitations,
• vendor dependency,
• incident history,
• date of the next review,
• retirement plan.

US regulatory guidance on model risk management uses the term model inventory for the set of information needed to understand the risks of individual models and of the whole model portfolio.[5]

The technical registry and the enterprise inventory need not always be one system.

The technical registry may be wired into development and deployment pipelines. The enterprise inventory may sit inside a governance platform, a risk system or an internal register.

In a mature organisation, however, they should form a connected whole.

What a model registry should record

A basic record can be split into six layers:

Identity

A model needs a stable name and a clearly defined purpose. For example:

A generic label such as "AI for sales" is not enough. Without a concrete purpose you cannot determine the right metrics, acceptable risk or limits of use.

Provenance

Model lineage describes the chain the model came from:

• the training run,
• the dataset version,
• the code used,
• parameters,
• libraries,
• the compute environment,
• the author,
• the creation date.

Without lineage you may be able to load the model again, but you cannot reliably reproduce it or explain where it came from.

Evaluation

A single accuracy figure is not enough. Depending on purpose, the following may matter:

• accuracy,
• precision and recall,
• false positive rate,
• stability across data groups,
• robustness,
• latency,
• operating cost,
• explainability,
• security testing.

The registry should capture not only which model was chosen but also the conditions under which it was accepted.

Approval

A model version may be, for example:

• experimental,
• a candidate,
• awaiting validation,
• approved,
• in production,
• being replaced,
• archived,
• prohibited.

The record should also state who performed the technical review, who approved the business use and who is accountable for the model.

Deployment

The registry must show where a given version is used. That may be:

• an online API,
• batch processing,
• a mobile application,
• an internal decision system,
• an edge device,
• several regions or environments.

If a critical fault appears, the company must be able to identify quickly every process and application affected.

Operations

Registration does not end at deployment. The record should be linked to information about:

• production performance,
• changes in input data,
• quality degradation,
• incidents,
• exceptions,
• limitations,
• recalibrations,
• replacement or retirement of the model.

A model that was suitable at deployment may not be suitable forever.

What the model lifecycle looks like

A typical process has several steps:

1. Experimentation: the team tries different datasets, algorithms and configurations.
2. Candidate selection: one or more variants meet the basic criteria.
3. Registration: the candidate is recorded as a new version in the model registry.
4. Evaluation and validation: the model is compared against requirements and the current production version.
5. Approval: an authorised person or pipeline permits its use.
6. Deployment: the approved version is released to a test or production environment.
7. Monitoring: performance, data quality, cost and drift are tracked.
8. Replacement or rollback: a new version takes over, or the system returns to an older one.
9. Retirement: an unused version is archived, but its history remains traceable.

A model registry is therefore not a passive archive.

It is the control point between experimentation and production.

What a model registry is not

A model registry is part of a wider environment. It does not replace several other systems.

Experiment tracking

Records all development attempts, their parameters and results.

Model registry

Manages the selected models and versions that have operational significance.

Model monitoring

Tracks model behaviour after deployment.

Model hub or catalogue

Helps discover models available for use.

AI system inventory

Records whole AI systems, their uses, owners, data, vendors and risks.

These layers may live in one platform, but they answer different questions.

What generative AI changes

Traditional model registries were built primarily for models a company trained itself.

With generative AI the company often owns neither the model weights nor the training process. It uses an external foundation model via an API and builds its own application on top.

The behaviour of such an application is not determined by the model alone. The result is also shaped by:

• the system prompt,
• model parameters,
• the knowledge base,
• the embedding model,
• retrieval logic,
• available tools,
• agent permissions,
• guardrails,
• output post-processing.

In a RAG system, changing the documents or the retrieval pipeline can alter behaviour as fundamentally as swapping the language model.

The managed unit is therefore no longer just a model version, but rather:

The modern model registry is thus expanding towards recording AI components, agents and whole system configurations.

An external model does not remove accountability

When using an external model the company has less information and less technical control. The provider can change:

• the model or its behaviour,
• available versions,
• pricing,
• limits,
• safety filters,
• data processing terms.

The record for an external model should therefore contain at least:

• the provider,
• the model identifier,
• the access method,
• the version or endpoint in use,
• the adoption date,
• the categories of data processed,
• known limitations,
• cost,
• a fallback model,
• the procedure if the service is discontinued.

The fact that the company did not train the model does not mean it does not have to govern it.

On the contrary: with a proprietary model the record can matter even more, because the organisation has no access to full information about its construction, data and internal changes.

Model registry and AI governance

A model registry alone will not ensure responsible use of AI. It does, however, provide the infrastructure without which governance is hard to carry out.

It helps evidence:

• which version was used,
• how it was tested,
• who approved it,
• where it was deployed,
• what limitations it had,
• when it was changed,
• whether it was later replaced.

The EU AI Act does not require organisations to use a product called a "model registry".[6]

For regulated AI systems, however, it works with risk management, technical documentation, record-keeping, human oversight, monitoring and accountability across the system lifecycle.

A model registry can be one of the technical layers supporting those processes.

It is necessary, though, to distinguish the model itself from the whole AI system.

A model registry can record model components. Legal, security and commercial assessment generally applies to a specific AI system and the way it is used.

When a company actually needs a model registry

Not every organisation needs a full technical registry.

A company using only a handful of off-the-shelf SaaS applications will probably mainly need an AI system inventory and vendor rules.

A model registry starts to matter particularly when the organisation:

• develops or fine-tunes models itself;
• runs several versions of the same model;
• uses models in significant decision processes;
• needs formal validation and approval;
• must ensure reproducibility;
• needs fast rollback;
• uses multiple clouds or deployment environments;
• is building a larger number of RAG applications and agents;
• is subject to stricter audit or model risk management requirements.

The first implementation does not have to be extensive. It must, however, create one authoritative source of truth and be connected to the real deployment process.

A registry that can be bypassed by a developer pushing a different model straight into production does not govern real operations. It only documents an idealised version of them.

The most common mistakes

The registry turns into a dumping ground for experiments

If every attempt is saved into it automatically, it quickly fills with hundreds of variants of no operational significance.

Recording all experiments is what experiment tracking is for. What should enter the registry are models that have become candidates for validation, deployment or other managed use.

The model has no specific owner

The technical team built the model, but nobody is accountable for its business purpose, correct use and continued operation.

A register without accountability becomes a file catalogue.

The link to data and code is missing

The company records the model artefact but does not know which dataset and code it came from.

Such a model cannot be reliably reproduced or explained.

Approval is merely formal

The model is marked as approved, but it is not clear:

• who approved it,
• against what criteria,
• for what purpose,
• for how long,
• what should invalidate the approval.

The registry is not connected to deployment

The model is registered, but the production team can deploy any artefact outside the approval process.

The registry then records a different reality from the one actually running.

Record-keeping replaces governance

Detailed metadata alone will not determine whether a model is suitable, safe or commercially worthwhile.

A model registry can enforce and record a process. It cannot itself replace decision-making, accountability and genuine oversight.

Conclusion

A model registry answers a basic operational question:

Without a registry, models can exist as isolated files, API endpoints and experiments.

With a registry they become managed assets with traceable provenance, accountability and a lifecycle.

Its main benefits are:

• versioning,
• lineage and reproducibility,
• managed approval,
• a link to production deployment,
• the ability to roll back,
• a record of owners and accountability,
• support for audit and governance.

In traditional machine learning the main object of governance was the model itself.

In generative AI the model is only one part of a wider configuration comprising prompts, data, tools and permissions. A model registry is therefore gradually shifting from a technical store into a control layer for enterprise AI.

A company does not only need to know which model it uses.

It needs to be able to explain how the behaviour of its AI comes about.

Frequently asked questions

Sources and further reading

1. MLflow: ML Model Registry. The reference open-source implementation: versioning, lineage, aliases and a link back to the experiment. mlflow.org
2. Amazon Web Services: SageMaker Model Registry. Model groups, versions and approval statuses wired into the deployment pipeline. docs.aws.amazon.com
3. Microsoft: Register and work with models in Azure Machine Learning. Model registration, versioning and management within a workspace. learn.microsoft.com
4. Google Cloud: Vertex AI Model Registry. A central overview of models and their versions across deployments. cloud.google.com
5. Federal Reserve: SR 26-2 — Revised Guidance on Model Risk Management. Updated US guidance on model risk management (superseding SR 11-7 and SR 21-8). federalreserve.gov
6. Regulation (EU) 2024/1689 — Artificial Intelligence Act. The foundational text of European AI regulation: risk management, documentation, records and human oversight. eur-lex.europa.eu

This article is informational and does not constitute legal advice.