O problema do ciclo de vida de hardware: quando hardware de segurança sobrevive à sua garantia sob um agente em execução

As propriedades de segurança de uma implantação de agente de AI são muitas vezes descritas como se fossem características estáveis do software. O agente é descrito como atestado, resistente a adulteração ou autenticado criptograficamente, no presente e por duração indefinida. Estas declarações estão fundadas em hardware: um trusted platform module, um secure enclave, um hardware security module que fornece o root-of-trust para cada atestação feita pelo agente. Mas hardware tem ciclo de vida. Patches de segurança deixam de chegar. Certificações de firmware expiram. Algoritmos implementados em silício tornam-se obsoletos. O root-of-trust que tornou possível a arquitetura de responsabilidade continua a correr, mas já não é confiável da mesma forma, e normalmente não há sinal no registo de responsabilidade indicando que algo mudou.

O desalinhamento de escalas temporais é estrutural. Implantações de agentes de AI em residências de cuidado, redes hospitalares e ambientes de controlo industrial são desenhadas e orçamentadas para vidas operacionais de dez a quinze anos. Os componentes de segurança de hardware embutidos nesses ambientes, trusted platform modules, secure enclaves, hardware security modules, carregam compromissos de suporte do fabricante de cinco a sete anos. Depois dessa janela, o hardware continua a funcionar. Continua a produzir atestações. Continua a assinar. Mas o fornecedor já não o audita por vulnerabilidades, não corrige o seu firmware e não certifica as suas implementações criptográficas contra padrões atuais. A atestação que o agente produz é indistinguível de uma válida para qualquer observador que verifica apenas o formato da assinatura e não a proveniência do hardware que assina.

O que end-of-life significa para responsabilidade

No modelo padrão de segurança de hardware, o valor de um hardware root-of-trust deriva de duas propriedades: assume-se que o hardware é resistente a adulteração, e assume-se que a sua postura de segurança é mantida. End-of-life quebra a segunda suposição enquanto deixa a primeira aparentemente intacta. O hardware não anuncia que já não recebe patches. As atestações que produz não carregam um timestamp de expiração. O trilho de auditoria gerado por um agente que corre em hardware de segurança end-of-life parece idêntico a um trilho gerado por um agente que corre em hardware atual e totalmente suportado.

Isto cria um problema específico de responsabilidade. Quando uma decisão feita por um agente de AI é revista, numa auditoria regulatória, numa investigação de evento adverso ou numa análise pós-incidente, o revisor avalia a integridade da decisão verificando se as declarações do agente foram devidamente atestadas. A atestação era válida. O hardware root-of-trust existia. A arquitetura de responsabilidade parece sustentar-se. O que não aparece no registo de auditoria é que o hardware que fornecia esse root-of-trust não recebia atualização de firmware há quatro anos, que dois CVEs afetando a sua implementação de atestação tinham sido publicados sem patch, e que o algoritmo criptográfico usado para assinar atestações fora depreciado dezoito meses antes. A responsabilidade estava formalmente completa e substantivamente vazia.

No cruzamento do hardware

O cruzamento do hardware é onde agentes de AI interagem com infraestrutura física cujas propriedades de segurança estão fundadas em silício. Neste cruzamento, o problema do ciclo de vida de hardware é mais direto: as declarações de responsabilidade do agente são tão atuais quanto o hardware que as ancora. Um agente de hardware que gere uma frota de dispositivos ao longo de uma implantação de dez anos sobreviverá às garantias de segurança do hardware em que corre. À medida que isso acontece, os registos de atestação que produz tornam-se progressivamente menos confiáveis sem qualquer mudança visível na sua estrutura ou conteúdo. Uma frota cujos componentes de segurança de hardware entraram em end-of-life no sexto ano parece idêntica no registo de auditoria a uma frota cujos componentes estão totalmente atuais, a menos que um operador acompanhe o ciclo de vida de hardware separadamente e o correlacione com o registo de responsabilidade, o que quase ninguém faz.

O problema compõe-se para agentes que gerem outro hardware. Um agente de hardware que atesta a integridade de dispositivos numa frota está implicitamente a afirmar que a sua própria integridade é comprovável. Se o hardware root-of-trust do agente gestor estiver ele próprio fora da janela de suporte, cada declaração de integridade que o agente faz sobre dispositivos a jusante herda essa garantia vazia. A cadeia de responsabilidade não falha visivelmente. Falha em silêncio, na camada onde declarações encontram a física, de uma forma que só se torna aparente quando alguém faz uma pergunta que o registo formal não consegue realmente responder.

No cruzamento da segurança pós-quântica

A migração pós-quântica acrescenta uma dimensão crítica de tempo ao problema do ciclo de vida de hardware. A transição para algoritmos criptográficos resistentes a quantum não é apenas uma migração de software. Muitos dos algoritmos que precisam ser substituídos, RSA e variantes de curva elíptica, são implementados nos aceleradores criptográficos dedicados dentro de hardware security modules e trusted platform modules. Substituir esses algoritmos exige atualizações de firmware, disponíveis apenas enquanto o hardware está em suporte ativo, ou substituição de hardware. Uma implantação de agente de AI cujo hardware de segurança subjacente atingiu end-of-life não receberá o firmware que implementa algoritmos resistentes a quantum. Continuará a assinar com algoritmos cuja integridade de longo prazo não pode ser presumida. Os registos de responsabilidade que produz agora terão de ser interpretados no futuro contra a pergunta de se o algoritmo de assinatura já era conhecido como inadequado, e o registo formal não conterá esse contexto.

O problema harvest-now-decrypt-later que impulsiona a urgência da migração pós-quântica aplica-se simetricamente aos registos de responsabilidade. Atestações assinadas hoje com algoritmos depreciados tornam-se retroativamente questionáveis quando esses algoritmos são quebrados. Para um agente de AI que toma decisões em domínios de alto risco, a integridade do registo de responsabilidade não importa apenas no momento da decisão. Tem de resistir a revisão retrospetiva anos ou décadas depois. Uma decisão tomada em 2026 em nome de um paciente numa instituição de cuidado pode ser revista num procedimento regulatório em 2033. Se o hardware que atestou a integridade dessa decisão está em end-of-life desde 2028, a atestação formal torna-se um artefacto contestado em vez de uma âncora confiável.

No cruzamento do cuidado no mundo físico

Implantações de cuidado no mundo físico enfrentam o problema do ciclo de vida de hardware em dois eixos: a sua duração operacional e o seu contexto de compra. Instituições de cuidado não são empresas de tecnologia. Não têm ciclos de renovação de hardware sincronizados com janelas de suporte de segurança. Uma frota de tablets implantada numa residência de cuidado em 2024 poderá plausivelmente ainda estar a correr em 2032, muito depois de os componentes de segurança de hardware embutidos nesses tablets terem passado a janela de suporte. Os agentes de AI que correm nessa infraestrutura, gerindo horários de medicação, monitorizando sinais vitais e encaminhando tarefas de cuidadores, continuarão a produzir registos de responsabilidade formalmente válidos mas fundados em hardware cuja postura de segurança já não é certificada.

O contexto de compra amplifica isto. A renovação de hardware em ambientes de cuidado é limitada por ciclos orçamentais, aprovação regulatória de software de dispositivo médico e a interrupção operacional de migrar um sistema de cuidado em funcionamento. Substituir o hardware subjacente de um agente de cuidado implantado não é uma decisão que uma instituição de cuidado toma no calendário de um fornecedor de segurança. Em muitas jurisdições exige validação clínica, treino de equipa e nova aprovação regulatória. O resultado é que o ciclo de vida real de hardware em sistemas de cuidado implantados se estende muito além das janelas de suporte do fabricante por necessidade estrutural, e a arquitetura de responsabilidade construída em cima desse hardware degrada-se em conformidade.

O que responsabilidade consciente de ciclo de vida exige

Três adições à arquitetura padrão de responsabilidade tornariam visível o problema do ciclo de vida de hardware. Primeiro, registos de proveniência de hardware: a arquitetura de responsabilidade de uma implantação de agente de AI deve incluir registos explícitos dos componentes de hardware que fornecem o root-of-trust, marca, modelo, versão de firmware, estado de suporte do fabricante e data de fim de suporte, como objetos de auditoria de primeira classe. Esses registos devem ser atualizados sempre que o estado do hardware muda e correlacionados com os registos de responsabilidade que o hardware ancora. Segundo, alertas de fim de suporte: o sistema de responsabilidade deve assinalar, no próprio registo de auditoria, quando um componente root-of-trust entra em end-of-life. Atestações produzidas após essa data devem carregar metadados indicando que o hardware por trás delas está fora da janela de suporte. Isto não invalida essas atestações, mas fornece o contexto de que um revisor futuro precisa. Terceiro, acompanhamento de depreciação de algoritmos: quando o hardware implementa algoritmos criptográficos específicos, o sistema de responsabilidade deve acompanhar o estado de depreciação desses algoritmos e assinalar atestações produzidas usando implementações depreciadas.

O problema do ciclo de vida de hardware não é falha de qualquer componente individual. O hardware funciona. As atestações são formalmente válidas. O registo de responsabilidade é preciso até onde vai. O problema é uma lacuna estrutural entre as suposições temporais embutidas na arquitetura de responsabilidade e o ciclo de vida real dos componentes físicos que a suportam. Fechar essa lacuna exige tratar o ciclo de vida de hardware como uma dimensão de responsabilidade, não apenas operacional, e exige fazê-lo antes que o desalinhamento se torne visível apenas em retrospetiva.