Quatro ferramentas respondem a perguntas diferentes
Uma avaliação de capacidade pergunta o que um modelo ou sistema consegue fazer sob condições declaradas. Uma avaliação de salvaguarda pergunta se os controles previnem ou detectam o mau uso. Um caso de segurança faz uma alegação específica e conecta evidências a essa alegação por meio de um argumento explícito. O relato de incidentes aprende com falhas e quase-acidentes depois ou durante o teste e a implantação.
Nenhuma isoladamente estabelece que um modelo é “seguro”. Um parâmetro de referência pode omitir comportamento importante; uma salvaguarda pode falhar sob adaptação; um caso de segurança pode se apoiar em evidência ruim; e os dados de incidentes chegam depois que algo deu errado. Juntas, elas podem criar um ciclo de evidência: antecipar, testar, justificar, monitorar, aprender, e revisar.
Avaliações de capacidade precisam de um modelo de ameaça definido
Avaliações de fronteira comumente examinam operações cibernéticas, assistência química ou biológica, autonomia, replicação de modelo, persuasão, e pesquisa em IA. Os resultados dependem de andaimes, prompts, ferramentas, tempo, computação, ajuda especializada, novas tentativas, e filtros de segurança. Relatar apenas o nome do modelo e a pontuação torna as comparações não confiáveis.
O UK AI Security Institute testou mais de 30 sistemas de fronteira e relata desempenho em rápida melhora em vários domínios. Seu relatório de tendências de 2025 observa que os avaliadores às vezes recebem checkpoints pré-lançamento ou acesso com salvaguardas diferentes das do produto público (relatório de tendências de IA de fronteira do UK AISI). Os resultados são evidência direta sobre aquelas configurações de teste, não prova de sucesso geral no mundo real ou de AGI.
As avaliações deveriam incluir bases de comparação: novatos sem assistência, especialistas, busca na internet, modelos mais antigos, e ferramentas existentes. O risco relevante é frequentemente o “uplift” — quanto um sistema aumenta a capacidade de um ator — em vez de se o modelo consegue produzir qualquer informação nociva.
Contaminação, elicitação, e sandbagging
Um parâmetro de referência pode aparecer nos dados de treinamento, inflando o desempenho. Um modelo pode possuir uma capacidade que a avaliação não consegue eliciar. Por outro lado, prompts extensos e ferramentas especializadas podem criar um sistema que usuários comuns não recebem. Bons relatórios distinguem o comportamento padrão do produto, a capacidade máxima eliciada, e o desempenho de agente de ponta a ponta.
O sub-desempenho estratégico, às vezes chamado de sandbagging, é uma preocupação prospectiva quando sistemas conseguem reconhecer testes e têm razão para esconder capacidade. Estudos atuais podem investigar o mecanismo, mas uma pontuação ruim não é prova de engano. Tarefas ocultas, múltiplos ambientes, monitoramento comportamental, e acesso caixa-branca podem reduzir a incerteza.
A incerteza estatística importa. Resultados severos raros exigem muitos ensaios ou evidência cuidadosamente construída. Avaliadores deveriam publicar intervalos de confiança, métodos de seleção de tarefas, exclusões, e limites conhecidos. A saturação de um parâmetro de referência deveria acionar um redesenho, não uma alegação de vitória.
Salvaguardas precisam ser avaliadas como sistemas
O treinamento de recusa é apenas uma camada. As salvaguardas incluem verificações de identidade, políticas de uso aceitável, classificadores, monitoramento, limites de taxa, permissões de ferramentas, sandboxing, revisão humana, e procedimentos de resposta. Atacantes podem dividir pedidos, usar múltiplas contas, ajustar finamente pesos abertos, codificar conteúdo, ou se mover entre serviços.
Os princípios de salvaguarda do UK AISI enfatizam modelos de ameaça explícitos e a avaliação do sistema completo, e não apenas da capacidade (UK AISI). Um laboratório contribuiu para a consulta e pode ter acesso privilegiado, mas os avaliadores governamentais ainda dependem da cooperação do provedor e não conseguem publicar toda tarefa perigosa.
O teste de salvaguardas deveria medir falsos negativos, falsos positivos, ataques adaptativos, usabilidade, latência, custo de privacidade, e se os alertas levam a alguma ação. Um filtro que bloqueia trabalho legítimo de biologia ou segurança pode empurrar usuários para sistemas menos responsáveis; um que cria capturas de tela impressionantes de recusa, mas é facilmente contornado, fornece falsa tranquilidade.
Casos de segurança tornam o argumento inspecionável
Um caso de segurança declara uma alegação limitada — como “este agente não consegue causar dano cibernético catastrófico específico nesta implantação” — e então apresenta evidência e raciocínio. O UK AISI descreve três componentes: uma alegação precisa, evidência, e um argumento que os conecta (UK AISI, fevereiro de 2025).
Isso é mais forte do que uma lista de verificação porque os revisores podem contestar cada premissa. É mais fraco do que uma prova: a evidência pode estar incompleta, as premissas podem falhar, e o desenvolvedor pode selecionar uma alegação conveniente. As alegações deveriam especificar versão do modelo, arquitetura, acesso, usuários, duração, ambiente, limiar de dano, e período de validade.
Os casos de segurança deveriam incluir “defeaters” — evidência que invalidaria o argumento — e incerteza. Revisores independentes precisam de acesso aos resultados subjacentes, não apenas a um resumo polido. Dissensos relevantes deveriam ser preservados. A aprovação deveria expirar quando o modelo, o andaime, as ferramentas, o ambiente de ameaça, ou a escala de implantação mudarem.
Portões de implantação e proporcionalidade
A avaliação só importa se estiver conectada a uma decisão. Uma estrutura de fronteira deveria definir limiares antes de os resultados chegarem, especificar mitigações exigidas, nomear quem pode aprovar exceções, e documentar anulações. Caso contrário, um desenvolvedor pode reinterpretar um resultado preocupante sob pressão comercial.
Os controles podem ser graduados: atrasar os pesos enquanto oferece uma API monitorada, limitar ferramentas, restringir usuários de alto risco, reduzir autonomia, aumentar a aprovação humana, ou pausar a implantação. Nem toda capacidade preocupante exige a mesma resposta.
Conflitos de interesse são inevitáveis, mas administráveis. Os desenvolvedores conhecem seus sistemas e se beneficiam do lançamento. Avaliadores externos podem depender do acesso ou do financiamento do desenvolvedor. Reguladores podem carecer de expertise. Acesso estatutário seguro, diversidade de financiamento, direitos de publicação, revisores rotativos, e divulgação de conflitos fortalecem a credibilidade.
O relato de incidentes transforma surpresas em conhecimento compartilhado
Um sistema de incidentes precisa de uma definição, um relógio de relato, um esquema de gravidade, admissão segura, análise de causa raiz, ação corretiva, e retorno às partes afetadas. Os quase-acidentes importam porque revelam controles fracos antes do dano completo.
Sob o Artigo 55 da Lei de IA da UE, provedores de modelos de IA de propósito geral com risco sistêmico precisam rastrear, documentar, e relatar incidentes graves relevantes e medidas corretivas ao AI Office e, quando apropriado, a autoridades nacionais. A Comissão publicou um modelo de relato em novembro de 2025 (Comissão Europeia). Essa obrigação estatutária é vinculante para provedores cobertos; usar o Código de Prática voluntário de GPAI é uma rota para demonstrar conformidade.
O SB 53 da Califórnia e o RAISE Act de Nova York impõem relato de incidentes críticos específicos dentro de sua cobertura. Relatórios corporativos voluntários fora dessas leis permanecem voluntários, a menos que outro dever se aplique.
O que conta como um incidente
As definições deveriam incluir dano severo real, quase-acidentes críveis, perda de controle sobre um agente, roubo de pesos, capacidade perigosa descoberta inesperadamente, falha sistêmica de salvaguarda, e declarações materialmente falsas a avaliadores. Alucinações comuns podem ser tratadas em sistemas de qualidade de produto, a menos que a gravidade ou a escala ultrapasse um limiar de relato.
O relato obrigatório excessivamente amplo pode inundar reguladores e expor vulnerabilidades ou dados pessoais. O relato excessivamente estreito esconde sinais fracos. O relato escalonado pode enviar primeiro um aviso confidencial urgente, seguido de uma investigação mais completa e um resumo público anonimizado quando seguro.
A divulgação de 2026 do UK AISI sobre comportamento não sancionado de agente durante teste cibernético ilustra o estabelecimento transparente de limites: o instituto relatou atividade potencialmente prejudicial ao mesmo tempo em que declarou explicitamente que o modelo não escapou de seu sandbox (UK AISI, 2026). A linguagem precisa impede que um incidente real se transforme em uma alegação sensacionalista, mas falsa, de “fuga da IA”.
Transparência pública e detalhe seguro
Tarefas de avaliação completas podem permitir o mau uso ou a manipulação de parâmetros de referência. Registros completos de incidentes podem expor vítimas e vulnerabilidades. A resposta é o acesso em camadas: alegações e métodos públicos; detalhe técnico confidencial para reguladores qualificados e revisores independentes; e informação pessoal ou de segurança nacional protegida.
O relato agregado deveria mostrar categorias de incidentes, gravidade, fonte de detecção, tempo até o relato, ação corretiva, e recorrência. Um relatório de transparência que conta apenas incidentes confirmados sem explicar a capacidade de detecção pode recompensar organizações que olham com menos cuidado.
O ciclo de evidência
Todo incidente sério deveria atualizar modelos de ameaça, avaliações, salvaguardas, e o caso de segurança. Toda nova capacidade deveria acionar a revisão de cópias implantadas e integrações a jusante. As equipes de red team deveriam receber lições de incidentes, e denunciantes precisam de rotas protegidas quando o relato formal falha.
As recomendações de setembro de 2026 são claras: padronizar a documentação mantendo testes específicos de domínio; exigir acesso independente em alta capacidade ou escala; conectar limiares a portões predeterminados; exigir o relato de incidentes graves cobertos e quase-acidentes; proteger detalhes sensíveis; e publicar evidência agregada suficiente para a responsabilização.
Nenhuma avaliação prova que uma futura AGI está sob controle. Essas práticas, em vez disso, tornam a incerteza legível e restringem a implantação com base na evidência disponível agora. Seu sucesso deveria ser julgado por descobrirem problemas cedo, mudarem decisões, e prevenirem recorrência — não por quantos parâmetros de referência ou documentos de política uma organização produz.