Como avaliar fornecedores que prometem superinteligência: evidências

Para avaliar um fornecedor que promete superinteligência, deixe a palavra de lado e julgue o que ele realmente vai entregar: um papel definido, um comportamento que você consiga observar no seu próprio trabalho, permissões claras e uma descrição honesta do que o fornecedor não controla. Superinteligência descreve um possível nível de capacidade, não um recurso de produto. Por isso, toda promessa precisa virar algo que você possa inspecionar, medir e interromper. Se uma promessa não pode ser transformada em teste, trate-a como marketing.

Principais pontos

• Superinteligência em uma proposta comercial é uma afirmação sobre direção, não uma evidência. Pergunte o que existe hoje, em produção, sob a responsabilidade operacional de alguém.
• Bons fornecedores sabem dizer, em linguagem simples, qual é o papel, quais são as ferramentas, a memória, os limites de aprovação e o critério de sucesso.
• A evidência que importa é a que vem dos seus dados e do seu fluxo de trabalho, produzida em condições que você consegue observar, e não demonstrações montadas para a reunião de vendas.
• Os sinais de alerta mais confiáveis são a vagueza sobre quem opera o sistema, a recusa em definir limites e promessas que não podem ser testadas nem revertidas.
• Um teste curto e delimitado, com saída por escrito, é um filtro melhor do que qualquer apresentação.

O que o fornecedor quer dizer com superinteligência?

A palavra é usada em pelo menos três sentidos diferentes, e o comprador precisa saber qual deles está na mesa antes de qualquer outra pergunta.

O primeiro sentido é uma afirmação sobre um modelo: o fornecedor revende ou envolve um modelo de uso geral e o descreve como próximo ou superior à especialização humana. O segundo é uma afirmação sobre o futuro: o fornecedor acredita que a capacidade continuará crescendo e posiciona o produto como a forma de estar preparado. O terceiro é uma afirmação sobre um sistema: o fornecedor constrói, em volta dos modelos, uma camada de memória, ferramentas, permissões e avaliação, de modo que a empresa se beneficie à medida que os modelos melhoram. Nosso guia sobre superinteligência empresarial e governança de agentes de IA descreve essa terceira ideia com mais detalhe.

Só o terceiro sentido é algo que uma empresa pode comprar e operar. O primeiro é uma propriedade de um modelo que o fornecedor talvez nem controle. O segundo é uma previsão, e previsões não são entregáveis. Quando uma proposta escorrega entre os três sem marcar as transições, você está sendo convidado a pagar pelo segundo enquanto vê uma demonstração do primeiro.

Um bom pedido inicial é simples: peça ao fornecedor que reescreva a proposta sem a palavra superinteligência. O que sobrar é a oferta real. Se sobrar um papel claro, com tarefas, ferramentas e limites definidos, você tem algo para avaliar. Se tudo se reduzir a frases genéricas sobre transformação, você aprendeu algo importante logo no começo.

Que evidências pedir a um fornecedor de IA?

A evidência tem uma hierarquia. O que está mais acima nesta lista vale mais do que o que está abaixo.

• Comportamento no seu próprio material: o fornecedor executa uma tarefa delimitada em uma amostra dos seus documentos, chamados ou registros reais, com você acompanhando, e mostra entradas, saídas e erros.
• Um método de avaliação por escrito: a descrição de como o fornecedor verifica a qualidade ao longo do tempo, incluindo os casos de teste, quem revisa as falhas e o que acontece quando os resultados pioram. Materiais públicos de engenharia sobre avaliação de agentes, como os da Anthropic sobre evals para agentes, mostram como é um método sério.
• Registros operacionais: como os incidentes foram tratados, como as mudanças foram aprovadas, como as permissões foram revisadas. Exemplos com dados ocultados já bastam.
• Documentação de arquitetura: onde os dados ficam armazenados, quais sistemas o agente pode ler ou alterar, como as credenciais são guardadas e como o agente é interrompido.
• Referências com quem você possa conversar diretamente, sobre a situação em que estavam, e não apenas um resumo de resultados.
• Estudos de caso, por último. São os mais fáceis de polir e os mais difíceis de verificar. Desconfie de relatos que não trazem contexto, limites e nome de alguém que possa confirmá-los.

Observe o que não está na lista: notas de benchmark citadas sem contexto, demonstrações com dados preparados e depoimentos sem uma pessoa que você possa contatar. Benchmarks medem um modelo em um conjunto fixo de tarefas. Eles não dizem se o sistema vai lidar com as suas exceções, com as suas permissões ou com o seu tom de voz com clientes.

Se o fornecedor só consegue oferecer material da parte de baixo da lista, isso não o torna desonesto, mas deve reduzir a sua confiança e encurtar o compromisso que você aceita assumir.

Quais perguntas separam quem opera de quem só vende?

Boas perguntas são específicas o bastante para que uma resposta vaga seja óbvia. Envie estas ao fornecedor por escrito e guarde as respostas.

• Qual é o único papel que este sistema exerceria para nós e o que ele está explicitamente proibido de fazer?
• Quais dos nossos sistemas ele vai ler, em quais vai escrever e quem aprova cada permissão?
• O que ele lembra entre uma sessão e outra, onde essa memória fica armazenada e como inspecionamos ou apagamos esse conteúdo?
• Quem opera o sistema no dia a dia: a equipe de vocês, um parceiro ou uma plataforma de terceiros? Quem responde quando algo falha fora do horário comercial? (Veja agência de automação com IA ou provedor gerenciado para entender por que isso importa.)
• De qual modelo ou modelos ele depende e o que acontece com a nossa configuração se vocês trocarem de modelo ou perderem o acesso a um deles?
• Como vocês detectam que a qualidade caiu e o que mostram a nós quando isso acontece?
• Como lidam com entradas hostis ou manipuladas, como instruções escondidas em um e-mail ou documento? A lista de riscos da OWASP para aplicações com modelos de linguagem é uma boa referência do que um fornecedor preparado já deveria estar discutindo.
• O que podemos exportar se formos embora e em que formato? O artigo sobre como migrar agentes de IA para outro fornecedor trata das verificações práticas.
• Qual é o critério de sucesso do primeiro projeto e quem, do nosso lado, confirma que ele foi atendido?

Observe como o fornecedor responde, não só o que diz. Quem opera costuma responder com limites, escolhas e coisas que ainda não sabe. Quem só vende costuma responder com capacidade e entusiasmo. Ambos podem ser sinceros, mas só o primeiro padrão ajuda você a decidir.

Repare também se o fornecedor faz perguntas a você. Um provedor sério vai querer entender o seu fluxo de trabalho, a qualidade dos seus dados, a sua cadeia de aprovação e a sua tolerância a erro antes de propor qualquer coisa.

Quais sinais de alerta devem pausar a conversa?

Nenhum item abaixo prova, sozinho, que um fornecedor não serve. Vários juntos devem fazer você desacelerar.

• A proposta se apoia na palavra superinteligência, mas não consegue nomear um papel, um fluxo de trabalho ou um resultado observável.
• O fornecedor descreve o sistema como autônomo sem descrever os limites de aprovação ao redor dele.
• Ninguém sabe dizer quem é responsável pelo monitoramento, pela resposta a incidentes e pela revisão de permissões depois do lançamento.
• A evidência se resume a demonstrações com os dados do próprio fornecedor ou a resultados que não podem ser ligados a uma referência acessível.
• O fornecedor desencoraja um teste delimitado e pressiona por um compromisso longo antes de qualquer prova.
• O contrato é omisso sobre devolução de dados, exclusão, mudanças de modelo e encerramento da relação. O guia sobre escopo de trabalho para implantação de agente de IA mostra o que essas seções devem conter.
• O sistema exige acesso amplo aos sistemas da empresa desde o primeiro dia, sem ampliação por etapas.
• Promessas sobre o futuro são usadas como motivo para pular a avaliação, por exemplo, dizer que o sistema vai melhorar sozinho e que testar é desnecessário.
• O risco é tratado como problema de outra pessoa. Um fornecedor que não consegue discutir modos de falha não os procurou. Referências como o NIST AI Risk Management Framework oferecem um vocabulário neutro para aprofundar esse ponto.

O último sinal é o mais revelador. Qualquer sistema capaz falha de vez em quando. Um fornecedor que descreve com tranquilidade como o sistema falha, como as falhas são detectadas e como são revertidas demonstra o tipo de maturidade que de fato protege você.

Como conduzir a avaliação, passo a passo?

O plano abaixo serve para uma empresa de médio porte e não exige uma equipe técnica para começar. Para um tratamento mais amplo do teste de fornecedores, veja a avaliação de segurança de fornecedor de IA, passo a passo.

• Passo um: traduza a proposta. Escreva um parágrafo descrevendo o papel que o fornecedor propõe, sem a palavra superinteligência. Peça que ele confirme o texto por escrito.
• Passo dois: escolha um fluxo de trabalho com dono claro, entradas reais e um resultado que uma pessoa consiga conferir. Evite qualquer coisa em que um erro seria difícil de reverter.
• Passo três: defina o critério de sucesso antes do teste. Decida como é o resultado bom, o que é inaceitável e quem julga. Sem isso, qualquer desfecho pode ser descrito como sucesso.
• Passo quatro: configure as permissões no mínimo. Primeiro acesso de leitura, e acesso de escrita só onde houver uma etapa de aprovação. Registre quem concedeu cada permissão.
• Passo cinco: execute um teste delimitado com material real, reservando uma amostra para verificar se os resultados se mantêm em casos inéditos.
• Passo seis: revise as falhas com o fornecedor. Observe a rapidez com que são reconhecidas, como são explicadas e se a correção é uma mudança que você consegue ver e aprovar.
• Passo sete: teste a saída. Peça uma exportação do que o sistema guarda sobre a sua empresa e confirme que você consegue ler esse conteúdo sem o fornecedor.
• Passo oito: decida com base em evidências escritas. Compare o resultado com o critério do passo três, e não com a impressão deixada pelas apresentações.

A fase do projeto também importa. Um teste prova coisas diferentes de um piloto, e um piloto prova coisas diferentes da produção. O artigo sobre por que pilotos de IA não saem do papel mostra o que cada fase precisa demonstrar antes de você avançar.

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

Este é um cenário ilustrativo, não um projeto real.

Uma distribuidora recebe duas propostas para ajudar a equipe de operações a lidar com a correspondência com fornecedores. O primeiro fornecedor abre com uma apresentação sobre sistemas superinteligentes que vão tocar todo o back office. Oferece uma demonstração impecável, um contrato de longo prazo e acesso amplo ao e-mail e à plataforma de pedidos desde o início.

O segundo fornecedor fala de um único papel: redigir respostas a consultas rotineiras de fornecedores e sinalizar tudo o que envolva alteração de pedido. Propõe acesso de leitura a uma caixa de entrada compartilhada, rascunhos que uma pessoa nomeada aprova antes do envio, uma lista escrita do que o agente nunca deve fazer e um teste curto com uma amostra de mensagens antigas que o fornecedor ainda não viu.

A liderança de operações faz aos dois a pergunta sobre quem opera o sistema e quem responde a uma falha. O primeiro diz que a plataforma é altamente confiável. O segundo nomeia uma pessoa, um caminho de escalonamento e um procedimento para pausar o agente.

Nenhum dos dois usava uma tecnologia de base diferente. A diferença é que o segundo tornou suas afirmações testáveis, delimitou o risco e descreveu os próprios limites. A empresa aprende com o segundo teste mesmo que ele termine em um não. Com o primeiro, só aprenderia depois de se comprometer.

Como uma operação gerenciada trata esse problema?

A Be Human trata a avaliação como parte do serviço, e não como um obstáculo anterior a ele. O primeiro projeto define um papel útil, a memória e as ferramentas de que ele precisa, os limites de aprovação e um critério de sucesso observável, tudo escrito antes de qualquer coisa ser ligada. Depois, a Be Human opera o agente remotamente, com monitoramento, avaliações recorrentes, manutenção de integrações, revisão de permissões e resposta a incidentes, de modo que a resposta para quem é o responsável seja um processo com nome, e não uma suposição. As mudanças passam por um caminho controlado que o cliente consegue acompanhar, e a empresa mantém o controle humano sobre identidade, memória, canais, ferramentas e permissões. Para ver de perto o trabalho recorrente, leia o que é AgentOps e como operar um agente de IA no dia a dia.

Perguntas frequentes

Algum fornecedor entrega superinteligência hoje? Trate a afirmação como não comprovada, a menos que o fornecedor consiga mostrar, no seu trabalho, o que o sistema faz e sob quais controles. A capacidade dos modelos é um assunto em movimento, e você não precisa resolvê-lo para comprar bem. Compre um papel definido que você possa testar e deixe que as melhorias dos modelos cheguem como benefício, e não como promessa.

Devemos evitar fornecedores que usam a palavra? Não automaticamente. Alguns a usam como atalho para uma direção de longo prazo e, ainda assim, oferecem um serviço claro e delimitado. Julgue a oferta por trás da palavra: um papel nomeado, evidência observável, limites declarados e uma saída.

Quem dentro da empresa deve liderar a avaliação? Defina um responsável do lado do negócio, de preferência a liderança da área que o agente vai atender, com apoio de quem cuida de segurança e dados. Um patrocinador nomeado mantém as decisões andando e evita que a avaliação vire um exercício técnico sem pergunta de negócio.

E se o fornecedor recusar um teste delimitado? Pergunte o motivo e ouça se há uma razão concreta, como um acesso a dados que precisa ser providenciado antes. Se a razão for apenas que o sistema funciona melhor em escala ou que um teste não mostraria o valor dele, considere isso um sinal forte para esperar. Um bom fornecedor consegue mostrar algo real em um ambiente pequeno e reversível.

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