Implantando modelos de ML em produção: a realidade do MLOps em 2026

De onde vem o 87%

Você vai encontrar o número "87% dos modelos de ML nunca chegam à produção" em quase toda apresentação sobre o assunto. Vale saber de onde ele vem: um artigo da VentureBeat de 2019 reproduzindo uma cifra que um executivo citou num painel. Não há estudo nenhum por trás, nem método declarado. Cite e mais cedo ou mais tarde alguém vai pedir a fonte, e você não vai ter. O número mais próximo com método por trás é o do Gartner: numa pesquisa com 699 organizações, 54% dos projetos de IA passaram do piloto à produção (Gartner, 2022).

O que sobrevive sem o número é a observação por baixo dele: os modelos que não chegam quase nunca falham por acurácia. Falham por dono, por acesso a dados e pela ausência de alguém cujo trabalho seja operá-los no trimestre que vem. A restrição é operacional, não técnica.

Os três padrões que respondem pelas implantações fracassadas:

1. Treinado com dados que não correspondem à produção. A acurácia no notebook era alta. Em produção, não é. O modelo nunca viu uma entrada real.
2. Ninguém é dono da implantação. O cientista de dados que construiu o modelo não tem acesso à produção. A equipe de DevOps não tem contexto de ML. O modelo fica meses num notebook.
3. Sucesso medido por acurácia offline, não por métrica de negócio. O modelo melhora o AUC. A métrica de negócio não se move. O projeto é arquivado como "iniciativa de IA".

A correção é a inversão: construir o esqueleto de implantação primeiro, o modelo depois.

As cinco peças de um esqueleto de MLOps

Antes de treinar, construa estes cinco componentes. Sem eles, o modelo nunca entra no ar.

Se algum estiver faltando no dia 1, a implantação não tem para onde voltar quando quebrar. Construa os cinco antes de gastar uma semana ajustando hiperparâmetros.

Training-serving skew: a falha que não derruba nada

O training-serving skew é uma forma frequente de um modelo aprovado na avaliação falhar em produção: ele vê dados diferentes no treino e no serviço, porque o feature engineering acontece duas vezes, em dois pipelines, escritos por duas equipes.

Exemplos que já depuramos:

• O treino calcula a idade a partir de dob interpretado como MM/DD/YYYY. A produção interpreta como DD/MM/YYYY. Metade das idades está errada.
• O treino faz one-hot encoding em 11 categorias de produto. A produção encontra uma 12ª categoria e a codificação falha em silêncio para um vetor de zeros.
• O treino imputa valores ausentes com a mediana calculada no conjunto de treino. A produção imputa com a mediana móvel da última hora. Distribuições diferentes.

A correção é estrutural: um único pipeline de features, usado de modo idêntico em treino e serving. Ferramentas como Tecton, Feast e Hopsworks existem exatamente para isso. Se a equipe não adotar uma feature store, a alternativa são dados de treino capturados diretamente dos logs de produção - nunca de amostras sintéticas.

Monitoramento que captura desvio real

Sem monitoramento a degradação não está ausente: está invisível. O modelo continua devolvendo previsões no horário. Nada lança erro. As previsões apenas ficam piores do que eram, e a primeira pessoa a notar costuma ser um cliente. Não é caso raro: em 32 conjuntos de dados e quatro tipos de modelo, a qualidade caiu com o tempo em 91% dos pares modelo-dataset (Vela et al., 2022).

Três sinais de monitoramento, na ordem em que vale construí-los:

1. Desvio de distribuição da entrada. Estatísticas das features (média, variância, valores categóricos top-k) se afastam da distribuição de treino. Automatizado por Evidently, Whylogs, Arize.

2. Desvio de distribuição das previsões. Proporções das classes de saída ou distribuições de score mudam sem causa na entrada. Frequentemente sinaliza corrupção de dados a montante.

3. Acurácia contra a verdade. Quando os rótulos reais ficam disponíveis (muitas vezes com atraso de dias ou semanas), meça a acurácia contra eles. Pega os problemas sutis que os dois primeiros não enxergam.

Sem os três, você está voando às cegas. A maioria das equipes só tem os dois primeiros. O sinal de acurácia é o caro - exige um pipeline de rotulagem - mas é o único que captura o concept drift, em que as features parecem iguais, mas sua relação com o alvo mudou.

Cadência de retreinamento

Três opções, em ordem crescente de maturidade:

Retreinamento agendado (semanal/mensal): fácil de configurar. Desperdiçador quando o modelo é estável. Lento demais quando as distribuições mudam rápido. O ponto de partida padrão, mas não o estado final correto.

Retreinamento por desvio: monitorar o desvio, retreinar quando ele exceder o limiar, validar, implantar com aprovação humana. O estado final correto para a maioria dos modelos em produção.

Aprendizado online contínuo: o modelo é atualizado a partir de dados de produção quase em tempo real. Parece ótimo em palestras de conferência. Tem casos de uso legítimos muito estreitos (sistemas de recomendação, ranking de anúncios). A maioria das equipes não deveria tentar.

Realidade de custo: a maior parte não é treinamento

A AWS, que vende hardware de inferência, diz que até 90% do gasto com infraestrutura para desenvolver e rodar aplicações de ML costuma ir para inferência (AWS, EC2 Inf1, 10.2026). Os engenheiros do Google disseram o mesmo sobre esforço em 2015: as vitórias rápidas do ML trazem custos ocultos de manutenção que vivem no sistema ao redor do modelo, não no modelo (Sculley et al., 2015).

A obsessão com "custo de GPU" em 2024-2025 estava deslocada. As partes caras são a infraestrutura de serving (puxada por requisitos de latência) e o tempo de engenharia (puxado pela complexidade de implantação). Ferramentas e padrões que reduzem o tempo de engenharia têm ROI mais alto do que ferramentas que reduzem o custo de treinamento. Como traduzir isso em retorno financeiro está em medindo ROI de IA.

O playbook de MLOps de 30 dias para um primeiro modelo em produção

Semana 1: construa o esqueleto de implantação. Pipeline de features (offline + online), registro de modelos, stub de serving devolvendo uma constante, monitoramento sobre o stub, caminho de rollback testado. Coloque o stub em produção.

Semana 2: treine um modelo de baseline (regressão logística ou árvore rasa). Substitua o stub. Verifique se as previsões em produção batem com as previsões offline na mesma entrada. Configure o monitoramento de desvio.

Semana 3: implante o baseline para atender 100% do tráfego real de produção. Monitore desvio, latência, taxa de erro. Configure alertas.

Semana 4: agora treine seu modelo de verdade. Substitua o baseline se e somente se ele superar o baseline na métrica de negócio (não apenas no AUC). Documente o procedimento de rollback. Para o lado de segurança do que vai entrar em produção, ver práticas de segurança de IA.

No dia 30, você tem um modelo em produção com monitoramento, detecção de desvio, rollback e um baseline para o qual recuar. Os próximos modelos herdam o esqueleto.

O que rejeitar

Ao avaliar propostas de MLOps ou pitches de fornecedores, rejeite qualquer um destes:

• "Plataforma Auto-ML" sem propriedade do monitoramento ou do desvio.
• Ferramentas só de treinamento, sem serving e monitoramento.
• "Acurácia do modelo" como métrica primária de sucesso, sem uma métrica de negócio.
• Promessas de "implantar em dias" sem nomear quem é dono do acesso a produção.
• Fornecedores que não conseguem mostrar sua detecção de desvio rodando sobre dados reais de cliente.

O escopo do primeiro modelo segue o mesmo método da auditoria de processo antes da automação.

Conclusão

ML em produção, em sua maior parte, não é ML. É pipeline de features, monitoramento, caminho de rollback e clareza de quem é acionado quando algo quebra. Os projetos que entram no ar são os que constroem esse esqueleto primeiro. Os que travam passam meses ajustando um notebook antes de pensar em implantação. Se você consegue colocar em produção um stub que devolve uma previsão constante na semana 1 do projeto, está do lado que entra no ar. Se sua equipe está debatendo arquitetura de modelo antes de o esqueleto de implantação existir, está do outro.