Como avaliar a estabilidade de um fornecedor de IA antes de contratar

Para avaliar a estabilidade de um fornecedor de IA, deixe de tentar prever se a empresa vai sobreviver e teste se o seu trabalho sobreviveria sem ela. Quatro pontos podem ser verificados antes da assinatura: uma documentação que corresponda ao sistema real, a possibilidade de exportar aquilo de que você depende, um suporte que vá além de uma única pessoa e uma arquitetura que não dependa de um só modelo. Um fornecedor que passa nessas verificações é uma escolha mais segura, aconteça o que acontecer com o seu financiamento ou com o seu modelo favorito.

Principais pontos

• Estabilidade tem menos a ver com o tamanho do fornecedor e mais com a capacidade de o seu agente continuar funcionando se o fornecedor mudar, encolher ou desaparecer.
• Peça documentação escrita para o sistema que você de fato vai operar e entregue-a a alguém que não participou das reuniões comerciais.
• Solicite, antes de assinar, uma exportação real de instruções, memória, definições de ferramentas e registros, e abra os arquivos você mesmo.
• Profundidade de suporte significa substitutos nomeados e escalonamento por escrito, não um contato simpático.
• Pergunte o que acontece quando o modelo de base é aposentado ou muda de comportamento, e procure um plano alternativo já testado.

O que significa estável para um fornecedor de IA?

A maioria dos compradores começa por capital, número de funcionários e anos de mercado. Esses dados são difíceis de verificar e preveem pouco. Um fornecedor pequeno e bem gerido pode ser um parceiro mais seguro do que um grande, cujo produto muda a cada trimestre e cujo conhecimento está na cabeça de um único engenheiro.

Uma definição mais útil é continuidade. Se o fornecedor aumentasse os preços, aposentasse um modelo, perdesse o engenheiro principal ou fechasse, quanto do seu agente você conseguiria manter funcionando? Essa pergunta transforma uma preocupação vaga em algo que pode ser inspecionado e se desdobra em quatro sinais: documentação, portabilidade, profundidade de suporte e dependência de um único modelo.

O [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) incentiva as organizações a mapear e gerenciar riscos que vêm de componentes de terceiros. Esses quatro sinais são uma forma prática de aplicar essa ideia à relação com um fornecedor sem precisar montar antes um grande programa de governança.

Cada sinal pode ser testado com um pedido, e não com uma opinião. Se o fornecedor hesita em deixar você testar, essa hesitação já é uma informação. Para um método mais amplo, veja como avaliar uma demonstração de agente de IA antes de comprar.

A documentação descreve o sistema que você realmente vai operar?

Boa documentação é o seguro de continuidade mais barato que um fornecedor pode oferecer, porque permite que outra pessoa, além do autor, opere o sistema. Páginas de marketing não contam. O que você procura é material que explique como o seu agente será construído e mantido.

Peça para ver, em versão anonimizada ou em modelo:

• Uma descrição da arquitetura que nomeie o modelo, o repositório de memória, as ferramentas conectadas e os canais que o agente usa.
• Uma definição de função: o que o agente faz, o que não pode fazer e quem aprova exceções.
• Um manual de operação para tarefas de rotina, como atualizar instruções, trocar credenciais e tratar uma integração que falhou.
• Um histórico de alterações que mostre como as atualizações anteriores foram registradas e revisadas.
• Um processo de incidentes: como você é avisado quando algo quebra e o que o relatório de acompanhamento contém.

Depois, faça um teste simples. Entregue o material a um colega que não participou de nenhuma reunião comercial e peça que explique, com as próprias palavras, como o agente está configurado e a quem recorrer quando ele se comportar mal. Se ele não conseguir, a documentação é uma pessoa, não um documento.

Verifique também se o material está atualizado. Documentação que descreve funções que o produto já não tem, ou que omite mudanças recentes, sugere que ninguém é responsável por ela. Esse mesmo material deve alimentar diretamente o seu escopo de trabalho, de modo que o que está documentado seja também o que foi prometido.

Você consegue levar o seu agente embora se sair?

Portabilidade é o sinal que mais pesa quando todo o resto dá errado. Ela responde a uma pergunta: se a relação terminasse amanhã, o que você levaria?

Divida o agente em partes e pergunte sobre cada uma:

• Instruções e definição de função, em um formato legível que você abra sem software especial.
• Memória e fontes de conhecimento, incluindo como são armazenadas e se podem ser exportadas.
• Definições de ferramentas e integrações, incluindo de quais contas e credenciais elas dependem.
• Permissões e regras de aprovação, escritas, e não apenas implícitas na configuração.
• Registros e trilhas de auditoria do que o agente fez.

A propriedade das contas merece uma linha própria. Verifique se a conta do modelo, o projeto na nuvem, a identidade de e-mail e as credenciais de integração estão em nome da sua empresa ou do fornecedor. Um agente que roda inteiramente em contas às quais você não tem acesso não é portável, por melhor que pareça o arquivo de exportação.

Padrões abertos ajudam na camada de ferramentas. O [Model Context Protocol](https://modelcontextprotocol.io/docs/getting-started/intro) é um exemplo de forma compartilhada de conectar modelos a ferramentas e dados, o que facilita mover uma conexão de ferramenta entre sistemas, em comparação com conectores todos proprietários. Pergunte se o fornecedor usa padrões onde eles existem e se explica onde não usa.

O teste decisivo é simples: peça uma exportação de amostra antes de assinar e peça que sua equipe a abra. Se levar semanas para ser produzida, você já descobriu como seria uma saída. A mecânica completa da troca está em como migrar agentes de IA para outro fornecedor, e o lado da dependência em como evitar dependência de fornecedor de IA em agentes.

Qual é a profundidade do suporte depois do primeiro contato?

Um vendedor atencioso diz pouco sobre o que acontece no nono mês. Profundidade de suporte é o número de pessoas e de processos escritos entre o seu problema e a solução dele.

Faça estas perguntas ao fornecedor e peça as respostas por escrito:

• Quem é o contato principal nomeado e quem é o substituto nomeado que também conhece a sua configuração?
• Se o contato principal ficar indisponível por duas semanas, quem age e com qual autoridade?
• Quais são os prazos de resposta para uma integração quebrada e para uma reclamação de qualidade, e quem decide qual é qual?
• Como você é informado sobre incidentes e recebe uma explicação por escrito depois?
• Quais fusos horários o suporte cobre e o que acontece fora deles?

Preste atenção em quem faz o trabalho de manutenção. Modelos são aposentados, integrações mudam de interface e credenciais expiram. Um fornecedor que tem uma rotina para esses eventos, e não apenas a promessa de reagir, tende a continuar útil daqui a um ano.

Pergunte também como o fornecedor se comportaria se as pessoas do seu lado mudassem. Um bom fornecedor consegue integrar um novo responsável da sua empresa apenas com base na documentação. Se a relação só funciona porque um gerente seu tem afinidade pessoal com um gerente deles, a continuidade é social, não estrutural.

Quanto o fornecedor depende de um único modelo?

A maioria dos agentes de IA usa um modelo operado por outra empresa. Essa empresa pode mudar o comportamento entre versões, aposentar uma versão, alterar seus termos ou ajustar seus limites. Um fornecedor totalmente preso a um só modelo repassa esse risco diretamente a você.

O objetivo não é usar muitos modelos. É saber onde está o valor. Em um sistema bem projetado, os ativos duráveis são a definição de função, a memória, as conexões de ferramentas e o conjunto de avaliação, e o modelo é um componente substituível. Em um sistema frágil, o comportamento de que você gostou é efeito colateral de um modelo específico e ninguém sabe explicar por que funciona.

Pergunte ao fornecedor:

• O que acontece, passo a passo, quando o modelo atual é aposentado?
• Existe uma alternativa já testada ou apenas a intenção de encontrar uma?
• Há um conjunto de tarefas de exemplo com respostas corretas conhecidas, para comparar um substituto com o comportamento atual antes de colocá-lo no ar?
• Quem aprova uma troca de modelo e como você é avisado?

O conjunto de avaliação é a evidência mais forte. O artigo da Anthropic [Demystifying evals for AI agents](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents) explica por que verificações sistemáticas importam quando os agentes estão em produção, e a mesma lógica vale para trocar um modelo. Um fornecedor sem forma de medir a diferença não consegue mudar nada com segurança. Para o lado estratégico, veja como escolher modelo de IA para empresa.

Que checklist você pode aplicar antes de assinar?

Os sinais acima cabem em uma sequência curta de verificação. Trate-a como uma semana de pedidos objetivos, não como uma auditoria.

• Peça o conjunto de documentação e faça um colega de fora do processo comercial resumi-lo.
• Peça uma exportação de amostra de instruções, formato de memória, definições de ferramentas e registros, e abra cada arquivo.
• Liste todas as contas em que o agente rodaria e marque quem é o dono de cada uma.
• Solicite por escrito os contatos principal e substituto nomeados, o caminho de escalonamento e os prazos de resposta.
• Peça o plano de aposentadoria de modelo e a abordagem de avaliação usada para comparar um substituto.
• Pergunte como os incidentes são comunicados e veja um exemplo anonimizado de relatório de acompanhamento.
• Pergunte o que o fornecedor faz com os seus dados, inclusive se são usados para treinamento, e obtenha a resposta por escrito.
• Classifique cada resposta como verificada, declarada ou ausente e decida quais lacunas você pode aceitar.

Cenário ilustrativo: uma distribuidora compara dois fornecedores para um agente que redige respostas a e-mails de fornecedores. Ambos fazem boas demonstrações. O fornecedor A envia uma definição de função documentada, uma exportação de amostra em arquivos simples, contas abertas em nome da empresa e um contato substituto nomeado. O fornecedor B promete a mesma qualidade, mas diz que a exportação só fica disponível sob pedido depois do lançamento, e o único contato é o fundador. As demonstrações foram iguais. A continuidade não foi, e a decisão fica simples quando as evidências estão na mesa.

Um alerta: verificado vale mais que declarado. A promessa de fornecer uma exportação é mais fraca do que uma exportação que você já abriu.

Como uma operação gerenciada trata a continuidade?

A Be Human trata a continuidade como parte do projeto, e não como algo a resolver depois. Cada contratação começa definindo uma função, a memória e as ferramentas de que ela precisa, os limites de aprovação e um critério de sucesso observável, e tudo isso é registrado por escrito para que o cliente tenha uma descrição legível do agente. Identidade, memória, canais, ferramentas e permissões ficam sob controle humano, e o modelo é tratado como um componente que pode ser avaliado e substituído. A operação gerenciada inclui monitoramento, avaliações recorrentes, manutenção de integrações, revisão de permissões e resposta a incidentes, de modo que mudanças de modelo e conexões quebradas são tratadas como trabalho de rotina. O atendimento é remoto, em português e inglês.

Perguntas frequentes

Devo evitar empresas jovens de IA? Não automaticamente. A idade diz pouco sobre a continuidade do seu agente, enquanto documentação, ativos exportáveis e suporte substituto nomeado dizem muito. Um fornecedor jovem que passa nessas verificações pode ser uma escolha mais segura do que um consolidado que falha nelas.

Um fornecedor grande é automaticamente mais estável? O porte reduz alguns riscos, como um fechamento repentino, mas acrescenta outros, como mudanças de produto sobre as quais você não tem influência e um suporte que o trata como mais uma conta entre muitas. Aplique as mesmas verificações a todo fornecedor, grande ou pequeno, e compare as evidências, não a marca.

E se o provedor do modelo mudar os termos ou aposentar um modelo? Peça ao fornecedor o plano por escrito antes que isso aconteça. Um fornecedor preparado mantém um conjunto de avaliação, testa um substituto com base nele, avisa você sobre a mudança e registra quem a aprovou. Um despreparado descobrirá o problema quando as respostas do seu agente mudarem.

Com que frequência devo reavaliar o fornecedor depois de assinar? Revise os sinais em um ritmo regular, por exemplo quando revisar as permissões ou a cada conversa de renovação. Confirme que a documentação está atual, que uma exportação nova ainda abre, que os contatos continuam nomeados e que o plano de modelo não mudou. A continuidade se desgasta em silêncio, por isso uma verificação curta e recorrente funciona melhor do que uma grande revisão isolada.

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