Implement machine learning model lifecycle and operations
Model Registration, Versioning, and Responsible AI
ImportantRegister models in MLflow format with their lineage, package feature retrieval specifications with models that use a feature store, assess models with the Responsible AI dashboard, and retire old versions by archiving.
Aligned to the live AI-300 guide, which publishes no skills-measured date; guide and product behavior verified October 10, 2026.
Why this matters
A registered model is the hand-off point between training and deployment. Registering it with the right format, feature lineage, and responsible AI evidence decides whether deployment is no-code or custom, whether inference uses the same features as training, and whether stakeholders can trust the model.
Must Know
- Registering a model creates a named, versioned entry that records its source job and files; registering the same name again creates a new version.
- An MLflow model includes an MLmodel file that describes its flavor and signature. Registered with the mlflow_model type, it supports no-code deployment without a scoring script or environment.
- A custom model type needs a scoring script and an environment when deployed.
- A managed feature store keeps feature definitions separate from models. Packaging the feature retrieval specification with the model artifact records which features and versions the model needs, so inference and lineage use the same features as training.
- The Responsible AI dashboard brings together error analysis, fairness assessment, model interpretability, counterfactual what-if analysis, causal analysis, and data analysis.
- Archiving a model hides it from list queries by default, but you can still reference and use it. A new version created under an archived model container is archived automatically.
- The Responsible AI dashboard supports tabular classification and regression models registered in MLflow format with a scikit-learn implementation.
Compare and Distinguish
- MLflow model versus custom model: no-code deployment with a recorded signature versus your own scoring script and environment.
- Error analysis versus fairness assessment: where the model fails by cohort versus how outcomes differ across sensitive groups.
- Interpretability versus counterfactual analysis: which features drive predictions versus what minimal change would flip a prediction.
- Archive versus delete: hidden but still resolvable for existing use versus removed.
Scenario examples
- Scenario: A team wants to deploy a scikit-learn model without writing a scoring script. Think: log it with MLflow and register it as an mlflow_model.
- Scenario: Online inference computes features differently from training. Think: package the feature retrieval specification with the model from the feature store.
- Scenario: Overall accuracy is good but one customer segment has many errors. Think: error analysis in the Responsible AI dashboard.
Exam traps
- Interpretability explains predictions; it does not measure fairness across groups.
- Archiving a version does not stop endpoints that already serve it.
- A model saved as plain pickle files and registered as custom does not get no-code deployment.
- Registering a model again under the same name does not overwrite the earlier version.
Key takeaways
- Prefer MLflow models for traceable, no-code deployment.
- Package feature retrieval specifications to keep training and inference features aligned.
- Use the Responsible AI dashboard to find failure cohorts and fairness gaps before release.
How it works
- Registering a model from a job output links it to the job that produced it, so lineage shows data, code, and environment, while a model uploaded from a local folder has no source job.
- Responsible AI insights are computed by a pipeline and rendered as an interactive dashboard on the model.
Objects and administrative surfaces
- Studio Models page for versions, lineage, and archive actions.
- az ml model create with type mlflow_model or custom_model and paths that point to job outputs.
- Responsible AI dashboard generated through a pipeline of Responsible AI components.
When to use it
- Use counterfactual what-if analysis when stakeholders ask what would change an individual decision.
- Archive superseded versions after their replacements are deployed and validated.
Security and governance implications
- Restrict who can register or archive models in production workspaces and registries.
- Keep Responsible AI dashboards with the model version as release evidence.
Troubleshooting signals
- A no-code deployment that fails to find a signature or flavor usually means the model was not logged in MLflow format.
- Inference that disagrees with offline evaluation often points to feature computation that differs from training.
More detail
- Package a feature retrieval specification with the model artifact.
- Register MLflow models from job outputs or local files.
- Evaluate models with Responsible AI dashboard components.
- Manage model versions through archive and promotion.
Ready for the quiz?
- What does the MLmodel file add to a registered model?
- Why package a feature retrieval specification with a model?
- Which Responsible AI component finds cohorts with high error rates?
- What happens to existing deployments when a model version is archived?
Related objectives
- D2.2.S1 — Package a feature retrieval specification with the model artifact
- D2.2.S2 — Register an MLflow model
- D2.2.S3 — Evaluate a model by using responsible AI principles
- D2.2.S4 — Manage model lifecycle, including archiving models