Colocar machine learning em produção exige transformar um artefato experimental em um serviço reproduzível, monitorado, seguro e com comportamento operacional mensurável. O SLA contratual deve cobrir indicadores controláveis — como disponibilidade, latência, prazo de recuperação e atualização — enquanto a qualidade preditiva precisa ser tratada por métricas, faixas de tolerância e regras explícitas sobre dados e mudança de contexto.
Por que um bom modelo ainda não é um produto
Um notebook pode demonstrar que existe sinal preditivo, mas não responde às principais perguntas de produção: de onde vêm os dados, qual versão está ativa, como detectar degradação, como desfazer uma implantação e quem atua quando algo falha.
A passagem do protótipo ao serviço operacional envolve pelo menos seis componentes:
- Pipeline de dados: coleta, validação, transformação e disponibilização das variáveis.
- Pipeline de treinamento: código reproduzível para treinar, avaliar e registrar modelos.
- Serving: API, processamento em lote, streaming ou execução embarcada.
- Observabilidade: métricas técnicas, de dados, do modelo e do negócio.
- Governança: versionamento, aprovação, rastreabilidade e controle de acesso.
- Operação: alertas, plantão, runbooks, rollback e resposta a incidentes.
MLOps é a disciplina que integra essas partes. Não se resume a automatizar deploy: ela aplica práticas de engenharia de software, dados e operações ao ciclo de vida do modelo.
Defina o contrato operacional antes da arquitetura
O primeiro passo não deveria ser escolher Kubernetes, uma feature store ou uma plataforma de experimentos. Antes disso, é necessário documentar como a predição será consumida e qual impacto uma falha terá.
Perguntas que mudam a solução
- A inferência será síncrona, em lote ou por eventos?
- Qual é o volume médio e qual é o pico esperado?
- O consumidor pode esperar segundos, minutos ou horas?
- Existe uma regra determinística para contingência?
- Quanto tempo o sistema pode ficar indisponível?
- Quando o valor real usado como rótulo ficará disponível?
- Uma previsão incorreta produz recomendação, bloqueio automático ou decisão clínica?
- Quais dados pessoais ou sensíveis serão processados?
Uma recomendação de produtos tolera condições diferentes das de um sistema hospitalar. Em contextos críticos, o modelo não deve ser o único mecanismo de decisão sem validação de risco, supervisão adequada e procedimentos de contingência.
Arquitetura mínima para machine learning em produção
Não existe uma pilha universal, mas existe um conjunto mínimo de responsabilidades que precisa ser coberto.
Dados e features
As entradas devem ter contrato de esquema, tipo, unidade, domínio aceitável, política para valores ausentes e responsável pela fonte. Validações precisam ocorrer antes do treinamento e da inferência.
Exemplos de falhas que devem bloquear ou sinalizar o pipeline:
- coluna obrigatória ausente;
- idade negativa ou fora do domínio definido;
- unidade alterada de miligramas para gramas;
- categoria nova não suportada;
- crescimento ou redução anormal do volume;
- atraso além da janela de atualização.
Treinamento e inferência também precisam compartilhar a mesma lógica de transformação. Duplicar código entre notebook e API cria training-serving skew, situação em que o modelo recebe em produção dados diferentes daqueles usados na validação.
Treinamento e registro
Cada execução deve registrar, no mínimo:
- versão do código e dos dados;
- hiperparâmetros;
- ambiente e dependências;
- métricas gerais e por segmentos relevantes;
- artefato produzido;
- data, autor ou processo responsável;
- critérios de aprovação.
O registro de modelos deve distinguir candidatos, versões homologadas, versões em produção e versões arquivadas. Promover um modelo significa aprovar um artefato imutável, não executar novamente um notebook e esperar o mesmo resultado.
Serving e contingência
O modelo pode ser exposto por API, fila, streaming ou lote agendado. A escolha deve seguir a necessidade do processo, não a ferramenta mais sofisticada.
Toda implantação deveria prever uma saída segura: retornar a última previsão válida, usar uma regra determinística, encaminhar para análise humana ou suspender a automação. O comportamento de contingência precisa constar no desenho e, quando aplicável, no contrato.
CI, CD e CT no ciclo de MLOps
Em machine learning, a automação tem três dimensões:
- CI — integração contínua: testa código, transformações, contratos de dados, segurança e compatibilidade.
- CD — entrega ou implantação contínua: empacota, homologa e publica o serviço com rollout controlado.
- CT — treinamento contínuo: inicia novo treinamento diante de agenda, novos dados ou gatilhos de degradação.
CT não significa promover automaticamente qualquer modelo mais recente. Um candidato deve passar por testes mínimos:
- qualidade dos dados;
- reprodutibilidade do treinamento;
- comparação com o modelo ativo;
- métricas por segmentos críticos;
- latência e consumo de recursos;
- vulnerabilidades de dependências;
- compatibilidade de entrada e saída;
- validação humana quando o risco exigir.
Para implantação, estratégias como shadow, canary e blue-green reduzem risco. Em shadow, o novo modelo recebe tráfego sem afetar respostas. Em canary, atende uma parcela limitada. Em blue-green, dois ambientes permitem troca e reversão rápida.
O que realmente pode entrar em um SLA
SLA é o compromisso contratual; SLO é a meta operacional; SLI é o indicador medido. Um SLA útil informa definição, janela de cálculo, fonte de medição, exclusões, responsabilidade e consequência do descumprimento.
| Dimensão | Exemplo de SLI | Observação contratual |
|---|---|---|
| Disponibilidade | requisições válidas atendidas / total | Definir códigos de erro e manutenções excluídas |
| Latência | percentil 95 ou 99 | Evitar usar somente média |
| Recuperação | tempo até restaurar o serviço | Associar a severidades de incidente |
| Atualização | tempo entre dado disponível e processamento | Depende também da fonte de dados |
| Freshness | idade máxima das features | Definir relógio e fuso de referência |
| Qualidade técnica | taxa de respostas válidas | Separar falha do serviço de erro preditivo |
Valores como 99,9% de disponibilidade ou latência p95 abaixo de 300 ms podem servir como exemplos de desenho, mas só devem virar compromisso após teste de carga, análise de dependências e cálculo de custo. Metas mais rígidas exigem redundância, capacidade ociosa, observabilidade e operação compatíveis.
Acurácia deveria estar no SLA?
A qualidade preditiva depende da distribuição dos dados, do atraso dos rótulos e de fatores que podem estar fora do controle do fornecedor. Por isso, prometer uma acurácia fixa sem definir população, período, amostra mínima e método de medição produz um contrato ambíguo.
Uma abordagem mais verificável é definir:
- métrica adequada ao problema, como precisão, sensibilidade, F1, MAE ou AUC;
- coorte e janela de avaliação;
- tamanho mínimo da amostra;
- atraso máximo para obtenção do rótulo;
- faixa de tolerância em relação ao baseline homologado;
- procedimento diante de drift;
- prazo para investigação ou retreinamento.
Em classes desbalanceadas, acurácia pode esconder falhas graves. Para detecção de eventos raros, sensibilidade, precisão, curva precision-recall e custo de falso positivo ou falso negativo costumam ser mais informativos.
Observabilidade: infraestrutura, dados, modelo e negócio
Monitorar apenas CPU e memória confirma que o processo está ativo, não que a previsão continua útil. A observabilidade precisa operar em quatro camadas.
Camada técnica
Monitore disponibilidade, erros, timeout, latência por percentil, throughput, saturação, filas e custo por inferência. Logs devem ter identificador de correlação, versão do modelo e versão do contrato de entrada, respeitando minimização de dados pessoais.
Camada de dados e modelo
Monitore valores ausentes, mudanças de esquema, categorias novas, distribuição das features, distribuição das previsões e divergência entre treinamento e produção. Drift é um sinal para investigação, não prova automática de perda de qualidade.
Quando os rótulos chegam, calcule desempenho real por período e segmentos relevantes. O alerta deve considerar volume mínimo para evitar decisões baseadas em amostras pequenas.
Camada de negócio
A métrica do modelo precisa ser conectada ao processo: conversão, tempo economizado, taxa de revisão humana, desperdício evitado ou outro resultado verificável. Correlação não demonstra causalidade; testes controlados ou desenhos quase experimentais podem ser necessários para atribuir impacto.
Checklist para chegar ao SLA contratual
Antes da entrada em produção, confirme:
- [ ] problema, usuário e decisão apoiada estão documentados;
- [ ] baseline técnico e de negócio foi definido;
- [ ] dados possuem contrato, validação e responsável;
- [ ] treinamento é reproduzível e versionado;
- [ ] modelo e dependências são artefatos imutáveis;
- [ ] testes cobrem código, dados, segurança e desempenho;
- [ ] deploy possui canary, shadow ou mecanismo equivalente;
- [ ] rollback foi testado, não apenas documentado;
- [ ] métricas possuem fonte, fórmula e janela de cálculo;
- [ ] alertas apontam para runbooks e responsáveis;
- [ ] contingência sem o modelo foi validada;
- [ ] retenção, acesso e tratamento de dados estão definidos;
- [ ] SLA separa disponibilidade de qualidade preditiva;
- [ ] responsabilidades sobre fontes externas estão explícitas;
- [ ] custo de operação foi testado em carga representativa.
Como a Predictor Solutions resolve isso
A Predictor Solutions, software house de Lavras, Minas Gerais, estrutura projetos de inteligência artificial aplicada combinando engenharia de dados, desenvolvimento de software, cloud/DevOps e segurança. O trabalho parte do processo de negócio e dos critérios mensuráveis de operação para definir pipelines, APIs, observabilidade, versionamento, implantação controlada e indicadores que possam sustentar SLOs e SLAs.
Na área de saúde, a empresa desenvolve o Predictor Health, voltado a dashboards e wearables, e o Predictor AI Hospitals, direcionado à predição de sepse, infarto e pneumonia em UTI. Esses cenários exigem atenção especial a integração — incluindo HL7 v2 e FHIR —, rastreabilidade, qualidade dos dados, controle de acesso e contingência operacional.
No conjunto de seus projetos de software e automação, a Predictor Solutions informa 9 empresas de médio e grande porte atendidas, 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. Esses resultados devem ser interpretados no contexto de cada projeto; um novo sistema precisa estabelecer baseline e método próprio de medição.
Contato: contato@predictorsolutions.com / WhatsApp +55 31 98835-3246