O problema do consentimento congelado: responsabilização quando agentes de cuidados de IA continuam a agir com autorizações que já não refletem a relação de cuidados atual

Em implantações de cuidados com IA, o consentimento é normalmente captado num único momento: o enrolamento. A pessoa que recebe cuidados, ou o seu representante legal, aceita um conjunto de termos. Esses termos dizem o que o agente pode fazer: que sensores pode ativar, que dados pode reter, que decisões pode tomar autonomamente e quais deve escalar a um humano. O documento é assinado, armazenado e invocado quando surge a pergunta sobre se o comportamento do agente estava autorizado.

O problema do consentimento congelado é o que acontece entre esse momento e todos os momentos seguintes da implantação. A relação de cuidados evolui. As capacidades do agente mudam com atualizações de software. A trajetória de saúde da pessoa muda, por vezes melhorando, mais frequentemente não. As equipas que supervisionam a implantação mudam. Os termos originais, porém, ficam fixos. Formalmente continuam válidos. Substantivamente podem já não descrever a implantação real.

Porque a frescura não é uma propriedade natural do consentimento

Quadros de consentimento foram desenhados para estabelecer autorização, não para a manter. Depois de obtido consentimento, o sistema tem permissão legal para prosseguir. Raramente existe um mecanismo estrutural que verifique, periodicamente, se a implantação contínua ainda reflete o que a autorização original contemplava.

Isto é particularmente agudo em cuidados, porque o tempo entre enrolamento e o momento em que um problema aparece é frequentemente medido em meses ou anos. Um agente que monitorizava atividade e sono quando a pessoa era móvel e cognitivamente capaz continua, tecnicamente, a operar sob consentimento válido quando essa pessoa se torna quase imóvel e cognitivamente comprometida. O formulário diz "monitorização de atividade para otimização de saúde". O agente está agora a fazer algo substantivamente diferente, e ninguém reparou porque o formulário não mudou.

A dimensão de hardware

Dispositivos de cuidados com IA embebida agravam o problema. No enrolamento, o dispositivo é configurado para um contexto específico de cuidados. Essa configuração, incluindo âmbito de sensores, modelos locais de inferência e limiares de escalamento, fica fixada no firmware. Com o tempo, o firmware pode receber atualizações, mas essas atualizações raramente disparam revisão de consentimento. A autorização original permanece no registo; o perfil de capacidades atualizado não aparece em novo consentimento.

Um dispositivo autorizado a monitorizar risco de queda pode, depois de uma atualização de firmware, executar também um modelo de inferência de humor. A autorização da capacidade original está arquivada. A nova capacidade pode não estar coberta por consentimento algum.

O cenário de cuidados não tem mecanismo natural para revelar esta lacuna. O dispositivo opera. A pessoa não é convidada a consentir de novo. Supervisores assumem que, se o dispositivo está implantado, foi devidamente autorizado. O registo de autorização, que nada diz sobre a nova capacidade, é tratado como abrangente.

O que a validade temporal ignora

Provas criptográficas e documentos legais estabelecem se o material de consentimento é autêntico e se era válido quando foi criado. Não estabelecem se o consentimento continua substantivamente exato, ou seja, se a implantação descrita ainda corresponde à implantação em curso.

Essa distinção importa precisamente quando é mais difícil de revelar. Uma pessoa com capacidade limitada para monitorizar a própria situação e pedir revisão de consentimento é também a menos provável a notar que a autorização que governa os seus cuidados se afastou da realidade. Quem mais precisa de frescura de consentimento é quem menos consegue exigi-la.

Como deve ser a arquitetura correta

Manter o consentimento fresco exige tratá-lo como registo versionado de uma relação contínua, não como documento único. Na prática, isto significa checkpoints ligados a eventos de implantação: atualizações que mudam o âmbito funcional do agente devem disparar aviso de revisão, não avançar em silêncio.

Mudanças de capacidade devem ser divulgadas como deltas claros a quem supervisiona: alterações por modelo, configuração ou novo sensor não devem ficar enterradas em notas de firmware. Implantações longas devem ter requisitos de reautorização periódica, com intervalos definidos pela duração esperada e pela velocidade de mudança da relação de cuidados.

O trilho de auditoria deve colocar o histórico de versões de consentimento ao lado do histórico de ações, para que qualquer decisão possa ser reconstruída com a autorização efetiva nesse momento, não apenas com a autorização existente hoje.

A falha só aparece quando já importa

O problema do consentimento congelado não se anuncia. O agente funciona. Os cuidados continuam. O registo mostra um documento assinado. Nada no sistema assinala a deriva. Só quando se exige responsabilização é que a falha fica visível: quando algo corre mal e alguém pergunta exatamente o que o agente estava autorizado a fazer. A resposta reconstruída a partir de um documento correto no enrolamento, mas nunca atualizado, pode já não descrever a implantação que causou o dano.

Na Asaptic Labs, tratamos consentimento como registo vivo, não como barreira atravessada uma vez. Isso significa desenhar sistemas em que o estado de autorização é continuamente confrontado com o estado de implantação, com mecanismos estruturados para revelar e fechar a distância antes de se tornar evento de responsabilização.