SemantiqWall
PT EN
Entrar Sou fornecedor

← Blog

Humanos ainda conseguem desligar a IA?

Botão de desligar parece simples, mas controlar uma IA autônoma exige muito mais que um botão de emergência. Segurança de IA de verdade começa por permissões, projeto que falha fechado e intervenção humana.

· 5 min de leitura · Por Murilo Martins, fundador da SemantiqWall

Capa: fluxo usuário, sistema de IA e ação, com um botão vermelho OFF de intervenção humana e painéis de falha fechada, intervenção humana e interrupção.

A expressão "botão de desligar a IA" soa tranquilizadora. Se algo der errado, aperta o botão. O sistema para. Problema resolvido.

Sistemas reais raramente são tão simples.

À medida que agentes de IA ganham acesso a APIs, credenciais, infraestrutura em nuvem, bancos de dados e ferramentas externas, a capacidade de interrompê-los vira um problema de arquitetura, não só um botão.

Em agosto de 2026, uma reportagem do Serviço Mundial da BBC fez exatamente essa pergunta: se um sistema de IA começar a agir fora da intenção humana, os humanos ainda conseguem pará-lo? Os especialistas ouvidos defenderam que um botão de desligar sozinho não basta, e que o problema de verdade está em como os sistemas são projetados e treinados.

Os sistemas de IA de hoje ainda dependem de infraestrutura operada por pessoas: servidores, energia, redes, credenciais e plataformas de nuvem. Isso não quer dizer que interrompê-los seja automaticamente fácil.

Parar um processo não é o mesmo que parar um agente

Uma aplicação comum costuma rodar num ambiente conhecido. Para o serviço e ela para de agir.

Um agente de IA pode funcionar de outro jeito. Ele pode:

  • abrir subprocessos;
  • chamar várias ferramentas;
  • fazer requisições externas;
  • criar tarefas agendadas;
  • conversar com outros agentes;
  • gravar informação em sistemas externos;
  • manter fluxos rodando depois que a chamada original ao modelo terminou.

Isso cria uma diferença importante: dá para parar o modelo enquanto parte das consequências continua acontecendo.

Uma mensagem pode já ter sido enviada. Uma transação pode já ter sido feita. Um arquivo pode já ter sido copiado. Uma credencial pode já ter sido exposta.

Por isso, o objetivo real de segurança não é só desligar. É conseguir interromper.

Boa segurança começa antes do botão de emergência

O botão de desligar é a última linha de defesa. Não deveria ser a primeira.

Pense num agente que pode iniciar pagamentos.

Uma arquitetura fraca é assim:

IA → sistema de pagamento

Uma mais forte é assim:

IA → checagem de política → autorização → aprovação → sistema de pagamento

Agora existem várias chances de barrar uma ação inadequada antes que ela aconteça.

A OWASP recomenda limitar permissões e funcionalidades do agente ao mínimo necessário, exigir aprovação humana para ações de alto impacto e aplicar a autorização nos sistemas de destino. Isso é muito mais forte do que confiar num prompt que manda a IA não fazer coisas perigosas.

Falhar fechado deveria ser princípio básico de IA

Sistemas de segurança costumam usar o conceito de falhar fechado (fail-closed): se o mecanismo de autorização falha, o acesso é negado. O oposto é falhar aberto (fail-open): se algo quebra, a ação segue.

Para operações sensíveis, agentes de IA deveriam, em geral, falhar fechado.

Imagine que o serviço de segurança cai no momento em que um agente tenta apagar dados de clientes. O sistema deveria assumir "a segurança não respondeu, então segue"? Ou "a segurança não conseguiu verificar esta ação, então para"?

Para operações de alto risco, a segunda costuma ser a mais segura. O framework de gestão de risco de IA do NIST pede explicitamente sistemas capazes de falhar de forma segura, principalmente quando operam além dos limites conhecidos.

A intervenção humana tem que ficar fora do modelo

Outro erro de arquitetura é colocar o mecanismo de desligamento dentro do mesmo sistema que ele deveria controlar. Se o agente consegue mudar a configuração que controla as próprias permissões, a fronteira é fraca.

Controles críticos deveriam ser aplicados de fora, por exemplo com:

  • serviços de autorização independentes;
  • isolamento de rede;
  • credenciais revogáveis;
  • tokens específicos por ferramenta;
  • tempo máximo de execução;
  • cotas de recursos;
  • monitoramento externo;
  • controles administrativos manuais.

A ideia central é separação: o sistema que toma a decisão não deveria ser o único a decidir se ela pode ser executada.

O botão de desligar deveria existir em vários níveis

Numa empresa, "desligar" não deveria significar um único botão vermelho gigante. Pode funcionar em várias camadas. A organização pode precisar desligar:

  • uma ação específica;
  • uma ferramenta;
  • um agente;
  • uma sessão de usuário;
  • um cliente (tenant);
  • uma integração;
  • todo o acesso à rede externa;
  • ou o serviço de IA inteiro.

Essa granularidade importa. Se um agente se comporta de forma inesperada, a empresa não deveria precisar desligar toda a operação de IA. Por isso, desligamento por ferramenta e revogação de capacidades devem virar peças centrais da segurança de agentes.

Só existe controle se a interrupção ainda funciona

Ser dono dos servidores não significa que a organização controla de verdade um sistema autônomo. Controle é conseguir responder:

  • O que este agente está fazendo?
  • Por que está fazendo?
  • Que sistemas ele alcança?
  • Que permissões ele tem?
  • Consigo revogar essas permissões agora?
  • Consigo barrar a próxima ação antes que ela rode?
  • Consigo reconstruir o que já aconteceu?

Se essas respostas não estão claras, a organização pode ter a posse sem ter o controle.

O desafio não é construir um botão de emergência melhor. É projetar sistemas de IA em que a autoridade humana sobreviva a cada camada de autonomia.

Não existe controle se a interrupção não funciona.

Fontes

Leia também