Como governar modelos de ML com MLflow e SageMaker Model Registry

O gargalo entre experimentação e produção

Toda organização que faz machine learning em escala esbarra no mesmo problema: os cientistas de dados acompanham dezenas de modelos candidatos no MLflow durante a experimentação, enquanto a área de governança precisa de um registro único e autoritativo para validar, aprovar e auditar os modelos que chegam à produção. Entre esses dois mundos, abre-se um vão que costuma ser preenchido com planilhas, prints e muito trabalho manual.

A AWS atacou esse problema com uma evolução no Managed MLflow do Amazon SageMaker AI: o sync com o Model Registry, antes limitado, agora carrega métricas de treino, resultados de avaliação e linhagem de forma automática. Mais importante, ele também carrega a promoção de estágio do ciclo de vida, permitindo que o modelo seja movido de staging para produção sem que o cientista de dados precise sair do seu fluxo de trabalho.

Como funciona o registro automático

O Model Registry sync é um recurso opt-in. Ao criar ou atualizar um app MLflow, você define o modo de registro como AutoModelRegistrationEnabled. A partir daí, todo modelo registrado no MLflow gera automaticamente um Model Package Group e uma versão correspondente no SageMaker AI Model Registry.

O sync transporta quatro categorias de metadados:

• Metadados de execução — parâmetros do modelo, métricas de treino, localização do dataset e caminho do artefato.
• Métricas de avaliação — anexadas como um model card, renderizadas na aba Evaluate do Studio.
• Especificação de inferência — imagem do container, localização dos dados do modelo e tipos de instância suportados, para implantação direta a partir do registro.
• Linhagem — relação entre experimento, versão do modelo, imagem do container e o package group.

Na prática, um cientista de dados registra o modelo com uma única chamada do MLflow após o treino. A governança passa a ter, no Studio, uma visão pronta para revisão — com métricas e linhagem completas — sem precisar voltar ao MLflow para coletar contexto.

Separando as personas com IAM

O desenho separa duas personas por guardrails do IAM. O cientista de dados trabalha em notebook e interage apenas com o MLflow; o oficial de governança trabalha no Studio UI revisando métricas e promovendo modelos. Um administrador faz a configuração única que separa os dois, usando chaves de condição como sagemaker:ModelLifeCycle/stage para negar a promoção para produção pelo papel do cientista.

O estágio de ciclo de vida é controlado por aliases com convenção sagemakerlifecycle-{estágio}-{status}. Definir o alias sagemakerlifecycle-staging-pending move o candidato para staging; a transição para produção só é permitida ao papel de governança.

Governança entre contas: hub-and-spoke e híbrido

Para organizações maiores, a Parte 2 da série estende o mesmo bloco de construção para duas topologias de governança entre contas. A primeira é o hub-and-spoke, que centraliza a governança compartilhando um único app MLflow entre contas de desenvolvimento via AWS Resource Access Manager (RAM). A segunda é o padrão híbrido, para ambientes regulados, que mantém as contas de desenvolvimento totalmente isoladas do hub de governança.

Em ambos os casos, um modelo aprovado sai do registro e chega a um endpoint implantado por meio de um pipeline de CI/CD, fechando o ciclo completo entre experimentação e produção.

Por que isso importa agora

A novidade reduz um atrito silencioso que consome tempo de engenheiros de MLOps no Brasil e no mundo: a duplicação manual de linhagem entre ferramentas. Com o registro automático, a governança ganha consistência sem que o time de ciência de dados mude sua rotina. Para empresas que já usam MLflow e SageMaker, ativar o sync é uma mudança de configuração — não uma migração de plataforma.