O problema do agente offline: responsabilidade quando a rede falha

Quando um agente de IA age, a infraestrutura de responsabilidade assume que um servidor de registo está acessível. Em deployments de centros de dados e cloud, este pressuposto é válido. Em deployments do mundo físico — instalações de cuidados, locais industriais, hardware embebido em localizações remotas — a rede é intermitente, pouco fiável ou inexistente por design. O agente ainda tem de agir. Mas o que significa responsabilidade quando não há registo acessível?

Este é o problema do agente offline. Não é um caso extremo. Precisamente nos deployments onde os agentes de IA têm as consequências físicas mais imediatas — cuidados a idosos, monitorização clínica, gestão de infraestrutura — a fiabilidade da rede é frequentemente o elo mais fraco do sistema. O hiato de responsabilidade abre-se precisamente onde é mais consequente: nas decisões que não podem ser desfeitas.

Dois maus padrões predefinidos

A resposta ingénua à perda de rede é parar: se o agente não consegue registar as suas decisões, não deve tomar nenhuma. Esta é a política mais segura num centro de dados, onde o custo de parar é uma tarefa atrasada e o custo de uma ação não registada é um hiato de responsabilidade. O cálculo inverte-se numa instalação de cuidados. Um agente de monitorização responsável por detetar eventos médicos num residente que não consegue cuidar de si próprio não pode parar porque o servidor de registo está inacessível. Parar na perda de rede cria uma garantia de segurança na camada de responsabilidade que elimina a garantia de segurança na camada de cuidados. O agente que se recusa a agir porque não consegue registar trocou uma falha de responsabilidade por uma mais imediata.

O padrão predefinido oposto — continuar a agir, fazer buffer dos registos localmente, sincronizar quando a rede regressar — é operacionalmente sensato mas criptograficamente ingénuo. Um registo local é um ficheiro mutável num dispositivo a que um operador pode aceder. Nada num buffer local padrão impede que um ficheiro seja editado entre o momento em que o agente o escreve e o momento em que é carregado para o sistema central. Quando o agente se reconecta e transfere as suas decisões em buffer, não há evidência criptográfica de que o registo não foi modificado durante o período offline. O sistema central de responsabilidade não consegue distinguir um registo fiel do que o agente realmente fez de um registo que foi curado após o facto para remover decisões que o operador preferia não ter registadas.

Atestação offline com raiz em hardware

A resposta arquitetural é a atestação local no momento de cada decisão. Antes de o agente escrever uma entrada de registo, um módulo de segurança de hardware — um TPM, um enclave seguro ou silício equivalente — assina a entrada com uma chave que está vinculada ao hardware e não pode ser exportada do dispositivo. A assinatura compromete-se com o conteúdo da decisão, o seu timestamp, a identidade atual do modelo do agente e uma cadeia de hash que liga esta entrada a todas as entradas anteriores da sessão. Se qualquer entrada for eliminada, reordenada ou modificada após o facto, a cadeia de hash quebra. Como a chave de assinatura não pode sair do hardware, a assinatura não pode ser regenerada para cobrir a cadeia adulterada. A corrupção é detetável no momento da reconexão.

Quando a conectividade regressa, o agente carrega o seu registo assinado e encadeado para a infraestrutura central de responsabilidade. O sistema central valida a cadeia para a frente a partir da última entrada conhecida e boa no momento da desconexão. Qualquer lacuna na cadeia, qualquer assinatura inválida, qualquer timestamp que viole a ordenação esperada é evidência suficiente para sinalizar todo o período offline para revisão humana — não prova de intenção maliciosa, mas evidência de que o registo não pode ser aceite como limpo sem exame.

Esta não é uma ideia nova em engenharia de segurança geral. A atestação com raiz em hardware é a fundação do arranque seguro, dos ambientes de execução confiável e dos produtos de integridade de endpoint empresarial. O que é novo é aplicá-la especificamente aos registos de decisões de agentes de IA como um mecanismo de responsabilidade de primeira classe, com o propósito explícito de fazer a ponte durante o período em que o registo central está inacessível, em vez de tratar a operação offline como uma exceção à responsabilidade.

A dimensão pós-quântica

As chaves de assinatura num esquema de atestação offline devem sobreviver não apenas às ameaças atuais ao nível da rede, mas à transição quântica. Um agente de IA embebido em infraestrutura física hoje — numa instalação de cuidados, num sistema de gestão de edifícios, num dispositivo médico — pode operar durante dez a quinze anos sem substituição de hardware. Se as suas chaves de assinatura vinculadas ao hardware usarem um esquema de curva elíptica que será vulnerável a adversários com capacidade quântica dentro dessa janela operacional, o esquema de atestação offline fornece responsabilidade apenas até o ataque se tornar viável. Um adversário que consiga retroativamente quebrar as chaves de assinatura pode falsificar todo um histórico de registo offline, inserindo ou removendo decisões à vontade, e produzir uma cadeia de assinaturas que o sistema central aceitará como intacta.

A implicação é que os módulos de segurança de hardware provisionados para agentes de IA do mundo físico hoje devem usar esquemas de assinatura pós-quânticos, mesmo ao custo de tamanhos de assinatura maiores e uma sobrecarga de verificação modestamente mais elevada. A janela para fazer esta escolha corretamente é no momento do fabrico. Retrofitar primitivas criptográficas em hardware implementado é tecnicamente difícil e na maioria das categorias de dispositivos embebidos requer acesso físico a cada unidade — uma operação que é impraticável à escala em toda uma infraestrutura de cuidados distribuída.

O momento da reconexão

O período offline termina quando a rede regressa. O evento de reconexão não é apenas uma sincronização de dados — é a primeira auditoria de responsabilidade do período durante o qual o sistema central não tinha visibilidade. O tratamento correto é lidar com a reconexão como uma revisão de atestação: validar a cadeia de hash completa das decisões offline a partir do ponto de desconexão, verificar que a identidade do modelo do agente registada na desconexão corresponde à identidade na reconexão (confirmando que não ocorreu nenhuma atualização silenciosa enquanto o agente estava offline e não monitorizado), e confirmar que a atestação do módulo de hardware do seu próprio ambiente de execução permanece consistente ao longo do hiato.

Se alguma destas verificações falhar, a resposta correta não é descartar os outputs do período offline ou reverter as ações do agente. As decisões do mundo físico do agente durante esse período já estão concluídas e são tipicamente irreversíveis — um alerta de cuidados foi levantado ou suprimido, uma porta foi trancada ou destrancada, uma administração de medicação foi sinalizada ou limpa. A revisão de responsabilidade não pode desfazer essas ações. O seu propósito é sinalizar o período offline para revisão humana, anexar uma advertência de atestação a cada output produzido durante essa janela e apresentar a anomalia a quem é responsável pela operação do agente.

Em deployments de cuidados no mundo físico, isto importa de forma aguda. Um agente que esteve offline durante seis horas durante uma situação invulgar deve ter as suas decisões dessa janela revistas por um clínico antes de essas decisões serem tratadas como inputs autoritativos para planos de cuidados subsequentes. A aceitação automática de uma sincronização reconectada — porque o carregamento foi bem-sucedido sem erros — não é responsabilidade. É a aparência de responsabilidade sem a substância.

Conceber para offline desde o início

O problema do agente offline não cede a ferramentas posteriores ao facto. A atestação local de hardware, a seleção de chaves de assinatura pós-quânticas e os protocolos de auditoria de reconexão devem ser concebidos na arquitetura do agente antes do deployment. Requerem capacidades de hardware específicas que devem estar presentes no momento do fabrico, compromissos de formato de registo que devem ser consistentes ao longo de toda a vida operacional do agente, e fluxos de trabalho de auditoria que devem ser integrados na infraestrutura central de responsabilidade antes do primeiro deployment. Um agente de IA enviado para um ambiente do mundo físico sem estes mecanismos é um agente cujo registo de responsabilidade durante os inevitáveis períodos offline não é verificável — não porque o agente tenha feito algo errado, mas porque a infraestrutura nunca foi concebida para saber de qualquer forma.

A responsabilidade não é uma propriedade do servidor de registo. É uma propriedade do registo de decisão desde o momento em que a decisão é tomada. Em deployments do mundo físico, isso significa que a arquitetura de responsabilidade deve funcionar quando a rede não funciona.