Perguntas para referências de fornecedor de IA: roteiro de ligação

As perguntas mais úteis para referências de fornecedor de IA tratam da vida depois do lançamento: como os problemas foram reportados e corrigidos, como as mudanças foram aprovadas, quem controlava os acessos e o que seria preciso para sair. Uma referência que consegue descrever uma semana ruim específica e a resposta do provedor diz mais do que outra que apenas afirma que o trabalho foi bem. Peça fatos em vez de opiniões e compare as respostas com o que o provedor prometeu durante a venda.

Principais pontos

• Pergunte o que aconteceu depois do lançamento. Demonstrações e reuniões de kickoff são fáceis de polir, mas o comportamento meses depois não é.
• Peça eventos, não opiniões: um incidente específico, uma mudança específica, uma discordância específica.
• Cubra cinco áreas: as primeiras semanas, incidentes, mudanças, acesso e dados, e saída ou renovação.
• Escolha referências parecidas com a sua situação e inclua alguém que trabalha com o agente todos os dias, não apenas o patrocinador.
• Trate respostas vagas e perguntas recusadas como informação, e depois verifique com documentos e um teste pequeno.

Por que referências de IA exigem perguntas diferentes das de outros softwares?

Uma ligação de referência para um software comum costuma confirmar que o produto funciona e que o fornecedor responde e-mails. Um agente de IA é diferente porque seu comportamento depende de várias peças móveis: o modelo por baixo, as instruções, a memória que ele consulta, as ferramentas que pode acionar e as permissões que possui. Qualquer uma delas pode mudar depois do lançamento, e a mudança em uma pode alterar o que o agente faz sem que ninguém mexa nas outras.

Por isso a parte reveladora da relação começa quando a equipe do projeto se afasta. Alguém precisa acompanhar o agente, definir o que conta como falha, aprovar mudanças e revisar acessos. Uma referência só consegue descrever esse trabalho se você perguntar diretamente sobre ele.

Lembre-se de que as referências são escolhidas pelo provedor e costumam estar comprometidas com a própria decisão de compra. Isso não é desonestidade, apenas um viés que precisa entrar na conta. A mesma cautela vale para histórias publicadas, tema de Como avaliar estudos de caso de IA sem se deixar enganar. Uma ligação vale mais quando suas perguntas são concretas o bastante para dificultar respostas gerais e educadas.

Como preparar uma ligação que gere respostas honestas?

A preparação importa mais do que o roteiro. Use este plano:

• Peça referências parecidas com a sua empresa no papel que o agente exerce, nos canais em que atua e no tamanho da equipe ao redor dele.
• Solicite uma referência que esteja em operação há algum tempo, não apenas lançamentos recentes, e, se possível, uma que tenha passado por uma fase difícil.
• Peça para falar com a pessoa que trabalha com o agente no dia a dia, além do executivo que assinou o contrato.
• Compartilhe os temas com antecedência (primeiras semanas, incidentes, mudanças, acesso, saída), mas guarde as perguntas exatas para a ligação.
• Faça anotações no mesmo formato em todas as ligações para poder compará-las lado a lado.
• Encerre cada ligação com duas perguntas abertas: o que você faria diferente e o que eu deveria ter perguntado e não perguntei?
• Registre o que a referência não soube responder. O que ela desconhece muitas vezes aponta para trabalho que o provedor fez sem avisar o cliente.

O que perguntar sobre as primeiras semanas depois do lançamento?

O período inicial mostra se o provedor continua engajado depois que o contrato é assinado. Estas perguntas funcionam bem:

• O que o agente errou nas primeiras semanas e quem percebeu primeiro: sua equipe ou o provedor?
• Quando você reportou um problema, quanto tempo passou até o comportamento do agente realmente mudar?
• O escopo vendido foi o mesmo que entrou em operação? O que foi acrescentado ou discretamente deixado de lado?
• Quanto tempo da sua equipe o agente exigiu por semana e isso correspondeu ao esperado?
• Em que sua equipe deixou de confiar e no que passou a confiar?
• O provedor já avisou você sobre um problema que vocês mesmos ainda não tinham notado?

A última pergunta é a mais forte. Um provedor que antecipa más notícias antes de você encontrá-las está monitorando o agente. Um provedor que só responde quando provocado está esperando a reclamação. Para ter uma ideia de como pode ser um início saudável, veja Primeiros meses com um agente de IA gerenciado: o que esperar.

Quais perguntas revelam como incidentes e mudanças são tratados?

Incidentes e mudanças são o ponto em que os provedores mais se diferenciam, e em que a memória do cliente costuma ser detalhada. Peça a história, não a política.

• Descreva o incidente mais sério até agora. O que aconteceu, como vocês ficaram sabendo e o que o provedor fez nas primeiras horas?
• Houve uma explicação por escrito depois? Ela levou a alguma mudança na forma de operar o agente?
• Quando o modelo de base ou um sistema conectado mudou, quem avisou vocês e foi antes ou depois de a mudança entrar em vigor?
• Como vocês pedem uma mudança? Quem aprova e dá para ver depois o que foi alterado?
• Alguma mudança já piorou as coisas? Como foi desfeita?
• Vocês conseguem ver o que o agente fez ontem sem pedir ao provedor?
• O provedor já recusou algo que vocês pediram? Qual foi o motivo?

As perguntas sobre mudanças correspondem a um processo que você deve esperar de qualquer provedor, parte da rotina descrita em O que é AgentOps? Como operar um agente de IA no dia a dia. A pergunta sobre visibilidade se liga à observabilidade, que o guia introdutório do OpenTelemetry descreve como entender o que um sistema está fazendo a partir dos registros que ele emite. Se o cliente depende do provedor para explicar cada comportamento, o monitoramento provavelmente é um serviço privado, e não um registro compartilhado.

A pergunta sobre recusas merece atenção. Um provedor que já disse não a um pedido arriscado ou mal definido está protegendo o cliente. Um provedor que nunca disse não pode ser apenas complacente, o que não é o mesmo que cuidadoso.

O que perguntar sobre acesso, dados e saída?

Esses temas parecem jurídicos ou técnicos, então as referências costumam pulá-los se ninguém puxar o assunto. Puxe.

• Quais sistemas o agente pode ler e quais pode alterar? Quem decidiu isso?
• Alguém revisou e reduziu as permissões do agente desde o lançamento?
• Onde ficam a memória e os registros do agente e quem do seu lado consegue vê-los?
• O provedor informou por escrito se os seus dados são usados para treinar algum modelo?
• Vocês conseguiriam exportar instruções, memória, configuração e registros se saíssem? Alguém já tentou?
• O que mudou entre o piloto e a conversa de renovação, em escopo e em condições?

A orientação de autorização da OWASP descreve o princípio do menor privilégio: dar a cada agente apenas o acesso que a tarefa exige. Uma referência que não sabe dizer o que o agente tem permissão para fazer sugere que esse conhecimento está só com o provedor, o que dificulta todas as revisões futuras. Nas perguntas de saída, um cliente que nunca testou uma exportação não tem como saber se ela funciona. Essa lacuna vale ser levada ao provedor, e Como migrar agentes de IA para outro fornecedor, passo a passo explica o que pedir.

Como interpretar as respostas?

Uma ligação de referência produz impressões. Transforme-as em decisão com um guia simples:

• Se a referência cita um incidente específico e uma correção específica, dê muito peso. Detalhe é difícil de inventar.
• Se as respostas sobre mudanças são vagas, peça ao provedor um exemplo de registro de mudança e compare.
• Se a referência não sabe descrever as permissões do agente, presuma que só o provedor as conhece.
• Se todas as respostas são positivas e genéricas, peça uma segunda referência e procure alguém mais próximo da operação diária.
• Se a referência menciona uma recusa ou um questionamento do provedor, trate isso como um sinal levemente positivo.
• Se o provedor se recusa a organizar qualquer ligação, peça uma conversa anonimizada ou descrições por escrito e pese a recusa.

Cenário ilustrativo: um comprador liga para duas referências. A primeira, um diretor, diz que o agente é excelente, mas não sabe dizer quem aprova mudanças. A segunda, uma coordenadora de operações, descreve uma semana em que o agente deu respostas desatualizadas depois da atualização de um sistema conectado. Ela conta que o provedor avisou antes da equipe, enviou um relato por escrito e acrescentou uma verificação depois. O comprador dá mais peso à segunda ligação e pede ao provedor os registros de mudança por trás do elogio do primeiro cliente.

Nenhuma ligação isolada resolve a questão. Combine o que você ouvir com um teste pequeno e delimitado, em que você mesmo observa o comportamento do provedor antes de se comprometer.

O que o provedor deve mostrar além das referências?

As referências descrevem a experiência passada de outras empresas. O provedor também deve conseguir mostrar como trabalha, em documentos que você possa inspecionar. Peça um exemplo de relatório de monitoramento, um exemplo de registro de mudança, a rotina de revisão de permissões, o processo de incidentes e as condições de exportação e saída.

A Be Human adota essa abordagem na infraestrutura de IA gerenciada. Um 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. A operação gerenciada pode então incluir monitoramento, avaliações recorrentes, manutenção de integrações, revisão de permissões, resposta a incidentes e melhorias controladas, com identidade, memória, canais, ferramentas e permissões do agente sob controle do cliente. São os mesmos itens que vale pedir a qualquer provedor que comprove, porque são eles que as histórias das referências devem confirmar.

Para um conjunto mais amplo de verificações sobre o comportamento de um provedor, Avaliação de segurança de fornecedor de IA: passo a passo é um bom complemento, e o NIST AI Risk Management Framework oferece um vocabulário neutro para perguntas de governança, se a sua empresa precisar de um.

Perguntas frequentes

Quantas referências devo pedir? Duas ou três costumam bastar, se diferirem de maneiras úteis: uma de longa data, uma recente e uma que passou por um período difícil. Mais ligações acrescentam pouco, a menos que as respostas entrem em conflito. Se entrarem, investigue a diferença em vez de tirar uma média.

E se o provedor disser que seus clientes são confidenciais? A confidencialidade é comum e legítima, então ofereça alternativas: uma conversa anonimizada, uma descrição escrita aprovada pelo cliente ou relatórios operacionais de exemplo sem dados identificáveis. Se nada disso for possível, dê mais peso a um teste delimitado em que você observa o comportamento do provedor por conta própria.

Devo procurar clientes que o provedor não indicou? Sim, se você tiver uma conexão natural, como um colega de outra empresa ou alguém da sua rede profissional. Seja transparente sobre o motivo do contato, mantenha o pedido leve e nunca peça informações confidenciais. Opiniões espontâneas tendem a ser menos polidas, o que as torna mais informativas.

Há quanto tempo a referência deveria estar em operação? Tempo suficiente para ter vivido uma mudança no modelo de base ou em um sistema conectado, uma revisão de permissões e pelo menos uma troca de pessoas na equipe do lado dela. Esses eventos testam como o provedor se comporta quando algo muda. Um lançamento muito recente informa sobre a implantação, mas ainda não sobre a operação.

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