Como escolher fornecedor para operacionalizar modelos de IA em produção: RFP, SLAs e checklist de due diligence

Um bom fornecedor de MLOps precisa demonstrar capacidade em quatro frentes: pipeline de dados, ciclo de vida do modelo, operação em produção e governança. Sem isso, você pode até contratar pessoas competentes, mas não compra um sistema operável. Em produção, o que conta é o conjunto: ingestão confiável, validação de dados, versionamento, testes, deploy, monitoramento, rollback e resposta a incidentes. Na etapa de avaliação, peça evidências e não apenas slides. Exija exemplos de arquiteturas já operadas, documentação de decisões, runbooks, definição de SLIs, logs de incidentes resolvidos e padrões de segurança aplicados. Se o fornecedor trabalha com AWS, Azure ou GCP, ele precisa explicar como usa serviços gerenciados sem criar dependência excessiva e como evita custo descontrolado em inferência e armazenamento. Outro ponto crítico é saber se o parceiro entende o seu estágio. Um MVP com poucos usuários não pede a mesma estrutura de um produto enterprise, assim como um SaaS com dados regulados não pode ser tratado como um projeto experimental. Se o seu roadmap já sofre com dependências técnicas, vale cruzar este guia com Como transformar backlog técnico em roadmap de produto orientado por valor e Arquitetura de referência para produtos digitais com IA escalável: do protótipo à produção em AWS, Azure e GCP. Na prática, os fornecedores mais maduros respondem bem quando você pergunta sobre dados, operações e continuidade. Os menos preparados falam só de framework, linguagens e velocidade de entrega. Isso é um sinal útil. MLOps em produção exige disciplina operacional, não só repertório técnico.

Muitos contratos falham porque negociam SLA genérico de disponibilidade, mas esquecem o que realmente afeta o usuário. Em MLOps, você precisa separar camada de serviço, camada de dados e camada de modelo. Um modelo pode estar “no ar” e ainda assim entregar resposta ruim, atrasada ou economicamente inviável. Os SLIs mais úteis costumam ser tempo de resposta da inferência, taxa de erro do pipeline, frescor dos dados, frequência de re-treinamento, tempo de recuperação após falha e precisão mínima aceitável em validação. Para produtos com impacto financeiro, operacional ou regulatório, vale definir também limites de drift de dados e drift de conceito. Drift de dados é quando a distribuição de entrada muda; drift de conceito é quando a relação entre entrada e resultado muda, o que costuma degradar a performance silenciosamente. No contrato, peça que o fornecedor explique qual métrica aciona alerta, qual aciona investigação e qual aciona rollback. Isso evita discussão subjetiva quando um incidente acontece. Também vale estabelecer janelas de manutenção, horário de suporte, prazo de resposta e prazo de contorno, porque disponibilidade técnica sem tempo de resposta não protege operação. Se a sua empresa já sofre com incidentes e picos de tráfego, este tema se conecta diretamente com Guia prático de observabilidade para produtos digitais com IA. Outro cuidado pouco discutido é custo. Inferência em produção pode crescer rápido conforme tráfego, tamanho do modelo e requisitos de latência aumentam. Para esse ponto, o fornecedor precisa mostrar como monitora custo por requisição, custo por ambiente e custo de re-treinamento, e não apenas custo de desenvolvimento inicial. Em produtos B2B, a conta que interessa é custo total de operação, não só o orçamento do projeto.

O erro mais comum é comprar “MLOps” como se fosse um pacote de ferramentas. Ferramenta ajuda, mas não substitui desenho de processo, responsabilidade operacional e governança. Sem isso, você fica com dashboards bonitos e incidentes mal resolvidos. Outro erro frequente é não separar teste, validação e produção. Quando o mesmo fluxo serve para tudo, o risco de vazamento de dados, regressão de modelo e degradação de qualidade aumenta bastante. Em empresas com setor regulado, essa confusão pode virar problema de compliance. Em SaaS B2B, vira churn e perda de confiança do cliente. Também é comum negociar SLA de disponibilidade e esquecer estabilidade de modelo. Um sistema pode responder rápido e ainda assim recomendar errado, classificar mal ou perder precisão silenciosamente. Se a solução impacta decisão financeira, logística ou atendimento, isso é tão grave quanto downtime. Por isso, o contrato precisa refletir o que o usuário percebe, e não apenas o que a infraestrutura mede. Por fim, muita empresa subestima a saída. Se você não define propriedade de código, documentação, segredos, pipelines e conhecimento, cria dependência do fornecedor. Para evitar isso, vale usar a mesma disciplina de saída usada em contratos de squads, como discutimos em Contrato de saída e code escrow para squads alocados: checklist executivo, cláusulas essenciais e modelo negociável.