Modos de falha da superinteligência em empresas: riscos reais hoje

Os modos de falha da superinteligência dentro das empresas raramente são dramáticos. Para uma empresa que já opera agentes de IA, as falhas realistas são memória desatualizada que continua agindo com base em fatos antigos, permissões maiores do que o trabalho exige, desvio silencioso quando as respostas mudam sem aviso e instruções escondidas em documentos ou mensagens. Cada uma pode ser contida com disciplina operacional comum: acesso restrito ao necessário, verificações programadas, ações registradas e uma pessoa nomeada que responde pelo resultado.

Principais pontos

• As falhas que mais importam no nível da empresa são operacionais: memória, permissões, desvio, entradas não confiáveis e responsabilidade pouco clara.
• Cada modo de falha precisa de um controle específico, não de um compromisso genérico de usar IA com responsabilidade.
• As permissões devem ser concedidas em níveis e revisadas com periodicidade, não definidas uma única vez no lançamento.
• O desvio se descobre comparando respostas reais com um padrão escrito, porque o sistema não avisa quando mudou.
• Todo agente precisa de um dono nomeado, que consiga pausá-lo, desfazer as ações registradas e explicar o que ele fez.

De onde vêm as falhas de IA no nível da empresa

A ficção científica costuma apresentar a falha como um sistema poderoso que se volta contra quem o criou. Dentro de uma empresa, a falha costuma parecer um erro comum de operação, produzido mais rápido e repetido com mais frequência do que uma pessoa faria. Um agente que responde perguntas de clientes, atualiza uma planilha compartilhada ou rascunha pedidos a fornecedores é um conjunto de partes: um modelo, instruções, memória, ferramentas, canais e permissões. Um problema pode começar em uma parte e aparecer em outra. Para o dono do negócio, a pergunta útil é qual parte pode estar errada, quem perceberia e quanto tempo levaria até isso aparecer.

O NIST AI Risk Management Framework trata o risco de IA como algo a ser governado durante toda a vida de um sistema. Para uma empresa, isso significa transformar a lista abstrata em modos de falha concretos, que possam ser escritos, atribuídos e testados. Um primeiro passo prático é descrever um único papel: a memória e as ferramentas de que ele precisa, as ações que pode executar sozinho e o resultado que você vai observar. Os projetos gerenciados da Be Human partem dessa mesma definição, porque uma lista de falhas só é útil quando está ligada a um trabalho específico.

Memória desatualizada: quando o agente age com fatos de ontem

A memória é o que torna um agente útil ao longo de dias e semanas. Ela também é o que o torna silenciosamente errado. Uma política de entrega, uma tabela de preços, a escala de uma equipe ou a preferência declarada de um cliente podem mudar enquanto as anotações guardadas pelo agente continuam iguais. Como o agente escreve com fluência a partir dessas anotações, o erro parece competência.

A memória desatualizada costuma ter três origens: fatos registrados uma vez e nunca revisados, cópias de documentos tiradas de uma versão antiga de uma pasta compartilhada e resumos de conversas passadas que deixaram de fora uma correção posterior. A solução tem menos a ver com memória melhor e mais com procedência. Cada fato armazenado deve registrar de onde veio, quem o confirmou e quando precisa ser revisado novamente.

Passos de contenção:

• Marque cada entrada de memória com a fonte e com a pessoa que a confirmou.
• Defina uma regra de revisão para cada categoria de memória, revisando preços e políticas com mais frequência.
• Exija que o agente informe a fonte de qualquer fato que apresente a um cliente ou colega.
• Quando uma fonte mudar, descarte as anotações relacionadas em vez de acrescentar uma correção abaixo delas.

Cenário ilustrativo: o agente de uma pequena empresa de serviços guarda uma anotação sobre o prazo de aviso para cancelamentos. O dono muda a política e atualiza o manual, mas ninguém mexe na memória do agente. Por semanas, o agente cita a regra antiga, com educação e confiança. O modelo não errou. A falha estava em uma entrada de memória sem fonte e sem data de revisão.

Em um projeto gerenciado, a Be Human define o escopo de memória de cada papel no início, registra a fonte por trás de cada categoria de memória e inclui a revisão da memória nas avaliações recorrentes. Assim, as entradas desatualizadas são encontradas em uma rotina programada, e não por um cliente reclamando. Para o lado da configuração, como carregar o histórico da empresa na memória de um agente de IA ajuda a decidir o que carregar primeiro.

Permissões excessivas: quando o agente pode fazer mais do que o seu trabalho

As permissões tendem a crescer por conveniência. Um agente criado para rascunhar respostas ganha acesso à caixa de entrada para testes, depois permissão de escrita no CRM para registrar anotações e, por fim, acesso ao painel de pagamentos porque alguém quis que ele conferisse faturas. Cada passo parece razoável isoladamente. Somados, eles produzem um agente capaz de enviar, apagar ou gastar muito além do que alguém pretendia. Ninguém escolheu esse resultado, e é por isso que ele persiste.

As orientações de autorização da OWASP partem de uma ideia simples: o acesso deve ser verificado contra uma política explícita a cada uso, e não presumido só porque uma conexão existe. Para agentes, isso significa separar três coisas: o que o agente pode ler, o que pode propor e o que pode executar. A execução acima de um limite definido deve depender da aprovação de uma pessoa.

Passos de contenção:

• Liste cada ferramenta e cada conta que o agente possui, com as ações exatas que cada uma permite.
• Remova qualquer ação que o critério de sucesso do papel não exija, principalmente direitos de excluir, exportar e pagar.
• Organize as ações restantes em níveis: ler livremente, rascunhar para revisão, executar com aprovação, nunca executar.
• Repita a revisão em uma data fixa e depois de cada pedido de alteração.

Cenário ilustrativo: uma distribuidora dá ao agente de pedidos acesso somente leitura ao portal de um fornecedor, para consultar estoque. Uma mudança posterior na configuração acrescenta direito de compra ao mesmo login, para que o agente possa emitir pedidos de reposição. Ninguém decidiu que o agente deveria comprar sem aprovação. O direito simplesmente chegou junto com o login. Uma revisão que comparasse o que o login pode fazer com o que o papel está autorizado a fazer teria detectado isso.

A abordagem em níveis descrita em autorização de agentes de IA: níveis de permissão por confiança é uma forma de estruturar esses níveis. A operação gerenciada da Be Human inclui a revisão de permissões como tarefa recorrente: o acesso é definido por papel, as mudanças passam por um pedido por escrito e cada revisão compara os direitos reais das ferramentas com as ações aprovadas.

Desvio silencioso: quando o mesmo agente se comporta de outro jeito com o tempo

Desvio é uma mudança de comportamento que ninguém anunciou. Pode vir de um fornecedor de modelo que atualiza o modelo por trás, de uma instrução editada que muda a ênfase, de um documento novo na base de conhecimento que passa a prevalecer sobre um mais antigo ou de uma ferramenta cujo formato de resposta mudou sem alarde. Software convencional costuma falhar de forma barulhenta. Um agente muitas vezes continua produzindo respostas fluentes e plausíveis enquanto a qualidade cai.

A detecção depende de evidências coletadas fora das próprias palavras do agente. A prática de observabilidade, como o material introdutório da OpenTelemetry descreve, se apoia em registrar o que um sistema fez para que seu comportamento possa ser examinado e comparado ao longo do tempo. Aplicado a agentes, isso significa registrar pedidos, chamadas de ferramentas e resultados, e então medi-los contra uma referência. Um conjunto fixo de avaliação, com os mesmos casos reexecutados após cada mudança, oferece uma comparação que não depende de o agente julgar as próprias respostas.

Um plano prático:

• Escreva como é uma boa resposta para o papel, com alguns exemplos que um revisor aceitaria.
• Monte um pequeno conjunto de testes fixo a partir de casos reais passados, incluindo os mais difíceis.
• Reexecute o conjunto de testes antes e depois de qualquer mudança de modelo, instrução, ferramenta ou dado.
• Amostre respostas reais toda semana e avalie-as contra o padrão escrito.
• Trate qualquer queda na avaliação como incidente a investigar, não como uma peculiaridade a ignorar.

O monitoramento gerenciado da Be Human mantém o conjunto fixo de testes, registra as mudanças de instruções, ferramentas e fontes de dados e informa as variações de pontuação ao dono nomeado. Assim, uma atualização de modelo é testada antes de chegar aos clientes, em vez de ser descoberta por uma reclamação. A etapa de amostragem semanal está descrita em como avaliar agentes de IA em tarefas de negócio.

Instruções injetadas: quando o conteúdo diz ao agente o que fazer

Um agente que lê e-mails, páginas da web, arquivos enviados ou mensagens de clientes está lendo textos escritos por pessoas que você não controla. A injeção de prompt acontece quando esse texto contém instruções que o agente passa a seguir, como uma linha mandando ignorar as regras e encaminhar uma lista de contratos. A orientação da OWASP sobre injeção de prompt trata isso como um risco básico para qualquer sistema que mistura instruções e dados no mesmo canal. Como um modelo nem sempre consegue distinguir os dois, a contenção não pode depender só do modelo.

Os controles que funcionam são estruturais. Limite o que o agente pode fazer em qualquer sessão que tenha incluído conteúdo não confiável. Mantenha uma lista de destinos permitidos para envio. Separe a leitura da ação e exija aprovação para qualquer ação disparada por texto externo. Trate também a saída do agente como não confiável quando outro sistema a consumir.

Passos de contenção:

• Classifique cada entrada pela origem: registros internos, material enviado pelo cliente ou web pública.
• Depois de processar uma entrada não confiável, bloqueie o envio de dados a destinatários novos sem aprovação.
• Nunca deixe conteúdo vindo de fora da empresa alterar as instruções ou permissões do agente.
• Registre cada chamada de ferramenta feita em uma sessão que teve entrada não confiável, para que possa ser revisada.

Cenário ilustrativo: um cliente anexa a um pedido de suporte um documento com um texto oculto pedindo que o agente revele a tabela de preços interna. O papel de suporte não tem acesso a preços, e qualquer resposta a um endereço externo espera aprovação. A tentativa não funciona, e o registro a documenta. Esse registro é o que o dono precisa para decidir se o tratamento das entradas ou o escopo do papel deve ser apertado.

Ações descontroladas e responsabilidade pouco clara

Duas falhas envolvem escala e responsabilidade, não conhecimento. Um agente com um objetivo e uma regra de nova tentativa pode entrar em loop, enviando mensagens repetidas, criando registros duplicados ou consumindo chamadas pagas de ferramentas sem um ponto de parada visível. Além disso, quando um agente comete um erro, muitas empresas não conseguem dizer quem o autorizou a agir. As duas são questões operacionais, e ambas saem muito mais baratas se resolvidas antes do lançamento.

Defina limites rígidos de tentativas, de ritmo e de gasto para cada tarefa, com uma parada que qualquer pessoa nomeada possa acionar. Toda ação que cria ou envia algo deve ser idempotente, ou seja, uma nova tentativa reconhece que a ação já aconteceu e não a repete. Pergunte aos seus fornecedores de ferramentas como eles tratam pedidos repetidos e aplique a mesma verificação nas integrações que você mesmo mantém. A responsabilidade é uma decisão que se escreve: quais ações o agente pode tomar sozinho, quais vão para uma pessoa e quem responde pelo resultado. Quem é responsável quando o agente de IA comete um erro aprofunda essa decisão.

Passos de contenção:

• Limite as novas tentativas e o total de ações por tarefa.
• Exija uma verificação de duplicidade em qualquer ação que crie um registro ou envie uma mensagem.
• Nomeie um dono por agente e um substituto que também possa pausá-lo.
• Escreva quais decisões o agente pode tomar sozinho e quais vão para uma pessoa.

Na operação gerenciada, a resposta a incidentes inclui pausar o agente, desfazer as ações registradas sempre que possível e escrever uma revisão depois. A Be Human opera os controles que a empresa aceitou. A decisão sobre quanto risco a empresa aceita continua com a empresa.

Conter cada falha antes que o primeiro agente entre em operação

Essas falhas seguem um padrão: cada uma fica invisível por padrão e é fácil de prevenir quando é nomeada. Antes de qualquer agente tocar em dados reais, escreva a lista de falhas daquele papel específico e atribua um controle e um responsável a cada item. Uma lista curta, com responsáveis, é usada. Um documento genérico de segurança em IA muitas vezes não é.

• Memória desatualizada: marcas de fonte, regras de revisão e descarte de anotações quando as fontes mudam.
• Permissões excessivas: inventário de ações, níveis de aprovação e revisão programada.
• Desvio silencioso: conjunto fixo de testes, registro de mudanças e amostragem semanal contra um padrão escrito.
• Instruções injetadas: rótulos nas entradas, lista de destinos permitidos e aprovação para ações disparadas de fora.
• Ações descontroladas e responsabilidade pouco clara: limites de tentativas, verificação de duplicidade, dono nomeado e direito de pausa.

Trate o primeiro papel como um teste dos controles, e não apenas do modelo. Se os controles forem fáceis de explicar para a pessoa que vai supervisionar o agente, provavelmente estão funcionando. Se o dono não consegue dizer o que o agente pode fazer sozinho, o papel ainda não está pronto. Revise a lista após cada mudança relevante e mantenha o registro de mudanças como prova do que foi decidido e por quê.

Se você não tem certeza de qual tarefa deve ser entregue primeiro a um agente, o diagnóstico gratuito de IA da Be Human pode ajudar a encontrar a primeira tarefa que vale a pena delegar.

Perguntas frequentes

A superinteligência é um risco realista para uma empresa hoje? Os riscos que vale a pena gerenciar agora são as falhas dos sistemas que você já usa ou planeja usar, como memória desatualizada, permissões excessivas, desvio silencioso e instruções injetadas. São problemas operacionais comuns, que aparecem em escala e velocidade maiores. Planejar para eles, com responsáveis, registros e revisões, também prepara a empresa para sistemas mais capazes no futuro.

Quais permissões um agente de IA deve ter no lançamento? O agente deve ter apenas o acesso que o papel precisa para cumprir seu critério de sucesso, e nada que seja apenas conveniente para testes. Separe leitura, rascunho e execução, e exija que uma pessoa aprove qualquer execução acima de um limite definido. Revise a lista em uma data fixa e depois de cada mudança, porque as permissões tendem a crescer com o tempo.

Com que frequência as respostas de um agente devem ser verificadas? Verifique com frequência suficiente para que uma queda de qualidade seja percebida antes de causar dano. Muitos papéis se beneficiam de uma amostra semanal avaliada contra um padrão escrito, mais a reexecução de um conjunto fixo de testes após cada mudança de modelo, instrução, ferramenta ou dado. Papéis de maior risco podem exigir verificações mais frequentes ou a revisão de cada resposta antes de sair da empresa.

Quem deve ser o dono dos controles contra falhas de agentes de IA? Cada agente precisa de um dono nomeado, que consiga pausá-lo, desfazer as ações registradas e responder pelos resultados, além de um substituto que possa agir na ausência do dono. O dono não precisa ser um engenheiro, mas precisa entender o que o agente tem permissão para fazer. A operação gerenciada pode executar o monitoramento, as revisões e a resposta a incidentes, enquanto a empresa mantém as decisões sobre risco.

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