Como negociar SLAs para modelos de IA em contratos com fornecedores

Negociar SLAs para modelos de IA não é a mesma coisa que contratar infraestrutura, suporte ou desenvolvimento tradicional. Um modelo pode responder com baixa latência e, ainda assim, errar com confiança, degradar por drift de dados ou apresentar vieses que só aparecem depois de semanas em produção. Por isso, o contrato precisa tratar não apenas de disponibilidade, mas também de qualidade estatística, rastreabilidade, revisão humana e responsabilidades de manutenção do modelo. A armadilha mais comum é comprar uma promessa genérica de “modelo inteligente” e tentar encaixar isso em um SLA operacional clássico. Isso costuma gerar conflito quando o sistema está “no ar”, mas o negócio não confia nas respostas. Em projetos de IA que acompanham processos críticos, como saúde, govtech, fintech ou operações industriais, a discussão precisa começar antes da linha de código, com uma auditoria técnica da arquitetura, dos dados e do papel do fornecedor na sustentação do modelo. Essa abordagem aparece com frequência em empresas que já vivem a tensão entre velocidade e segurança. Em geral, o CEO quer reduzir tempo de entrega, o CTO quer evitar dívida técnica e o fornecedor quer limitar a responsabilidade ao que ele controla. O contrato bom é o que transforma essa tensão em critérios mensuráveis, evitando discussões subjetivas quando o modelo começar a errar ou perder desempenho. Se você está estruturando uma contratação maior, vale cruzar este tema com um playbook decisório para contratar squad sênior dedicado, bodyshop ou ampliar o time interno e com um guia prático de observabilidade para produtos digitais com IA, porque o SLA só funciona quando há medição confiável e rotina de governança.

A primeira cláusula relevante é a de definição de responsabilidade técnica. Ela deve separar o que é defeito do modelo, o que é problema de integração, o que é indisponibilidade de terceiros e o que é uso fora do escopo. Se tudo cair na mesma cesta, o fornecedor vai atribuir a falha ao dado, à operação ou ao usuário, e você fica sem mecanismo objetivo de cobrança. A segunda cláusula crítica é a de mudança controlada. Modelos evoluem, prompts mudam, versões são trocadas e bases de conhecimento são atualizadas. Sem um processo formal de aprovação, o fornecedor pode alterar comportamento em produção sem que o time interno saiba, o que cria risco operacional, jurídico e reputacional. Isso vale ainda mais quando a solução toca fluxos regulados ou integrações com sistemas legados, como ERP, SAP e Power BI ou ambientes com requisitos de compliance mais rígidos. A terceira cláusula deve tratar de explicabilidade e logs. Se o modelo influencia uma decisão de negócio, uma triagem clínica, uma sugestão de crédito ou um acionamento de operação, você precisa conseguir reconstruir o contexto da resposta. Não é luxo. É defesa mínima para auditoria, contestação interna, revisão humana e investigação de incidentes. Em projetos sensíveis, a ausência de trilha costuma ser mais cara do que a própria falha do modelo. A quarta cláusula importante é a de retraining e manutenção contínua. O contrato precisa dizer quem detecta drift, quem coleta amostras de validação, quem testa nova versão, qual janela de aprovação existe e o que acontece se a performance cair abaixo do piso acordado. Em muitos casos, o fornecedor quer vender o modelo como produto pronto, mas a realidade operacional exige um ciclo vivo de observabilidade, testes e ajuste. Se o tema do seu projeto inclui segurança, LGPD ou setores regulados, complemente a análise com um checklist de segurança e compliance para projetos sensíveis e com as referências da ANPD sobre a LGPD. Por fim, inclua cláusulas de saída, portabilidade e cooperação técnica. Se o fornecedor sair, o contrato deve prever exportação de artefatos, documentação mínima, código, pesos, instruções de inferência, critérios de substituição e apoio por um período de transição. Isso evita vendor lock-in e reduz o impacto de uma troca futura, seja por performance, custo ou governança. Um bom ponto de partida é o contrato de saída e code escrow para squads alocados, porque a lógica de proteção é muito parecida.

A melhor forma de fazer essa ponte é separar resultado de operação. O SLA técnico fala sobre comportamento observável do modelo, enquanto o SLA comercial fala sobre suporte, prazos de correção, governança e continuidade do serviço. Já o resultado de negócio, como aumento de conversão ou redução de custo, costuma depender de fatores externos e não deve ser prometido de forma absoluta em contrato. Na prática, você pode negociar um contrato por camadas. A primeira camada cobre infraestrutura e inferência. A segunda cobre performance do modelo dentro de um conjunto de testes acordado. A terceira cobre governança, resposta a incidentes, revisão de vieses e relatórios executivos. Essa estrutura reduz disputa porque cada parte sabe qual problema está sendo medido. Quando o fornecedor tenta “embutir” resultado de negócio como obrigação direta, o contrato tende a ficar frágil e difícil de auditar. Um modelo saudável de contratação usa baseline, janela de avaliação e faixas de tolerância. Por exemplo, se o caso é classificação de chamados, você pode exigir uma taxa mínima de acerto em um conjunto de validação estável, mais um tempo máximo de resposta, mais um procedimento formal para quando a distribuição dos dados mudar. Não é preciso prometer que a receita vai subir, mas é possível garantir que o sistema continuará operável, rastreável e apto a escalar com previsibilidade. Para lideranças que estão avaliando se a solução deve ser construída internamente ou comprada de um parceiro, este tema se conecta diretamente ao guia decisório sobre treinar modelos próprios versus usar APIs de modelos e ao guia de negociação técnica com squad externo. A decisão de arquitetura muda o tipo de SLA que faz sentido, e ignorar isso costuma gerar custo escondido.

A negociação fica mais madura quando o fornecedor enxerga o seu risco como parte do problema, e não como obstáculo comercial. Se você trabalha com IA em setores como saúde, govtech, indústria, varejo ou fintech, o contrato precisa refletir o impacto de uma resposta errada, de uma queda de disponibilidade ou de um retrabalho em escala. Em um sistema que atende muitos usuários ou unidades de negócio, uma pequena variação de qualidade pode se tornar um custo operacional recorrente. Empresas que têm backlog grande e equipe interna sobrecarregada costumam aceitar cláusulas vagas por pressa. Esse é um erro caro. O ideal é negociar com base em artefatos, como amostras de teste, cenários de validação, dashboards, planos de rollback e relatórios periódicos. Se o fornecedor não topar medir, ele provavelmente não está pronto para sustentar o modelo em produção. Quando há maturidade, a conversa flui melhor e a operação ganha previsibilidade. Se o seu caso envolve lançamento de MVP, auditoria pré captação ou preparação para investidores, um bom contrato de IA precisa ajudar você a provar que sabe operar o modelo, não apenas demonstrar que ele existe. Essa visão é muito próxima do que a OrbeSoft aplica em projetos de software sob medida com IA: primeiro entende o problema, depois valida a solução e só então transforma isso em entrega escalável. Em outras palavras, o SLA deve proteger o uso real, não apenas o artefato técnico.