Perguntas para fornecedor de agentes de IA antes de assinar

As perguntas para fornecedor de agentes de IA se dividem em cinco grupos: quem é dono do que o agente sabe e produz, a que ele tem acesso, quem dá suporte depois da entrada em produção, como você pode sair e que evidências mostram que ele está sendo supervisionado. O fornecedor que responde a cada grupo por escrito, com papéis nomeados e registros que você pode inspecionar, está vendendo um sistema operado. O que responde com garantias genéricas está vendendo uma demonstração.

Principais pontos

• Pergunte primeiro sobre propriedade: instruções, memória, resultados e as contas usadas pelo agente devem ser claramente suas, ou estar documentados como não sendo suas.
• Trate o acesso como uma lista de permissões, não como uma lista de funcionalidades. Cada conexão precisa de um escopo, de um responsável e de um jeito de você revogá-la.
• A supervisão aparece em registros, limites de aprovação e avaliações recorrentes, não na promessa de que o agente é monitorado.
• Suporte e saída são a mesma pergunta vista de pontas opostas: o que você recebe, em que formato e quem age quando algo dá errado.
• Avalie cada resposta pelo que ela aponta que você possa inspecionar. A recusa em colocar propriedade, acesso ou saída por escrito é motivo para parar.

Quem é o dono do agente, da memória e do trabalho dele?

Uma demonstração mostra o que o agente consegue fazer num bom dia. O contrato decide quem fica com as peças depois. Um agente não é um objeto único. É um conjunto de instruções, definições de ferramentas, contas conectadas, memória acumulada e um rastro de resultados e registros. Cada parte pode ter um dono diferente, e os fornecedores raramente dizem espontaneamente qual é qual.

Um teste prático: imagine que o fornecedor desapareça no mês que vem. Quais partes você poderia pegar e entregar a outra pessoa? Se a resposta não é clara, faça estas perguntas antes de assinar:

• Quem é dono das instruções, das definições de ferramentas e da configuração escritas para o nosso agente?
• Quem é dono da memória que o agente constrói sobre nossos clientes, produtos e decisões, e em que formato podemos exportá-la?
• Quem é dono dos resultados: rascunhos, resumos, registros e logs?
• Nossos documentos e conversas são usados para treinar ou melhorar algo fora da nossa própria conta?
• Quais provedores de modelo e subprocessadores têm contato com nossos dados, e em quais regiões?
• As contas, os números e as caixas de e-mail do agente estão registrados em nosso nome ou no de vocês?

Dê atenção especial à memória. É nela que mora o conhecimento de trabalho do agente sobre o seu negócio. Se ela existe só dentro do sistema do fornecedor, num formato que você não consegue ler, você está alugando o conhecimento da sua própria empresa. Peça para ver um exemplo de como a memória armazenada se parece. Um fornecedor que projetou a memória para ser legível e corrigível por uma pessoa conseguirá mostrar um.

Pergunte também onde fica a fonte da verdade do agente. Se ele responde a partir de documentos, alguém precisa decidir qual versão está em vigor e quem pode alterá-la. Essa decisão deve ser sua.

O que o agente pode acessar e quem controla esse acesso?

A maior parte do risco de um projeto com agente de IA está no acesso. Um agente que só lê uma pasta compartilhada é uma proposta muito diferente de um que envia e-mails, edita o seu CRM e movimenta dinheiro. Um bom fornecedor descreve o acesso como faria um revisor de segurança: por sistema, por ação, por conta.

Existem padrões de autorização para isso. O OAuth 2.0 permite conceder a uma ferramenta escopos limitados e revogáveis sem compartilhar senha, e orientações gerais como o OWASP Authorization Cheat Sheet recomendam negar por padrão e conceder o mínimo necessário. Seu fornecedor deve se sentir à vontade falando nesses termos. O princípio é detalhado em menor privilégio para agentes de IA.

Leve estas perguntas para a conversa:

• A quais sistemas o agente vai se conectar e qual é o nível de permissão de cada conexão: ler, preparar rascunho ou enviar?
• As conexões são feitas por contas nossas, com escopos revogáveis, ou por credenciais compartilhadas ou mantidas pelo fornecedor?
• Quais pessoas da sua empresa podem ver nossos dados ou agir por meio das nossas conexões, e onde esse acesso é registrado?
• Podemos revogar qualquer conexão por conta própria, de imediato, sem abrir chamado?
• Como os nossos dados são separados dos dados dos seus outros clientes?
• O que o agente faz quando uma conexão expira ou uma permissão é removida?

A última pergunta é fácil de esquecer e muito reveladora. Um agente que falha em silêncio, repete tentativas às cegas ou improvisa para contornar uma permissão ausente é um risco. A resposta certa é que ele para, registra o que não conseguiu fazer e avisa uma pessoa.

Se o fornecedor propõe começar com acesso amplo e restringir depois, pergunte por quê. Começar restrito e ampliar com evidências é a ordem mais segura.

Como o agente será supervisionado depois de entrar no ar?

Esta é a pergunta que separa um agente gerenciado de uma ferramenta que você precisa vigiar sozinho. Todo fornecedor diz que o agente é monitorado. Seu trabalho é descobrir o que esse monitoramento produz: quais registros, quem os lê, com que frequência e o que acontece quando algo parece errado.

A supervisão tem três partes, e vale perguntar sobre cada uma.

A primeira são os registros. A ideia geral de observabilidade, descrita na introdução do OpenTelemetry, é que você consegue entender o comportamento de um sistema pelos dados que ele emite. Para um agente, isso significa um rastro legível do que ele recebeu, das fontes que usou, das ferramentas que chamou e do que produziu. O artigo sobre o que registrar na observabilidade de agentes de IA entra nos detalhes.

A segunda são os limites. Algumas ações nunca deveriam acontecer sem a aprovação de uma pessoa. Peça ao fornecedor que mostre onde essa linha foi traçada para o seu fluxo e quem pode movê-la. Quando seu agente de IA deve parar e perguntar explica como decidir.

A terceira é a avaliação. Um agente que funcionou na entrada em produção pode se desviar à medida que documentos, ferramentas e modelos mudam. Pergunte como a qualidade é testada antes do lançamento e de forma recorrente depois. Uma referência de nível mais amplo, como o NIST AI Risk Management Framework, trata a medição contínua e a supervisão humana como parte da gestão de um sistema de IA, e não como uma verificação única.

Use estas perguntas:

• O que é registrado em cada execução: entrada, fontes, chamadas de ferramentas, resultados e aprovações?
• Podemos ler esses registros por conta própria, em linguagem simples, sem a ajuda de vocês?
• Quais ações exigem aprovação humana e onde esse limite está escrito?
• Como o agente é avaliado antes do lançamento e com que frequência depois?
• Qual é o critério de sucesso para esta função e como ele é observado, em vez de apenas relatado?
• O agente vai rodar primeiro em modo de observação, produzindo propostas que ninguém executa até que as tenhamos revisado?
• Quem revisa o comportamento do agente a cada semana e o que recebemos dessa revisão?

Sobre o modo de observação, um fornecedor que já passou por isso terá opinião. O raciocínio está em como testar um agente de IA em modo de observação. Se o fornecedor quer dar autoridade real ao agente já no primeiro dia, pergunte que evidências usaria para justificar isso.

O que o suporte cobre quando algo dá errado?

Suporte para um agente de IA não é só uma central de atendimento. O agente depende de ferramentas conectadas que mudam, de documentos que ficam desatualizados e de modelos que recebem atualizações. Alguém precisa notar e agir. A questão é se esse alguém é você, o fornecedor ou ninguém.

Peça detalhes sobre estes pontos:

• Quem responde a um incidente, em qual idioma e fuso horário, e por qual canal?
• O que conta como incidente e qual é a primeira ação: pausar o agente, revogar uma conexão ou investigar com ele ainda em funcionamento?
• Quem mantém as integrações quando uma ferramenta conectada muda sua interface ou suas permissões?
• Como as mudanças no comportamento do agente são propostas, testadas e aprovadas antes de entrar no ar?
• Receberemos um relato por escrito após um incidente, com causa, efeito e correção?
• Quais verificações de rotina acontecem de forma agendada, como revisão de permissões e reexecução de avaliações?

A diferença entre suporte reativo e suporte gerenciado aparece no último item. O fornecedor reativo espera você relatar um problema. Um serviço operado tem uma rotina recorrente que encontra os problemas primeiro. Um exemplo dessa rotina está em um checklist semanal de manutenção de agentes de IA gerenciados. Peça ao fornecedor que mostre a dele.

Pergunte também sobre o idioma do suporte. Se a sua equipe trabalha em português, em inglês ou nos dois, confirme que as explicações de incidentes e os relatórios chegarão no idioma que seus tomadores de decisão realmente leem.

Como sair se a relação terminar?

Falar de saída parece pessimismo quando você está animado com uma nova capacidade. Mas é também o sinal mais claro de como o fornecedor pensa o seu negócio. Quem confia no valor do serviço não tem motivo para dificultar a saída.

Peça o pacote de saída em termos concretos:

• O que recebemos ao sair: memória, configuração, instruções, logs e documentação?
• Em que formato e em quanto tempo depois do pedido?
• Todas as conexões e credenciais são revogadas, e recebemos essa confirmação por escrito?
• Os nossos dados são apagados mediante pedido, e que comprovação de exclusão recebemos?
• O agente pode continuar funcionando por um período definido de transição, enquanto migramos para outro provedor ou levamos o trabalho para dentro de casa?
• Alguma cláusula do contrato limita nossa capacidade de exportar ou de sair antes do prazo?

Um bom hábito é pedir o pacote de saída como documento antes de assinar, não como promessa. Se o fornecedor consegue descrever hoje os arquivos, a estrutura de pastas e as etapas da transição, ele já pensou nisso. Se a resposta é que cada caso será tratado separadamente, espere atrasos mais tarde.

A saída também se conecta às perguntas de propriedade vistas antes. Tudo o que você não conseguiria exportar na primeira seção é algo que perderia aqui.

Como pontuar as respostas que você receber?

Uma lista longa de perguntas só serve se você consegue comparar as respostas. Em vez de somar pontos, classifique cada resposta em um de quatro grupos:

• Forte: a resposta nomeia um papel, um documento ou um registro que você pode inspecionar, e o fornecedor se oferece para mostrá-lo.
• Aceitável: a resposta descreve um processo com responsável claro, mas ainda não existe um exemplo. Peça um antes de assinar.
• Fraca: a resposta é uma garantia genérica, como a nossa plataforma cuida disso, ou fica para uma conversa futura.
• Pare: o fornecedor não aceita colocar por escrito os termos de propriedade, acesso ou saída.

Cenário ilustrativo: uma distribuidora regional compara dois fornecedores para um agente que responde a dúvidas sobre o status de pedidos. As duas demonstrações são boas. O responsável de operações envia a mesma lista curta a cada um. Um responde com um exemplo de registro de execução, a descrição de quais ações exigem aprovação e a lista do que é entregue na saída. O outro responde que monitoramento e portabilidade de dados estão incluídos na plataforma. O responsável de operações não precisa julgar as demonstrações. O primeiro fornecedor produziu algo inspecionável, e o segundo produziu uma frase.

Envie a lista antes da conversa, para que o fornecedor traga as pessoas e os documentos certos. Peça as respostas por escrito e use a reunião para aprofundar as fracas. Se quiser ir além, peça ao fornecedor que execute uma tarefa pequena e definida antes de você se comprometer, com um checklist de aceitação combinado de antemão. Um checklist para aceitar a integração do seu agente de IA pode servir de modelo inicial.

Como a Be Human trata isso: a Be Human projeta, implementa e opera infraestrutura de IA personalizada, e um primeiro 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. A operação gerenciada pode incluir monitoramento, avaliações recorrentes, manutenção de integrações, revisão de permissões, resposta a incidentes e melhorias controladas. O serviço é remoto e atende em português e em inglês. São as mesmas áreas que esta lista cobre, então espere que lhe peçam a mesma clareza em troca.

Perguntas frequentes

Quantos fornecedores devo comparar antes de escolher? Dois ou três costumam bastar se você enviar a cada um as mesmas perguntas por escrito. Mais do que isso tende a gerar cansaço de comparação sem trazer informação melhor. A qualidade das respostas escritas separa os fornecedores mais rápido do que o número de funcionalidades.

Uma empresa pequena deve fazer todas essas perguntas? Sim, mas pode encurtar a lista concentrando-se no fluxo que está comprando. Uma empresa pequena com um agente em uma função ainda precisa saber quem é dono da memória, no que o agente pode mexer e como sair. A profundidade das respostas pode ser proporcional, mas os temas são os mesmos.

E se o fornecedor disser que algumas respostas são confidenciais? Alguns detalhes de implementação podem ser protegidos de forma razoável. Propriedade, escopos de acesso, limites de aprovação, responsabilidades de suporte e termos de saída dizem respeito ao seu negócio e devem poder ser compartilhados. Se o fornecedor não os descreve nem sob um acordo de confidencialidade, trate isso como uma resposta fraca.

Preciso de equipe técnica para avaliar as respostas? Para a maioria delas, não. Você precisa de alguém que consiga ler um registro de execução e dizer se ele está claro, e de alguém que possa aprovar o acesso aos seus sistemas. Se nenhuma dessas pessoas existe internamente, peça ao fornecedor que explique cada resposta em linguagem simples e mostre as evidências. Um fornecedor que não consegue explicar com clareza já lhe disse algo útil.

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