O problema da retirada do consentimento: quando uma pessoa muda de ideias depois de um agente já ter começado

A arquitectura de responsabilidade para agentes de IA dedica muita atenção ao consentimento no enrolamento: quem autorizou o agente, com que âmbito e em nome de quem. Em sistemas bem desenhados, a camada de consentimento representa autorização no arranque do workflow. Essa camada importa. Mas trata consentimento como portão, não como condição. Depois de aberto, o agente prossegue. O problema da retirada começa precisamente aí.

As pessoas mudam de ideias. As circunstâncias mudam. Um paciente que consentiu de manhã num protocolo de cuidados assistido por IA pode retirar esse consentimento à tarde, porque o estado clínico mudou, porque um familiar levantou uma preocupação ou porque reconsiderou. A arquitectura de consentimento-como-portão não responde a isto: como chega a retirada a um agente já em execução, e o que faz o agente quando a recebe?

Anatomia de uma falha de retirada

Um agente gere um workflow de coordenação de cuidados para um residente numa instituição de longa duração. Às 10:00, o representante autorizado reviu o plano e consentiu em agendamento e comunicação assistidos por IA para as consultas do dia. O agente começou: confirmou transporte, notificou a equipa clínica, preparou o plano de medicação da tarde e enfileirou comunicações ao especialista.

Às 13:30, o representante telefonou directamente à instituição e retirou verbalmente o consentimento para o resto do plano gerido por IA. Um coordenador registou a retirada no processo. O agente não tinha ligação a esse registo. Às 14:15, enviou as comunicações enfileiradas, acções dentro do consentimento da manhã e fora do consentimento retirado. O agente não avariou. Executava um workflow autorizado no arranque contra um estado de consentimento que mudara horas antes.

A falha não é agente malicioso nem má configuração. É uma lacuna estrutural: consentimento modelado como pré-condição de entrada, e não como estado contínuo de autorização dentro do qual o workflow deve permanecer.

O problema da entrega do sinal

O desafio imediato é o canal. Na maioria das arquitecturas, o consentimento é uma flag numa base de dados, definida no enrolamento e lida no início. Não há subscrição nem notificação push para avisar que a flag mudou. O agente lê uma vez e prossegue com estado em cache até concluir ou encontrar um checkpoint explícito.

Mesmo com polling periódico, o intervalo cria uma janela. Se o agente verifica consentimento a cada cinco minutos e a retirada chega quatro minutos e cinquenta segundos depois da última verificação, o agente continua cinco segundos com autorização já retirada. Em cuidados no mundo físico, cinco segundos bastam para enviar uma comunicação, disparar um lembrete de medicação ou confirmar uma consulta.

A arquitectura correcta é push: a retirada gera um evento entregue a todos os agentes que executam workflows sob esse consentimento. Isto exige agentes alcançáveis com estado, por ligação persistente ou fila de mensagens. É diferente de execução stateless, e a maioria dos sistemas actuais não é construída assim.

O problema da autenticação

Mesmo existindo canal, o agente deve verificar que o sinal é autêntico. Uma retirada fraudulenta injectada por um adversário é um ataque de negação de serviço disfarçado de evento de consentimento. Aceitar qualquer sinal sem verificação criptográfica torna o agente manipulável; esperar por verificação pode atrasar a resposta até o dano já ter ocorrido.

A infraestrutura que gere concessões deve gerir retiradas: sinais assinados, datados e não repudiáveis, verificáveis contra chaves conhecidas. Em implantações pós-quânticas, as assinaturas devem resistir a adversários com capacidade quântica. O custo computacional dessa verificação, agregado em muitas instâncias concorrentes, liga a criptografia da retirada ao orçamento de latência do agente.

Ambientes com raiz de confiança em hardware ajudam: a atestação pode incluir o estado de consentimento no contexto de execução atestado, fazendo falhar tentativas de injectar sinais não gerados pela autoridade legítima. Mas isso exige integração da infraestrutura de consentimento com a cadeia de atestação desde o início.

O problema das acções em voo

Mesmo com entrega e autenticação, resta saber o que acontece às acções já despachadas entre o momento da retirada e o momento em que o sinal chegou. Não foram não autorizadas por negligência. Eram autorizadas quando tomadas, mas a autorização caducou antes de os efeitos se resolverem.

Uma comunicação enviada às 14:10 pode só ser lida às 14:30. Um lembrete de medicação enviado às 14:12 chega às 14:15. O agente recebe a retirada às 14:20 e pára. A paragem é correcta. Mas comunicações já enviadas continuam a propagar-se e a produzir efeitos que a pessoa já não autorizava.

Aqui a retirada cruza rollback e handoff. Acções já propagadas para sistemas externos não são chamadas de volta simplesmente parando o agente. A pergunta de responsabilidade é difícil: o agente actuou dentro da autorização no momento; a autorização caducou antes dos efeitos; nenhum actor único errou. A lacuna é arquitectural.

Consentimento como estado contínuo

O princípio de desenho é o mesmo da análise TOCTOU e de revogação: autorização não pode ser verificada uma vez e presumida permanente. Consentimento é uma relação humana com expressão contínua, não um documento assinado uma vez. Arquitecturalmente, deve ser propriedade de streaming do contexto de execução do agente, não portão de inicialização.

Na prática, isto requer três coisas: infraestrutura de consentimento com push e latência de segundos; sinais de retirada criptograficamente verificáveis integrados na mesma cadeia de atestação das concessões; e postura definida para acções em voo, para que o agente saiba que classes podem ser chamadas de volta, quais não podem e quem deve ser notificado.

A camada de consentimento mais importante não é a que regista acordo no início. É a que acompanha se o acordo ainda vale em cada momento de execução e chega ao agente a tempo de agir quando deixa de valer.