O problema da desativação: o que a responsabilização de agentes de IA exige quando o sistema é desligado

Quando um sistema de agente de IA é desligado, a suposição mais natural é que as suas obrigações terminam com a operação. O agente deixa de agir; a auditoria é arquivada; a equipa que o construiu segue em frente. Mas responsabilização não depende de o sistema estar a correr. Depende de as consequências das suas ações passadas continuarem no mundo, e essas consequências não desaparecem quando o agente desaparece.

Este é o problema da desativação. Não é um problema técnico em sentido estreito; é um problema de governação que surge quando alguém pergunta o que acontece às obrigações de responsabilização acumuladas enquanto o sistema estava vivo. Em muitas implementações atuais, essas obrigações dissolvem-se. O sistema desapareceu. Os registos podem ou não estar acessíveis. As pessoas que o compreendiam podem ter-se dispersado.

O que a desativação destrói

Três categorias de infraestrutura de responsabilização ficam em risco quando um sistema de agente é desligado. A primeira é evidenciária: logs de auditoria, registos de decisão e o contexto necessário para os interpretar. Arquivar logs é necessário mas insuficiente. Uma entrada que diz “ação tomada às 14:32:07” não é interpretável sem versão do modelo, contexto de input, permissões ativas e sistemas a jusante invocados.

A segunda é criptográfica. Se o agente usou chaves de assinatura para atestar decisões, essas chaves têm uma questão de custódia na desativação. Chaves destruídas no shutdown não podem verificar decisões históricas. Chaves retidas indefinidamente criam os seus próprios riscos. A desativação exige um plano deliberado de custódia de chaves.

A terceira é relacional. Um sistema de agente opera dentro de integrações: APIs chamadas, sistemas atualizados, fluxos humanos onde estava embutido. Essas relações não terminam quando o agente termina. Um sistema a jusante pode continuar a agir durante anos com base em saídas de um agente já desativado.

No cruzamento pós-quântico

A dimensão criptográfica é mais aguda no encontro com segurança pós-quântica. Um agente que assinou decisões com algoritmos agora considerados vulneráveis apresenta um problema retroativo de integridade: decisões passadas, mesmo corretamente registadas, podem deixar de ser verificáveis por qualquer parte futura. A trilha de auditoria existe, mas a capacidade de confiar nela expirou.

Isto cria uma obrigação específica na desativação: transitar chaves e registos para algoritmos pós-quânticos antes do shutdown, não depois. Se os registos históricos forem reassinados com novos algoritmos, o próprio evento de reassinatura deve ser atestado. A cadeia de evidência inclui a migração.

No cruzamento do hardware

Agentes executados em hardware dedicado — enclaves seguros, módulos de segurança de hardware, ambientes de execução confiáveis — deixam um resíduo específico. O hardware pode ser reaproveitado, revendido ou destruído. Cada caminho tem implicações diferentes para o que preserva e o que destrói.

Hardware reaproveitado carrega risco de persistência indesejada de dados. Chaves, logs parciais e artefactos de modelo que não foram limpos explicitamente podem sobreviver à transição. Destruir hardware elimina o risco de persistência, mas também elimina material criptográfico que futuras reclamações de responsabilização podem precisar.

Nenhum destes resultados é automaticamente correto. O caminho certo depende das obrigações acumuladas, da sua duração e de quem tem autoridade para decidir a custódia.

Em cuidados no mundo físico

Em cuidados físicos, o problema da desativação assume a forma mais consequente. Um agente que geriu monitorização, escalamento, horários ou medicação acumula obrigações em escalas biológicas, não em ciclos de vida de sistema. Um paciente cujos cuidados foram moldados por decisões do agente pode ter resultados que se desenrolam durante anos.

Obrigações de cuidados também são juridicamente estruturadas. Requisitos de retenção de registos médicos variam por jurisdição e podem durar anos ou décadas. Um agente que contribuiu para decisões médicas foi, funcionalmente, parte do registo médico. A sua desativação tem de ser coordenada com essas obrigações de retenção.

Se um agente de cuidados é substituído por um sucessor, o sucessor precisa de compreender não só o estado atual, mas a história de decisões que produziu esse estado. Um plano sem transferência estruturada introduz uma descontinuidade no registo de cuidados.

O que um plano de desativação exige

A desativação deve ser tratada como um evento de responsabilização de primeira ordem, não como limpeza. Antes do shutdown, uma auditoria de obrigações deve documentar que obrigações o sistema acumulou, quanto tempo duram e quem as herda.

A preservação de logs deve incluir contexto interpretativo. O objetivo não é guardar bytes; é preservar a capacidade de um investigador futuro reconstruir o que aconteceu. Isso requer versões de modelo, esquemas de contexto, estados de permissão e anomalias conhecidas.

A continuidade criptográfica exige decisão de custódia antes do shutdown. A notificação a jusante deve alcançar todos os sistemas e fluxos que receberam saídas do agente desativado. O problema da desativação lembra que sistemas agentivos não são limitados pelo tempo em que correm; estendem-se para a frente pelas consequências e para trás pelos registos.