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

Colocar machine learning em produção exige transformar um experimento em um serviço reproduzível, observável, seguro e operável sob condições reais. MLOps conecta dados, modelos, infraestrutura e processos para que métricas técnicas — como disponibilidade, latência, qualidade das previsões e tempo de recuperação — possam ser convertidas em SLOs mensuráveis e, quando necessário, em um SLA contratual.

Por que um bom protótipo ainda não é um sistema de produção

Um notebook pode demonstrar que existe sinal preditivo nos dados, mas normalmente não resolve ingestão contínua, versionamento, autenticação, monitoramento ou recuperação de falhas. Também pode depender de arquivos locais, etapas manuais e bibliotecas sem versões fixadas.

A passagem para produção muda a pergunta. Em vez de apenas “o modelo acerta?”, a equipe precisa responder:

• Qual versão dos dados gerou cada modelo?
• A inferência funcionará com dados incompletos ou atrasados?
• Quanto tempo a resposta pode levar?
• Como detectar degradação sem conhecer imediatamente o resultado real?
• Quem recebe o alerta e decide entre manter, reverter ou retreinar?
• O sistema continuará funcionando se o modelo estiver indisponível?
• Quais compromissos podem ser assumidos em contrato?

A unidade operacional deixa de ser somente o arquivo do modelo. Ela passa a incluir código de transformação, contrato de dados, ambiente de execução, infraestrutura, políticas de segurança, telemetria e procedimentos de incidente.

O que MLOps precisa controlar

MLOps aplica princípios de engenharia de software, dados e operações ao ciclo de vida de machine learning. Uma implementação consistente controla quatro tipos de artefato.

Dados e atributos

Os dados precisam ter origem, esquema, período e regras de qualidade registrados. Mudanças aparentemente pequenas — unidade de medida, categoria nova, campo renomeado ou alteração de preenchimento — podem invalidar as transformações aprendidas.

O contrato de dados deve definir pelo menos:

• campos obrigatórios e opcionais;
• tipos, unidades e valores permitidos;
• tratamento de dados ausentes;
• frequência e atraso esperado de atualização;
• identificação de dados pessoais ou sensíveis;
• política de retenção e descarte;
• responsável pela origem de cada conjunto.

Em saúde, por exemplo, uma integração baseada em HL7 v2 ou FHIR precisa separar a validade estrutural da mensagem da validade clínica do conteúdo. Receber um recurso FHIR válido não garante que os valores necessários para uma predição estejam presentes ou temporalmente coerentes.

Código, ambiente e dependências

Transformações de treinamento e inferência devem compartilhar a mesma implementação sempre que possível. Isso reduz o risco de training-serving skew, situação em que o modelo é treinado com uma lógica e executado com outra.

Código-fonte, imagem de contêiner, dependências, configurações e infraestrutura como código precisam ser versionados. A reconstrução de uma versão não pode depender da memória de quem executou o treinamento.

Modelo e evidências de validação

O registro do modelo deve associar cada versão a:

• conjunto e intervalo temporal dos dados;
• hiperparâmetros e código de treinamento;
• métricas por segmento relevante;
• aprovação técnica e, quando aplicável, aprovação de negócio;
• limitações conhecidas;
• imagem ou ambiente usado na inferência;
• critérios de promoção e reversão.

A métrica adequada depende do custo do erro. Acurácia pode esconder falhas em classes raras; por isso, precisão, recall, especificidade, F1, área sob a curva e calibração devem ser avaliadas conforme o caso. Em modelos de regressão, MAE, RMSE e erro por faixa podem oferecer leituras complementares.

Serviço operacional

O modelo precisa ser empacotado como serviço em lote, API síncrona, consumidor de eventos ou componente embarcado. A arquitetura deve corresponder ao processo de negócio, e não ao formato mais conveniente durante o protótipo.

Uma API online favorece decisões imediatas, mas exige disponibilidade e controle de latência. O processamento em lote tende a simplificar custos e reprocessamento, porém introduz atraso. Streaming reduz o intervalo entre evento e previsão, ao custo de maior complexidade operacional.

Pipeline do protótipo até a produção

Um fluxo auditável pode ser organizado nas seguintes etapas:

1. Validar o problema: definir decisão suportada, público afetado, custo dos erros e alternativa sem ML.
2. Criar uma linha de base: comparar o modelo com regra simples, processo atual ou modelo anterior.
3. Versionar os dados: registrar origem, recorte temporal, transformações e validações.
4. Automatizar o treinamento: remover etapas manuais e gerar artefatos rastreáveis.
5. Executar testes: cobrir código, esquema, transformações, integração e comportamento do modelo.
6. Registrar e aprovar: armazenar modelo, métricas, limitações e responsáveis pela promoção.
7. Implantar gradualmente: usar shadow deployment, canary ou blue-green conforme o risco.
8. Monitorar: observar infraestrutura, dados, previsões, resultados e impacto no processo.
9. Operar incidentes: manter alertas acionáveis, runbooks, rollback e responsáveis definidos.
10. Reavaliar: retreinar ou retirar o modelo quando as premissas deixarem de valer.

Shadow deployment executa o modelo novo sem usar sua resposta na decisão real. Canary libera a versão para uma parcela controlada do tráfego. Blue-green mantém ambientes separados e permite trocar entre versões. O método deve ser escolhido pela possibilidade de observar resultados, pelo impacto de uma previsão incorreta e pelo custo de manter infraestrutura duplicada.

Como converter métricas de MLOps em SLO e SLA

SLI é o indicador medido, como disponibilidade ou latência. SLO é a meta interna definida para esse indicador. SLA é o compromisso contratual, normalmente acompanhado de escopo, exclusões, método de apuração e consequência por descumprimento.

Não é seguro prometer contratualmente a mesma meta usada internamente. O SLO deve preservar margem para investigação, manutenção e variações esperadas. Os valores precisam ser calculados a partir da criticidade, da arquitetura e de medições reais; números genéricos copiados de outro sistema não representam a capacidade do serviço.

Dimensões que podem entrar no SLA

• Disponibilidade: percentual de solicitações atendidas dentro da janela acordada.
• Latência: percentil da duração, e não apenas média.
• Taxa de erro: respostas técnicas inválidas, timeouts ou falhas de processamento.
• Atualidade dos dados: atraso máximo entre origem, processamento e disponibilidade.
• Recuperação: prazo para restaurar o serviço ou ativar uma versão anterior.
• Suporte: canais, horários, severidades e tempos de resposta.
• Rastreabilidade: capacidade de identificar versão do modelo, entrada e resultado.

Qualidade preditiva exige tratamento diferente. O resultado real pode chegar dias ou meses depois, e a distribuição observada pode mudar. Em vez de garantir que cada previsão estará correta, o contrato pode especificar método de avaliação, população elegível, janela temporal, tratamento de dados ausentes e procedimento quando a métrica cair abaixo do limite acordado.

O que o contrato deve esclarecer

Um SLA de ML precisa definir fronteiras de responsabilidade. A degradação foi causada pelo serviço, por dados enviados fora do contrato ou por mudança no processo que gera os rótulos? Sem essa separação, a discussão contratual se torna subjetiva.

Inclua no documento:

• fórmula e fonte de cada indicador;
• janela de medição e fuso horário;
• dependências externas;
• períodos de manutenção;
• critérios de exclusão;
• classificação de incidentes;
• responsáveis por comunicação e decisão;
• política de rollback;
• processo para contestar medições;
• consequência e plano corretivo em caso de violação.

Monitoramento: infraestrutura, dados, modelo e negócio

Monitorar apenas CPU e memória não indica se o modelo continua útil. Uma operação madura combina quatro camadas.

Infraestrutura: disponibilidade, latência, filas, erros, consumo de recursos e falhas de dependências.

Dados: esquema, completude, faixas, categorias desconhecidas, atraso e distribuição dos atributos. Data drift indica mudança estatística nas entradas, mas não prova perda de qualidade.

Modelo: distribuição das previsões, confiança, calibração, métricas com rótulos disponíveis e desempenho por segmento. Concept drift ocorre quando a relação entre entradas e resultado muda.

Negócio: adesão às recomendações, decisões modificadas, resultados e possíveis efeitos adversos. Um modelo tecnicamente estável pode não gerar valor se estiver desconectado do fluxo de trabalho.

Cada alerta deve informar severidade, evidência, responsável e ação recomendada. Alertas sem runbook produzem ruído; retreinamento automático sem critérios pode promover um modelo pior. Para aplicações críticas, aprovação humana e implantação gradual costumam ser controles mais seguros.

Checklist de prontidão para produção

Antes da liberação, confirme:

• [ ] problema, usuários e decisão estão documentados;
• [ ] existe baseline comparável;
• [ ] dados e transformações são versionados;
• [ ] treino e inferência são reproduzíveis;
• [ ] testes automatizados fazem parte do pipeline;
• [ ] modelo possui registro, responsável e limitações conhecidas;
• [ ] segredos não estão no código ou na imagem;
• [ ] acessos seguem privilégio mínimo;
• [ ] logs evitam exposição indevida de dados pessoais;
• [ ] métricas e alertas têm responsáveis;
• [ ] rollback foi testado;
• [ ] SLI, SLO e método de apuração estão definidos;
• [ ] dependências e exclusões do SLA estão documentadas;
• [ ] há plano para drift, retreinamento e desativação.

Como a Predictor Solutions resolve isso

A Predictor Solutions implementa machine learning como parte de sistemas operáveis, combinando engenharia de dados, software sob medida, inteligência artificial aplicada, cloud/DevOps e segurança ofensiva. Em saúde, trabalha com integração HL7 v2 e FHIR e mantém produtos como o Predictor Health, voltado a dashboards e wearables, e o Predictor AI Hospitals, direcionado à predição de sepse, infarto e pneumonia em UTI.

A abordagem conecta contratos de dados, pipelines reproduzíveis, registro de modelos, implantação controlada, observabilidade e definição de indicadores que possam sustentar SLOs e SLAs. A empresa, sediada em Lavras, Minas Gerais, já atendeu 9 organizações de médio e grande porte; nos projetos realizados, registra economia média de R$ 1,32 milhão por cliente ao ano, aumento médio de produtividade de 70% e crescimento de lucro de 43% em seis meses.

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