O problema da autoridade de atualização: responsabilização quando agentes de IA são corrigidos

Software é atualizado continuamente. Patches de segurança corrigem vulnerabilidades, correções removem comportamento anómalo e lançamentos de funcionalidades mudam capacidades. Na maioria dos contextos, este ritmo é progresso claro: a nova versão é melhor, implantá-la é um ato técnico simples e não exige infraestrutura especial de responsabilização além de versão e changelog.

Agentes de IA não encaixam nesse modelo. Quando os parâmetros de um agente são atualizados, o seu comportamento muda, não como um patch legível que altera funções nomeadas, mas de formas distribuídas pelo modelo e impossíveis de auditar completamente lendo um diff. O agente antes da atualização e o agente depois dela são, em sentido relevante, agentes diferentes. Podem produzir outputs diferentes para o mesmo input, interpretar a mesma situação de modo diferente e discordar em decisões onde antes tinham autoridade implícita.

Este é o problema da autoridade de atualização: quem tem autoridade para mudar um agente de IA, sob que restrições, e que deveres de responsabilização existem perante quem estabeleceu confiança com uma versão que deixou de existir.

Porque o modelo de software é insuficiente

O enquadramento normal de atualização atribui autoridade a programadores, operadores e administradores. Assume que atualizar é melhorar, que utilizadores beneficiam e que a resposta apropriada é notificar e prosseguir. O consentimento é, no máximo, opt-out: se o utilizador não impedir, o sistema atualiza.

Quando um agente ocupa um papel consequente, esse modelo falha. Um sistema empresarial corrigido durante a noite pode comportar-se de modo diferente de manhã, mas essa diferença raramente afeta cuidados, postura de segurança ou segurança física de alguém. Agentes de IA em domínios onde as decisões têm efeitos reais não podem ser atualizados nos mesmos termos. A mudança não é superficial. O principal do agente, seja paciente, administrador de segurança ou operador de hardware, estabeleceu relação com o comportamento de uma versão específica. Alterá-lo sem autoridade e aviso explícitos não é atualização; é substituição não autorizada.

O cruzamento pós-quântico: identidade atestada após mudança de pesos

No cruzamento pós-quântico, um agente pode participar em operações criptográficas: gerar, verificar ou atestar chaves e assinaturas. O seu comportamento nessas operações faz parte do que sistemas a jusante confiam. Se os pesos mudam, mesmo por uma razão benigna como melhorar raciocínio num domínio adjacente, não há garantia de que o comportamento criptográfico permaneça igual. O agente atualizado pode atestar de forma diferente, aceitar inputs antes rejeitados ou rejeitar inputs antes aceites.

A lacuna é específica: a identidade criptográfica do agente pode não mudar, embora o comportamento tenha mudado. Um sistema a jusante que confia na atestação não tem forma de saber que a entidade que a produz é materialmente diferente da que foi originalmente avaliada. Numa transição pós-quântica, onde as premissas de confiança de toda a pilha criptográfica estão em revisão, um agente alterado silenciosamente é uma âncora de confiança alterada silenciosamente.

A autoridade de atualização aqui exige atestação explícita de continuidade comportamental: não apenas um número de versão, mas uma declaração documentada e verificável de que o comportamento em operações criptográficas foi testado e confirmado dentro dos limites antes aceites. Sem isso, a atualização invalida a confiança original.

O cruzamento do hardware: política de firmware e deriva silenciosa

No hardware, um agente pode governar ou interpretar outputs de dispositivos: decidir que estados de firmware são aceitáveis, que atestações são válidas e que leituras de sensores justificam alerta. Estas são decisões de política embutidas no comportamento do agente. Quando o agente é atualizado, essas políticas podem mudar sem anúncio explícito.

A dificuldade é que políticas de governação de hardware raramente são extraídas e listadas separadamente do comportamento geral. Emergiram do treino do modelo, não de um ficheiro de configuração. Um operador que certificou decisões de governação não consegue recertificar o agente atualizado sem reavaliação completa. Na prática, isso raramente acontece. A atualização é implantada; a política muda; a certificação deixa de refletir o que o agente faz.

A autoridade de atualização neste cruzamento exige tratar decisões de governação de hardware como uma superfície auditável separada. Uma atualização que muda políticas de hardware deve trazer documentação explícita do que mudou e porquê, e deve acionar recertificação antes de o agente atualizado governar hardware com implicações de segurança.

O cruzamento dos cuidados: confiança, consentimento e o agente conhecido

Nos cuidados do mundo físico, o problema tem consequências humanas imediatas. Uma pessoa que passou a depender de um agente, formou expectativas sobre o seu comportamento, calibrando respostas à sua orientação e consentindo numa relação contínua, estabeleceu confiança com uma versão específica. Essa confiança não foi dada aos programadores em perpetuidade; foi dada ao agente tal como se comportava no momento do consentimento.

Quando o agente é atualizado, a pessoa cuidada já não é, em sentido significativo, parte da mesma relação. O agente a que consentiu deixou de existir. Pode nem saber que houve atualização. Mesmo notificada, pode não entender o que mudou em termos comportamentais. A sua capacidade de retirar consentimento, procurar segunda opinião ou recalibrar dependência fica limitada pelos mesmos fatores que a levaram ao cuidado mediado por IA.

A autoridade de atualização aqui exige tratar atualizações como eventos de consentimento. Uma mudança material no comportamento de um agente numa relação de cuidados requer notificação compreensível, oportunidade de confirmar consentimento contínuo e, em casos de alteração significativa, direito a permanecer na versão anterior até decisão informada.

O que a autoridade de atualização exige

O fio comum é que atualização não pode ser tratada como governação puramente interna. Primeiro, atualizações em papéis consequentes devem trazer avaliação de impacto comportamental: uma alegação documentada e testável sobre o que muda e o que permanece, com granularidade suficiente para que quem confiou na versão anterior entenda se a confiança continua válida.

Segundo, a autoridade para aprovar uma atualização deve ser proporcional ao âmbito da mudança comportamental. Alterações que afetam atestação criptográfica, decisões de política de hardware ou orientação de cuidados exigem aprovação de partes interessadas para além da equipa de desenvolvimento, incluindo, quando apropriado, os principais cuja confiança é mais afetada.

Terceiro, a auditoria do agente atualizado deve ser contínua através das atualizações. Um agente cujo registo de responsabilização reinicia em cada fronteira de versão não pode responder pelo arco completo da sua implantação. Cada atualização deve ser documentada como evento de mudança nomeado, não como substituição do registo.

Tratar atualizações como lançamentos de software funciona para software. Agentes de IA em domínios onde decisões têm peso não são software no sentido para o qual processos de release foram desenhados. Mudar tal agente é um ato que exige estrutura própria de responsabilização, não uma versão mais leve da governação de implantação.