Consultoria de IA: formatos de contratação

Quatro formatos concentram quase tudo o que se contrata hoje sob o nome de consultoria de IA: escopo fechado por entregável, horas alocadas, retainer mensal e advisory por período. A escolha entre eles não é uma questão de preço, e sim de quanto do problema já está definido no momento em que se assina. Escopo fechado exige objeto conhecido e fronteira estável. Horas servem quando a empresa já sabe o que quer construir e o que falta é capacidade de execução. Retainer faz sentido quando o objeto é operação continuada, e não entrega. Advisory por período compra critério de decisão, não mão de obra — é o único dos quatro em que a ausência de entregável físico não é defeito.

O erro mais caro, porém, é anterior à escolha do formato: fechar escopo antes do diagnóstico e depois tratar como falha de execução o fato previsível de que a realidade da operação não coube na proposta. Antes de escolher o formato vale ter clara a natureza do trabalho — o que uma consultoria de fato entrega, por que projeto morre em dado e processo, como se mede retorno —, e isso está desenvolvido em consultoria de inteligência artificial. O que segue aqui é só o instrumento comercial: o que cada formato serve, onde cada um falha, o que precisa estar escrito no contrato e como estruturar o pagamento para que a incerteza técnica não vire prejuízo financeiro de um dos lados.

Escopo fechado só é honesto depois do diagnóstico

Escopo fechado é um bom contrato quando existe uma fronteira que os dois lados conseguem desenhar antes de começar. O problema é que, em projeto de IA, essa fronteira quase sempre é produto do diagnóstico, não insumo dele. Você contrata “um assistente para o atendimento” e descobre, assim que alguém abre o sistema de verdade, que boa parte das perguntas do cliente depende de uma base que não expõe API e que o processo real tem uma etapa de aprovação humana que ninguém mencionou porque parecia óbvia demais. Nada disso é surpresa: é o comportamento normal de uma investigação que funcionou.

A partir daí, o contrato de escopo fechado passa a trabalhar contra o resultado. Quem executa tem incentivo para entregar exatamente o que está escrito, mesmo sabendo que aquilo já não resolve o problema; quem contratou tem incentivo para empurrar dentro do escopo tudo o que apareceu depois. As duas partes ficam gastando energia numa negociação de fronteira em vez de gastar no processo. Na minha leitura, escopo fechado assinado antes de qualquer diagnóstico é o desenho comercial que mais quebra no meio — e ele quebra pelo motivo certo, porque o diagnóstico mudou o escopo, que é literalmente para o que ele serve.

A saída não é abandonar o formato, e sim mudar a ordem. Diagnóstico curto contratado à parte, com entregável próprio, e só então escopo fechado sobre um objeto que agora tem contorno. Nessa sequência, escopo fechado vira o formato mais confortável para quem contrata, porque transfere o risco de estimativa para quem executa — e quem executa aceita esse risco justamente porque já enxergou o terreno.

Horas medem presença, e presença não é o produto

Contratar horas resolve um problema real: dá elasticidade quando o trabalho é exploratório demais para ter fronteira. E cria outro, silencioso. Horas medem alocação, não decisão. Um projeto de IA pode consumir meses de reunião e conversa sem produzir uma única escolha arquitetural defendida, e ainda assim o contrato terá sido integralmente cumprido. Pior: o formato remunera a demora. Ninguém precisa agir de má-fé para que isso apareça no resultado; basta que ninguém tenha interesse estrutural em terminar antes.

Horas funcionam bem em duas situações específicas. A primeira é quando a empresa já tem o desenho e falta braço técnico para construir — nesse caso o que se está comprando é engenharia, e a fronteira entre consultoria e desenvolvimento de software com IA precisa estar declarada, porque são contratos com naturezas de risco distintas. A segunda é sustentação pontual, do tipo “temos um sistema rodando e queremos alguém disponível quando ele degradar”. Fora disso, horas costumam ser o formato escolhido por quem não conseguiu descrever o objeto e preferiu não admitir.

O retainer precisa ter objeto, senão vira assinatura

Retainer mensal é o formato mais confortável de propor e o mais fácil de desenhar mal. Ele se justifica quando existe uma operação continuada de verdade: sistemas em produção que precisam ser monitorados, avaliações que precisam ser rodadas de novo quando o modelo do fornecedor muda, política de uso que precisa ser revisada quando entra um caso novo, fila de melhorias que se renova todo mês. Isso é trabalho real e recorrente, e pagar por evento seria mais caro para os dois lados.

O retainer mal desenhado é aquele que descreve disponibilidade em vez de objeto. “Acompanhamento estratégico contínuo” não é objeto — é a promessa de que alguém atende o telefone. Um retainer que se sustenta diz quais rotinas rodam por mês, com que frequência, quais relatórios saem, qual é o tempo de resposta quando algo quebra e o que caracteriza cumprimento. E deve ter duas cláusulas desconfortáveis: revisão do próprio objeto a cada ciclo e prazo de aviso curto para encerrar, sem multa que torne a saída teórica. O teste do desenho está justamente na saída — se encerrar o retainer implica perder acesso a prompts, avaliações, registros e credenciais, o que o contrato descreve não é continuidade, é trava. Continuidade se escreve em objeto, prazo de aviso e devolução de artefatos; trava se escreve por omissão dos três.

Quando o retainer cobre operação de IA generativa dentro da empresa, o que precisa ser recorrente é política e revisão, não presença: o desdobramento de quais classes de dado entram em qual modelo está em consultoria em IA generativa, e é isso que se mantém todo mês, não o slide de status.

Advisory por período compra critério, não entrega

Advisory é o formato menos compreendido, e o mal-entendido é quase sempre do lado de quem contrata. Não se está comprando execução nem documento: está se comprando o julgamento de alguém que já viu esse tipo de decisão dar errado. O valor aparece em reunião de escolha — se compra ou constrói, se aquele fornecedor está descrevendo capacidade ou promessa, se aquele piloto merece virar produção, se aquele problema é de modelo ou de dado. Bem contratado, consome pouca hora e incide exatamente onde o erro sai caro.

Como o objeto é imaterial, o contrato de advisory precisa ser o mais explícito dos quatro sobre a mecânica: por quanto tempo vale, qual disponibilidade está reservada, em quanto tempo uma pergunta é respondida, se o parecer sai por escrito ou fica na reunião, e se opinar sobre um fornecedor específico gera conflito com alguma outra relação de quem aconselha. Advisory sem declaração de conflito de interesse é o formato mais fácil de contaminar sem que ninguém perceba.

Advisory falha em duas circunstâncias. Falha quando a empresa não tem quem execute, porque conselho sem braço vira ata de reunião. E falha quando é contratado para legitimar uma decisão já tomada, o que se identifica rápido: nenhuma pergunta é feita antes de o parecer ser pedido. Se a organização está na etapa de comparar propostas concretas, o critério de escolha do fornecedor está desenvolvido em empresa especialista em inteligência artificial, e isso é anterior a qualquer advisory.

De quem é o prompt, o dado e o modelo ajustado

Aqui está a parte do contrato que costuma ser tratada como formalidade e depois vira impasse. Projeto de IA produz ativos que não se parecem com software tradicional, e por isso escapam das cláusulas padrão. Prompts de sistema, conjuntos de avaliação, base de conhecimento estruturada, taxonomias, exemplos rotulados e pesos de um modelo ajustado sobre dado da empresa são ativos com valor econômico próprio — e o contrato precisa dizer, nominalmente, de quem é cada um deles.

Três pontos merecem redação explícita:

• Propriedade e licença. A quem pertencem prompts, avaliações, base estruturada e modelo ajustado; se o fornecedor pode reutilizar o que aprendeu em outro cliente; e se a empresa fica com o artefato em formato utilizável — não apenas com o direito abstrato sobre ele — quando o contrato terminar.
• Confidencialidade de base. Se o dado da empresa pode ou não ser usado para treinar, ajustar ou avaliar modelos, quem além do fornecedor tem acesso, o que acontece com cópias ao fim do contrato e se a empresa pode ser citada como case sem autorização por escrito.
• Responsabilidade sobre saída errada. Nenhuma prática técnica zera o erro: o repertório que reduz alucinação trabalha com probabilidade, não com garantia, e fornecedor que aceita cláusula de saída sempre correta está assinando o que não consegue cumprir. O que dá para escrever é outra coisa — a partir de qual ação a máquina deixa de sugerir e passa a comprometer a empresa perante um cliente, um contrato ou um pagamento; quem revisa antes desse limite; qual margem de erro o contratante aceitou por escrito; e de quem é o prejuízo quando o erro atravessa a revisão.

Falta um quarto item, que não é jurídico e é o mais esquecido: quem mantém o sistema depois da entrega. Modelo do fornecedor muda, integração quebra, política interna se atualiza, e alguém precisa reavaliar. Contrato que termina no aceite entrega um sistema com prazo de validade silencioso.

Pagamento por fase é o que segura o risco dos dois lados

Diagnóstico, desenho de arquitetura, implantação assistida e transferência de operação têm naturezas de risco diferentes e não deveriam ser vendidas em bloco único, com o preço inteiro fechado antes de alguém ter olhado a operação por dentro. A estrutura que funciona vincula cada parcela a um artefato verificável — o mapa do processo com os números medidos na operação, a arquitetura escolhida com as alternativas descartadas e o porquê, o sistema rodando em produção com o tratamento de exceção já em pé, o procedimento de operação com dono nominal — e coloca um ponto de saída declarado entre uma fase e a seguinte.

O ponto de saída é a cláusula que muda o comportamento das duas partes. Ele permite que o diagnóstico conclua honestamente que aquele problema não precisa de IA, sem que essa conclusão custe o contrato inteiro a quem a produziu. E permite que a empresa pare quando percebe que a fase seguinte não se justifica, sem pagar por um escopo que deixou de fazer sentido. Contrato que só permite sair no fim transformou incerteza técnica em compromisso financeiro, e essa conversão sempre cobra depois.

Sinais de que a proposta foi mal desenhada

Alguns padrões aparecem antes da assinatura e dispensam análise técnica. Proposta com preço e prazo fechados sobre um briefing de uma página está estimando o que ainda não viu. Proposta que descreve tecnologia e não descreve processo alvo, dono interno e métrica de base está vendendo instalação. Proposta cujo entregável final é relatório e treinamento acabou no ponto em que o trabalho começaria. Proposta sem cláusula de propriedade sobre prompts, base e modelo ajustado está deixando esse ativo em aberto — e o aberto costuma pender para o lado de quem redigiu.

Há ainda o sinal mais simples de todos: a proposta que não dedica uma linha à manutenção, à sucessão da operação e ao destino dos artefatos no encerramento. Contrato que só descreve a entrega assume, sem dizer, que o depois é problema de outro — e o depois chega sempre. Formato comercial é, no fundo, uma hipótese sobre onde está o risco do projeto. Escopo fechado aposta que o risco é de estimativa. Horas apostam que é de definição. Retainer aposta que é de operação. Advisory aposta que é de decisão. Escolher o formato antes de saber qual desses riscos é o seu é a maneira mais direta de contratar bem a coisa errada.

---

Se você tem uma proposta de consultoria de IA na mesa e a dúvida é o desenho comercial — qual formato cabe no estágio em que a empresa está, o que exigir por escrito, como fatiar o pagamento —, essa é uma leitura rápida de fazer com quem já viu contrato de IA quebrar no meio, e é o tipo de conversa que conduzo no Grupo WYS antes de qualquer proposta virar assinatura. O caminho é o contato, com a proposta em mãos e o processo alvo descrito em uma página. Começamos pelas duas perguntas que o desenho comercial deveria responder antes do preço: qual risco esse formato está assumindo, e com quem ficam os artefatos no fim.