A lacuna de responsabilidade: quando um agente de IA causa dano, quem responde?

Agentes de IA estão a tomar acções consequentes. Executam protocolos de cuidado, aprovam transacções financeiras e encaminham recursos em infra-estrutura crítica. Quando essas acções causam dano, e algumas causarão, alguém suporta responsabilidade. Mas a arquitectura da IA agentiva distribui a cadeia causal por várias partes de uma forma que os quadros de responsabilidade existentes não foram desenhados para tratar. A lacuna de responsabilidade não é uma preocupação teórica para um regulador futuro; é um problema prático de engenharia que os construtores de agentes resolvem agora ou adiam para um momento pior.

O problema da acção distribuída

O direito tradicional da responsabilidade pressupõe um actor responsável. Quando um profissional humano causa dano, o caminho de responsabilização é identificável: o profissional, o empregador, a instituição e o padrão de cuidado que foi treinado para seguir. Quando um agente de IA causa dano, a cadeia causal distribui-se simultaneamente pelo programador que treinou o modelo, pelo operador que o configurou e implantou, pelo utilizador ou instituição cuja instrução desencadeou a acção e pelo quadro regulatório ou política institucional que o agente seguia.

Isto não é um quebra-cabeças abstracto. Num ambiente de cuidado, se um agente escalar ou despriorizar um alerta clínico e daí resultar dano, as contribuições causais de treino do modelo, configuração do operador, contexto do utilizador e protocolo institucional ficam entrelaçadas. Um tribunal ou regulador que tente atribuir responsabilidade depois do facto trabalhará com informação incompleta, a menos que a arquitectura do agente tenha sido construída para registar o que aconteceu e sob que autoridade.

Os limites de “segui a minha configuração”

A postura implícita de responsabilidade da maioria dos agentes implantados é simples: o operador configurou o sistema, logo o operador é dono do resultado. Isto é razoável como primeira aproximação, mas falha nos casos mais importantes. Uma configuração é escrita antecipadamente, com pressupostos que podem não se manter no momento em que o agente actua. Um agente que executa correctamente o comportamento configurado, mas ignora contexto disponível que uma pessoa razoável teria considerado, pode causar dano por uma falha de julgamento que nem o programador nem o operador autorizaram explicitamente.

Nem o programador nem o operador conseguem dizer simplesmente “isso estava dentro dos parâmetros que definimos”. E o agente não pode dizer “usei o meu julgamento”; diz apenas “segui os meus parâmetros”. Ambas as atribuições são incompletas. A lacuna de responsabilidade vive no espaço entre elas.

O trilho de auditoria como âncora de responsabilidade

O que fecha parcialmente a lacuna é um registo completo e fiável. Se, para cada acção consequente, o agente produzir um log com data e hora da instrução recebida, do principal de onde veio, da cadeia de autoridade resolvida, dos dados contextuais disponíveis no momento e da acção tomada, a responsabilidade pode ser atribuída com prova em vez de inferência. A ausência desse registo torna a atribuição de responsabilidade um jogo de adivinhação feito depois, com informação degradada.

O argumento sobre o registo de substituições humanas mostrou que cada intervenção calibrada se transforma numa vantagem operacional. O argumento de responsabilidade é o seu espelho: o registo calibrado de cada acção do agente, tomada sob autoridade identificável e com contexto recuperável, é também a base em que uma operação regulada pode assentar.

Atestação de hardware e cadeia probatória

Há um problema mais difícil sob o trilho de auditoria: a proveniência do próprio trilho. Uma entrada de log produzida por software pode ser contestada. Pode ser alterada, omitida selectivamente ou fabricada por um sistema comprometido. A utilidade de um registo para responsabilidade depende inteiramente da sua integridade, e logs apenas de software não fornecem garantias que satisfaçam uma contestação probatória séria.

É aqui que o cruzamento do hardware encontra a arquitectura de responsabilização. Logs de agentes produzidos dentro de um ambiente de execução fiável e assinados por uma chave de atestação enraizada em hardware têm peso probatório que logs de software não têm. As acções do agente não são apenas registadas; são registadas de uma forma que não pode ser falsificada silenciosamente depois. Um trilho auditável por hardware é prova. Um log apenas de software é uma alegação.

Construir para responsabilidade desde o início

Uma arquitectura pronta para responsabilidade não pode ser aparafusada depois de uma implantação se revelar consequente. A infra-estrutura de responsabilização tem de existir antes da primeira acção com impacto real, porque os eventos mais escrutinados serão frequentemente os iniciais, os casos-limite e os momentos em que o agente se comportou de uma forma que ninguém antecipou.

O que essa arquitectura exige não é uma nova lista de conformidade. Exige primitivos tratados ao longo desta série: hierarquias explícitas de principais em vez de regras implícitas de prioridade; registos estruturados de consentimento e autorização em vez de comentários de configuração; logs atestados por hardware em vez de eventos apenas de software; e assinatura criptográfica de acções na fronteira do agente com material de chaves que sobreviva à transição pós-quântica. A lacuna de responsabilidade é real e pode ser fechada, mas apenas por quem trata a arquitectura de responsabilização como requisito de primeira implantação.