O problema da correção assimétrica

A assimetria é direta: um agente de IA pode entregar uma decisão errada a dez mil pessoas antes de um único revisor humano processar o primeiro caso. Entregar o erro levou milissegundos. Corrigi-lo levará meses.

Este é o problema da correção assimétrica: a lacuna estrutural entre a escala a que erros agentivos são entregues e a escala a que podem ser corrigidos. Não é uma falha contingente de processo; é uma propriedade geométrica da implantação de agentes.

Porque os erros sistemáticos são diferentes

Erros aleatórios podem muitas vezes ser corrigidos em escala através do mesmo canal de entrega. Erros sistemáticos não. Os que surgem de desalinhamento da distribuição de treino, deslocação de fronteiras de configuração ou modos de falha partilhados afetam uma classe definida pelas características que causaram a falha.

Cada pessoa afetada recebeu aconselhamento ajustado ao seu input. Cada correção exige estabelecer qual foi o conselho errado, qual seria o correto e o que a pessoa fez no intervalo antes de o erro ser encontrado.

Porque o dano latente agrava a obrigação

Quando o dano de uma decisão errada não é imediato, as pessoas afetadas continuam a agir com base no resultado errado enquanto o erro permanece indetetado. A obrigação de correção acumula-se durante todo esse período latente.

Arquiteturas de responsabilidade desenhadas com o pressuposto de deteção rápida não contemplam a procura de correção que se acumula nesse intervalo.

Porque a correção não pode ser automatizada

Rollback computacional é simétrico: o sistema que escreveu o estado errado pode reescrevê-lo. Dano humano não. Corrigir exige contactar pessoas afetadas, informá-las do erro, aconselhar sobre a recomendação correta e apoiar as mudanças necessárias.

Organizações que implantam agentes numa escala que não conseguem corrigir depois não estão apenas a decidir implantar. Estão a tomar uma decisão de responsabilidade.

O cruzamento da segurança pós-quântica

Quando uma família de algoritmos criptográficos é descontinuada, cada registo assinado sob ela exige revisão individualizada: não se o algoritmo foi descontinuado em geral, mas se aquele registo específico dependia de uma garantia que já não se mantém.

O cruzamento de hardware

Uma vulnerabilidade de firmware numa frota exige identificar dispositivos afetados, enviar configurações corrigidas e determinar se ações tomadas durante o período vulnerável merecem reexame. As duas primeiras tarefas podem ser automatizadas. A terceira é trabalho caso a caso.

O cruzamento dos cuidados no mundo físico

Em implantações de cuidados, o problema é mais consequente. Um agente que falhou sistematicamente uma classe de contraindicações ou subponderou um padrão de sintomas distribuiu orientação errada à velocidade da máquina.

Corrigir exige contactar cada pessoa afetada, rever o seu caso e fornecer orientação corrigida. Esta capacidade é pré-requisito de implantação, não recurso de remediação posterior.

O que isto exige no desenho

Melhorar a deteção de erros não resolve o problema; apenas acelera o reconhecimento da obrigação. Respostas adequadas incluem limitar o alcance até demonstrar capacidade de correção, construir fluxos de correção como componentes de primeira classe e tratar capacidade de correção como fator de risco antes da implantação.