Um contrato de consultoria de IA que protege os dois lados precisa de sete peças: escopo com entregável nomeado, critério de aceite objetivo, propriedade dos dados e fluxos no cliente, confidencialidade bilateral, SLA de suporte com canal e prazo, condição de saída com transição assistida, e uma lista escrita do que fica fora. Isso é orientação geral, não parecer jurídico: revisa com advogado antes de assinar.
A maioria dos contratos de consultoria de IA que a gente já viu (inclusive os nossos, nas primeiras versões) erra pro mesmo lado: protege demais quem vende e de menos quem contrata, ou vice-versa quando o cliente tem mais poder de barganha. Contrato bom não é o que favorece um lado, é o que deixa claro o que cada um deve ao outro antes de qualquer coisa dar errado.
O que precisa ter um contrato de consultoria de IA pra proteger os dois lados?
Sete cláusulas mínimas, na ordem que costuma gerar problema quando falta: escopo nomeado, critério de aceite, propriedade de dados e fluxos, confidencialidade nos dois sentidos, SLA de suporte, saída com transição assistida, e lista do que está fora. Faltando qualquer uma delas, o risco não desaparece, só migra pra quem tem menos poder de negociação na hora que o problema aparece.
Não acho que exista contrato “genérico” bom o suficiente pra qualquer projeto de IA. Pq cada implantação muda de entregável, de dado sensível envolvido e de dependência do time interno, e cláusula copiada de outro contrato raramente cobre o risco específico do seu caso.
Como escrever o escopo do contrato de IA sem cair em “implantação de IA”?
Nomeando o entregável, não o conceito. “Implantação de IA” não significa nada assinável; “agente de qualificação de leads integrado ao WhatsApp e ao CRM, com até 3 fluxos de resposta configurados” significa. Escopo vago é o motivo mais comum de acordo virar mal-entendido.
Um projeto como o Super SDR, por exemplo, tem setup na faixa de R$8-15 mil justamente porque o escopo inclui mapeamento de processo, integração com CRM e configuração de fluxo, item por item, não uma linha genérica de “implantação”. Se o contrato não nomeia o que está incluído, o cliente assume que tudo cabe ali dentro, e o fornecedor assume que só cabe o mínimo. Os dois estão certos dentro da própria leitura, e é exatamente aí que nasce o atrito.
O que é critério de aceite num contrato de IA e por que ele evita a maior briga?
É a definição escrita, objetiva e mensurável do que significa “entregar” aquele projeto, combinada antes do início, não depois que o sistema já está rodando. Sem critério de aceite, “funcionar” vira opinião: o fornecedor acha que sim, o cliente acha que não, e ninguém tem o que apontar no papel.
Critério de aceite bom cita número ou comportamento verificável, tipo “responde mensagem recebida em até X minutos durante horário comercial” ou “qualifica lead segundo os 4 critérios definidos no diagnóstico”. Critério ruim é “sistema funcionando conforme esperado”, porque “esperado” nunca foi escrito em lugar nenhum.
Quer revisar o escopo do seu contrato antes de assinar?
No diagnóstico gratuito a gente olha seu projeto e mostra qual cláusula de aceite faz sentido pro seu caso, sem enrolação.
Quero fazer o diagnóstico gratuitoDe quem são os dados, prompts e fluxos configurados durante o projeto?
Deveriam ser do cliente, por cláusula explícita, sempre. Base de leads, histórico de conversa, fluxo de automação desenhado e prompt customizado nasceram da operação do cliente, mesmo que o fornecedor tenha feito a configuração técnica.
Isso já apareceu em outro texto nosso sobre fidelidade contratual, e continua valendo aqui: contrato que não deixa a propriedade escrita abre brecha exatamente na hora de sair, quando o cliente já está insatisfeito e com menos força de negociação. Um agente como o Super SDR, por exemplo, roda em cima de dado de CRM e histórico de WhatsApp que já eram do cliente antes do projeto começar, então a lógica configurada em cima disso segue a mesma regra. A exceção legítima é a metodologia interna do fornecedor (o processo de diagnóstico, o framework de priorização), que é propriedade intelectual dele mesmo, não do cliente. O que muda de mão é o que foi construído em cima da operação específica daquele cliente, não o método genérico.
Como funciona a confidencialidade bilateral num contrato de IA?
Protegendo os dois lados ao mesmo tempo, não só um. O cliente expõe dado sensível de operação (lista de cliente, número de faturamento, processo interno) pro fornecedor durante o diagnóstico. O fornecedor expõe metodologia proprietária, estrutura de prompt e lógica de fluxo pro cliente durante a implantação.
Contrato de confidencialidade unilateral (só protegendo o fornecedor, por exemplo) é sinal de que quem redigiu pensou só no próprio risco. Cláusula bilateral trata os dois tipos de informação sensível como equivalentes em proteção, mesmo que a natureza do dado seja diferente.
O que precisa estar escrito no SLA de suporte?
Canal de contato definido e prazo de resposta por gravidade, não a promessa verbal de “a gente resolve rápido”. SLA sem prazo escrito é decoração: parece proteção, mas não segura nada quando o sistema trava numa sexta à noite.
SLA razoável costuma separar por gravidade: bug crítico (sistema parado) com prazo curto em horas úteis, ajuste não urgente com prazo maior, sempre dentro de um canal nomeado (WhatsApp, e-mail, ticket), não “manda mensagem que a gente vê”. Fornecedor que promete suporte 24h sem cobrar por isso, na prática, raramente sustenta a promessa depois dos primeiros meses de contrato.
O que acontece se o contrato terminar: eu fico refém do fornecedor?
Só se a cláusula de transição assistida não existir. Quando o contrato termina, seja por fim natural do prazo ou rescisão justificada, o fornecedor deveria ter obrigação contratual de exportar dados e documentar a lógica do fluxo o suficiente pra outro fornecedor, ou o time interno, assumir sem recomeçar do zero.
Isso vale mesmo dentro de contrato com fidelidade. Fidelidade de 12 meses costuma ser o padrão que a gente vê no mercado brasileiro pra projeto com setup pesado, mas fidelidade sem cláusula de saída por não-entrega transfere todo o risco pro cliente. As duas cláusulas (saída por não-entrega e transição assistida) andam juntas: uma resolve o “posso sair”, a outra resolve “o que eu levo comigo quando saio”.
O que fica fora do escopo por escrito (e por que evita orçamento extra depois)?
A lista negativa: integração com sistema novo contratado depois, treinamento de colaborador que entra na função meses depois, mudança grande de processo que não estava no diagnóstico original. Escopo positivo diz o que está incluído; lista negativa diz o que definitivamente não está, mesmo parecendo relacionado.
A maioria dos atritos de contrato de IA nasce exatamente daqui: cliente acha que “manutenção” cobre qualquer ajuste futuro, fornecedor entende que cobre só o que já foi configurado no escopo original. Escrever a lista negativa evita a frase “isso não estava no contrato” seis meses depois, quando os dois lados já estão irritados um com o outro.
O que o fornecedor pode exigir do cliente por contrato?
Cooperação mínima, também escrita, não deixada de boca. Três itens costumam aparecer: acesso aos sistemas necessários (CRM, WhatsApp Business, planilha de processo) dentro de um prazo combinado; um dono interno do projeto (o “campeão”), não uma pessoa diferente a cada reunião; e prazo de feedback definido pra validar entregas parciais, porque projeto trava quando o cliente demora semanas pra aprovar uma etapa.
Sendo bem sincero, contrato que só cobra do fornecedor e nada do cliente também está desequilibrado, só que pro lado contrário do que a gente vê com mais frequência. Se o cliente atrasa acesso a sistema ou não define quem aprova entrega, o cronograma atrasa por causa dele, não do fornecedor, e isso precisa estar escrito pra não virar discussão de quem errou depois.
FAQ
Contrato de consultoria de IA precisa de advogado especializado em tecnologia?
Ajuda, mas o essencial é ter alguém revisando antes de assinar, mesmo que não seja especialista em IA especificamente. As cláusulas que mais protegem (escopo nomeado, critério de aceite, propriedade de dados, SLA) são princípios de contrato de serviço técnico em geral, não exigem jurisprudência específica de inteligência artificial. Este texto é orientação geral, não substitui revisão jurídica formal do seu caso.
Escopo genérico tipo “implantação de IA” é motivo pra recusar o contrato?
Não pra recusar de cara, mas é motivo pra pedir revisão antes de assinar. Peça pro fornecedor listar entregável por nome (qual sistema, qual integração, quantos fluxos) em vez do termo genérico. Fornecedor que resiste a nomear o escopo específico, quando questionado, costuma estar deixando margem pra cobrar item extra depois como se sempre tivesse ficado de fora. Contrato com escopo nomeado deixa claro, desde o início, o que já está pago e o que vira orçamento à parte, o que evita boa parte da fricção quando o projeto avança e aparece pedido fora do combinado.
Quem é dono do prompt customizado depois que o contrato termina?
Deveria ser o cliente, porque o prompt foi escrito em cima da operação e do vocabulário específico daquele negócio, não é metodologia genérica do fornecedor. Isso precisa estar em cláusula explícita de propriedade de dados e fluxos, do jeito que a gente já detalhou em outro texto sobre fidelidade contratual. Sem essa cláusula escrita, a discussão só aparece na hora de sair, com o cliente em posição mais fraca de negociação.
Confidencialidade bilateral é diferente de confidencialidade normal?
Sim. Confidencialidade unilateral protege só um lado (normalmente o fornecedor, contra o cliente divulgar a metodologia dele). Confidencialidade bilateral protege os dois: o cliente contra o fornecedor divulgar dado sensível de operação, e o fornecedor contra o cliente divulgar estrutura proprietária de prompt ou processo interno. Contrato que só tem cláusula unilateral está desequilibrado, mesmo que pareça padrão de mercado.
O que acontece se o cliente não cumprir a cláusula de cooperação?
Depende do que o contrato define, e por isso ela precisa estar escrita com prazo, não como expectativa implícita. Contrato bem redigido prevê que atraso de acesso a sistema ou de aprovação de etapa por parte do cliente desloca o cronograma proporcionalmente, sem penalizar o fornecedor por atraso que não foi causado por ele. Sem essa cláusula, discussão sobre “de quem foi a culpa pelo atraso” fica sem critério objetivo.
SLA de suporte sem prazo em horas é sempre red flag?
Quase sempre. SLA que diz só “suporte incluso” sem separar gravidade nem prazo de resposta é promessa vaga, não cláusula. Peça pro fornecedor definir prazo por tipo de problema (crítico, urgente, ajuste simples) e canal de contato nomeado antes de assinar. Fornecedor confiante no próprio suporte normalmente não hesita em colocar isso por escrito. Isso vale pra fornecedor de qualquer porte: prazo escrito não depende de tamanho de equipe, depende de disposição de assumir compromisso verificável.
Antes de assinar qualquer contrato de consultoria de IA, confere se as sete cláusulas estão lá, e leva o rascunho pro seu advogado revisar como parte do processo, não como formalidade final. Fornecedor que trava em mais de uma dessas cláusulas está mostrando, sem precisar dizer, qual lado ele pretende proteger se o projeto não sair como combinado.
Quer liderar a virada de IA na sua empresa?
No mapeamento gratuito a gente olha sua operação e define onde a IA entra primeiro, sem quebrar o que já funciona.
Fazer o mapeamento gratuito Ou me acompanhe no Instagram: @ericluciano