O problema da degradação graciosa: o que um agente de IA lhe deve quando não consegue cumprir

Discussões sobre responsabilização de agentes de IA focam normalmente as ações tomadas: agiu dentro do âmbito autorizado? Emitiu recibo de ação? A ação é atribuível ao principal correto? São perguntas certas, mas pressupõem que o agente está em funcionamento normal.

Esse não é o problema inteiro. Sistemas falham, hardware envelhece, redes caem, a confiança do modelo entra em regimes onde continuar a inferir não é apropriado. Em cada caso, o agente enfrenta uma escolha raramente especificada: o que fazer quando não consegue entregar.

Degradação graciosa não é uma métrica de fiabilidade anexada ao quadro de responsabilização. É parte do próprio quadro. Um agente correto no caso nominal e arbitrário no caso anómalo tem uma lacuna enorme, que aparece precisamente quando o risco é mais alto.

Três modos de falha

O primeiro é degradação de serviço. Em pipelines multicomponente, qualquer elo pode perder acesso a qualquer momento. Quando o endpoint de autorização está indisponível, muitas implantações continuam porque a continuidade operacional é tratada como prioridade. Para leituras de baixo risco isso pode ser aceitável; para ações físicas em cuidados, tratamento, ajuste de parâmetros ou alerta clínico, continuar sem confirmação de autorização é falha de responsabilização.

O segundo é degradação de hardware. Quando a plataforma de execução falha, sensor, enclave seguro ou TPM indisponível, a cadeia de atestação quebra. Um agente que continua depois de a infraestrutura de atestação falhar produz ações que não podem ser verificadas, reproduzidas para investigação ou atribuídas a um contexto de hardware específico.

O terceiro é incerteza de modelo. Entradas fora de distribuição, prompts adversariais e contextos diferentes dos dados de treino podem tornar as distribuições de saída pouco fiáveis. Um agente não tem introspeção fiável sobre estes modos de falha. A especificação segura deve depender de monitores externos, limites de confiança e limiares de override.

Porque é requisito de responsabilização

Um agente que só consegue prestar contas no caso nominal construiu metade de um sistema de responsabilização. A outra metade é a especificação do que faz quando algo corre mal, e o trilho de auditoria que prova que fez exatamente isso.

Investigadores e operadores não perguntam apenas o que aconteceu quando o agente operou corretamente. Perguntam: quando encontrou uma condição para a qual não foi desenhado, falhou de modo seguro? Escalou? Parou? Ou continuou como se a falha não existisse?

Como aparece nos cruzamentos

No cruzamento pós-quântico, a degradação intersecta infraestrutura criptográfica. Um agente que não consegue verificar a vinculação pós-quântica da sua credencial de autorização não deve prosseguir. O modo correto é parar e escalar, não voltar para criptografia mais fraca.

No cruzamento de hardware, a degradação é problema de sensores e atestação. Um agente cujo ambiente perdeu garantias de integridade deve tratar-se como fora da sua fronteira de responsabilização e parar ações consequentes, não assumir que a cadeia de atestação será restaurada.

No cruzamento de cuidados físicos, as consequências são imediatas. Um agente de cuidados que degrada em silêncio, continuando recomendações depois de inputs de sensores ou cadeia de autorização quebrarem, está fora de qualquer quadro de responsabilização. Isto não é apenas falha de software; é falha de cuidados.

Especificar o ponto seguro de paragem

A arquitetura correta especifica antecipadamente as condições em que cada categoria de ação consequente deve parar. Isto exige prever modos de falha, atribuir cada tipo de ação a uma classe de degradação e construir monitorização capaz de detetar limiares e acionar uma paragem controlada.

Um agente que não consegue descrever o que fará quando não consegue cumprir ainda não terminou o seu desenho de responsabilização. A pergunta não é apenas se agiu corretamente quando podia. É se parou corretamente quando não podia.