O contrato que quase destruiu um projeto excelente
Existe um projeto da minha carreira que foi tecnicamente impecável e quase virou um litígio. O modelo funcionou. As recomendações estavam corretas. O cliente ficou satisfeito com os resultados. E ainda assim, quando chegou a hora de fechar o projeto, houve um conflito sério sobre o que estava e o que não estava no escopo do que eu havia entregado.
O problema não foi incompetência de nenhum dos lados. Foi um contrato mal escrito que deixava ambiguidades em áreas críticas. O cliente entendeu que eu entregaria a implementação completa do sistema. Eu entendi que entregaria o modelo e as recomendações de implementação. Ambas as leituras eram plausíveis a partir do texto do contrato que usamos.
Esse episódio foi o mais caro da minha carreira — não em dinheiro, mas em tempo, energia e desgaste de uma relação que havia sido muito boa até aquele momento. E me forçou a repensar completamente como estruturo contratos e escopos para projetos de consultoria de IA.
O que apresento aqui é o resultado de anos de refinamento — o que aprendi com os erros, com projetos bem executados e com o framework metodológico da Trilion, que tem princípios muito claros sobre gestão de escopo e formalização de entregas.
Por que contratos de consultoria de IA são especialmente difíceis
Contratos de consultoria em geral já são mais complexos do que contratos de produto, porque o objeto da prestação de serviço é intangível e subjetivo. Em consultoria de IA, essa complexidade tem camadas adicionais que precisam ser endereçadas explicitamente:
O resultado depende de dados que você não controla: Um modelo de IA é tão bom quanto os dados que o alimentam. Se os dados do cliente são piores do que o esperado na fase de qualificação, o resultado do modelo vai ser afetado. O contrato precisa estabelecer claramente a dependência entre qualidade de dados e resultado esperado — e o que acontece se essa qualidade não for atingida.
O escopo de IA tem fronteiras difusas: O cliente que contrata 'uma solução de IA para reduzir churn' pode entender que essa solução inclui a integração com o CRM, o treinamento da equipe, o suporte pós-implantação e as iterações do modelo pelo primeiro ano. Você pode entender que inclui apenas o modelo e as recomendações de como implementá-lo. Sem definição explícita, qualquer coisa que você não entregou vai parecer omissão.
Projetos de IA mudam no meio do caminho: É quase inevitável que, durante um projeto de IA, novos dados revelem problemas ou oportunidades que não estavam no escopo original. Como você trata essas situações — absorve no escopo, cobra adicional, cria um projeto separado — precisa estar definido contratualmente antes de surgir.
A responsabilidade pelos resultados é compartilhada: Diferentemente de um produto com especificação técnica objetiva, os resultados de uma consultoria de IA dependem tanto do trabalho do consultor quanto das decisões e ações do cliente com as recomendações entregues. O contrato precisa estabelecer claramente essa distinção.
'Em consultoria de IA, o contrato mais perigoso não é o mais curto. É o que usa linguagem vaga em áreas críticas — resultado esperado, dependências de dados, escopo de implementação. A vagueza parece conveniente no fechamento e é um problema garantido na entrega.'
A estrutura de contrato que uso hoje
O contrato que uso para projetos de consultoria de IA tem oito seções principais. Vou detalhar cada uma com o racional de por que existe e o que ela precisa cobrir.
Seção 1: Objeto e definições
Define claramente o que é o projeto, qual é o problema que está sendo atacado e quais são os termos técnicos que serão usados ao longo do contrato. Essa última parte — definições — é frequentemente omitida em contratos de consultoria e é onde nasce boa parte das disputas de escopo.
Exemplos de definições que incluo explicitamente: o que é 'modelo de IA' no contexto desse projeto específico, o que significa 'entregue' versus 'implementado' versus 'em produção', quais são as fronteiras do sistema que vou desenvolver em relação a sistemas existentes do cliente.
Seção 2: Escopo detalhado de entregas
Esta é a seção mais crítica — e a que mais tempo gasto elaborando. Aqui listo todas as entregas do projeto com quatro atributos cada: descrição da entrega, formato (documento, dashboard, modelo em código, apresentação), critério de aceite (como definimos que a entrega está completa e aceita), e responsável principal (consultor ou cliente).
A inovação que aprendi com a metodologia Trilion foi a inclusão do critério de aceite explícito para cada entrega. 'Modelo de previsão de churn' sem critério de aceite pode ser contestado indefinidamente. 'Modelo de previsão de churn com AUC-ROC acima de 0.75 no dataset de validação, validado pelo responsável técnico do cliente' é objetivamente verificável.
Igualmente importante é o que está explicitamente fora do escopo — uma seção que muitos consultores omitem e que é tão importante quanto o que está dentro. 'Não estão incluídos no escopo: integração com sistemas do cliente, treinamento da equipe operacional além das 4 horas previstas no Marco 5, suporte técnico pós-entrega além de 30 dias.'
Seção 3: Dependências e responsabilidades do cliente
Essa seção lista tudo o que o cliente precisa fazer para que o projeto seja bem executado. Acesso a dados, designação de ponto de contato técnico, participação em reuniões de validação, disponibilização de ambiente de testes, aprovações em prazo definido.
E aqui está uma cláusula que considero essencial: o que acontece se o cliente não cumpre essas responsabilidades. 'Se o acesso ao sistema de dados não for disponibilizado até [data], o cronograma do projeto será ajustado proporcionalmente ao atraso, sem impacto no valor contratado.' Isso protege tanto o consultor quanto o cliente — e deixa claro que o cronograma não é responsabilidade unilateral do consultor.
Seção 4: Qualidade de dados e limitações do modelo
Esta seção é específica para contratos de consultoria de IA e raramente existe em contratos genéricos de consultoria. Ela estabelece:
- As premissas de qualidade de dados sobre as quais o projeto foi dimensionado
- O processo de avaliação de qualidade de dados que acontecerá nas primeiras semanas do projeto
- O que acontece se os dados reais forem significativamente piores do que as premissas: o escopo pode ser ajustado, o prazo pode ser estendido, ou o projeto pode ser reescoped para incluir uma fase de preparação de dados antes de avançar
- As limitações inerentes ao modelo — qualquer modelo preditivo tem taxa de erro, e essa taxa precisa estar explicitada para que as expectativas de resultado do cliente sejam calibradas corretamente
Seção 5: Propriedade intelectual e confidencialidade
Duas perguntas que precisam de resposta explícita: a quem pertencem os modelos desenvolvidos no projeto? E como são tratados os dados do cliente?
Minha abordagem padrão: a metodologia e o know-how pertencem a mim — eles são o capital intelectual que continuarei desenvolvendo e refinando. O modelo específico treinado com os dados do cliente pertence ao cliente. O código fonte do modelo é entregue ao cliente ao final do projeto. Os dados do cliente são tratados com absoluta confidencialidade e não são usados em nenhum outro contexto.
Para projetos em setores com regulamentação específica — saúde, finanças — incluo um adendo de conformidade regulatória que detalha como os dados serão tratados em alinhamento com LGPD e normas setoriais.
Seção 6: Gestão de mudança de escopo
O protocolo de change management é onde mais projetos de consultoria perdem dinheiro e criam conflito. Quando o escopo muda — e vai mudar —, precisa haver um processo claro para como a mudança é solicitada, avaliada, precificada e aprovada.
O processo que uso:
- Qualquer solicitação de mudança de escopo é documentada formalmente pelo cliente ou pelo consultor (e-mail com o template correto, não mensagem de WhatsApp)
- O consultor avalia o impacto em prazo e custo em até 3 dias úteis
- O cliente aprova formalmente a mudança antes de qualquer trabalho adicional começar
- Mudanças acumuladas que representam mais de 20% do escopo original demandam um aditivo contratual formal
Esse processo parece burocrático. Na prática, ele protege a relação com o cliente — porque define um espaço seguro onde mudanças de escopo são tratadas como normais e esperadas, não como conflito.
Seção 7: Pagamento e marcos financeiros
Nunca aceito pagamento integral adiantado. Nunca aceito pagamento integral ao final. A estrutura que uso é baseada em marcos: uma porcentagem na assinatura do contrato, porcentagens parciais em marcos definidos ao longo do projeto, e um saldo final na entrega e aceite da última entrega.
A distribuição exata varia por projeto, mas a lógica é sempre a mesma: cada pagamento está atrelado a um marco verificável. Isso alinha incentivos para ambos os lados — eu preciso entregar os marcos para receber, o cliente precisa validar os marcos para avançar.
Incluo também uma cláusula de suspensão: se o pagamento de um marco atrasar mais de X dias úteis, o projeto é suspenso automaticamente até regularização. Isso nunca precisou ser ativado, mas a existência da cláusula — conhecida por ambos os lados — previne que o atraso aconteça.
Seção 8: Resolução de conflitos e encerramento
Como disputas são resolvidas, qual o foro de eleição (onde aplicável), e o processo de encerramento do projeto — tanto bem-sucedido quanto prematuro.
Para o encerramento prematuro, incluo dois cenários: encerramento por iniciativa do cliente (com percentual de cancelamento baseado no trabalho realizado até aquele ponto) e encerramento por iniciativa do consultor (nos casos em que o cliente não cumpre as responsabilidades essenciais após notificação formal).
'Um bom contrato de consultoria de IA não é um instrumento de desconfiança. É um instrumento de alinhamento. Quando ambas as partes sabem exatamente o que foi acordado, a energia do projeto vai toda para entregar resultado — não para resolver ambiguidades.'
O que aprendi sobre comunicação de escopo
Contrato bem escrito é necessário, mas não suficiente. A comunicação de escopo precisa acontecer ativamente ao longo do projeto — não apenas uma vez no momento da assinatura.
Práticas que adotei:
Revisão de escopo em cada Milestone: Em toda reunião de Milestone, reviso explicitamente com o cliente: o que está incluído no escopo daqui para frente, o que está fora do escopo, e se há alguma expectativa sobre o projeto que ainda não foi formalizada. Essa conversa regular previne o acúmulo silencioso de expectativas não alinhadas que é a causa mais comum de conflito de escopo.
Registro escrito de alinhamentos informais: Toda vez que uma decisão relevante de escopo é tomada em conversa informal — em reunião, por telefone, por mensagem — envio um e-mail de confirmação. 'Conforme alinhamos hoje, vamos incluir [X] no escopo e remover [Y].' Isso cria um trail documentado de cada mudança.
Relatório mensal de status de escopo: Todo mês, envio ao cliente um relatório de duas páginas que inclui: entregas concluídas, entregas em andamento, próximas entregas, mudanças de escopo registradas no período e status do orçamento consumido versus orçamento total. Transparência total, proativamente.
Os erros que cometi e que você não precisa cometer
Além do episódio que abriu este artigo, aprendi com outros erros específicos de gestão contratual em projetos de IA:
- Aceitar briefing verbal como definição de escopo: Tudo que foi dito na reunião de briefing precisa ser confirmado por escrito antes de a proposta ser elaborada. O que o cliente diz na reunião e o que ele assina podem ser muito diferentes.
- Não incluir cláusula de dependência de terceiros: Em projetos que dependem de integração com sistemas de terceiros — ERP, CRM, plataformas de e-commerce —, a viabilidade técnica da integração precisa estar documentada como premissa. Se o fornecedor do ERP do cliente não disponibiliza API ou cobra além do previsto, isso não pode ser risco do consultor.
- Escopar resultados em vez de entregas: Nunca escopo 'redução de 30% no churn em 12 meses'. Escopo 'modelo preditivo de churn treinado e validado, com documentação completa e plano de ação para implementação'. O resultado depende de muitas variáveis além do meu controle. A entrega está totalmente dentro do meu controle.
O template que uso como base
Depois de anos refinando, tenho um template de contrato que cobre todas as seções que descrevi, adaptável para diferentes tipos de projeto de consultoria de IA. Não é um template jurídico formal — recomendo sempre uma revisão por advogado para projetos de maior valor. É uma base sólida que garante que as questões críticas sejam endereçadas.
A Trilion foi uma das referências que mais influenciou a estrutura desse template — especialmente nas seções de gestão de escopo, dependências de dados e critérios de aceite. O framework Trilion é muito claro sobre a importância de formalizar expectativas antes do projeto começar, não depois de o problema aparecer.
Próximos passos
Se você quer estruturar melhor seus contratos de consultoria de IA ou está começando a montar sua operação de consultoria e precisa de uma base sólida, tenho um material direto ao ponto.
Template de contrato — baixe o template que uso como base para todos os meus projetos de consultoria de IA. Inclui todas as oito seções descritas neste artigo, exemplos de cláusulas para as situações mais críticas e um guia de adaptação para diferentes tipos de projeto e escopo.
Ou entre em contato se quiser discutir um projeto específico ou aprofundar qualquer aspecto do processo de estruturação de escopo e contrato.
