O problema do atraso de certificação
As linhas temporais de certificação de AI são medidas em anos; os ciclos de melhoria dos modelos são medidos em meses. Quando um agente é aprovado para implantação de alto risco, a versão revista já ficou para trás.
Quando um agente de AI causa dano num domínio de alto risco, uma das primeiras perguntas em qualquer processo de responsabilidade parece simples: a versão que causou o dano era a versão aprovada? Em disciplinas de engenharia estabelecidas, como farmacêutica, aviação e dispositivos médicos, a resposta é limpa. O artefacto aprovado fica congelado, o registo de implantação mostra que versão correu, e a responsabilização pode avançar a partir daí.
Para agentes de AI, a resposta é quase sempre complicada. A certificação demora. Os modelos melhoram continuamente. O intervalo entre a entrada de uma versão num processo de certificação e a conclusão desse processo pode ser de doze, dezoito ou trinta e seis meses. Durante esse período, os programadores do modelo normalmente já lançaram várias versões sucessoras com melhor desempenho mensurável, menores taxas de erro e modos de falha corrigidos que a versão certificada ainda exibe.
O dilema criado pelo atraso
Usar a versão certificada é defensável em sentido estreito: a certificação está registada, a versão está documentada e a autoridade de aprovação validou-a. Mas a versão certificada pode ter limitações conhecidas que versões mais recentes corrigiram. Implantar um modelo mais antigo e pior apenas porque está certificado pode parecer prudente dentro do processo, mas pode produzir piores resultados para as pessoas que o agente deve servir.
Usar uma atualização não certificada introduz outro vazio de responsabilidade. O operador pode implantá-la porque reduz genuinamente o risco, por exemplo ao corrigir um modo de falha relevante para a segurança, mas qualquer dano subsequente ocorre fora da fronteira de certificação. O registo mostra uma implantação divergente da versão aprovada, e a investigação tenderá a discutir se essa divergência causou o dano antes de discutir o que o agente realmente fez.
Nenhum caminho é limpo. O atraso de certificação transforma uma pergunta sobre qualidade do modelo numa pergunta sobre conformidade processual, e essas perguntas têm respostas diferentes para partes diferentes em momentos diferentes.
No cruzamento pós-quântico
As normas criptográficas sempre tiveram ciclos longos de certificação. A transição para algoritmos pós-quânticos ocorre numa escala de anos, com organismos de normalização a concluir revisões muito depois da implantação prática dos algoritmos analisados. Um agente de AI que gere operações de chaves pós-quânticas e foi certificado contra um modelo de ameaça anterior opera hoje contra um panorama de ameaças que evoluiu para lá da revisão. A certificação dá cobertura legítima; não dá garantia real contra ameaças surgidas depois.
No cruzamento de hardware
A certificação de hardware para aceleradores de AI, controladores embebidos e plataformas industriais envolve ensaios longos contra versões específicas de firmware e condições operacionais. Correções de segurança e atualizações de firmware são parte normal da manutenção. Quando surge uma vulnerabilidade crítica, os operadores aplicam a correção, e esse firmware corrigido normalmente não é o firmware certificado. Correr firmware vulnerável porque a correção ainda não foi recertificada raramente é uma escolha viável.
No cruzamento do cuidado
A AI médica enfrenta a versão mais aguda deste problema. Um dispositivo ou agente de software autorizado para o mercado foi revisto contra uma utilização prevista, uma população de pacientes e uma versão específica do modelo. A implantação real raramente permanece dentro dessas fronteiras. Populações mudam, usos previstos expandem-se, novas versões são lançadas e operadores integram o agente com outros sistemas. Quando ocorre dano, os investigadores precisam reconstruir que versão correu, o que a autorização cobria e que desvios contribuíram para o resultado.
O que a arquitetura de responsabilidade exige
O problema do atraso de certificação não tem uma solução simples. Certificação mais rápida reduz o atraso, mas não o elimina; os modelos continuarão a melhorar mais depressa do que qualquer revisão institucional consegue operar. A solução estrutural é tratar a certificação não como aprovação pontual de um artefacto congelado, mas como uma relação contínua entre a autoridade certificadora, o implantador e o histórico de versões do agente.
Isto exige três elementos que os quadros atuais em grande medida não têm: atestação de versão nos registos de implantação, avaliações de impacto de mudança que distingam alterações que invalidam a certificação de atualizações menores, e uma fronteira de certificação explícita nos processos de responsabilidade. Investigadores devem declarar que aspetos do comportamento estavam dentro do âmbito certificado e quais estavam fora dele antes de atribuir dano.
A versão certificada e a versão implantada raramente são a mesma. Quadros que as tratam como intercambiáveis deixam uma lacuna estrutural que nem a entidade certificadora nem o implantador possuem plenamente.
As linhas temporais de certificação são medidas em anos, enquanto os modelos evoluem em meses. Até à implantação, a versão certificada pode já estar atrasada. A responsabilidade exige atestação de versão, classificação explícita de impacto de mudanças e processos que distingam o que a certificação cobriu do que ficou fora dela.