Machine learning em produção: do protótipo ao SLA contratual com MLOps

Colocar machine learning em produção exige transformar um modelo experimental em um serviço reproduzível, observável, seguro e operável sob metas mensuráveis. O caminho até um SLA contratual passa por definir SLOs técnicos e de negócio, automatizar dados e modelos, controlar versões, monitorar degradação e estabelecer responsabilidades para incidentes.

Por que um bom protótipo ainda não é um produto

No protótipo, o objetivo costuma ser provar que existe sinal preditivo nos dados. Em produção, o objetivo muda: entregar previsões confiáveis dentro de um processo real, continuamente e com impacto controlado.

Um notebook com boa acurácia não responde a perguntas operacionais essenciais:

• Qual versão dos dados gerou o modelo?
• O treinamento pode ser reproduzido?
• Qual latência o sistema suporta?
• O que acontece quando uma variável não chega?
• Como identificar data drift e concept drift?
• É possível voltar à versão anterior?
• Quem responde quando o serviço fica indisponível?
• Como medir o resultado quando o rótulo verdadeiro chega semanas depois?

MLOps é o conjunto de práticas que trata essas questões por meio de engenharia de software, engenharia de dados, automação, observabilidade e governança. Ele não é apenas uma ferramenta de deploy nem um pipeline de treinamento.

A arquitetura mínima de ML em produção

Uma arquitetura não precisa começar complexa, mas precisa separar responsabilidades. Os componentes mínimos são:

1. Ingestão e validação de dados: recebe dados, verifica tipos, faixas, nulidade, duplicidade e integridade.
2. Processamento de atributos: aplica transformações consistentes no treinamento e na inferência.
3. Treinamento reproduzível: registra código, configuração, dados, dependências, métricas e artefatos.
4. Registro de modelos: identifica versões, estágio de aprovação e histórico de promoção.
5. Serviço de inferência: executa previsões online, em lote ou por streaming.
6. Monitoramento: acompanha infraestrutura, qualidade dos dados, comportamento do modelo e efeito no negócio.
7. Ciclo de feedback: associa previsões aos resultados reais quando eles ficam disponíveis.

A decisão entre inferência online e em lote altera todo o desenho. Uma recomendação que precisa aparecer durante uma sessão pode exigir API online. Uma previsão diária de demanda pode ser processada em lote, com menor custo e menos pontos de falha.

Online, lote ou streaming

Use online quando a resposta precisar ser calculada sob demanda. Use lote quando previsões puderem ser pré-computadas em intervalos definidos. Use streaming quando eventos contínuos exigirem processamento próximo do tempo real.

Não adote baixa latência como requisito automático. Reduzir a latência aumenta custo, complexidade operacional e risco. O requisito deve nascer do processo de negócio, não da capacidade da tecnologia.

O caminho do protótipo ao SLA

1. Defina o contrato de dados

Antes de automatizar o modelo, documente o contrato entre produtores e consumidores de dados. Ele deve especificar:

• nomes e tipos dos campos;
• unidades e formatos;
• regras de nulidade;
• chaves e cardinalidade;
• frequência e atraso de atualização;
• tratamento de informações sensíveis;
• comportamento esperado em caso de ausência ou corrupção.

Uma mudança silenciosa de unidade, categoria ou semântica pode manter a API disponível enquanto invalida as previsões. Por isso, disponibilidade técnica não equivale a qualidade do serviço de ML.

2. Torne o treinamento reproduzível

Cada execução deve registrar, no mínimo:

• versão do código;
• referência do conjunto de dados;
• parâmetros e hiperparâmetros;
• ambiente e dependências;
• métricas por segmento relevante;
• artefato final;
• responsável e motivo da execução.

Seeds ajudam, mas não garantem determinismo em todas as bibliotecas e infraestruturas. O objetivo prático é conseguir explicar e repetir o processo dentro de tolerâncias conhecidas.

3. Crie gates de promoção

Modelos não devem chegar à produção apenas porque superaram uma métrica média. A promoção precisa passar por critérios automatizados e revisão proporcional ao risco.

Um checklist de aprovação pode exigir:

• desempenho superior ao baseline vigente;
• ausência de regressão crítica por segmento;
• validação de latência e consumo de recursos;
• análise de vazamento de dados;
• testes de contrato da API;
• verificação de segurança e dependências;
• plano de rollback;
• aprovação humana para decisões de alto impacto.

Os valores mínimos devem ser definidos a partir do custo dos erros. Em detecção de fraude, falso negativo e falso positivo têm impactos diferentes. Em saúde, uma predição deve apoiar fluxos clínicos e governança, não substituir automaticamente julgamento profissional.

4. Faça deploy progressivo

O deploy direto para toda a base amplia o impacto de falhas. Estratégias mais seguras incluem:

• shadow: o novo modelo recebe tráfego sem influenciar decisões;
• canary: apenas uma parcela controlada usa a nova versão;
• blue-green: versões antiga e nova coexistem para troca e reversão rápidas;
• A/B: versões são comparadas em grupos definidos, quando o desenho experimental for válido.

Rollback precisa incluir modelo, código de pré-processamento, configuração e esquema de atributos. Reverter apenas o arquivo do modelo pode criar incompatibilidade com o restante do pipeline.

SLI, SLO e SLA aplicados a machine learning

Esses termos não são sinônimos:

• SLI: indicador observado, como disponibilidade, latência ou percentual de entradas válidas.
• SLO: objetivo interno para um SLI durante uma janela definida.
• SLA: compromisso contratual, normalmente acompanhado de escopo, exclusões, responsabilidades e consequências.

Um SLA de ML não deve se limitar ao uptime da API. Uma API pode responder normalmente com previsões inutilizáveis. O contrato precisa distinguir pelo menos quatro dimensões.

Disponibilidade e desempenho operacional

Indicadores possíveis:

• percentual de requisições atendidas;
• latência em percentis, e não apenas na média;
• taxa de erro por endpoint;
• tempo de processamento de lotes;
• atraso máximo dos dados;
• capacidade sob carga esperada.

Os números contratuais devem refletir a arquitetura, o orçamento e o impacto da indisponibilidade. Quanto mais rígido o SLA, maior tende a ser a necessidade de redundância, plantão, testes de recuperação e capacidade reservada.

Qualidade dos dados

Monitore completude, validade, distribuição e atualização. Exemplos de SLIs são percentual de registros aceitos, frequência de campos ausentes e tempo desde a última carga válida.

É importante separar falhas do fornecedor do modelo de falhas nas fontes controladas pelo cliente ou por terceiros. Essa fronteira deve aparecer explicitamente no contrato.

Qualidade preditiva

Métricas como precisão, recall, F1, AUC, erro absoluto e calibração dependem do problema. Entretanto, métricas preditivas nem sempre podem integrar um SLA em tempo real, pois o rótulo verdadeiro pode chegar muito depois da previsão.

Nesse caso, o contrato pode combinar:

• métricas operacionais imediatas;
• indicadores de drift como alerta, não como prova isolada de queda;
• avaliação periódica em dados rotulados;
• procedimento de revalidação e retreinamento;
• regras para suspender ou substituir o modelo.

Não prometa acurácia fixa quando a distribuição dos dados está fora do controle das partes. Prefira definir método de medição, população avaliada, janela temporal, amostra mínima e tratamento de exceções.

Resultado de negócio

Conversão, economia, redução de perdas e produtividade dependem do modelo e do processo onde ele atua. Para contratualizá-los, é necessário estabelecer baseline, atribuição, janela de observação e variáveis externas. Sem isso, o indicador mistura efeito do modelo com preço, operação, sazonalidade e decisões humanas.

Monitoramento: infraestrutura, dados, modelo e negócio

A observabilidade deve conectar quatro camadas:

1. Infraestrutura: CPU, memória, filas, erros, disponibilidade e latência.
2. Dados: esquema, nulidade, categorias novas, atraso e mudança de distribuição.
3. Modelo: distribuição das previsões, confiança, calibração e desempenho quando houver rótulos.
4. Negócio: adoção, decisões alteradas, custo dos erros e resultado operacional.

Drift não significa automaticamente que o modelo piorou. Data drift indica mudança nas entradas; concept drift representa mudança na relação entre entradas e resultado. Ambos exigem investigação, mas o retreinamento automático sem validação pode incorporar dados ruins e degradar o sistema.

Alertas também precisam de runbooks. Cada alerta útil deve informar gravidade, hipótese provável, responsável, evidências e ação recomendada. Alertar tudo produz fadiga; alertar apenas indisponibilidade deixa degradações silenciosas sem resposta.

O que precisa constar no SLA contratual

Antes da assinatura, valide este checklist:

• serviço, endpoints e ambientes cobertos;
• janela de medição e fonte oficial dos indicadores;
• SLOs de disponibilidade, latência e processamento;
• critérios de qualidade e atraso dos dados;
• método e periodicidade da avaliação preditiva;
• dependências externas e exclusões justificadas;
• níveis de severidade e tempos de resposta;
• processo de comunicação e escalonamento;
• RTO e RPO quando houver recuperação de desastre;
• política de atualização, rollback e descontinuação;
• responsabilidades sobre dados, acesso e segurança;
• retenção de logs e evidências;
• consequências pelo descumprimento;
• procedimento de revisão do SLA.

Use error budgets para equilibrar confiabilidade e evolução. Se o orçamento de falhas de uma janela estiver próximo de ser consumido, a prioridade passa de novas funcionalidades para estabilização. Esse mecanismo transforma confiabilidade em decisão operacional, não apenas em relatório.

Build, comprar ou contratar uma equipe especializada

Construir internamente oferece maior controle, mas exige competências de dados, software, cloud, segurança e operação. Plataformas gerenciadas reduzem trabalho de infraestrutura, porém podem aumentar dependência tecnológica e custo em escala. Uma equipe especializada é útil quando o projeto precisa acelerar a passagem do experimento para uma operação auditável sem formar todas as disciplinas do zero.

A decisão deve considerar criticidade, volume, frequência de mudança, sensibilidade dos dados, capacidade interna e custo total de operação. Para poucos modelos em lote, uma arquitetura simples pode ser suficiente. Para modelos críticos, online e sujeitos a auditoria, automação, redundância e governança tornam-se parte do produto.

Como a Predictor Solutions resolve isso

A Predictor Solutions estrutura projetos de ML desde os contratos de dados até CI/CD, registro de modelos, deploy progressivo, observabilidade, segurança e definição de SLIs, SLOs e SLAs. A atuação combina software sob medida, inteligência artificial aplicada, engenharia de dados e cloud/DevOps; em saúde, inclui sistemas com integração HL7 v2 e FHIR, além dos produtos Predictor Health e Predictor AI Hospitals.

Como praticante, a empresa trabalha com casos como Ártemis AI, Avea, AMF, CEIS, Corrigiu, MiniMe Labs e NexusML. Em seu portfólio de nove empresas de médio e grande porte atendidas, registra R$ 1,32 milhão de economia média por cliente ao ano, aumento médio de produtividade de 70% e crescimento de lucro de 43% em seis meses. Esses resultados não substituem a definição de baseline e métricas específicas para cada novo projeto, mas demonstram a importância de ligar engenharia a indicadores verificáveis.

Contato: contato@predictorsolutions.com / WhatsApp +55 31 98835-3246