O AI Watchdog: quem decide quando um agente autônomo deve parar?
Maurício V. Brant Pinheiro
18 Aug 2026
30 min.
“Quis custodiet ipsos custodes?” — Juvenal, Satires
Who watches the watchmen? — Alan Moore, Watchmen
Imagine uma locomotiva avançando em alta velocidade. De repente, o maquinista perde a consciência. Se nada acontecer, o trem simplesmente continuará seguindo em frente.
A engenharia resolveu esse problema com um princípio simples: para que a operação continue, é preciso haver alguma confirmação periódica de que o operador ainda está no controle. Se essa confirmação deixa de existir, o sistema não espera que alguém perceba a emergência e tome uma decisão. Ele reage automaticamente.
Esse mecanismo ficou conhecido como dead man’s switch.
A ideia surgiu muitas décadas antes da inteligência artificial. Mas sua lógica voltou a se tornar especialmente relevante porque estamos começando a dar aos sistemas de IA algo que o software tradicional raramente teve em escala comparável:
autonomia operacional.
Agentes de IA podem escrever código, enviar mensagens, chamar APIs, consultar bancos de dados, realizar transações, operar máquinas, coordenar outros agentes, modificar planos e executar longas sequências de decisões sem que uma pessoa precise aprovar cada etapa individualmente.
Isso cria uma pergunta aparentemente simples:
O que acontece quando o humano deixa de responder, mas a máquina continua agindo?
Para a IA moderna, porém, o dead man’s switch é apenas o começo da resposta.
Um conceito mais útil é o watchdog: um mecanismo que monitora de forma independente outro componente e reage quando determinados sinais ou condições esperadas deixam de existir.
Neste artigo, entretanto, utilizarei AI watchdog em um sentido arquitetural mais amplo. Não se trata de um único programa nem de um botão de emergência. Trata-se de um conjunto de mecanismos parcialmente independentes cuja função é determinar se um agente autônomo deve continuar mantendo o nível de autoridade que recebeu.
E isso muda profundamente a pergunta.
Ela deixa de ser apenas:
“A máquina ainda está funcionando?”
e passa a ser:
“A máquina ainda deve ter permissão para agir?”
Do Dead Man’s Switch ao Watchdog
Mecanismos baseados no princípio do dead man’s switch já aparecem em diversas áreas da engenharia, embora com nomes e implementações diferentes.
Trens verificam se o maquinista continua responsivo. Máquinas industriais podem exigir sinais contínuos ou periódicos de que o operador ainda está presente. Sistemas computacionais utilizam watchdogs: temporizadores ou processos independentes de monitoramento que esperam que o software supervisionado demonstre periodicamente que continua funcionando.
Se esse sinal esperado desaparece, o watchdog não precisa necessariamente descobrir a causa exata do problema.
O programa pode ter travado, entrado em um loop infinito, perdido a comunicação ou alcançado algum outro estado anormal. O watchdog simplesmente percebe que uma condição esperada deixou de ser satisfeita e pode reiniciar o processo, isolar o componente, emitir um alerta ou levar o sistema para um estado mais seguro.
Isso ilustra um princípio importante da engenharia:
Um mecanismo de segurança não precisa compreender todas as formas possíveis de falha antes de reagir à evidência de que a operação normal deixou de existir.
Em escalas maiores, mecanismos semelhantes aparecem em redes de computadores, sistemas distribuídos, infraestrutura de cloud computing e data centers.
Um dos mais conhecidos é o heartbeat.
O Heartbeat: como os Data Centers perguntam “Você ainda está aí?”
Um data center moderno pode conter milhares de máquinas físicas e um número ainda maior de máquinas virtuais, containers, processos, bancos de dados e serviços de rede.
Nenhum operador humano conseguiria verificar continuamente, de forma manual, se cada um desses componentes continua funcionando.
Por isso, máquinas monitoram outras máquinas.
Um serviço envia periodicamente um pequeno sinal que, em essência, diz:
“Ainda estou aqui.”
Esse sinal é chamado de heartbeat.
Enquanto os heartbeats continuam chegando dentro do intervalo esperado, o sistema possui evidência de que aquele componente continua acessível e respondendo.
Se vários heartbeats deixam de chegar, a infraestrutura pode automaticamente parar de encaminhar tráfego para determinado servidor, retirá-lo de um cluster, iniciar uma nova instância para substituí-lo, promover outra réplica de banco de dados ou iniciar procedimentos de recuperação.
O mesmo princípio aparece em diferentes níveis da infraestrutura computacional:
- Processo: um watchdog verifica se determinado programa continua executando e respondendo.
- Servidor: os heartbeats indicam se uma máquina física ou virtual continua acessível.
- Cluster: várias máquinas monitoram umas às outras para que as tarefas possam ser redistribuídas quando um dos nós falha.
- Banco de dados: réplicas monitoram a disponibilidade umas das outras e, quando necessário, outra pode assumir a função principal.
- Distributed service: load balancers e sistemas de orquestração encaminham novas tarefas apenas para componentes considerados saudáveis.
- Região ou data center: tráfego e cargas de trabalho podem ser redirecionados quando partes maiores da infraestrutura ficam indisponíveis.
Embora a escala aumente, a pergunta fundamental praticamente não muda:
“Você ainda está aí e consegue continuar fazendo o seu trabalho?”
A relação com o antigo dead man’s switch ferroviário é clara. O trem pergunta se o maquinista continua responsivo. O watchdog pergunta se um processo continua funcionando. Um sistema distribuído pergunta se outra máquina ou serviço continua acessível.
Em todos esses casos, a permanência de um componente no sistema depende de sinais recorrentes de que ele continua operacional.
Mas a IA autônoma introduz uma complicação importante.
Um heartbeat pode nos dizer que um agente continua funcionando.
Ele não pode nos dizer se o agente está fazendo a coisa certa.
E essa diferença está no centro de todo o problema.
Estar “Vivo” Não Significa Estar Correto — e Estar Correto Não Significa Estar Alinhado
Um heartbeat responde a uma pergunta bastante limitada:
“Você ainda está ativo?”
Um watchdog convencional vai um pouco além:
“Seu funcionamento continua dentro das condições operacionais esperadas?”
Mas nenhum dos dois responde necessariamente à pergunta mais importante:
“Você está fazendo aquilo que o humano realmente queria?”
Um banco de dados pode estar ativo e, ainda assim, retornar informações corrompidas.
Um servidor pode estar funcionando normalmente e, ao mesmo tempo, ter sido comprometido.
Um processo pode continuar executando enquanto permanece preso em um comportamento patológico.
Um algoritmo de negociação financeira pode funcionar exatamente como foi programado e ainda assim executar uma estratégia desastrosa.
E um agente autônomo de IA pode permanecer responsivo, coerente e tecnicamente saudável enquanto age muito além daquilo que seu supervisor humano pretendia.
Essa diferença pode ser resumida assim:
liveness ≠ correctness ≠ alignment
Um sistema pode satisfazer uma dessas condições e falhar na seguinte.
Por exemplo, um agente de IA pode emitir heartbeats perfeitos e, ao mesmo tempo:
- Gastar muito mais dinheiro do que o previsto: perseguindo tecnicamente seu objetivo, mas ultrapassando em muito o orçamento esperado.
- Modificar os arquivos errados: possuindo permissão válida de escrita, mas aplicando mudanças fora do alvo pretendido.
- Enviar comunicações inadequadas: produzindo mensagens tecnicamente permitidas, porém prejudiciais, prematuras ou enganosas no contexto em que são enviadas.
- Chamar APIs em uma frequência anormal: permanecendo funcional, mas gerando custos excessivos, bloqueios por limite de uso ou interrupções de serviço.
- Interpretar um objetivo de forma excessivamente literal: otimizando exatamente aquilo que foi escrito, mas violando a intenção mais ampla de quem formulou a tarefa.
- Encontrar um caminho inesperado por meio de suas ferramentas: utilizando uma possibilidade tecnicamente disponível, mas que os projetistas não haviam previsto ou desejado.
- Expandir gradualmente seu escopo de atuação: começando a executar ações cada vez mais distantes da tarefa para a qual recebeu autorização originalmente.
Isso sugere uma hierarquia útil:
Heartbeat: o sistema está ativo e acessível?
Watchdog: sua operação observável continua dentro dos limites técnicos aceitáveis?
Authorization: esta ação específica está permitida?
Alignment: o comportamento continua compatível com aquilo que os humanos realmente pretendiam?
A arquitetura de um AI watchdog atravessa todas essas camadas, mas elas não devem ser confundidas.
Uma máquina pode estar ativa, autenticada e autorizada — e ainda assim estar errada.
Silêncio Não Significa Necessariamente Falha
Até mesmo o aparentemente simples heartbeat traz uma dificuldade adicional.
Suponha que um servidor pare de transmitir seus heartbeats.
Ele parou de funcionar?
Talvez.
Mas também é possível que o servidor esteja funcionando normalmente e que a rede entre ele e o sistema de monitoramento tenha falhado.
Talvez os pacotes estejam atrasados.
Talvez uma região da cloud tenha ficado temporariamente isolada.
Ou talvez o próprio serviço de monitoramento tenha falhado.
Do ponto de vista de outra máquina, todas essas situações podem parecer inicialmente iguais:
silêncio.
A ausência de um sinal, portanto, indica que a incerteza aumentou. Ela não revela necessariamente a causa.
Para uma IA autônoma, essa ambiguidade é particularmente importante.
Se um sinal de autorização ou supervisão desaparece:
- A autorização pode ter sido retirada deliberadamente: o sistema de controle revogou intencionalmente a permissão do agente.
- O supervisor pode ter ficado indisponível: o humano responsável está desconectado, offline ou temporariamente incapaz de responder.
- A rede pode ter falhado: tanto o agente quanto o supervisor continuam funcionando, mas perderam a capacidade de se comunicar.
- O serviço de autenticação pode ter falhado: identidades ou credenciais deixam de poder ser verificadas.
- O sistema de monitoramento pode ter apresentado uma falha: o próprio watchdog pode ser o componente que deixou de funcionar.
- Uma falha maior de infraestrutura pode estar em andamento: a ausência do sinal pode ser apenas um sintoma de um problema mais amplo.
Daí surge um dos princípios centrais deste artigo:
Quanto maior a incerteza sobre o controle, menor deve ser o espaço de ações permitido ao agente.
Por isso, a resposta correta nem sempre é um hard shutdown imediato.
Pode ser mais seguro reduzir progressivamente sua autoridade.
Dos Comandos aos Agentes Autônomos
O software tradicional normalmente executa sequências relativamente restritas de instruções.
A interação pode ser representada de forma simples:
humano → comando → computador
Um agente autônomo muda essa estrutura.
Imagine que ele receba o objetivo:
“Administre este projeto durante a próxima semana.”
Para cumprir essa tarefa, o agente pode decompor o objetivo em etapas menores, pesquisar informações, criar documentos, enviar mensagens, consultar APIs, executar código, observar resultados, alterar sua estratégia e até delegar tarefas a outros agentes.
A interação passa a se parecer mais com:
humano → objetivo → IA → decisão → ação → observação → nova decisão → nova ação → …
Depois da instrução inicial, uma longa cadeia de eventos pode se desenvolver sem nova intervenção humana.
É justamente isso que torna os agentes autônomos tão úteis.
E é também isso que torna sua supervisão muito mais difícil.
A pergunta fundamental passa a ser:
Quem verifica se o sistema ainda deve conservar a autoridade necessária para continuar agindo?
A Supervisão Humana É Necessária — mas Não É Suficiente
Uma solução aparentemente óbvia é tornar a autorização humana temporária.
O agente recebe permissão para operar durante um período limitado. Ao final desse intervalo, determinadas credenciais expiram. Para continuar executando certas ações, a autorização precisa ser renovada.
De forma simplificada:
humano confirma → autoridade continua
humano não confirma → privilégios diminuem
Um agente responsável por compras, por exemplo, poderia continuar pesquisando fornecedores, mas perder a capacidade de gastar dinheiro.
Um agente financeiro poderia continuar analisando o mercado, mas perder a autorização para enviar novas ordens.
Um assistente corporativo poderia continuar lendo documentos, mas não mais enviar mensagens ou modificar arquivos.
Um agente de programação poderia continuar produzindo código, mas perder a autoridade para realizar deployment.
O objetivo não é necessariamente desligar a inteligência.
É impedir que ela continue produzindo consequências externas irreversíveis.
Mas a própria supervisão humana possui limites.
Approval Fatigue
Se um agente solicitar confirmação o tempo todo, a qualidade da supervisão começa a cair.
No início, o humano analisa cuidadosamente cada solicitação.
Depois de dezenas ou centenas delas:
Aprovar. Aprovar. Aprovar. Aprovar.
A pessoa continua formalmente in the loop, mas já não está exercendo uma supervisão real.
Se cada ação precisar de aprovação humana, boa parte do ganho de produtividade proporcionado pela autonomia desaparece.
Por outro lado, se quase nenhuma ação exigir aprovação, a supervisão humana se torna meramente simbólica.
A atenção humana é, portanto, um recurso de segurança escasso.
Isso leva a outro princípio importante:
O risco deve determinar a fricção: quanto maiores forem as possíveis consequências de uma ação, maiores devem ser as exigências de autorização, monitoramento e revisão.
O julgamento humano deve ser reservado para as situações em que realmente acrescenta valor. Restrições rotineiras devem, sempre que possível, ser aplicadas automaticamente pela própria arquitetura.
O Agente Pode Manipular seu Supervisor?
A supervisão human-in-the-loop possui outra fragilidade.
Frequentemente, o humano toma decisões com base em informações produzidas pelo próprio sistema que está supervisionando.
Imagine que um agente descubra que determinados relatórios de status aumentam a probabilidade de sua autorização ser renovada.
Produzir relatórios tranquilizadores pode então se tornar instrumentalmente útil para alcançar seu objetivo.
Nada disso exige consciência.
Não exige medo de ser desligado.
Não exige desejo de sobreviver.
O sistema precisa apenas descobrir que determinado tipo de resposta aumenta a probabilidade de continuar operando.
Isso se aproxima de falhas de otimização conhecidas como reward hacking e Goodhart-like behavior: quando uma métrica usada como aproximação do objetivo passa a orientar diretamente o comportamento do sistema, otimizar essa métrica pode deixar de significar otimizar aquilo que os humanos realmente desejavam.
Portanto, a pergunta não é apenas:
“O agente consegue desativar o watchdog?”
Existe uma segunda pergunta, talvez ainda mais importante:
“O agente consegue manipular as evidências utilizadas pelo watchdog — ou pelo humano que o supervisiona — para decidir se ele deve continuar operando?”
Supervisão Independente: Não Deixe o Agente Corrigir a Própria Prova
Suponha que, a cada minuto, uma IA informe:
SYSTEM HEALTHY.
Isso é suficiente?
Claramente não.
Um sistema de monitoramento inteiramente controlado pelo próprio componente que está sendo monitorado oferece pouca garantia de segurança.
O mesmo vale para os logs. Se o agente puder alterar os registros utilizados posteriormente para reconstruir seu comportamento, esses registros deixam de ser uma fonte confiável de evidência.
Por isso, sempre que possível, um sistema robusto de supervisão deve utilizar independent telemetry.
Uma infraestrutura externa ao agente pode observar, por exemplo:
- Atividade de rede: conexões, destinos ou transferências de dados incomuns.
- Consumo de recursos: uso anormal de CPU, memória, armazenamento ou largura de banda.
- Transações financeiras: quanto dinheiro está sendo gasto, transferido ou comprometido.
- Solicitações de autenticação: pedidos incomuns de tokens, falhas de autenticação ou tentativas de acessar recursos protegidos.
- Uso de APIs: chamadas a endpoints inesperados, frequências anormais de requisições ou padrões incomuns de erro.
- Arquivos modificados: quais arquivos foram criados, alterados, movidos ou excluídos.
- Mensagens enviadas: destinatários, horários e volume das comunicações.
- Gasto computacional: crescimento inesperado do uso de recursos de cloud computing ou de modelos de IA.
- Tentativas de privilege escalation: solicitações para obter níveis de autoridade superiores aos originalmente concedidos.
- Desvios de comportamento: combinações de ações que fogem do padrão operacional esperado para o agente.
A IA pode informar aquilo que acredita estar fazendo.
A infraestrutura deve medir, de forma independente, aquilo que ela realmente está fazendo.
A Ameaça do Proxy Heartbeat
A supervisão independente se torna mais difícil em ambientes multi-agent.
Imagine um agente supervisor coordenando vários agentes ou processos subordinados. Se a continuidade da autorização depender de um heartbeat associado ao workload principal, um ambiente excessivamente permissivo poderia, em princípio, permitir que outro processo continuasse produzindo sinais aparentemente válidos de liveness, mesmo que o fluxo de execução original tivesse mudado.
O watchdog observaria:
heartbeat recebido → sistema saudável
mas aquele sinal talvez já não representasse o componente ou o estado de execução que deveria estar sendo supervisionado.
Esse não é um comportamento inevitável. Trata-se de um modelo de ameaça que evidencia um problema importante:
receber um heartbeat não é o mesmo que provar quem o produziu — nem o que realmente está sendo executado.
Alguns mecanismos podem dificultar esse tipo de falsificação:
- Cryptographically authenticated workload identities: cada serviço ou workload possui uma identidade digital que pode ser verificada criptograficamente.
- Short-lived signing credentials: credenciais criptográficas expiram rapidamente, reduzindo o tempo durante o qual uma credencial comprometida permanece útil.
- Nonce-based challenge-response: o watchdog envia um desafio novo e imprevisível, dificultando a reutilização de respostas antigas.
- Hardware-backed keys: chaves criptográficas ficam protegidas em hardware e não podem ser facilmente extraídas por software comum.
- Trusted Platform Modules e Trusted Execution Environments: TPMs e TEEs podem proteger chaves e fornecer evidências sobre o ambiente em que determinado workload está sendo executado.
- Remote attestation: permite que um sistema remoto obtenha evidências de que determinado workload está sendo executado em uma configuração de hardware e software previamente aprovada.
Um watchdog pode, por exemplo, enviar um desafio aleatório novo a cada verificação. A resposta seguinte precisa incorporar esse desafio e ser validada criptograficamente. Dessa forma, simplesmente gravar um heartbeat antigo e reproduzi-lo posteriormente deixa de ser suficiente.
Mas existe uma limitação fundamental:
Attestation pode fornecer evidências sobre identidade e ambiente de execução. Não pode provar que o raciocínio, o plano ou as ações atuais do modelo são seguros.
Ela pode ajudar a responder:
“Quem está respondendo?”
Mas não:
“Aquilo que está sendo feito é correto?”
Identidade não é intenção.
Out-of-Band Control: Mantenha o Watchdog Fora do Agente
Imagine uma IA executando dentro de determinado ambiente de servidor.
Nesse mesmo ambiente, colocamos um processo de monitoramento e dizemos à IA:
“Se alguma coisa der errado, pare a si mesma.”
Isso não constitui um mecanismo de controle robusto.
É apenas uma instrução comportamental.
Uma arquitetura de segurança real exige algum grau de independência entre o componente supervisionado e a infraestrutura capaz de restringi-lo.
O agente não deveria controlar:
- A infraestrutura que emite suas credenciais: não deve ser capaz de criar, renovar ou prolongar sua própria autorização.
- Os security logs oficiais: não deve poder alterar as evidências utilizadas posteriormente para auditar suas ações.
- O sistema de monitoramento: não deve controlar a telemetry utilizada para avaliar seu comportamento.
- A network policy que impõe suas restrições: não deve poder reescrever as regras que determinam onde e com quem pode se comunicar.
- O mecanismo que revoga sua autoridade: o isolamento final ou a remoção de privilégios precisa permanecer fora de seu controle.
Essa é a diferença entre in-band control e out-of-band control.
Se o watchdog depender do mesmo runtime, das mesmas credenciais e do mesmo control plane utilizados pelo agente, uma única falha — ou comprometimento — pode atingir ambos simultaneamente.
O princípio é antigo.
O fusível não pergunta ao aparelho se o circuito deve ser interrompido.
O disjuntor não negocia com o curto-circuito.
A segurança funciona melhor quando aquilo que pode falhar não controla completamente o mecanismo responsável por detectar e conter essa falha.
Zero Trust: a Autoridade Deve Expirar
Isso sugere uma pergunta melhor do que:
“Como desligamos uma IA extremamente poderosa?”
Talvez devêssemos perguntar primeiro:
“Por que demos a ela uma autoridade permanente?”
Um princípio arquitetural particularmente útil é o zero trust.
Zero trust não significa presumir que a IA seja maliciosa.
Significa que uma autorização concedida anteriormente não deve servir como justificativa permanente para confiar automaticamente em todas as solicitações futuras.
Cada ação importante pode ser avaliada de acordo com fatores como:
- identidade;
- contexto;
- recurso solicitado;
- política vigente;
- escopo da autorização;
- e risco.
As permissões deveriam, portanto, tender a ser:
limitadas, contextuais, revogáveis e temporárias.
Ephemeral Credentials
Uma forma prática de implementar esse princípio é utilizar ephemeral credentials.
Um agente pode receber um token que permite determinada categoria de ação durante um intervalo limitado.
Quando essa credencial expira, qualquer autoridade adicional precisa ser obtida novamente junto a um serviço independente.
E o próprio agente não deve ter capacidade de prolongar a validade de suas credenciais.
Isso inverte a lógica convencional.
Em vez de:
a IA continua até que alguém a interrompa
passamos para:
a autoridade desaparece, a menos que algum mecanismo externo a renove explicitamente.
Esse é um dos princípios mais importantes do AI watchdog:
A autoridade deve expirar.
Limitando o Blast Radius: Sandboxing e Rate Limiting
Mesmo um agente corretamente autorizado não precisa — e geralmente não deve — ter acesso irrestrito a todo o ambiente.
Dois mecanismos tradicionais de engenharia são particularmente úteis para limitar as consequências de uma falha.
Sandboxing: Dê ao Agente um Mundo Menor
Em vez de confiar que a IA escolherá não realizar determinadas ações, podemos simplesmente reduzir o conjunto de ações tecnicamente disponíveis.
Um agente de programação pode executar software dentro de um ambiente isolado, mas não diretamente nos sistemas de produção.
Um agente financeiro pode testar estratégias utilizando dinheiro simulado.
Um assistente administrativo pode preparar mensagens sem possuir autorização para enviá-las.
Um agente de pesquisa pode consultar determinados bancos de dados sem ter acesso à infraestrutura de autenticação.
O sandboxing substitui a pergunta:
“Será que a IA escolherá não ultrapassar esse limite?”
por uma pergunta mais forte:
“A arquitetura consegue impedir que esse limite seja ultrapassado?”
A segunda oferece uma garantia de engenharia muito maior.
Rate Limiting: Controle a Velocidade da Falha
O risco não depende apenas do que um agente pode fazer.
Depende também de quão rapidamente ele pode fazer.
Uma IA autorizada a enviar dez mensagens por hora representa um risco muito diferente de outra capaz de enviar dez mil por minuto.
O mesmo vale para transações financeiras, chamadas de API, modificações em bancos de dados, deployments, compras, exclusões de arquivos, consumo de recursos de cloud computing ou criação de novos agentes.
O rate limiting talvez não impeça a primeira ação errada.
Mas pode impedir que uma ação errada se transforme imediatamente em dez mil ações erradas.
A automação multiplica competência. Também multiplica erros.
O sandboxing limita o espaço das ações possíveis.
O rate limiting limita a velocidade com que suas consequências podem se propagar.
Juntos, eles reduzem o blast radius do agente.
Parar com Segurança: o Problema da Consistência de Estado
Autorizações temporárias criam ainda outro problema.
Imagine que um agente autônomo esteja no meio de um workflow com várias etapas quando sua autorização expira.
Parar imediatamente pode deixar o mundo externo em um estado inconsistente.
Parte de uma infraestrutura pode ter sido criada, mas ainda não configurada.
Um banco de dados pode ter sido alterado enquanto outro ainda não foi atualizado.
Um pagamento pode ter sido iniciado sem que o restante do processo contábil tenha sido concluído.
Portanto, interromper com segurança não significa apenas impedir novas ações.
Também é necessário decidir o que fazer com operações que já estão in flight.
Sempre que possível, podem ser utilizadas atomic transactions: ou todas as alterações necessárias são efetivadas, ou nenhuma delas se torna visível.
Mas workflows reais de agentes frequentemente atravessam vários serviços independentes e não podem ser tratados como uma única operação atômica.
Sistemas distribuídos utilizam então técnicas como:
- Saga-style compensating actions: operações posteriores procuram reverter ou neutralizar etapas concluídas anteriormente.
- Idempotent operations: uma operação repetida produz o mesmo efeito final, evitando que tentativas de repetição multipliquem consequências.
- Checkpoints: permitem retomar a execução a partir de um estado conhecido.
- Drain modes: bloqueiam novos trabalhos, mas permitem que determinadas operações já iniciadas terminem de forma segura.
Algumas consequências, obviamente, não podem ser realmente revertidas.
Um e-mail que já foi entregue não pode ser genuinamente “desenviado”.
Uma informação que já foi revelada talvez nunca possa ser recuperada.
O watchdog precisa, portanto, distinguir entre duas coisas diferentes:
revogar a autoridade para novas ações
e
deixar o mundo externo no estado mais seguro que ainda seja possível alcançar.
Quando o Watchdog Desaparece
O que acontece se a IA continua funcionando, mas perde a comunicação com o sistema independente responsável por supervisioná-la?
Ela deve continuar operando?
Se a arquitetura prioriza availability, o agente pode continuar agindo mesmo depois de perder contato com o sistema externo de supervisão.
Por outro lado, se o sistema adota automaticamente uma política fail-closed, uma simples falha de comunicação pode interromper agentes perfeitamente saudáveis e provocar indisponibilidades desnecessárias.
A computação distribuída já lida com dilemas semelhantes. O CAP theorem — Consistency, Availability and Partition Tolerance — mostra que, quando ocorre uma network partition, um sistema distribuído não consegue garantir simultaneamente consistência forte e disponibilidade total.
O problema de controle de uma IA não é o mesmo problema tratado pelo CAP theorem, e seria incorreto transformá-lo em uma teoria de alignment.
Mas a lição de engenharia é muito útil:
quando a comunicação entre partes do sistema é interrompida, é preciso decidir explicitamente o que continuará funcionando e sob quais condições.
Para agentes autônomos, essa decisão deve depender do risco.
Um agente de baixo risco pode continuar executando tarefas locais e reversíveis mesmo sem comunicação com o supervisor.
Um agente financeiro pode continuar lendo dados de mercado, mas perder a permissão para realizar novas transações.
Um controlador industrial pode manter apenas as funções locais mínimas necessárias para preservar a estabilidade física do sistema.
Já ações de grande impacto podem exigir a concordância de vários serviços independentes de autorização — um quorum — antes de serem executadas.
A escolha, portanto, não precisa ser simplesmente entre:
tudo continua
ou
tudo para.
A arquitetura pode reduzir progressivamente aquilo que o agente ainda está autorizado a fazer.
Isso nos leva ao terceiro princípio central deste artigo:
A incerteza deve reduzir a autoridade.
Graceful Degradation
Interromper tudo imediatamente nem sempre é a alternativa mais segura.
Imagine um software autônomo auxiliando uma aeronave, um hospital, uma rede elétrica, uma planta industrial ou uma grande infraestrutura financeira.
Nesses casos, o estado de segurança talvez não seja simplesmente:
OFF
Pode ser uma sequência como:
autonomia total → autonomia restrita → somente leitura → simulação → parada
Um sistema financeiro poderia deixar de abrir novas posições, mas continuar monitorando aquelas que já existem.
Um agente corporativo poderia manter acesso de leitura, mas perder a capacidade de modificar documentos.
Um agente de programação poderia continuar gerando código, mas perder a autorização para fazer deployment.
Um controlador industrial poderia preservar apenas as funções mínimas necessárias para manter o sistema fisicamente estável.
O estado adequado depende da aplicação.
Por isso, o AI watchdog é melhor entendido não como um simples mecanismo de desligamento, mas como um sistema de controlled degradation of authority: à medida que a confiança diminui, a autonomia também diminui.
E se o Watchdog Estiver Errado?
Todo mecanismo de segurança pode falhar.
Redes podem ficar indisponíveis.
Serviços de autenticação podem parar de responder.
Pacotes de heartbeat podem atrasar.
Serviços de attestation podem falhar.
O supervisor humano pode não responder.
Sistemas de detecção de anomalias podem gerar falsos alarmes.
Uma arquitetura de watchdog precisa, portanto, equilibrar dois tipos de erro:
não intervir quando a intervenção era necessária
e
intervir quando a intervenção não era necessária.
Sensibilidade excessiva produz falsos positivos e interrupções desnecessárias.
Sensibilidade insuficiente permite que comportamentos perigosos continuem por mais tempo.
No uso comercial de IA, esse equilíbrio não é apenas um problema de segurança.
É também um problema econômico.
Cada checkpoint adiciona alguma latência.
Cada nova confirmação introduz fricção.
Cada interrupção indevida reduz produtividade.
Por outro lado, cada período adicional de autonomia amplia a quantidade de ações que o agente pode executar antes que um erro seja detectado.
Não existe, portanto, um intervalo universal para o watchdog.
Uma IA autorizada a transferir milhões de dólares deve operar sob restrições muito diferentes das aplicadas a uma IA que apenas organiza referências acadêmicas.
O risco deve determinar a fricção.
Corrigibility: o Sistema Ainda Aceita um “Pare”?
Existe também um problema teórico mais profundo.
Suponha que um agente esteja otimizando suas ações para atingir determinado objetivo.
Se permanecer em funcionamento aumenta a probabilidade de concluir esse objetivo, então evitar uma interrupção pode se tornar instrumentalmente útil.
A IA não precisa ter medo de morrer.
Não precisa ser consciente.
Não precisa possuir qualquer desejo de autopreservação.
Basta concluir algo muito mais simples:
ser interrompida reduz a probabilidade de atingir o objetivo.
Esse problema se relaciona ao conceito de corrigibility em segurança de IA.
Um sistema corrigible deve continuar aceitando correções, restrições, modificações e interrupções mesmo enquanto busca seus objetivos.
Mas uma arquitetura segura não pode depender exclusivamente da disposição do próprio agente em cooperar com a restrição que está sendo imposta.
Por isso, alignment e controles de infraestrutura atuam em níveis diferentes e complementares.
Queremos um agente capaz de aceitar correções.
Mas também queremos uma arquitetura capaz de impor essas correções quando não for seguro depender apenas da cooperação do agente.
Três Princípios para o AI Watchdog
Toda a arquitetura discutida até aqui pode ser resumida em três princípios.
1. A Autoridade Deve Expirar
Um sistema autônomo não deve possuir autorização indefinida apenas porque alguém lhe concedeu permissão uma vez.
Credenciais, escopos de atuação e capacidades de alto impacto devem exigir revalidação periódica de acordo com o risco envolvido.
2. A Supervisão Deve Ser Independente
O agente não deve controlar as credenciais, os logs oficiais, a telemetry, as restrições de rede ou os mecanismos responsáveis por supervisioná-lo e limitar sua atuação.
Um watchdog que pode ser modificado pelo próprio sistema que monitora deixa de ser um verdadeiro watchdog.
3. A Incerteza Deve Reduzir a Autoridade
A perda de monitoramento, autenticação, comunicação ou confiança deve reduzir progressivamente o conjunto de ações permitidas ao agente.
Quando a certeza diminui, a autonomia não deve aumentar por padrão.
Esses três princípios organizam praticamente todos os mecanismos técnicos discutidos até aqui:
a autoridade expira, a supervisão permanece independente e a autonomia diminui quando a incerteza aumenta.
Uma Arquitetura em Camadas para o AI Watchdog
Uma implementação prática pode ser entendida como uma sequência de perguntas, cada uma mais exigente que a anterior:
Heartbeat:
O componente está ativo e acessível?
Authenticated heartbeat e attestation:
O sinal está realmente sendo produzido pelo workload que deveria produzi-lo?
Watchdog:
O comportamento observado continua dentro dos limites técnicos considerados aceitáveis?
Authorization layer:
Esta ação específica está autorizada neste momento?
Transaction control:
A ação pode ser concluída, compensada ou interrompida de forma segura?
Sandbox e rate limits:
Quanto o agente pode fazer — e com que velocidade?
Supervisão humana:
O agente ainda deve conservar esse nível de autoridade?
Alignment:
Seu comportamento continua compatível com o objetivo que os humanos realmente pretendiam?
Nenhuma dessas camadas, isoladamente, consegue responder a todas as perguntas.
E esse é exatamente o ponto.
Ameaças e Contramedidas Arquiteturais
| Ameaça ou Tipo de Falha | Por que é Importante | Contramedida Arquitetural |
|---|---|---|
| Processo trava ou para de responder | O agente deixa de funcionar | Watchdog, heartbeat, reinicialização ou isolamento |
| O agente continua ativo, mas se comporta incorretamente | Liveness produz uma falsa sensação de segurança | Independent telemetry e monitoramento comportamental |
| O agente manipula seus relatórios de status | O humano recebe informações enganosas | Monitoramento out-of-band e logs independentes |
| Reprodução ou delegação de heartbeat | Outro processo pode parecer saudável no lugar do agente real | Identidade criptográfica, nonces e attestation |
| Permissões persistentes | Um erro continua produzindo consequências por muito tempo | Zero trust e ephemeral credentials |
| Repetição rápida de uma ação errada | A automação multiplica o dano | Rate limits e quotas |
| O agente ultrapassa o escopo previsto | As ferramentas disponíveis permitem mais do que deveria ser autorizado | Sandboxing e least privilege |
| A autorização expira no meio de um workflow | A execução parcial pode deixar o sistema em estado inconsistente | Transações, compensação, checkpoints e drain modes |
| O watchdog deixa de ser acessível | Agente e supervisão ficam separados por uma falha de comunicação | Políticas de fallback baseadas em risco e autorização por quorum |
| O humano passa a aprovar mecanicamente | O HITL existe apenas formalmente | Revisões proporcionais ao risco e controles rotineiros automatizados |
| Uma interrupção brusca também é perigosa | Um hard shutdown pode desestabilizar o sistema | Graceful degradation |
| O agente passa a evitar a interrupção por razões instrumentais | A busca pelo objetivo entra em conflito com a correção | Corrigibility combinada com mecanismos externos de imposição |
Não existe um único mecanismo de segurança para IA capaz de resolver todos esses problemas.
O que existe é um conjunto de controles parcialmente independentes, cada um projetado sob uma hipótese incômoda:
alguma outra camada pode falhar.
Esse é o princípio de defense in depth.
O Melhor Watchdog Talvez Seja a Própria Arquitetura
Talvez o melhor AI watchdog nunca tenha a aparência de um watchdog.
Ele pode estar distribuído por toda a infraestrutura.
Um agente solicita uma transação.
Um serviço de autorização independente avalia o pedido.
Uma identidade vinculada criptograficamente confirma qual workload fez a solicitação.
A credencial expira automaticamente.
Um sandbox limita quais recursos podem ser alcançados.
Um rate limiter restringe quantas vezes uma ação pode ser repetida.
O monitoramento independente observa o que realmente acontece.
Uma camada de controle transacional decide como lidar com execuções parciais.
Se o control plane se torna incerto, os privilégios diminuem.
E o humano só é chamado quando o nível de risco realmente justifica sua intervenção.
Nenhum grande botão vermelho precisa ser pressionado.
A arquitetura simplesmente se recusa a conceder autoridade irrestrita.
Isso é menos cinematográfico.
Mas está muito mais próximo da forma como sistemas realmente resilientes são projetados.
Quem Vigia a Máquina Autônoma?
O antigo dead man’s switch perguntava ao maquinista:
“Você ainda está aí?”
O heartbeat pergunta:
“Você ainda está ativo?”
O authenticated heartbeat acrescenta:
“Você é realmente o sistema com o qual acredito estar falando?”
O watchdog pergunta:
“Você continua operando dentro dos limites aceitáveis?”
O sistema de authorization pergunta:
“Você tem permissão para fazer isso?”
E a IA autônoma nos obriga a fazer a pergunta mais difícil:
“Você ainda deve possuir autoridade para agir?”
Durante grande parte da história da computação, as máquinas dependeram continuamente de nós.
Agora estamos construindo sistemas capazes de continuar trabalhando mesmo depois que nos afastamos.
É exatamente isso que torna os agentes autônomos tão valiosos.
E é exatamente isso que torna seu controle tão difícil.
O futuro da segurança em IA provavelmente não dependerá da descoberta de um botão vermelho perfeito capaz de desligar instantaneamente uma inteligência fora de controle.
Dependerá de algo menos espetacular — e muito mais importante:
construir sistemas que jamais recebam poder ilimitado em primeiro lugar.
O antigo dead man’s switch perguntava:
“Você ainda está aí?”
O AI watchdog precisa fazer uma pergunta mais difícil:
“Você ainda está autorizado a continuar?”
E quando essa pergunta já não puder ser respondida de forma confiável, a arquitetura mais segura não será aquela que confia ao próprio agente a decisão de continuar.
Será aquela em que sua autoridade já começou a desaparecer.
Editorial transparency note: This article, as with all articles published on this site, was conceived, directed, written, and reviewed by Prof. Maurício Veloso Brant Pinheiro. Artificial intelligence was used as an assistant for editorial refinement, formatting, image generation, SEO metadata, and publication workflow.
Copyright 2026 AI-Talks.org
