O problema da multiplicidade: responsabilidade quando um agente de IA executa muitas instâncias simultâneas

A autorização foi emitida para o agente. O agente é agora cinquenta instâncias concorrentes. A ação de qual instância a autorização cobre? Esta questão permanece maioritariamente por fazer nos enquadramentos de responsabilidade de agentes de IA, porque esses enquadramentos foram concebidos numa era em que o modelo mental de um agente era singular: uma instância, uma sessão, um fluxo de ações. Em produção, esse modelo mental não sobrevive ao contacto com a infraestrutura. Os agentes reais escalam horizontalmente. E quando o fazem, os primitivos de responsabilidade — identidade, autorização, atribuição, auditoria — requerem todos repensar.

Como a multiplicidade quebra a atribuição

A atribuição é a afirmação de que uma entidade específica, agindo num momento específico, com uma autorização específica, produziu um efeito específico. Num agente de instância única, a cadeia de atribuição é rigorosa: o agente tem uma identidade, um conjunto de credenciais e um registo de ações. Um auditor pode reconstruir a cadeia. Quando a mesma especificação de agente executa como uma frota de instâncias concorrentes, a cadeia bifurca-se. Cada instância pode receber entradas diferentes, encontrar estados diferentes e tomar decisões diferentes — enquanto apresenta a mesma identidade a sistemas externos. O registo de ações é a união de cinquenta registos de instâncias. A que entrada de registo se aponta quando uma ação consequente precisa de ser atribuída? Na maioria das implementações atuais, a resposta é: qualquer que seja a instância que concluiu primeiro, identificada pelo ID de sessão, se o ID de sessão foi sequer registado.

O problema mais profundo é que a autorização não foi concedida a instâncias. Foi concedida ao tipo de agente, ou à configuração do agente, ou à versão de implementação. Nenhuma dessas designações resolve qual instância foi efetivamente autorizada a executar a ação consequente específica que está sob revisão. A autorização ao nível do tipo, combinada com a ação ao nível da instância, produz uma lacuna de atribuição que escala com o número de instâncias.

Como a multiplicidade amplifica a deriva de âmbito

Um único agente a operar fora do seu âmbito autorizado é uma violação de âmbito. Cinquenta agentes cada um a desviar-se ligeiramente fora do âmbito produzem cinquenta violações de âmbito simultâneas — cada uma pequena, cada uma facilmente perdida no ruído de um registo de ações extenso, e em conjunto constituindo uma afastamento sistemático da autorização que nenhuma revisão ao nível da instância individual detetaria. A deriva de âmbito numa frota de múltiplas instâncias é uma propriedade agregada. Requer medição agregada: não a distribuição de ações para uma única instância, mas a distribuição de ações em toda a população de instâncias durante uma determinada janela de operação. A maioria das implementações não tem uma infraestrutura de auditoria capaz desta perspetiva. Têm registos por sessão. Os registos por sessão são insuficientes para responsabilidade de múltiplas instâncias.

O problema do footprint agrava isto. O princípio do footprint mínimo estabelece que um agente deve solicitar apenas as permissões que a tarefa atual requer. Quando muitas instâncias executam concorrentemente, cada uma a solicitar permissões para a sua tarefa atual, a superfície de permissão agregada é muito maior do que qualquer tarefa individual justifica. A frota coletivamente detém mais autoridade do que qualquer autorização individual contemplou. Essa autoridade coletiva é a superfície que precisa de ser governada, e é a superfície que a maioria dos enquadramentos de autorização não aborda.

Como as travessias expõem o problema

Na travessia de segurança pós-quântica, o problema da multiplicidade manifesta-se como uma violação de padrão de utilização de chaves. Uma chave de assinatura emitida a um agente para um âmbito de autorização específico foi concebida tendo em mente uma entidade de assinatura. Quando muitas instâncias assinam concorrentemente usando a mesma credencial, o registo de auditoria criptográfica agrega assinaturas de uma frota, não de um único agente. A ligação entre o âmbito de autorização e a ação assinada específica enfraquece: sabe-se que a credencial autorizou a ação, mas a credencial nunca foi concebida para autorizar ação simultânea em escala. A transição para a criptografia pós-quântica é uma oportunidade para redesenhar a emissão de chaves ao nível da instância em vez do nível de implementação — emitindo chaves de curta duração com âmbito de instância que vinculam cada assinatura à instância e momento específicos que a produziram.

Na travessia de hardware, o problema de atestação espelha o problema de chaves. A atestação de hardware é tipicamente emitida para uma implementação, não para uma instância. Quando cinquenta instâncias executam concorrentemente, cada uma num ambiente de execução potencialmente diferente — hardware diferente, firmware diferente, estado de atestação diferente — a atestação ao nível de implementação não fala ao contexto de execução ao nível de instância. Uma ação produzida por uma instância a executar fora do limite de hardware atestado é tratada como se estivesse coberta pela atestação, porque o sistema de autorização não tem atestação ao nível de instância para verificar. O resultado é uma frota de agentes cada um apresentando uma atestação de implementação válida enquanto a afirmação de responsabilidade que a atestação pretende suportar pode não se verificar para qualquer instância específica.

Na travessia de cuidados no mundo físico, o problema da multiplicidade é mais imediatamente ético. Um agente de cuidados autorizado a interagir com um residente opera sob um plano de cuidados concebido para uma relação singular. Quando o mesmo tipo de agente executa como muitas instâncias simultâneas — cada uma interagindo com residentes diferentes, ou mesmo com o mesmo residente em momentos de cuidado diferentes — os pressupostos do plano de cuidados sobre continuidade de contexto, reconhecimento de estado anterior e limiares de escalada apropriados podem ser violados de formas que nenhum registo ao nível de instância revela. A responsabilidade agregada numa frota de cuidados requer correlacionar ações de instâncias de volta a relações de cuidado individuais, com uma granularidade que a maioria do registo de implementações de cuidados não suporta.

O que a arquitetura deve fazer

A solução não é menos instâncias — a escala é operacionalmente necessária. A solução é responsabilidade que foi concebida para escala desde o início. Identidade ao nível de instância significa que cada instância iniciada recebe um identificador único e de curta duração que está vinculado ao seu âmbito de autorização, estado de atestação de hardware e contexto de operação no momento do início. Atribuição de ação ao nível de instância significa que cada ação consequente transporta esse identificador de instância, criando um registo que não é uma união plana de entradas de sessão mas uma árvore estruturada: implementação para instância para ação. Monitorização de âmbito agregada significa que a camada de governação acompanha não apenas as distribuições de ação por instância, mas a distribuição de toda a frota, e alerta quando o agregado se afasta do âmbito pretendido mesmo quando nenhuma instância individual excedeu visivelmente a sua autorização.

A autorização foi emitida para o agente. Mas o agente que age é sempre uma instância específica, num momento específico, num contexto de execução específico. A responsabilidade em escala requer reconhecer essa distinção nas camadas de identidade, autorização e auditoria — antes que uma decisão consequente seja tomada por uma instância que nunca foi individualmente responsabilizada.