Resposta direta: um bom contrato de serviços de IA deve transformar promessas em evidências verificáveis. Além do escopo, preço e prazo, o SOW precisa definir resultado, critérios de aceitação, dados e propriedade intelectual, modelos e terceiros, risco e segurança, operação e mudanças, além de transferência e saída. A redação jurídica depende da jurisdição; este guia organiza decisões comerciais e técnicas para revisão pelo jurídico.
Contratos tradicionais de software falham quando tratam IA como uma entrega determinística. Um sistema pode mudar com novos dados, modelos, prompts, políticas e padrões de uso. Por isso, “funcionar” não é um critério suficiente. O contrato precisa dizer como desempenho será medido, em quais condições, quem aceita o risco residual e o que acontece quando a solução degrada.
AI Contract Evidence-7: sete evidências antes da assinatura
Para cada dimensão, peça três elementos: uma obrigação clara, a evidência que comprova seu cumprimento e a decisão decorrente. Pontue cada item de 0 a 3: ausente, descrito, mensurável ou operacionalmente testado. Uma proposta com preço atraente, mas sem evidência em dados, aceitação ou saída, transfere custo e risco para depois da assinatura.
1. Resultado: qual mudança de negócio está sendo comprada?
Defina processo, público, decisão ou tarefa afetada, baseline, métrica e janela de observação. Separe entregáveis do fornecedor — discovery, protótipo, integrações, avaliações e runbooks — dos resultados do negócio, que também dependem de adoção e operação do cliente. Determine product owner, premissas e dependências. Evite promessas vagas como “aumentar eficiência com IA”.
2. Aceitação: que teste libera cada pagamento e fase?
Anexe conjunto de avaliação, casos normais, exceções, limiares, revisão humana e ambiente de teste. Defina critérios para qualidade, latência, disponibilidade, custo por tarefa, segurança e experiência. Inclua quem executa, quem observa, como divergências são tratadas e quando há reexecução. Aceite por evidência, não por apresentação.
Use gates progressivos: decisão de seguir após discovery; prova de valor com dados representativos; readiness para produção; e estabilização pós-lançamento. Sistemas probabilísticos podem usar faixas e tolerâncias, mas o método, a amostra e a regra de decisão precisam ser reproduzíveis.
3. Dados e propriedade: quem pode usar o quê, para qual finalidade?
Mapeie dados de entrada, dados derivados, feedback, logs, prompts, embeddings, outputs e dados pessoais. Registre finalidade, base de acesso, retenção, localização, exclusão, suboperadores e possibilidade de treinamento. Diferencie propriedade de ativos preexistentes, código criado, configurações, avaliações e conteúdo. No Brasil, valide LGPD e transferências internacionais com jurídico e privacidade.
4. Modelos e terceiros: quais dependências podem mudar?
Liste modelos, APIs, bibliotecas, nuvens e componentes críticos, inclusive suas versões e restrições. Exija divulgação de substituições materiais, testes antes de upgrades e impacto em preço, desempenho ou direitos. Defina quem aprova mudança de modelo, como se evita lock-in não planejado e quais componentes podem ser substituídos. A cadeia de fornecimento precisa ser visível o bastante para governar.
5. Risco e segurança: quais controles viram obrigação operacional?
Conecte classificação de risco a acessos, segregação de ambientes, testes, revisão humana, red teaming quando proporcional, resposta a incidentes, logs e auditoria. NIST recomenda gerenciar riscos de tecnologias e provedores terceiros ao longo do ciclo de vida; o SP 800-218A leva práticas de desenvolvimento seguro ao software de IA. Defina prazos de notificação e responsabilidades, sem prometer risco zero.
6. Operação e mudança: quem mantém qualidade depois do lançamento?
Especifique SLOs, observabilidade, suporte, escalonamento, custo operacional, manutenção de avaliações e cadência de revisão. Defina gatilhos para revalidação: troca de modelo, novo conjunto de dados, mudança de finalidade, aumento de autonomia ou incidente. Separe correção, melhoria e mudança de escopo para evitar disputas. NIST orienta monitoramento contínuo de recursos de terceiros.
7. Transferência e saída: o cliente consegue continuar ou trocar?
Liste código, repositórios, documentação, configuração, prompts, avaliações, dados exportáveis, chaves, runbooks e capacitação. Determine formato, prazo e teste de portabilidade. Inclua assistência de transição, destruição ou devolução de dados e continuidade durante a saída. A dependência permanente pode ser uma escolha econômica, mas não deve ser surpresa.
Como estruturar o pacote contratual
- MSA: termos comerciais, confidencialidade, responsabilidade e regras gerais. SOW: resultado, fases, equipe, dependências, preço, aceite e mudança. Anexo de IA: dados, modelos, avaliações, riscos, transparência e controles. Anexo operacional: SLOs, suporte, incidentes, monitoramento e custos. Plano de saída: portabilidade, transferência e encerramento.
Teste final antes de assinar
Escolha um cenário crítico e uma falha plausível. Peça ao fornecedor para mostrar qual obrigação se aplica, qual evidência será produzida, quem decide, quanto tempo leva e qual remédio contratual existe. Se a resposta depender de boa vontade ou de uma reunião futura, o SOW ainda não está pronto. As cláusulas-modelo da União Europeia são referência útil, mas não constituem um contrato completo e devem ser adaptadas.
Próximo passo
Comece com o guia de RFP em https://makinai.co/insights/pt/como-criar-rfp-servicos-ia, compare estratégia e implementação em https://makinai.co/insights/pt/consultoria-estrategia-ou-empresa-implementacao-ia e estime investimento em https://makinai.co/insights/pt/quanto-custa-consultoria-ia-orcamento-prazo. Para conectar decisão, construção e operação, veja https://makinai.co/services/pt/consultoria-estrategia-ia-transformacao.