7 erros ao contratar consultoria de IA e como o contrato evita cada um

Quem vai contratar consultoria de IA pela primeira vez costuma cometer os mesmos erros. Não por descuido. É que o mercado vende IA como produto, e o comprador usa o modelo mental de compra de software: escolhe a ferramenta, negocia licença, assina. Consultoria de IA não é isso. É um serviço de engenharia com risco compartilhado, e o contrato é o único instrumento que distribui esse risco de forma honesta.

Abaixo estão os sete erros que mais vemos em propostas e contratos, e a cláusula que evita cada um. A lista serve tanto para quem está avaliando fornecedores quanto para quem já assinou e quer saber onde está exposto.

Erro 1: comprar a ferramenta antes do diagnóstico

O sintoma é uma proposta que começa pela plataforma (“vamos implantar X”) e não pelo processo. O comprador já chega com a ferramenta escolhida, muitas vezes porque viu uma demo, e a consultoria vira instalador.

O problema é que a ferramenta certa depende do processo, do volume, da sensibilidade do dado e do que já existe na empresa. Escolher antes de saber isso é escolher no escuro. E a consultoria que aceita esse arranjo sem questionar está cobrando por implantação, não por critério.

O que exigir: uma fase de diagnóstico com entregável próprio (mapa de processos candidatos, dados disponíveis, restrições regulatórias, estimativa de custo unitário) antes de qualquer compromisso com tecnologia. Se a proposta de consultoria de IA não tem essa fase separada, com preço e prazo, peça.

Erro 2: POC sem critério de sucesso

“Vamos fazer uma prova de conceito” sem definir o que prova o conceito. A POC termina, todo mundo acha interessante, e ninguém sabe se deve continuar. O projeto morre por falta de decisão, não por falta de resultado.

O critério de sucesso precisa ser numérico, do negócio, e escrito antes de começar. Não é “acurácia de 90%”. É “reduzir o tempo de triagem de 4 horas para 30 minutos em 80% dos casos, com taxa de erro que o supervisor aceita”. Se a consultoria não consegue propor esse critério, ela não entendeu o processo.

O que exigir: critério de aceite por escrito, com métrica, valor-alvo e método de medição, como condição de pagamento da etapa.

Erro 3: não definir quem fica com código, prompts e dados

É o erro mais caro e o mais silencioso. O projeto funciona, a consultoria sai, e a empresa descobre que o código está no repositório do fornecedor, os prompts são “metodologia proprietária” e os dados de avaliação foram embora junto. Trocar de fornecedor vira recomeçar.

Há modelos legítimos de licenciamento, mas eles precisam estar explícitos. O padrão que recomendamos: a empresa é dona de tudo que foi produzido especificamente para ela (código, prompts, configurações, datasets de avaliação, documentação), e a consultoria mantém apenas o que já era dela antes do projeto, listado em anexo.

O que exigir: cláusula de propriedade intelectual com lista do que é entregue, repositório em conta da empresa desde o primeiro dia, e vedação a dependência de componente que só o fornecedor pode operar.

Erro 4: ignorar LGPD e regulador até o fim

A conversa com jurídico, segurança e, em setores regulados, com quem responde ao BACEN, à SUSEP ou à ANS acontece depois da demo. Aí aparecem as perguntas: qual a base legal, o que sai do perímetro, onde fica o log, quem audita. Cada uma delas muda a arquitetura. E a arquitetura já está pronta.

Isso não é excesso de zelo. Dado pessoal entrando em modelo de linguagem tem implicações concretas de minimização, retenção e transferência internacional. Tratamos o assunto em detalhe em LGPD e modelos de linguagem. O ponto aqui é contratual: essas restrições precisam estar no escopo desde o diagnóstico.

O que exigir: anexo de tratamento de dados (quais dados, base legal, retenção, subprocessadores, localização), com aprovação do encarregado de dados antes do início da construção, e cláusula de que mudanças regulatórias durante o projeto são tratadas como alteração de escopo, não como problema do cliente.

Erro 5: sem plano de transferência para o time interno

O sistema entra em produção e só a consultoria sabe operá-lo. Cada ajuste vira chamado, cada chamado vira fatura. Não é má-fé necessariamente. É que transferência de conhecimento não acontece sozinha, e se não está no contrato, não está no cronograma.

Transferir significa: documentação de operação, sessões de treinamento com o time que vai operar, período de operação assistida em que o time interno executa e a consultoria observa, e critério de saída (o time consegue fazer determinada tarefa sem ajuda).

O que exigir: plano de transferência com marcos e horas dedicadas, e retenção de parte do pagamento final até a conclusão da operação assistida.

Erro 6: escopo aberto com cobrança por hora

Contratar consultoria de IA por hora parece flexível. Na prática, transfere todo o risco para o comprador: se o projeto demora, ele paga mais. E não há incentivo para a consultoria ser eficiente.

Isso não significa que preço fechado é sempre melhor. Projetos de IA têm incerteza real, e um preço fechado sobre escopo mal definido gera briga. O modelo que funciona é híbrido: diagnóstico com preço fechado, construção por etapas com preço fechado por etapa e critério de aceite, e operação por valor mensal com nível de serviço.

O que exigir: estrutura de preço por etapa, com gatilho de decisão entre elas (a empresa pode parar ao fim de cada uma sem penalidade) e teto de horas se houver componente variável.

Erro 7: só a TI na mesa

O contrato é negociado entre a consultoria e a TI, e a área que vai usar o sistema (financeiro, atendimento, operações) só aparece na homologação. Descobre então que o sistema resolve um problema que ela não tinha.

IA aplicada muda processo, não só sistema. Quem é dono do processo precisa participar do diagnóstico, definir o critério de sucesso e aprovar as etapas. Sem isso, a consultoria entrega o que a TI pediu, e a TI pediu o que imaginou que a área queria.

O que exigir: nomeação, no contrato, de um responsável de negócio com poder de aprovação em cada etapa, e participação dele nos rituais do projeto.

A cláusula que resolve cada erro ao contratar consultoria de IA

A tabela abaixo condensa os sete pontos. Serve como checklist para revisar uma proposta antes de assinar, ou um contrato já assinado para saber onde renegociar.

Uma consultoria séria não resiste a nenhuma dessas cláusulas. Ela as propõe. Se a resistência aparecer em propriedade intelectual ou em critério de aceite, o problema não é jurídico. É de modelo de negócio do fornecedor.

Sinais de alerta na proposta

• A primeira página fala da plataforma e não do seu processo.
• O cronograma tem “POC” como etapa, mas não tem critério de aceite escrito.
• A propriedade intelectual está descrita como “licença de uso” em vez de entrega.
• LGPD aparece como “responsabilidade do contratante” em uma linha.
• Não há horas nem marcos dedicados a treinar o seu time.
• O preço é uma estimativa de horas sem etapa, sem teto e sem ponto de saída.
• Ninguém da sua área de negócio foi entrevistado antes da proposta.

Dois ou mais sinais na mesma proposta indicam que o fornecedor vende horas, não resultado. Vale devolver com as cláusulas da tabela e ver como ele reage.

Como contratar IA para empresas sem repetir esses erros

Comece pelo diagnóstico, não pela ferramenta. Exija critério de aceite antes de cada etapa. Garanta que código, prompts e dados ficam com você. Traga jurídico e regulador para o primeiro mês, não para o último. Contrate a transferência como entregável. Pague por etapa. E coloque o dono do processo na mesa.

Se você tem uma proposta em mãos e quer saber como ela se sai nesses sete pontos, traga para uma conversa de diagnóstico. É uma hora, sem compromisso, e costuma economizar meses de contrato mal feito.