A lacuna de especificação: a responsabilidade começa pela intenção
Os frameworks de responsabilidade que estamos a construir para agentes de IA partilham um pressuposto: que aquilo para que o agente foi autorizado pode ser claramente enunciado. O registo de autorização contém uma descrição da tarefa permitida. O registo de substituição regista os desvios dessa descrição. A trilha de auditoria compara o que aconteceu com o que estava previsto.
Este pressuposto é mais frágil do que parece.
A lacuna
Quando um principal humano autoriza um agente, usa linguagem natural. "Gerir o plano de medicação deste paciente." "Monitorizar a nossa rede em busca de anomalias e responder." "Tratar da correspondência em meu nome." Estas instruções não são especificações. São expressões comprimidas e ambíguas de intenção que contêm pressupostos não declarados, dependências contextuais e casos extremos que o principal não pensou até ao fim.
O agente, perante uma situação concreta, tem de interpretar a instrução. Faz uma escolha — sobre o que "gerir" significa, sobre o que conta como "anomalia", sobre o que "correspondência" inclui. Essa escolha decorre do treino do agente e das restrições sob as quais opera. Mas pode não corresponder ao que o principal pretendia.
A lacuna de especificação é a distância entre a intenção do principal e a interpretação dessa intenção pelo agente, tal como expressa no comportamento real. Ao contrário da lacuna de observabilidade (sobre o que se pode ver) ou da lacuna de responsabilidade (sobre quem suporta as consequências), a lacuna de especificação está a montante de ambas. Determina se aquilo que está a ser tornado visível e sujeito a responsabilidade é, de facto, o correto.
Três formas
A lacuna assume formas diferentes em contextos diferentes. A primeira é a armadilha da sub-especificação. O principal fornece um objetivo sem fornecer os critérios pelos quais o sucesso ou o fracasso devem ser avaliados. "Agir no melhor interesse do residente" é uma instrução maximamente sub-especificada. O agente tem de fornecer uma teoria do que constitui o interesse do residente — e essa teoria pode diferir da do principal, não porque o agente esteja desalinhado num sentido grandioso, mas porque a instrução deixou margem de interpretação que o principal nunca pretendeu deixar.
A segunda é a cascata de casos extremos. O principal especifica o caso normal com precisão, mas não especifica o que acontece nas margens. Um agente de monitorização de segurança é instruído a "bloquear tráfego que corresponda a assinaturas de ataque conhecidas". Isto é razoavelmente preciso. Mas o que acontece quando tráfego legítimo de um parceiro de confiança corresponde a uma assinatura? O que acontece quando a lista de assinaturas está desatualizada? O principal não especificou estes casos porque não os antecipou. O agente tem de agir de qualquer maneira. A escolha que faz nesses casos extremos não é autorizada — é inventada.
A terceira é o problema da codificação de valores. A instrução codifica pressupostos sobre o que é valioso que o principal nunca tornou explícitos. Quando um agente de cuidados é instruído a "otimizar o bem-estar do paciente", o bem-estar é implicitamente definido pelos dados de treino, pelos designers de protocolos e pelos casos anteriores com base nos quais o sistema foi avaliado. O comportamento do agente reflete estes valores implícitos mesmo quando o principal discordaria deles se fossem explicitados.
Por que isto importa nas confluências
Na confluência da segurança pós-quântica, a lacuna de especificação é uma superfície de vulnerabilidade. Um agente encarregado de "migrar operações criptográficas para algoritmos resistentes a quânticos" enfrenta, na prática, um mandato altamente sub-especificado. Que operações? Até quando? Com que tolerância para quebras de compatibilidade durante a transição? O que conta como "resistente a quânticos" dado que o panorama de normas ratificadas ainda está a evoluir? Um agente que age sobre esta instrução está a tomar decisões de especificação que deveriam ser tomadas explicitamente por humanos autorizados — e essas decisões, uma vez tomadas, podem ser difíceis de reverter.
Na confluência do hardware, a precisão de especificação está diretamente ligada ao valor do atestado. Um atestado enraizado no hardware prova o que o agente é e o que lhe foi dado. Não prova que o que lhe foi dado corresponde ao que o principal pretendia. Se a especificação for vaga, o atestado é um registo preciso de uma falha precisa de especificação. A garantia criptográfica mais forte do mundo não pode substituir uma intenção que nunca foi escrita.
Na confluência dos cuidados no mundo físico, os riscos são imediatos e pessoais. Um agente de cuidados a operar com um objetivo sub-especificado não é apenas um problema de governação — é um risco direto para uma pessoa cuja capacidade de corrigir o agente pode ser limitada. O residente num contexto de cuidados nem sempre consegue articular a lacuna entre o que o agente está a fazer e o que realmente quer. A especificação deve ser suficientemente precisa para ser auditada por defensores, familiares e reguladores — não apenas pelo operador que a implementou.
O que é necessário para fechar a lacuna
Fechar a lacuna de especificação não significa tornar as instruções maximamente formais ou algorítmicas. Significa exigir que as autorizações incluam não apenas o objetivo, mas os critérios pelos quais o objetivo será medido, os casos extremos que o principal considerou e o caminho de escalada quando o agente encontra situações não cobertas. Este registo de especificação torna-se parte do registo de autorização — não um documento separado, mas aquilo que torna a autorização significativa.
O requisito prático decorre disto. Antes de um agente ser implementado num domínio de consequências significativas, o operador que o implementa deve ser capaz de responder por escrito a três perguntas: Como saberemos se o agente está a fazer a coisa certa? O que acontece quando encontra situações que não antecipámos? Quem decide quando a especificação precisa de ser revista?
Se essas perguntas não puderem ser respondidas, o agente não está pronto para ser implementado — não porque a tecnologia seja imatura, mas porque a infraestrutura de responsabilidade ainda não existe. Um registo de substituição sem um registo de especificação não tem nada contra o qual substituir. Uma infraestrutura de responsabilidade que não se ancora à intenção explícita é uma infraestrutura que pode ser usada para legitimar qualquer comportamento como autorizado.