O problema da modificação pós-incidente: responsabilização quando a resposta operacional a um evento adverso de IA destrói as evidências necessárias para investigá-lo

Um agente de IA de cuidados interpreta incorretamente um sinal fisiológico de um doente e não aciona um alerta de escalada. A equipa de operações, notificada em poucas horas, implementa uma correção de configuração e aciona uma atualização de modelo. Na manhã seguinte, o sistema funciona corretamente. Quando uma revisão formal tem início três semanas depois, o estado pré-incidente do sistema — a versão do modelo, a configuração, o contexto de inferência — já não existe de forma que qualquer investigação possa examinar.

Este é o problema da modificação pós-incidente: quando a resposta operacional a um evento adverso de IA destrói o estado probatório que uma investigação subsequente exigiria. A destruição não é maliciosa. É operações padrão. E está estruturalmente em conflito com todas as obrigações de responsabilização que o implementador aceitou aquando da implementação.

Três modos de destruição de evidências

A destruição de evidências após um evento adverso de IA ocorre em três modos, cada um individualmente defensável.

O primeiro é a substituição de modelo. Quando um sistema de IA produz um resultado errado, a resposta operacional correta é atualizá-lo — treinar novamente com dados corrigidos, implementar um novo ponto de controlo, mudar para uma versão diferente. O modelo pré-incidente é sobrescrito ou arquivado de formas que nem sempre são reproduzíveis. O modelo exato que produziu o resultado errado pode já não existir num estado executável quando qualquer investigador o solicitar para análise.

O segundo é a alteração de configuração. Os agentes de IA em cenários do mundo físico produzem frequentemente resultados adversos devido à forma como foram configurados, não por causa de uma falha no modelo subjacente. A engenharia de prompts, os limiares de recuperação, as definições de sensibilidade de alertas, os parâmetros de integração — cada um molda o comportamento sem tocar nos pesos do modelo. Atualizar a configuração após um evento adverso é tão rotineiro que frequentemente não aciona sequer um registo formal de gestão de alterações. A modificação que causou o incidente e a modificação que o corrigiu podem estar separadas por horas e ser indistinguíveis no registo de alterações.

O terceiro é a rotação de registos e a renovação da infraestrutura. Os registos de eventos que permitiriam a reconstrução — os prompts exatos, o contexto recuperado, os resultados intermédios, o estado do hardware no momento do incidente — estão sujeitos a políticas padrão de retenção de registos concebidas para conveniência operacional, não para investigação adversarial. Em muitas implementações, noventa dias é considerado generoso. O pressuposto operacional é que os registos são para depuração, não para responsabilização. Estes não são o mesmo requisito.

A interseção com a segurança pós-quântica

A assinatura criptográfica pós-quântica dos pesos do modelo aborda a adulteração: estabelece que os pesos em produção hoje são os pesos que o programador assinou. Não estabelece se os pesos em produção hoje são os mesmos que estavam a correr no momento do incidente. Uma versão de modelo assinada é um registo fidedigno do estado atual. Não é um registo do histórico de implementação.

A transição para infraestruturas de assinatura pós-quânticas introduz um risco específico. As organizações que migram para esquemas de assinatura resistentes a quantum frequentemente reassinam artefactos existentes como parte da migração — o que pode romper a cadeia de assinaturas que de outra forma teria preservado o estado no momento do incidente. Uma organização que completou uma migração de infraestrutura de assinatura entre o evento adverso e a investigação pode descobrir que a cadeia probatória que a investigação exige foi interrompida como efeito colateral rotineiro de uma melhoria de segurança legítima.

A oportunidade é igualmente estrutural. As arquiteturas de assinatura pós-quânticas que estão a ser concebidas e implementadas agora podem incluir requisitos explícitos de preservação do histórico de versões. Um esquema de assinatura concebido para preservar além de verificar — mantendo um histórico inviolável e de só adição do que foi assinado e quando — altera o cálculo probatório para todas as investigações de eventos adversos que se seguem à implementação.

A interseção com o hardware

Os sistemas de IA embebidos em ambientes de cuidados físicos — monitorização de cabeceira, dispositivos de assistência, sensores ambientais com camadas de inferência — recebem atualizações de firmware através de infraestruturas de gestão de dispositivos que são automatizadas, mal documentadas ao nível do dispositivo individual e raramente marcadas com precisão temporal suficiente para permitir a atribuição pré/pós-incidente.

O atestado de hardware verifica que o firmware atual é autêntico e não modificado. Não fornece um registo histórico do firmware que estava a correr no momento do incidente. Quando um dispositivo recebe uma atualização de firmware nas horas que se seguem a um evento adverso — o que é operacionalmente normal, porque um dispositivo que se comportou incorretamente deve ser atualizado — a cadeia de atestado de hardware para o estado pré-incidente é quebrada sem qualquer registo formal de que a quebra ocorreu. O dispositivo está agora correto e atestado. O estado no momento do incidente desapareceu.

A interseção com os cuidados do mundo físico

Os ambientes de cuidados criam a maior pressão operacional contra a preservação de evidências. Um coordenador de cuidados que sabe que um sistema de IA se comportou mal e opta por atrasar a correção para preservar um estado pré-incidente para investigação está a tomar uma decisão que todas as normas operacionais de cuidados classificariam como negligência. O dever de proteger os atuais destinatários de cuidados não pode aguardar pela conveniência investigativa.

Isto cria um problema estrutural que não pode ser resolvido atribuindo-o como falha de qualquer parte individual. O imperativo operacional de corrigir o problema imediatamente está correto. As evidências necessárias para investigar o problema são destruídas na mesma. A investigação prossegue com base em informação degradada, as reclamações de responsabilização são resolvidas na ausência das evidências que as teriam resolvido, e a lição do incidente — a configuração específica ou o comportamento do modelo que causou a falha — pode nunca ser claramente atribuída.

A assimetria agrava-se com o tempo. Cada evento adverso que não é investigado porque as evidências foram destruídas no curso da remediação contribui para um ambiente de responsabilização em que os implementadores não conseguem demonstrar diligência devida, os investigadores não conseguem reconstruir a causa, e as populações servidas por sistemas de IA de cuidados não podem confiar na responsabilização formal como mecanismo corretivo.

Rumo a uma resposta responsável

O problema da modificação pós-incidente não se resolve abrandando a resposta operacional. Resolve-se desacoplando a resposta operacional da preservação de evidências.

O requisito prático são instantâneos automáticos pré-modificação: antes de qualquer atualização de modelo, alteração de configuração ou implementação de firmware, o sistema captura e preserva o estado pré-modificação num repositório inviolável fora do caminho de atualização operacional. O instantâneo inclui a versão e hash do modelo, parâmetros de configuração, registos estruturados recentes e o estado do firmware de hardware. O repositório é de escrita única e atestado separadamente — a equipa operacional pode atualizar o sistema em produção sem que a atualização toque no estado preservado.

Este é um requisito de engenharia, não um requisito de política. A política não pode preservar evidências que o sistema nunca foi concebido para reter. O momento de incorporar a preservação de evidências nos sistemas de IA físicos é antes da implementação, quando os requisitos probatórios podem ser concebidos a par dos requisitos operacionais, em vez de descobertos em oposição a eles após o primeiro incidente grave.

Na Asaptic Labs, o problema da modificação pós-incidente é tratado como um requisito de conceção em cada interseção. A correção operacional e a correção probatória não são a mesma propriedade, e um sistema que aborda apenas a primeira satisfez a sua obrigação operacional enquanto torna as suas obrigações de responsabilização estruturalmente não investigáveis. Nos pontos de consequência irreversível, esse não é um resultado satisfatório.