O problema de governança que a sincronização resolve
Existe uma lacuna clássica no ciclo de vida de modelos de machine learning: cientistas de dados rastreiam dezenas de experimentos no MLflow, enquanto os responsáveis pela governança precisam de um registro único e confiável para validar, aprovar e auditar quais modelos chegam à produção. Sem uma ponte automática entre esses dois mundos, alguém sempre precisa registrar modelos manualmente, coletar contexto à mão ou sair do fluxo de trabalho para buscar informações em outro sistema.
A AWS anunciou um aprimoramento significativo nessa ponte. O Amazon SageMaker AI com MLflow gerenciado já sincronizava modelos registrados no MLflow para o SageMaker AI Model Registry automaticamente. Agora, essa sincronização ficou consideravelmente mais rica: ela carrega métricas de treinamento, resultados de avaliação e linhagem, além de adicionar a promoção de estágio de ciclo de vida diretamente pelo MLflow. O resultado prático é que equipes podem governar modelos candidatos a partir de um único sistema de referência, sem precisar que os cientistas de dados abandonem seu fluxo de experimentação.
Antes dessa melhoria, um modelo ainda era sincronizado para o registro, mas chegava sem métricas, resultados de avaliação ou linhagem. O responsável pela governança não conseguia validar um candidato apenas pelo registro — precisava voltar ao MLflow ou coletar o contexto manualmente. Além disso, como a sincronização não carregava a promoção de estágio de ciclo de vida, os cientistas de dados não podiam mover um modelo de staging para produção dentro do fluxo do MLflow.
Como funciona o registro automático
A sincronização com o Model Registry é uma funcionalidade opt-in. Ela pode ser ativada ao criar ou atualizar um app MLflow, definindo o modo de registro de modelos como AutoModelRegistrationEnabled (o padrão é desabilitado). Para configurar essa sincronização, é necessário configurar a função de serviço de Gerenciamento de Identidade e Acesso (IAM) com as permissões necessárias para criar os Model Package Groups e versões, adicionar tags e registrar associações de linhagem.
# Ativar sincronização com o Model Registry ao criar um app MLflow
aws sagemaker create-mlflow-app \
--name my-mlflow-app \
--artifact-store-uri s3://<your-sample-bucket-name>/mlflow \
--role-arn arn:aws:iam::<ACCOUNT>:role/my-mlflow-app-role \
--model-registration-mode AutoModelRegistrationEnabled \
--region <region>
# Atualizar um app MLflow existente com sincronização do Model Registry
aws sagemaker update-mlflow-app \
--arn <your-existing-mlflow-app-arn> \
--model-registration-mode AutoModelRegistrationEnabled \
--region <region>
Com a sincronização ativada, o cientista de dados pode registrar um modelo com uma única chamada MLflow. Dois artefatos opcionais — especificação de inferência e métricas de avaliação — podem ser anexados antes do registro e são então carregados para o Model Package:
import mlflow, sagemaker_mlflow
# Registrar o modelo treinado durante o run
model_info = mlflow.sklearn.log_model(model, name="sklearn-model")
# Opcionalmente registrar métricas de avaliação
sagemaker_mlflow.evaluate(model_info, data=dataset, model_type="regressor")
# Opcionalmente registrar uma especificação de inferência:
# habilita deploy direto a partir do registro
sagemaker_mlflow.log_inference_specification(
model_info.model_id,
inference_specification=inference_spec
)
# Registrar o modelo: cria o Model Package Group e versão automaticamente
mv = mlflow.register_model(f"models:/{model_info.model_id}", "my-model")
O que é sincronizado para o Model Registry
Após o registro, a sincronização carrega quatro categorias de metadados para o Model Registry no Amazon SageMaker Studio, disponibilizando-as para o responsável pela governança:
- Metadados do run: parâmetros do modelo, métricas de treinamento, localização do dataset de treinamento e caminho do artefato do modelo.
- Métricas de avaliação: anexadas como um model card na versão do Model Package, onde são exibidas na aba Evaluate no Studio, tornando as medidas de desempenho revisáveis junto ao modelo.
- Especificação de inferência: define a imagem de container, a localização dos dados do modelo e os tipos de instância suportados, permitindo o deploy direto a partir do registro. Para que o pacote seja genuinamente implantável, os artefatos do modelo também precisam incluir o handler de inferência (por exemplo, um
inference.pyempacotado com o modelo durante o treinamento ou registro). - Linhagem: registra o relacionamento entre o experimento MLflow, a versão do modelo, a imagem de container e o Model Package Group.
Controles de ciclo de vida e governança
Os responsáveis pela governança podem gerenciar o ciclo de vida dos modelos usando o construto de staging do Model Registry. As organizações podem usar o template predefinido ou definir o próprio, em conjunto com condition keys do IAM, para que apenas usuários com as permissões corretas possam promover modelos ao longo do ciclo de vida.
O estágio e o status do ciclo de vida são definidos adicionando um alias MLflow com a convenção de nomenclatura sagemakerlifecycle-{stage}-{status}, onde stage é staging ou production e status é pending ou active no template predefinido. Isso atualiza automaticamente o ciclo de vida do Model Package correspondente no SageMaker AI:
client = mlflow.MlflowClient()
# Mover um candidato para staging
client.set_registered_model_alias(
"my-model",
"sagemakerlifecycle-staging-pending",
version
)
Dois controles de governança podem ser aplicados para garantir que apenas o perfil adequado atualize o ciclo de vida do modelo:
- Condition keys do IAM: permitem controlar transições de ciclo de vida. As chaves
sagemaker:ModelLifeCycle/stageesagemaker:ModelLifeCycle/stageStatuscontrolam quem pode atualizar o estágio de um modelo e para qual estágio e status ele pode ser movido. - Condições de resource tag: permitem bloquear um Model Package Group após a aprovação, impedindo que novas atualizações fluam pelo MLflow.
Mudanças de ciclo de vida também emitem eventos para o Amazon EventBridge e são registradas como trilha de auditoria. Esses eventos podem ser consumidos para conectar o processo de aprovação a ferramentas de governança de terceiros.
Novidades no plugin sagemaker-mlflow
Os fluxos de trabalho descritos neste post utilizam o plugin sagemaker-mlflow, e a versão 0.5.0 adiciona duas capacidades relevantes. A primeira é o registro de imagem de inferência, que permite gravar a imagem de container de inferência junto ao modelo no momento do log — esses metadados seguem com o modelo para o Model Registry, reforçando o caminho de deploy direto a partir do registro. A segunda é a injeção de sessão (por meio de use_session() e set_session()), que permite fornecer uma sessão boto3 customizada para que o plugin assine requisições com credenciais por contexto. A configuração de conta única deste post não requer esse recurso, mas ele é o bloco de construção para as topologias de governança entre contas abordadas na Parte 2.
Os dois perfis de usuário
A configuração envolve dois perfis com ferramentas distintas. O cientista de dados trabalha em um notebook Jupyter e interage com o MLflow: treinando, registrando e promovendo modelos para staging. O responsável pela governança trabalha na interface do SageMaker Studio, na visão de Modelos: revisando métricas e linhagem sincronizadas, promovendo para produção e aprovando para deploy. Um administrador de plataforma realiza a configuração única que separa os dois perfis.
Configuração em conta única
Em uma configuração de conta única, tanto os cientistas de dados quanto o responsável pela governança operam na mesma conta. Esse modelo é adequado para equipes menores ou projetos em estágio inicial onde a separação de contas ainda não é necessária.

O fluxo funciona da seguinte forma: ao concluir o treinamento, o cientista de dados registra o modelo no app MLflow com sincronização ativada. O registro automático cria o Model Package Group e a versão no SageMaker AI Model Registry, incluindo métricas, resultados de avaliação, especificação de inferência e linhagem. Com as condition keys do IAM configuradas, o cientista de dados pode mover o modelo para staging, mas a promoção para produção será negada para seu perfil. Apenas o perfil do responsável pela governança, com as permissões adequadas, pode aprovar e promover o modelo para produção. Um engenheiro de ML pode então fazer o deploy do modelo aprovado para um endpoint SageMaker AI, normalmente por meio de um pipeline de Integração Contínua e Entrega Contínua (CI/CD).
Configuração pelo administrador de plataforma
O administrador ativa a sincronização com o Model Registry no app MLflow, concede à função de serviço do app as permissões de registro e linhagem, e aplica a política de IAM (guardrail de ciclo de vida) à função do cientista de dados. Essa política usa a condition key sagemaker:ModelLifeCycle/stage para negar promoções para produção:
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "DenyProductionPromotion",
"Effect": "Deny",
"Action": "sagemaker:UpdateModelPackage",
"Resource": "*",
"Condition": {
"StringEquals": {"sagemaker:ModelLifeCycle/stage": "production"}
}
}]
}
A função do responsável pela governança não contém esse deny, então apenas esse perfil pode promover para produção. Essa é uma configuração única. Após ela, os dois perfis trabalham de forma independente.
O cientista de dados: experimento e registro pelo notebook
O cientista de dados trabalha em um notebook Jupyter (no SageMaker Studio ou localmente) e interage apenas com o MLflow. Após o treinamento, ele registra métricas de avaliação e a especificação de inferência, registra o modelo e o move para staging com um alias de ciclo de vida:
mv = mlflow.register_model(f"runs:/{run_id}/sklearn-model", "my-model")
client = mlflow.MlflowClient()
client.set_registered_model_alias("my-model", "sagemakerlifecycle-staging-pending", mv.version)
O registro automático cria o Model Package Group e a versão do Model Package no Model Registry. O alias move o modelo para staging/pending. Se o cientista de dados tentar o alias de produção, a transição é negada pela política de IAM configurada.
O responsável pela governança: revisão e aprovação no Studio
O responsável pela governança trabalha na visão de Modelos do SageMaker Studio. A versão do Model Package sincronizada já traz as métricas de treinamento, o model card de avaliação e o grafo de linhagem, portanto toda a revisão acontece em um único lugar.

Após validar as métricas e a linhagem, o responsável promove o modelo para production/active e define o status de aprovação como Approved. O status de aprovação é um atributo separado do estágio de ciclo de vida, portanto promoção e prontidão para deploy permanecem como decisões distintas. Para bloquear o modelo aprovado contra alterações futuras, o responsável (ou uma etapa automatizada pós-aprovação) aplica uma resource tag ao Model Package Group com uma condição de deny correspondente no IAM (aws:ResourceTag/frozen = true).
Pré-requisitos
Para reproduzir o fluxo descrito, é necessário ter:
- Uma conta AWS com permissões para criar e gerenciar recursos do SageMaker AI.
- Um domínio do Amazon SageMaker AI com acesso ao Studio configurado.
- Um app MLflow gerenciado criado dentro do domínio. Para instruções de configuração, consulte como criar um app MLflow.
- Sincronização com o Model Registry ativada no app MLflow.
- O plugin
sagemaker-mlflowversão 0.5.0 ou superior instalado no ambiente de experimentos (pip install sagemaker-mlflow>=0.5.0). - Uma função IAM com permissões para registrar modelos, atualizar estágios de ciclo de vida e escrever no Model Registry.
Limpeza dos recursos
Para evitar cobranças contínuas, os recursos criados durante o walkthrough devem ser removidos na seguinte ordem, respeitando as dependências:
- Excluir o endpoint do SageMaker AI (se implantado).
- Excluir as versões do Model Package e o Model Package Group (remova todas as versões primeiro, depois exclua o grupo).
- Excluir o app MLflow.
- Remover as políticas IAM customizadas criadas para os perfis de cientista de dados e responsável pela governança.
- Excluir os artefatos do modelo no Amazon S3.
- Excluir o domínio do SageMaker AI (opcional, se criado exclusivamente para este walkthrough).
Conclusão
O registro automático de modelos entre o MLflow gerenciado e o SageMaker AI Model Registry oferece aos responsáveis pela governança uma visão completa e sincronizada de cada modelo candidato — abrangendo métricas de treinamento, métricas de avaliação, especificação de inferência e linhagem —, sem exigir que os cientistas de dados saiam do MLflow ou registrem modelos manualmente.
Ativar a sincronização é uma escolha deliberada: define-se AutoModelRegistrationEnabled no app MLflow e concede-se à função de serviço as permissões de registro e linhagem. A partir daí, cada modelo registrado flui para o registry com seus metadados intactos. Em uma conta única, as condition keys do IAM no estágio de ciclo de vida são o que separa os perfis de cientista de dados e responsável pela governança, e um bloqueio por resource tag protege modelos aprovados contra alterações futuras.
Organizações maiores raramente se limitam a uma única conta. Na Parte 2, a AWS estende esses blocos de construção para topologias de governança entre contas: um padrão hub-and-spoke que centraliza a governança compartilhando um app MLflow entre contas de desenvolvimento com o AWS Resource Access Manager (AWS RAM), um padrão híbrido para ambientes regulados que mantém as contas de desenvolvimento totalmente isoladas do hub de governança, e o caminho da aprovação para o deploy via CI/CD.
Para começar, consulte a documentação sobre registro automático de modelos e os scripts de execução passo a passo para conta única — ou o notebook equivalente — disponíveis no repositório GitHub.
Recursos adicionais
- Amazon SageMaker AI
- Registro automático de modelos SageMaker AI com o SageMaker Model Registry
- Construto de Staging para o Ciclo de Vida do Modelo
- AWS re:Post para Amazon SageMaker
Fonte
Govern models with MLflow and Amazon SageMaker AI Model Registry sync: Part 1 (https://aws.amazon.com/blogs/machine-learning/govern-models-with-mlflow-and-amazon-sagemaker-ai-model-registry-sync-part-1/)
Leave a Reply