Limiares de risco precisam de um mecanismo de medição, não de um corte

Um white paper do Center for Long-Term Cybersecurity da UC Berkeley argumenta que os limiares de ciber-risco por IA extraídos dos frameworks de segurança dos laboratórios de fronteira (OpenAI, Anthropic, DeepMind, Meta) falham porque são baseados em capacidades, são vagos e estão desligados do dano real. Os autores propõem redes bayesianas que convertem «este modelo cruza uma linha?» em «qual a probabilidade de causar dano em condições reais?» — e esse movimento, de um corte estático para um mecanismo medido continuamente, é exatamente o que um limiar defensável exige.

O limiar não é uma linha que se cruza; é uma medição que se mantém

Os frameworks de segurança de IA de fronteira convergem num punhado de «elementos de limiar» — automação de ataques de várias etapas, descoberta de zero-days, habilitação de atacantes pouco qualificados — e depois anexam benchmarks de capacidade a cada um. A crítica central do white paper de Berkeley é que esses cortes são determinísticos num sistema fundamentalmente probabilístico. Um modelo que «pode» descobrir um zero-day num benchmark não causa dano por esse facto; a mesma capacidade é benigna ou catastrófica conforme o acesso, a postura do defensor e a economia do atacante. Um limiar expresso como uma linha de capacidade ignora cada uma dessas variáveis mediadoras.

É o mesmo modo de falha que nomeamos com Theorem 3 nos 21 papers: uma propriedade é garantida exatamente quando o seu mecanismo está implementado e a medir. [ORIGINAL DATA] Theorem 3 (a property is guaranteed exactly when its mechanism is implemented and measuring) é decisivo aqui porque «ciber-risco inaceitável» é uma propriedade de um sistema sociotécnico, não de um modelo. Declarar um corte de capacidade não implementa a propriedade; afirma-a. A propriedade — que o dano se mantenha abaixo de um nível aceite — só existe quando algo está a produzir continuamente a medição que te diria que foi cruzado. Uma linha que ninguém mede não é um limiar; é uma esperança.

O white paper reformula a pergunta de «este modelo cruza um limiar?» para «qual a probabilidade de causar dano em condições reais?». É o reenquadramento correto, e tem uma consequência estrutural: o limiar torna-se um estado mantido, não um marco ultrapassado. Instrumentas o deployment, alimentas evidência num modelo probabilístico e manténs o posterior abaixo do nível aceite — ou restringes o deployment. O corte é a saída de um mecanismo em funcionamento, nunca um substituto dele.

Capacidades não são risco; o contexto é

O white paper afirma a crítica de forma direta: capacidades ≠ risco. A mesma capacidade pode ser benigna ou catastrófica conforme o contexto, o acesso e as defesas. Uma capacidade de geração de phishing atrás de um perímetro de autenticação empresarial com um filtro de email maduro é um risco diferente da mesma capacidade exposta a qualquer um com um número de telefone e um agravio. Os frameworks de fronteira eludem isto indexando sobre a capacidade e deixando o contexto implícito.

Dois defeitos adicionais agravam o problema. Primeiro, a linguagem é vaga — «aumento significativo» aparece nos frameworks sem uma linha de base, uma unidade ou um método. «Significativo» em relação a quê, medido como, por quem, atualizado quando? Um termo de limiar que não pode ser povoado é um artefacto de conformidade, não um controlo. Segundo, os frameworks focam-se em cenários extremos e improváveis — exploração autónoma de ponta a ponta de um alvo blindado — enquanto omitem as deslocações incrementais que realmente reconfiguram o equilíbrio ataque–defesa. A deriva lenta na economia do atacante, não o cenário cinematográfico, é onde o equilíbrio se inclina.

[UNIQUE INSIGHT] A razão pela qual os limiares de capacidade omitem a deriva incremental é que são declarações de um momento sobre um modelo, não medições longitudinais sobre um sistema. Um benchmark de capacidade é uma fotografia; o risco é um vídeo. A proposta de Berkeley — decompor o risco em variáveis, ligá-las através de dependências probabilísticas, alimentar com benchmark e red teaming e evidência do mundo real, e atualizar ao longo do tempo — é, em efecto, um pedido para começar a filmar. O limiar vive então na tendência do posterior, não numa única pontuação de benchmark.

Isto importa porque a regulamentação avança para o mesmo enquadramento. O white paper nota o alinhamento com a EU AI Act e o NIST Risk Management Framework, que pedem tratamento de risco contínuo e baseado em evidência em vez de uma declaração única. Um laboratório com apenas um corte de capacidade não pode responder à pergunta que esses frameworks realmente fazem: «Qual é o teu risco medido e qual é o teu mecanismo para o manter abaixo do nível aceite?»

A rede bayesiana é o mecanismo de medição

A proposta construtiva do white paper são as redes bayesianas (BN): grafos probabilísticos que representam relações entre variáveis — capacidade de IA, comportamento do atacante, deteção da defesa, impacto económico — e que integram evidência diversa e se atualizam continuamente à medida que as condições mudam. Ao contrário de um limiar estático, uma BN permite seguir quão perto um sistema está de cruzar uma fronteira de risco, porque a fronteira é uma região numa distribuição conjunta, não um único número num eixo.

É a parte do white paper que mais se liga a como pensamos o mecanismo. Uma BN não é uma predição no sentido coloquial; é um instrumento de medição. Diz, dado o que observámos, aqui está o posterior sobre as variáveis de dano, e aqui se move quando introduzimos um novo resultado de red team ou um novo relatório de incidente. O limiar é então uma política sobre esse posterior — «o deployment é restringido quando P(dano significativo) excede 0.X» — e a política é aplicável porque o posterior é reproduzível a partir da evidência e do grafo.

Três propriedades fazem da BN a forma certa para este trabalho, e cada uma mapeia para uma propriedade que procuramos em qualquer mecanismo de medição:

• Decomposição. Um risco de alto nível («a IA habilita phishing escalável») é decomposto em variáveis medíveis — domínio linguístico da IA, credibilidade do isco, taxa de deteção da defesa, suscetibilidade do alvo. Não se pode medir «risco de phishing» diretamente; podem-se medir os seus componentes. A decomposição é o que torna o risco legível para a evidência.
• Dependência. As variáveis estão ligadas através de probabilidades condicionais, não somadas independentemente. O sucesso do ataque depende conjuntamente da capacidade e da defesa, não de cada uma isoladamente. É por isso que um limiar só de capacidade falha: assume que a conjunta se pode ler de uma marginal.
• Atualização. O posterior é função da evidência, e a evidência acumula-se. Uma BN é um instrumento longitudinal por construção; o posterior de ontem é o a priori de hoje. Isso é o que «monitorização dinâmica» significa operacionalmente, não como slogan.

O limite honesto que o próprio white paper nomeia é que estes modelos estão numa fase inicial: não há BNs validadas no mundo real à escala, nem conjuntos de dados padronizados para povoar as probabilidades, nem uma integração de governação clara — quem define os limiares, como são aplicados. Cito a própria secção «What's Missing» do white paper porque uma leitura honesta não a tapa. Um mecanismo de medição nunca calibrado contra resultados é uma hipótese sobre uma medição, não uma medição ainda. O mecanismo tem a forma certa; a base de evidência não está construída.

Como o caso de phishing converte «aumento significativo» num número

O caso de phishing do white paper (páginas 31–32) é onde a abstração se torna concreta. Uma rede bayesiana decompõe o risco de engenharia social em nós — «domínio linguístico da IA», «credibilidade do isco», «taxa de deteção da defesa», «suscetibilidade do alvo» — que conjuntamente determinam resultados como se um empregado abre um email malicioso. Conceitos vagos tornam-se sinais quantificáveis porque cada nó é algo para o qual podes produzir evidência: uma pontuação de domínio linguístico de um benchmark, uma taxa de deteção de um teste de filtro de email, uma estimativa de suscetibilidade de uma campanha de simulação de phishing.

O caso faz duas coisas ao mesmo tempo, e vale a pena separá-las. Primeiro, mostra que um termo de risco como «aumento significativo na eficácia do phishing» pode ser decomposto em variáveis com unidades. Segundo, mostra que o aumento é uma mudança numa distribuição conjunta, não numa única pontuação. Uma melhoria de 10% no domínio linguístico não se traduz linearmente em 10% mais emails abertos; traduz-se através da taxa de deteção e do nó de suscetibilidade, e a tradução é diferente numa empresa defendida do que num pequeno negócio indefeso.

Esta é a diferença entre um benchmark de capacidade e um limiar de risco expresso com precisão. Um benchmark diz que o modelo melhorou numa tarefa. Uma BN diz quanto essa melhoria moveu o posterior de dano sob as condições em que realmente fazes deployment. O primeiro é necessário; o segundo é o que um limiar exige. A contribuição do white paper é mostrar que o segundo é construível, não apenas desejável — e mostrar, com honestidade, que o trabalho de o povoar à escala mal começou.

O que isto mapeia em Everythink

Lemos este white paper através de uma lente específica, e vale a pena ser explícito para que o leitor possa verificar o nosso raciocínio em vez de o aceitar por fé.

[PERSONAL EXPERIENCE] O HAI Engine está em produção desde 2016, e a lição de nove anos a operar um sistema de forecasting multiagente é que uma previsão que não podes atualizar é uma previsão que não devias publicar. As nossas Sisters produzem rascunhos de cenários; o Oracle funde-os num conjunto calibrado cujas probabilidades somam um e cuja entropia é seguida em nats. Esse conjunto é um instrumento de medição, não uma predição coloquial: reproduzível a partir das suas entradas, atualizado à medida que a evidência se acumula, errado de forma rastreável quando erra. A proposta de BN de Berkeley tem a mesma forma aplicada a um domínio diferente — variáveis de dano em vez de probabilidades de cenário, evidência de red team em vez de feeds de sinais — mas a mesma insistência em que o número só é fiável se o mecanismo que o produziu for inspetável.

O princípio estrutural que partilhamos é o que chamamos «the space is the router»: a topologia network→community→room encaminha um pedido antes de qualquer coisa responder. O encaminhamento é um mecanismo que produz um resultado medível — que contexto viu que sinal — e isso é o que torna a previsão auditável. Um limiar sem uma topologia de encaminhamento é um número atado a um modelo; um limiar dentro de uma topologia de encaminhamento é um número atado a um caminho através de um sistema, que é o único lugar onde o dano realmente vive. O dano é contextual, e o contexto é uma topologia.

As nossas etiquetas de honestidade existem pela mesma razão pela qual o white paper insiste na evidência sobre a afirmação. Onde temos um mecanismo em produção dizemos Production ✅ — o HAI Engine, Social, Campaigns, Whitelabel Network, World Monitor, as Sisters, o Oracle. Onde o mecanismo é parcial dizemos Partial ⚠️ — Matchmaking, Marketplace, Calendar. Onde é um roadmap dizemos Roadmap 🔵 — Wallet & Token, Super App, Community Credit — e não prometemos resultados para esses porque são pre-revenue e, para os componentes de token, estão sujeitos a revisão Howey. O ponto não é o glifo; o ponto é que um leitor pode mapear cada afirmação a um estado de maturidade e cobrar-nos por isso. É a mesma disciplina que o white paper pede aos laboratórios de fronteira: parar de afirmar limiares, começar a produzir as medições que os justificariam.

Somos explícitos sobre o limite de âmbito porque o white paper também o é. Everythink opera apenas em contextos civis e defensivos. Um mecanismo de limiar de risco honesto sobre a capacidade ofensiva não é uma licença para construir ferramenta ofensiva; é uma razão para saber onde está a linha defensiva e instrumentá-la. O framework de Berkeley é útil para nós precisamente porque torna a postura defensiva mensurável em vez de retórica.

A lacuna de governação que o white paper nomeia com honestidade

A secção mais útil do white paper pode ser a sua própria lista «What's Missing», porque é a parte que impede a proposta de se tornar outra afirmação de capacidade. Ao framework faltam modelos bayesianos validados no mundo real à escala, conjuntos de dados padronizados para povoar as probabilidades, orientação clara de integração de governação e benchmarks empíricos que liguem a capacidade do modelo ao impacto cibernético real. Domínios mais complexos — exploração autónoma, ataques à cadeia de fornecimento — não estão operacionalizados em profundidade.

Acrescentaríamos uma lacuna que o white paper intui mas não detalha: um mecanismo de limiar só é tão fiável quanto a independência da evidência que o alimenta. Um laboratório que povoa a sua própria BN com os seus próprios resultados de red team, contra as suas próprias linhas de base, sem verificação externa, construiu um instrumento que relata o que o laboratório precisa que ele relate. O pedido de conjuntos de dados padronizados é em parte um pedido de evidência que não provenha toda da parte que é medida. É a questão de governação que o framework deixa em aberto, e é a correta para deixar em aberto — a resposta é institucional, não técnica.

A consequência pragmática é que um mecanismo de limiar que valha a pena para governar é aquele que um terceiro pode reproduzir: grafo publicado, evidência nomeada, a priori declarados, posterior recomputável. Uma BN que cumpra essas condições é auditável da forma como um regulador pode realmente usar; uma que não cumpra é uma afirmação proprietária disfarçada de medição.

Conclusões principais

• Um corte de capacidade não é um limiar de risco; é uma afirmação de um momento sobre um modelo que ignora o contexto onde o dano vive.
• O white paper de Berkeley reformula a pergunta de «este modelo cruza uma linha?» para «qual a probabilidade de causar dano em condições reais?» — um movimento de um marco estático para uma medição mantida.
• As redes bayesianas são o mecanismo de medição proposto: decompor o risco em variáveis, ligá-las através de probabilidades condicionais, alimentar com benchmark e red teaming e evidência do mundo real, e atualizar continuamente.
• O caso de phishing mostra que termos vagos como «aumento significativo» podem ser decompostos em nós com unidades — mas o trabalho de povoar estes modelos à escala mal começou, e o white paper diz-no.
• Theorem 3 generaliza o princípio: uma propriedade (risco aceitável) é garantida exatamente quando o seu mecanismo (um posterior continuamente atualizado e inspetável) está implementado e a medir.
• Um mecanismo de limiar só é governável se um terceiro o puder reproduzir — grafo publicado, evidência nomeada, a priori declarados, posterior recomputável.

Perguntas frequentes

Por que é que um benchmark de capacidade não é um limiar de risco? Um benchmark mede o que um modelo pode fazer num teste; o risco é o que acontece quando essa capacidade encontra um defensor, um atacante e um alvo no mundo real. O benchmark é uma entrada para uma estimativa de risco; não é a estimativa. O ponto do white paper é que tratar a marginal como se fosse a conjunta é o erro central dos limiares dos frameworks de fronteira.

O que é que uma rede bayesiana acrescenta que uma checklist não? Uma checklist regista que um controlo existe; uma BN regista quanto o controlo moveu o posterior de dano. A primeira é binária e estática; a segunda é contínua e atualizável. Uma BN também torna as dependências explícitas — o sucesso do ataque depende conjuntamente da capacidade e da defesa — o que uma checklist não pode representar sem se tornar a BN em forma de prosa.

O framework de Berkeley está pronto para governar hoje? Não, e o white paper diz-o diretamente. Faltam-lhe modelos validados à escala, conjuntos de dados padronizados e integração de governação clara. É uma metodologia — uma forma repetível de operacionalizar o risco — não um instrumento acabado. Tratá-lo como acabado repetiria o erro que critica: afirmar uma propriedade em vez de a medir.

Como é que isto se liga ao Theorem 3? Theorem 3 diz que uma propriedade é garantida exatamente quando o seu mecanismo está implementado e a medir. «Ciber-risco aceitável» é uma propriedade de um deployment, não de um modelo. A garantia existe apenas quando uma BN (ou instrumento equivalente) está em funcionamento, alimentada e inspetável. Declarar um corte não implementa nenhum mecanismo e portanto não garante nada.

Para que é que a Everythink usa isto? Usamos o mesmo princípio estrutural — um posterior reproduzível e atualizável produzido por um mecanismo inspetável — no HAI Engine e no Oracle, para forecasting em vez de limiares de ciber-risco. A topologia de encaminhamento (network→community→room) é o que torna as nossas previsões contextuais e auditáveis. Não construímos ferramenta ofensiva; o valor de uma linha defensiva mensurável é saber onde ela está.

Se este enquadramento for útil, o trabalho que se segue é operacional: escolhe um risco, decompõe-no, liga as variáveis, nomeia a evidência e começa a atualizar. Cria a tua rede, ou lê os papers.

Sources

• 2026 — UC Berkeley Center for Long-Term Cybersecurity, «Toward Risk Thresholds for AI-Enabled Cyber Threats» (white paper, janeiro 2026; resumo publicado pela AIGL, março 2026) — https://www.aigl.blog/toward-risk-thresholds-for-ai-enabled-cyber-threats-2/