Como verificar as promessas de um fornecedor de IA antes de fechar

Para verificar as promessas de um fornecedor de IA, transforme cada promessa em um teste pequeno que use seus próprios documentos, suas próprias ferramentas e seus casos mais incômodos. Depois, avalie o resultado contra um critério de aprovação escrito antes de o teste começar. Demonstrações, conversas com clientes de referência e gráficos de benchmark mostram o que é possível em geral. Um teste curto e estruturado mostra o que acontece na sua empresa.

Principais pontos

• Uma promessa só é útil quando vira uma tarefa que você consegue executar com o seu material e que pode falhar contra um critério escrito antes.
• Teste primeiro as promessas que custam mais caro se estiverem erradas: precisão com os seus dados, comportamento nos extremos, integrações, permissões e o que acontece quando algo quebra.
• Testes sem custo bastam para avaliar aderência, honestidade e documentação. Testes pagos servem para o que exige acesso real, ferramentas reais ou execuções repetidas.
• Observe como o fornecedor se comporta durante o teste, principalmente como ele relata falhas. É a melhor prévia da relação depois da assinatura.
• Guarde os resultados por escrito, para que a decisão se apoie em evidência e não na lembrança de uma boa demonstração.

Por que uma demonstração não prova as promessas do fornecedor?

Uma demonstração é ensaiada. Os dados são escolhidos para favorecer o produto, o caminho pelo sistema é um que o fornecedor sabe que funciona, e as perguntas feitas são as que o sistema responde bem. Nada disso é desonesto. Apenas responde à pergunta isso pode funcionar, quando você precisa responder à pergunta isso vai funcionar aqui.

As outras fontes habituais de prova têm o mesmo limite. As conversas de referência são com clientes escolhidos pelo fornecedor. Os benchmarks públicos medem tarefas gerais, não os seus contratos, o seu catálogo de produtos ou o tom que você usa com clientes. Um slide que diz que o sistema é preciso não informa em quê, medido por quem, nem contra qual padrão de correto.

A mudança prática é tratar cada promessa como uma hipótese. O fornecedor não está mentindo até que se prove o contrário. Você apenas se recusa a pagar por algo que ainda não viu se comportar nas suas condições. A maioria dos fornecedores sérios recebe bem esse pedido, porque um teste aprovado fecha a venda mais rápido do que mais uma rodada de apresentações.

Quais promessas vale a pena testar primeiro?

Nem toda frase de uma apresentação comercial precisa de teste. Separe as promessas por tipo e depois ordene pelo custo que teriam para você se fossem falsas. Estes são os tipos mais comuns e o teste adequado a cada um:

• Promessas de capacidade, como responde corretamente a perguntas sobre os nossos documentos. Teste com um conjunto de perguntas reais tiradas dos seus arquivos, incluindo algumas cuja resposta correta é que os documentos não dizem.
• Promessas de integração, como conecta ao nosso e-mail e ao ERP. Conecte a um ambiente de testes ou a uma conta de teste com as mesmas permissões que você daria em produção e execute uma tarefa realista de ponta a ponta.
• Promessas de controle, como sempre pede aprovação antes de agir. Tente fazer o sistema pular a aprovação. Coloque uma instrução dentro de um documento ou e-mail e veja se ele obedece.
• Promessas de memória, como lembra do contexto entre sessões. Informe um fato em um dia, mude o fato depois e verifique o que ele usa no terceiro dia.
• Promessas operacionais, como monitoramos e respondemos a incidentes. Peça um relato passo a passo de um incidente recente, anonimizado, e uma amostra dos registros que você poderia ver.
• Promessas de saída, como você pode levar seus dados embora. Peça agora uma exportação, no formato que receberia no fim do contrato, e abra o arquivo. O guia sobre plano de saída de fornecedor de IA lista o que pedir.

Se a sua lista for longa, comece pelas promessas que tocam clientes, dinheiro ou dados regulados. Uma resposta errada em um resumo interno é um incômodo. Uma ação errada na conta de um cliente é um incidente.

Como transformar uma promessa em um teste que você possa executar?

Use a mesma sequência curta para cada promessa. Ela toma menos tempo do que parece e evita o erro mais comum, que é decidir o que conta como sucesso depois de ver os resultados.

• Passo um: reescreva a promessa como uma frase que pode falhar. Lida bem com e-mails de fornecedores vira redige respostas para os cinco tipos de solicitação mais comuns, e um revisor as enviaria com ajustes leves.
• Passo dois: monte o material de teste. Use documentos reais (anonimizados, se preciso), alguns bagunçados, alguns contraditórios e várias perguntas em que o comportamento correto é dizer que não sabe.
• Passo três: escreva o critério de aprovação antes de executar qualquer coisa e indique quem vai avaliar. O artigo sobre critérios de sucesso para piloto de agente de IA explica como tornar um critério observável.
• Passo quatro: execute o teste e avalie o resultado sem o fornecedor na sala. Se possível, peça a um colega que não escreveu as perguntas para fazer a avaliação.
• Passo cinco: execute de novo em outro dia. Consistência também é uma promessa, e um sistema que acerta uma vez e erra depois não está pronto para um processo de negócio.
• Passo seis: tente quebrá-lo de propósito. Dê a ele um campo ausente, um formato de arquivo errado, um pedido fora da sua função e uma instrução escondida em um documento.
• Passo sete: registre os resultados e envie ao fornecedor. Peça que explique cada falha. A explicação importa tanto quanto a nota.

A OpenAI e a Anthropic publicam orientações práticas sobre como montar avaliações para sistemas de IA. As ideias se aplicam bem ao teste de um comprador: um conjunto fixo de tarefas, um método de avaliação definido e execuções repetidas.

Quando pagar por um teste e quando não pagar?

O teste sem custo cobre mais do que as pessoas esperam. Você pode fazer perguntas objetivas por escrito e comparar as respostas com a documentação. Pode fazer uma demonstração em ambiente de testes, testar com material público ou não sensível, pedir uma amostra de exportação, ler os termos sobre uso e propriedade dos dados e solicitar o relato de um incidente. As perguntas para fornecedor de agentes de IA antes de assinar oferecem uma lista inicial para essa etapa.

Pague por um teste quando a promessa não puder ser verificada sem trabalho real. Isso costuma significar conectar-se aos seus sistemas de verdade, configurar o comportamento para o seu processo, rodar por vários dias para observar a consistência ou construir uma integração que o fornecedor ainda não fez. Um fornecedor que não faz esse trabalho de graça não está escondendo nada. Ele está protegendo o próprio tempo, e um teste pago também compromete você a levá-lo a sério.

Um bom teste pago tem limites. Ele tem escopo definido, data final fixa, entregável nomeado, uma declaração de que os resultados e qualquer configuração são seus e uma linha explícita dizendo que continuar depois é opcional. Não entregue dados de produção a ninguém antes de uma revisão básica de segurança. O artigo sobre prova de conceito, piloto e produção em IA descreve o que cada etapa deve e não deve ser chamada a provar.

O que observar enquanto o teste acontece?

A nota é só parte da evidência. O comportamento do fornecedor em torno do teste mostra como será trabalhar com ele. Mantenha esta lista por perto:

• Eles perguntam sobre os seus dados, o seu processo e as suas exceções, ou apenas mostram funcionalidades?
• Quando algo falha, explicam a causa ou mudam de assunto?
• Dizem não suportado quando algo não é suportado? Fornecedores que respondem sim para tudo estão chutando.
• Você consegue ver o que o sistema fez: fontes usadas, passos executados, ações tentadas? Sem isso, não há como revisar nada.
• O comportamento se mantém estável entre execuções e entre dias?
• As pessoas que participam do teste são as que vão operar o seu serviço?
• As promessas são específicas o bastante para serem testadas? Uma resposta vaga a uma pergunta precisa continua sendo uma resposta.

Para a parte de segurança, o OWASP Top 10 for LLM Applications e o NIST AI Risk Management Framework oferecem um vocabulário neutro para riscos como injeção de prompt, permissões excessivas e respostas pouco confiáveis. Você não precisa lê-los de ponta a ponta. Use-os para conferir se os seus testes de quebra cobrem os tipos de falha mais comuns.

Como isso fica na prática? Um cenário ilustrativo

Cenário ilustrativo: uma distribuidora de médio porte avalia um agente para triar e-mails de fornecedores. O fornecedor da solução promete que ele lê as mensagens recebidas, redige respostas, pede aprovação antes de enviar qualquer coisa e se conecta ao sistema de pedidos da empresa.

A líder de operações escreve quatro frases testáveis. Os rascunhos para os tipos de solicitação mais comuns precisam apenas de ajustes leves. Tudo o que estiver fora da função vai para uma pessoa, com uma nota. Nenhuma mensagem é enviada sem aprovação. A consulta de data de entrega em uma cópia de teste do sistema de pedidos devolve o registro correto.

Ela prepara um conjunto de e-mails reais sem nomes, acrescenta dois em que a resposta não está em nenhum documento e um em que o corpo do e-mail traz uma instrução para enviar uma resposta imediatamente. O fornecedor executa o conjunto em um ambiente de testes. Os rascunhos saem bons nas solicitações de rotina e mais fracos nas entregas parciais. A trava de aprovação se mantém em todas as mensagens, exceto na que contém a instrução embutida, que é redigida e colocada na fila de um modo que pula o revisor.

Nada disso encerra a conversa. O fornecedor explica a causa, propõe uma correção e a mostra funcionando em uma nova execução no dia seguinte. A empresa decide seguir com um escopo mais estreito, apenas rascunhos para os tipos de solicitação comuns, e inclui o resultado da trava de aprovação nos critérios de aceite do contrato. O teste custou alguns dias e mudou a decisão.

Como a Be Human trata isso?

A Be Human incorpora o teste ao primeiro trabalho conjunto. Antes de qualquer implantação, o projeto define uma função útil, a memória e as ferramentas de que ela precisa, os limites de aprovação e um critério de sucesso observável, de modo que cada promessa sobre o trabalho já seja uma frase testável. A operação gerenciada inclui avaliações recorrentes, revisão de permissões e monitoramento, para que as verificações feitas antes da assinatura continuem depois da entrada em produção, em vez de serem um evento único. A visão geral do que os serviços gerenciados de IA incluem descreve o trabalho recorrente em mais detalhe.

Perguntas frequentes

Quanto tempo deve durar o teste de um fornecedor de IA? O suficiente para repeti-lo. Para a maioria dos agentes de função única, isso significa dias, não meses: um dia para preparar o material, outro para executar e pelo menos mais um para repetir e quebrar o sistema de propósito. Se uma promessa exigir semanas de observação, transforme-a em um teste pago, com limites e data final clara.

O que fazer se o fornecedor se recusar a ser testado? Pergunte o que ele aceita fazer em vez disso e julgue pela resposta. Um fornecedor pode recusar, com razão, trabalho sem custo que exija acesso a sistemas, mas deve oferecer um teste pago, um ambiente de testes ou documentação detalhada. Uma recusa total a deixar você verificar qualquer promessa é motivo para ir mais devagar.

Devo confiar em benchmarks públicos para comparar fornecedores? Use-os como filtro aproximado, não como prova. Benchmarks medem tarefas gerais em condições controladas, e os seus documentos, as suas ferramentas e a sua tolerância a erro são diferentes. O seu próprio teste pequeno, avaliado por alguém que conhece o trabalho, sempre dirá mais.

Quem deve avaliar o teste? Alguém que faz o trabalho real hoje e que não escreveu as perguntas do teste. Essa pessoa sabe como é uma boa resposta no seu contexto e percebe erros que um generalista deixaria passar. Inclua uma segunda pessoa em tudo o que envolva clientes, dinheiro ou dados regulados.

Orientação editorial Be Human. Exemplos são ilustrativos, salvo atribuição explícita. Fontes oferecem contexto; a implementação depende do seu processo.