Resposta rápida: comprar IA bem exige mudar três hábitos do procurement tradicional. O primeiro é abandonar a comparação por preço de licença, porque o custo real de uma ferramenta de IA vive no consumo variável, na integração e no tempo do time interno. O segundo é tratar a cláusula de uso de dados como item central da negociação, e jamais como anexo técnico, porque ela define se a informação da empresa alimenta o modelo de terceiros. O terceiro é exigir prova de resultado em dado da própria casa antes da assinatura, em vez de aceitar demonstração com dado do fornecedor. Eu vejo empresas de porte gastarem meses negociando desconto de dez por cento numa licença e assinarem no mesmo contrato uma cláusula de dados que vale muito mais do que o desconto conquistado. O roteiro deste artigo organiza a compra em cinco etapas e entrega as perguntas que a área de compras faz sozinha, sem depender de tradução técnica.
Por que a compra de IA escapa do processo normal de procurement?
O processo tradicional de compra de software funciona sobre três pilares estáveis: escopo definido, preço previsível e resultado verificável na entrega. O fornecedor descreve funcionalidades, a empresa compara com a lista de requisitos, negocia valor por usuário e testa se o sistema faz o que prometeu. Esse desenho serviu bem por décadas, porque software tradicional entrega comportamento determinístico, ou seja, a mesma entrada produz a mesma saída sempre.
Ferramentas de IA rompem os três pilares ao mesmo tempo. O escopo é elástico, porque a mesma ferramenta resolve problemas que ninguém previu na negociação e falha em problemas que pareciam triviais. O preço é variável, porque a maioria dos fornecedores cobra por consumo, e o consumo depende de como o time usa. E o resultado varia entre execuções, o que dificulta o teste de aceitação clássico com critérios binários.
O efeito prático é que a área de compras recebe uma proposta com aparência familiar e conteúdo desconhecido. A tabela de preços parece uma tabela de licenças, os termos parecem termos de software, e a estrutura de risco fica bem diferente. Quando compras aplica o processo antigo sem ajuste, a empresa assina rápido e descobre o custo real no terceiro mês de operação, quando a fatura de consumo chega três vezes maior do que o previsto na planilha de aprovação.
O que o fornecedor de IA vende que o contrato tradicional deixa de descrever?
O primeiro item invisível é o modelo por trás da ferramenta. Boa parte dos fornecedores de aplicação opera sobre modelos de terceiros, e o contrato raramente diz qual modelo, qual versão e o que acontece quando esse fornecedor de base muda condições ou descontinua uma versão. Uma troca de modelo altera qualidade, custo e comportamento, e a empresa que assinou sem essa cláusula descobre a mudança pelo efeito na operação.
O segundo item é o desempenho esperado. Contratos de software tradicional definem disponibilidade em percentual de tempo no ar, o que segue relevante e passa longe de suficiente. Uma ferramenta de IA pode estar disponível cem por cento do tempo e entregar respostas ruins o suficiente para inviabilizar o uso, e nenhum indicador de disponibilidade captura isso. Vale negociar métricas de qualidade acordadas, com o método de medição escrito.
O terceiro item, e o mais valioso, é o destino do dado. Contratos genéricos usam expressões amplas como processamento para melhoria do serviço, formulação que pode abrigar o treinamento de modelos com informação da empresa. Esse ponto merece redação específica e explícita, e a discussão detalhada de como escrever essas cláusulas está no artigo sobre contratos na era da IA e suas cláusulas, que traz a lista de pontos a revisar antes da assinatura.
Quais perguntas técnicas a área de compras faz mesmo sem ser técnica?
A primeira é sobre a origem do modelo: qual modelo sustenta a ferramenta, de qual fornecedor, em qual versão, e qual o processo de comunicação quando essa versão muda. A resposta revela o grau de dependência do próprio fornecedor, e um fornecedor que hesita nessa resposta provavelmente carece de controle sobre a própria cadeia.
A segunda é sobre a localização do processamento: em qual país o dado da empresa é processado e armazenado, e se existe opção de manter tudo em território nacional. Essa pergunta afeta a conversa com o jurídico, com o cliente enterprise e com o regulador do setor, e ela costuma separar fornecedores maduros de fornecedores que ainda operam com infraestrutura improvisada.
A terceira é sobre reversibilidade: como a empresa extrai o próprio conteúdo, histórico e configuração caso decida sair, em qual formato e em quanto tempo. Uma resposta vaga aqui indica que a saída será dolorosa, e essa é a principal fonte de dependência em contratos de IA. O tema aparece com profundidade no artigo sobre dependência de fornecedor de IA e lock-in, que mapeia as formas de aprisionamento que passam despercebidas na negociação.
Como avaliar o custo real além do preço de licença?
O custo de uma ferramenta de IA tem quatro camadas, e a proposta comercial descreve apenas a primeira. A camada visível é a licença ou a assinatura de plataforma. A segunda camada é o consumo variável, que depende do volume de uso e cresce junto com a adoção, invertendo a lógica tradicional em que mais uso dilui o custo por usuário.
A terceira camada é a integração, que envolve conectar a ferramenta aos sistemas da casa, ajustar permissões e construir os fluxos de dado. Essa camada consome horas de time interno ou de parceiro externo, e ela costuma equivaler ao valor do primeiro ano de licença em implantações de porte médio. Ignorar essa conta na aprovação produz projetos que travam por falta de orçamento de execução, com a licença já paga e a ferramenta parada.
A quarta camada é o tempo de gente. Alguém precisa configurar, revisar saídas, treinar o time e manter a ferramenta calibrada conforme o negócio muda. Essa camada raramente entra na planilha de compra, e ela é a que define se a ferramenta rende. Eu recomendo somar as quatro camadas numa estimativa de três anos antes de comparar propostas, porque a ordem de preferência muda com frequência quando a conta fica completa.
O que olhar na cláusula de uso de dados para treinamento?
A cláusula precisa responder quatro perguntas com clareza. A primeira é se o conteúdo enviado pela empresa alimenta treinamento de modelos, em qualquer forma, incluindo ajuste fino e avaliação de qualidade. A resposta desejada é um compromisso explícito de exclusão, com a formulação escrita no corpo do contrato em vez de referência a política externa que o fornecedor altera quando quiser.
A segunda pergunta é sobre retenção: por quanto tempo o fornecedor guarda o conteúdo enviado, com qual finalidade, e como a empresa solicita eliminação. Prazos longos de retenção para fins de auditoria interna do fornecedor são comuns e legítimos, e eles precisam aparecer com número em vez de expressão vaga como período razoável.
A terceira pergunta trata de subcontratados: quais terceiros recebem o dado ao longo da cadeia, porque a maioria dos fornecedores de aplicação repassa o conteúdo ao provedor do modelo, que por sua vez opera em infraestrutura de nuvem de um quarto ator. A empresa assina com um e expõe dado a três, e esse encadeamento merece mapa explícito no anexo do contrato.
A quarta pergunta é sobre incidentes: em quanto tempo o fornecedor comunica uma exposição de dados, por qual canal e com qual nível de detalhe. Prazos de comunicação frouxos deixam a empresa sem tempo de reação diante das próprias obrigações legais, e vale alinhar esse prazo com a obrigação que a LGPD impõe à empresa como controladora.
Como medir a dependência que o contrato cria?
A medida prática é um exercício de cenário: quantos dias a empresa levaria para substituir aquele fornecedor por outro, mantendo a operação de pé. Quando a resposta fica em semanas, a dependência é gerenciável. Quando a resposta passa de um trimestre, a empresa está comprando muito mais do que uma ferramenta, e o preço negociado precisa refletir esse compromisso.
Três fatores puxam esse prazo para cima. O primeiro é o dado histórico acumulado dentro da ferramenta, que perde valor ou vira ilegível fora dela. O segundo é a integração profunda com sistemas internos, que exige refazer conectores a cada troca. O terceiro é o hábito do time, que constrói rotinas ao redor da interface específica de um fornecedor e resiste à mudança mesmo quando a alternativa é melhor.
O antídoto que funciona é negociar reversibilidade desde a primeira assinatura, com três compromissos escritos: exportação completa em formato aberto sob demanda, prazo máximo para entrega dessa exportação e continuidade de serviço por um período de transição em caso de encerramento. Esses três itens custam pouco na negociação inicial e valem muito no momento de renovar. O artigo sobre o aniversário do contrato de IA e a hora de renegociar mostra como esse momento se transforma em alavanca quando a reversibilidade já está contratada.
Qual o peso do roadmap do fornecedor na decisão?
Em software tradicional, o roadmap do fornecedor pesa pouco na escolha, porque a versão atual já resolve o problema e as próximas trazem melhorias incrementais. Em IA, o roadmap pesa muito, porque a distância entre o que a ferramenta faz hoje e o que ela fará em doze meses é grande o suficiente para redefinir a decisão de compra.
Isso cria um risco específico: comprar pela promessa. Fornecedores apresentam recursos em desenvolvimento com a mesma naturalidade dos recursos disponíveis, e a área de compras precisa separar as duas coisas com rigor. A pergunta que resolve é direta: esse recurso está disponível para uso em produção hoje, com cliente ativo usando, e a empresa consegue testá-lo na prova de conceito. Qualquer resposta diferente de um sim simples classifica o recurso como promessa.
Vale também avaliar a saúde do fornecedor além do produto. Fornecedores de IA operam num mercado em consolidação acelerada, com aquisições frequentes e encerramentos igualmente frequentes. Perguntar sobre tempo de operação, base de clientes de porte comparável e estrutura de suporte no Brasil dá uma leitura de risco que nenhuma demonstração de produto entrega.
Como comparar propostas que descrevem coisas diferentes?
O problema clássico da compra de IA é receber três propostas incomparáveis: uma cobra por usuário, outra por volume processado, a terceira por resultado entregue. Comparar preço nominal nessas condições produz decisão errada com frequência alta, e a saída é traduzir tudo para uma unidade comum que faça sentido para o negócio.
A unidade que funciona melhor é o custo por unidade de trabalho concluída, definida em termos do processo real: custo por atendimento resolvido, por documento analisado, por proposta gerada. Com essa unidade, as três propostas viram três números comparáveis, e a discussão passa a acontecer sobre o mesmo terreno. O trabalho de estabelecer essa unidade leva algumas horas e economiza a maior parte do risco de escolha.
Depois da tradução, vale aplicar uma matriz de quatro critérios com pesos declarados antes de ver as propostas: custo total de três anos, qualidade comprovada em dado próprio, reversibilidade contratada e maturidade do fornecedor. Declarar os pesos antes evita a racionalização posterior, aquele movimento em que o time ajusta os critérios para justificar a escolha que já havia feito por afinidade com o vendedor. O artigo sobre como escolher ferramentas de IA desenvolve essa matriz com o detalhe de cada critério.
Que provas pedir na fase de prova de conceito?
A prova de conceito que serve usa dado da própria empresa, e jamais o dado curado que o fornecedor traz na demonstração. Essa diferença explica a maior parte das frustrações posteriores, porque o dado real da casa vem sujo, incompleto e cheio de exceções que o dado de demonstração jamais tem. Uma ferramenta que entrega noventa por cento de acerto no dado do fornecedor e sessenta no dado da casa merece uma conversa bem diferente.
A segunda característica de uma boa prova é o prazo curto com escopo estreito. Duas ou três semanas sobre um único processo, com critério de sucesso definido por escrito antes de começar, entregam informação mais útil do que um piloto de três meses com escopo amplo. Escopo amplo dilui o resultado e permite que todo mundo enxergue o que quer no relatório final.
A terceira característica é a participação de quem vai usar. Provas de conceito conduzidas apenas pelo time técnico avaliam capacidade, e deixam de avaliar adoção. Colocar dois ou três usuários reais do processo no teste revela atritos de interface e de fluxo que definem se a ferramenta será usada depois de comprada, e essa informação vale mais do que qualquer métrica de precisão isolada.
Como o jurídico entra sem travar a compra?
O padrão que trava é o jurídico chegando no fim, com o contrato pronto e o time ansioso para começar. Nesse ponto qualquer objeção jurídica parece obstrução, a pressão de prazo empurra a assinatura e as cláusulas de dado passam com ajustes cosméticos. Esse desenho produz contratos frágeis com regularidade.
O padrão que funciona coloca o jurídico na definição dos requisitos, antes da primeira conversa com fornecedor. Nessa posição o jurídico entrega uma lista curta de exigências que qualquer proposta precisa atender, com quatro ou cinco itens sobre dado, responsabilidade, jurisdição e reversibilidade. Fornecedores recebem essa lista junto com o pedido de proposta, e quem tem dificuldade com ela se autoexclui cedo, o que economiza semanas.
Esse arranjo exige que jurídico, área de dados e tecnologia tenham combinado antes quem responde pelo quê. A divisão de responsabilidades entre essas três frentes é o assunto do artigo sobre jurídico, DPO e TI e quem cuida da IA, e resolver essa divisão antes da primeira compra evita a discussão de alçada no meio de uma negociação com prazo.
O que fazer quando o fornecedor é uma startup pequena?
Fornecedores pequenos entregam com frequência a melhor solução técnica para um problema específico, com atendimento próximo e velocidade de ajuste que fornecedores grandes raramente alcançam. Recusar startups por política reduz o leque de escolha e deixa vantagem competitiva na mesa. Contratá-las sem ajuste no processo de compra, por outro lado, expõe a empresa a um risco de continuidade real.
O caminho equilibrado passa por três proteções contratuais. A primeira é o depósito de configuração e dado em ambiente controlado pela empresa, com cópia periódica, garantindo que o encerramento do fornecedor deixe a informação acessível. A segunda é um período de transição contratado, com obrigação de suporte por alguns meses em caso de encerramento das atividades. A terceira é limitar o escopo inicial a um processo que a empresa consegue reverter para o modo manual sem crise.
Vale também dimensionar a exposição: um fornecedor pequeno atendendo um processo relevante e reversível é uma aposta razoável. O mesmo fornecedor sustentando o processo que fatura a empresa é uma decisão de risco que precisa subir para a diretoria com o cenário de encerramento descrito por escrito, em vez de uma decisão que a área de compras absorve sozinha.
Como estruturar o processo de compra de IA em cinco etapas?
A primeira etapa define o problema em termos de negócio, com a unidade de trabalho e o resultado esperado escritos antes de qualquer conversa com fornecedor. Empresas que começam pela ferramenta terminam adaptando o problema à solução que gostaram, e esse caminho custa caro.
A segunda etapa monta a lista de exigências mínimas com jurídico e segurança, incluindo dado, jurisdição, reversibilidade e evidência de controle. Essa lista vai junto com o pedido de proposta e filtra o mercado antes do esforço de avaliação.
A terceira etapa é a prova de conceito com dado próprio, escopo estreito, prazo de duas a três semanas e critério de sucesso escrito. Duas ferramentas em paralelo funcionam melhor do que uma, porque a comparação lado a lado revela diferenças que a avaliação isolada esconde.
A quarta etapa traduz as propostas para custo por unidade de trabalho em três anos e aplica a matriz de critérios com pesos declarados previamente. Aqui a decisão fica documentada com o raciocínio visível, o que serve tanto para o comitê de aprovação quanto para a revisão de contrato no aniversário.
A quinta etapa negocia o contrato com foco nos quatro pontos que a lista de exigências levantou, deixando o desconto de licença para o fim. Empresas que negociam reversibilidade e cláusula de dado antes do preço conseguem as duas coisas com frequência muito maior do que empresas que gastam a energia toda no valor e aceitam o resto como está.
Que sinais de alerta aparecem na apresentação comercial?
O primeiro sinal é a demonstração que roda apenas com dado do fornecedor, acompanhada de resistência ao teste com dado da empresa. Fornecedores confiantes na própria ferramenta oferecem esse teste antes de você pedir, porque ele fecha vendas mais rápido do que qualquer apresentação.
O segundo sinal é a resposta vaga sobre o modelo de base e sobre a localização do processamento. Um fornecedor maduro tem essas respostas prontas em uma frase, porque clientes enterprise perguntam isso toda semana. Hesitação nesse ponto indica que a arquitetura ainda muda com frequência ou que o fornecedor prefere manter a informação fora do contrato.
O terceiro sinal é a insistência em contrato longo com desconto agressivo na entrada. Três anos com trinta por cento de desconto parece bom negócio, e no mercado de IA esse arranjo aprisiona a empresa numa tecnologia que mudará bastante nesse intervalo. Doze meses com cláusula de renovação e reversibilidade contratada tende a valer mais do que o desconto, porque preserva a liberdade de trocar quando surgir algo claramente melhor.
O quarto sinal é o vendedor que responde toda objeção com um recurso futuro. Quando o roadmap resolve todos os problemas apontados na avaliação, a ferramenta atual provavelmente resolve poucos, e a empresa estará comprando uma intenção com prazo indefinido.
Conclusão
A compra de IA falha com frequência por um motivo bem específico: a área de compras aplica um processo desenhado para software determinístico e previsível a uma categoria de produto que carece dessas duas características. O resultado é uma sequência conhecida de faturas de consumo acima do previsto, cláusulas de dado permissivas assinadas sem discussão e dependências de fornecedor que só aparecem quando a empresa tenta sair.
O ajuste dispensa reformar o procurement inteiro. Ele exige quatro movimentos concretos: somar as quatro camadas de custo antes de comparar, colocar jurídico e segurança na definição de requisitos em vez do fim da fila, exigir prova de conceito em dado da própria casa e contratar reversibilidade na primeira assinatura. Esses quatro movimentos cabem no processo existente e mudam a qualidade da decisão de forma imediata.
Na Groovia, eu insisto em traduzir toda proposta de IA para custo por unidade de trabalho antes de qualquer conversa sobre desconto, porque essa tradução reorganiza a discussão inteira. Ela devolve a decisão para o terreno do negócio, tira o brilho da apresentação comercial e revela com clareza qual fornecedor entrega mais valor por real gasto ao longo de três anos. Quando o número aparece na mesa, a negociação vira uma conversa entre adultos sobre resultado, em vez de um exercício de comparação entre tabelas de preço que descrevem coisas diferentes.