O problema da passagem de responsabilidade: responsabilização no momento em que um agente de IA passa trabalho a outro

Em sistemas multiagente, raramente um único agente faz todo o trabalho. Na prática, o agente A recolhe informação, o agente B processa-a e o agente C age com base no resultado. Cada transição deste tipo, o momento em que o trabalho passa de um agente para o seguinte, é uma passagem de responsabilidade. É tão comum que se torna invisível na arquitetura. Essa invisibilidade é o problema.

O que realmente se transfere numa passagem

Quando o agente A passa trabalho ao agente B, duas coisas que a maioria dos sistemas trata como uma só ocorrem: o estado transfere-se e presume-se que a autorização se transfere com ele. Mas não são a mesma coisa. Estado é dados, contexto e descrição de tarefa. Autorização é uma declaração: o agente B pode continuar este trabalho em nome do mandante original e dentro do âmbito que esse mandante realmente concedeu.

Estado é fácil de transferir. Autorização não. A passagem típica transmite estado e espera que o agente B infira que a passagem é autorização suficiente. Quando tudo funciona, a suposição mantém-se. Falha nos casos que mais importam: injeção, interceção ou repetição de uma passagem para fazer o agente B executar algo que o mandante nunca autorizou.

O dilema do agente recetor

O agente B enfrenta um problema estrutural em cada passagem: sem um registo assinado e verificável, não consegue validar independentemente a legitimidade do trabalho recebido. Se confiar em tudo que chega do agente A, torna-se vetor para qualquer atacante que consiga imitar o agente A ou alterar a carga da passagem. Se recusar agir sem verificação, o fluxo interrompe-se.

A maioria dos sistemas resolve o dilema confiando implicitamente em tudo que chega por canais internos. Em implantações rigidamente controladas, isso pode ser razoável. Quando os canais cruzam fronteiras de rede, quando o agente A processa entradas não confiáveis ou quando ferramentas externas introduzem dados na carga, não é razoável. O problema de contaminação de contexto e o problema da cadeia de abastecimento cruzam-se aqui.

Passagens no mundo físico dos cuidados

Em contexto clínico, a passagem tem um análogo humano estudado e padronizado há décadas. Passagens clínicas entre turnos, equipas e instituições seguem protocolos estruturados porque as consequências de transferências incompletas são mensuráveis e graves. Um paciente cujo histórico medicamentoso ou monitorização contínua não foi transferido corretamente está em risco.

Passagens entre agentes em cuidados não têm padrão equivalente. Quando um agente de monitorização transfere responsabilidade para um agente de escalamento, o que constitui uma passagem completa? O que o recetor deve verificar antes de aceitar responsabilidade pela continuidade de cuidados de alguém? O que acontece ao registo de responsabilidade nesse momento? Em cuidados, o registo não é apenas artefacto técnico; é a base probatória para decisões e revisão. Uma pista de auditoria com observações do agente A, uma lacuna no momento da passagem e depois ações do agente B não reconstrói o que o sistema sabia quando decidiu escalar.

Passagens assinadas e o ângulo pós-quântico

Uma passagem bem desenhada gera um registo de passagem: um documento assinado que especifica quem transfere, quem recebe, que autorização a passagem transporta, de onde vem essa autorização na hierarquia do mandante e que estado é transferido. O agente recetor verifica a assinatura antes de aceitar. O conceito é simples, mas raramente é implementado.

A transição pós-quântica importa aqui pela mesma razão que importa para sinais de terminação e não repúdio: registos assinados hoje com criptografia assimétrica clássica podem tornar-se falsificáveis. Um atacante que capte tráfego agora pode, com capacidade futura suficiente, construir registos plausíveis que autorizam ações nunca permitidas, reescrevendo efetivamente a cadeia de autorização de uma tubagem já executada.

A atestação de hardware complica o quadro. Quando uma passagem cruza fronteiras de dispositivo, a atestação diz que cada dispositivo executa o que afirma executar. Não atesta a carga da passagem em si. Um dispositivo com firmware atestado ainda pode encaminhar um registo forjado ou contaminado. Atestação e registo de passagem são declarações de responsabilidade separadas; ambas são necessárias.

O que uma arquitetura completa exige

Uma arquitetura séria de passagem tem quatro componentes antes de qualquer pipeline multiagente tratar decisões importantes. Primeiro, um registo explícito criado no momento da transferência: agente cedente, agente recetor, âmbito transferido e cadeia de autorização original. Segundo, uma etapa de verificação pelo recetor que valida assinatura e cadeia antes de agir. Terceiro, verificação de consistência do estado, confirmando que o estado transferido é coerente e está dentro do âmbito autorizado. Quarto, um registo unificado de responsabilidade que trata a passagem como evento de primeira classe.

Nenhum destes componentes é mais caro do que o próprio sistema de agentes. Todos são regularmente omitidos porque a passagem parece detalhe de pipeline e não superfície de responsabilidade. A passagem é uma superfície de responsabilidade: o momento exato em que responsabilidade passa de um agente para outro. Sem documentação, assinatura e verificação, a auditoria posterior assenta em pressupostos, não em factos.