Phase 18 - Lesson 10

Controle de IA — Segurança Apesar da Subversão

Greenblatt, Shlegeris, Sachan, Roger (Redwood Research, arXiv:2312.06942, ICML 2024). O controle reformula a questão de segurança: dado um modelo forte não confiável U que pode estar se otimizando de forma adversarial contra você, quais protocolos permitem extrair trabalho útil limitando a probabilidade de um resultado inaceitável? Os recursos são um modelo fraco confiável T, um orçamento de trabalho humano confiável H e a capacidade de editar as saídas de U. Dentro desse enquadramento, a Edição Confiável (Trusted Editing) domina de forma Pareto o Monitoramento Não Confiável (Untrusted Monitoring) em tarefas de backdoor de código. O enquadramento herda suposições de pior caso da engenharia de segurança: a segurança é a probabilidade de que um U escolhido de forma adversarial não consiga causar um resultado inaceitável concreto, medida sob a pressão de uma red team que atua no lugar de U.

Tipo: Aprender Linguagens: Python (stdlib, fronteira de segurança vs utilidade na tarefa de backdoor de código) Pré-requisitos: Fase 18 · 07 (agentes adormecidos), Fase 18 · 08 (esquematização / scheming), Fase 18 · 09 (fingimento de alinhamento) Tempo: ~75 minutos

Objetivos de Aprendizagem

  • Definir o modelo de ameaça do Controle de IA: modelo forte não confiável U, modelo fraco confiável T, orçamento humano confiável H.
  • Descrever o protocolo de Edição Confiável (Trusted Editing) e por que ele domina de forma Pareto o Monitoramento Não Confiável (Untrusted Monitoring) na tarefa de backdoor de código do ICML 2024.
  • Explicar a diferença entre alinhamento (U é confiável) e controle (U não é confiável, mas estamos seguros de qualquer forma).
  • Apontar os três limites do controle: os humanos não escalam, os modelos fracos confiáveis eventualmente ficam obsoletos/ficam para trás, o controle não produz modelos fortes confiáveis.

O Problema

As Lições 7 a 9 estabelecem que um modelo de fronteira pode ser enganosamente alinhado, conspirador (scheming) ou fingir alinhamento. A questão de segurança se reformula: podemos extrair trabalho útil de um modelo no qual não confiamos, sem dar a ele a oportunidade de causar resultados inaceitáveis? Este é o problema do controle, e ele é estruturado como a segurança clássica: assuma um adversário no pior caso, projete um protocolo e meça a taxa de sucesso do adversário sob a pressão de uma red team.

O Conceito

O modelo de ameaça

O controle assume:

  • U — modelo forte não confiável (untrusted). Capaz. Possivelmente adversarial (a avaliação o trata como se fosse).
  • T — modelo fraco confiável (trusted). Menos capaz, mas sabemos que não é adversarial.
  • H — trabalho humano confiável (human). Orçamento pequeno; não escala.

O sistema deve produzir saídas úteis usando U. O adversário tenta causar um resultado inaceitável concreto (por exemplo, um backdoor no código entregue) enquanto mantém uma fração de trabalho legítimo útil para passar pelos limites de utilidade.

O controle desiste de confiar em U. Ele pergunta quais protocolos mantêm a segurança diante da falta de confiança em U.

A tarefa de backdoor do ICML 2024

Os prompts são problemas de codificação de nível de competição. U produtos uma solução candidata. Um oráculo oculto sinaliza se a solução contém um backdoor (uma entrada específica que faz o código produzir uma saída errada). A red team controla U e tem permissão para ver todos os detalhes internos do protocolo. O protocolo deve maximizar a taxa de problemas resolvidos, mantendo a taxa de backdoors entregues abaixo de um limite.

Comparação de quatro protocolos

  • Linha de base (Baseline): envia a saída de U diretamente. Utilidade maximizada. Segurança mínima.
  • Auditoria antecipada (Upfront auditing): usa H em todas as saídas. Segurança maximizada. Orçamento esgotado rapidamente.
  • Monitoramento Não Confiável (Untrusted Monitoring): uma segunda instância de U avalia a saída da primeira instância; H audita as saídas sinalizadas. Risco: as duas instâncias de U podem coludir.
  • Edição Confiável (Trusted Editing): T edita a saída de U em cada consulta. Se T não estiver confiante, direciona para H.

Greenblatt et al. constatam que a Edição Confiável domina de forma Pareto o Monitoramento Não Confiável: maior utilidade em cada nível de segurança.

Por que a Edição Confiável vence

O Monitoramento Não Confiável exige que a segunda instância de U não consiga coordenar com a primeira. A colusão é possível por meio de pistas esteganográficas ou priors de treinamento compartilhados. O protocolo precisa investir orçamento em resistência à colusão (parafraseamento, ofuscação), o que reduz o sinal do monitor. A Edição Confiável evita totalmente a colusão porque T é confiável — qualquer edição que T proponha, por premissa, não é adversarial. O custo é que T é menos capaz, portanto pode rejeitar em excesso ou deixar passar backdoors sutis.

Os quatro eixos do protocolo

  1. Qual papel U desempenha: apenas produtor, monitor ou ambos.
  2. Qual papel T desempenha: editor, monitor ou reamostrador.
  3. Como H é alocado: auditoria uniforme, auditoria aleatória ou auditoria direcionada por sinalização.
  4. Quanto compute o protocolo gasta em resistência à colusão.

Alinhamento vs controle

  • Alinhamento: "é seguro confiar em U?" As Lições 2, 4, 5, 6, 7, 8, 9 tratam disso.
  • Controle: "podemos usar U com segurança sem confiar nele?" Lição 10.

O alinhamento é uma propriedade do modelo. O controle é uma propriedade do protocolo de implantação. O controle não produz modelos alinhados; ele produz o uso seguro de modelos possivelmente não alinhados. Ambas as agendas são necessárias.

Três limites fundamentais

  • Os humanos não escalam. O orçamento H é limitado pelo número de humanos dispostos a auditar saídas complexas de IA.
  • Modelos fracos confiáveis eventualmente ficam para trás. Quando T é muito mais fraco que U, o sinal de edição de T torna-se ruído.
  • Controle não é alinhamento. Protocolos que funcionam no ASL-3 (Lição 18) podem não funcionar no ASL-4 — se U puder manipular T ou raciocinar sobre a distribuição de auditoria de H, o controle falha.

O desenvolvimento em 2025

UK AISI e Redwood colaboram em Casos de Segurança de Controle (Control Safety Cases) (metr.org / redwoodresearch.org 2025): um caso de segurança de controle argumenta que, sob suposições de pior caso sobre U, o protocolo limita a probabilidade de um resultado inaceitável. Os casos de segurança (Lição 18) herdam o enquadramento de controle.

Onde isso se encaixa na Fase 18

As Lições 6 a 9 descrevem a ameaça (o engano é possível). A Lição 10 descreve o paradigma defensivo sob a suposição de que a ameaça é real. A Lição 11 descreve o paradigma ofensivo complementar (tornar U confiável por meio de supervisão escalável).

Use-o

code/main.py simula os quatro protocolos em uma tarefa de backdoor simples. U produz saídas; uma fração contém backdoors (política da red team). T aprova ou edita. H é acionado dentro de um orçamento. Você pode variar o orçamento e o parâmetro de colusão para reproduzir a fronteira de Pareto apresentada na Figura 2 de Greenblatt et al. 2024 (o formato, não os números).

Envie

Esta lição produz outputs/skill-control-protocol-audit.md. Dada a descrição de um protocolo de implantação, ela identifica as funções de U / T / H, nomeia os vetores de colusão e estima a posição do protocolo na fronteira utilidade-segurança sob pressão de uma red team.

Exercícios

  1. Execute code/main.py. Reproduza a fronteira utilidade-segurança para a Edição Confiável vs Monitoramento Não Confiável. Identifique o regime de orçamento em que a premissa de colusão do Monitoramento Não Confiável se torna essencial.

  2. Adicione um novo protocolo: "T faz reamostragem com temperatura baixa e, em seguida, U edita a saída de T". Meça sua posição na fronteira. Por que isso falha de forma mais catastrófica do que a Edição Confiável?

  3. O artigo de 2024 assume que U pode ver o protocolo. Projete um protocolo que oculte de U quais saídas estão sendo auditadas. O que esse protocolo exige da infraestrutura de implantação?

  4. Leia a Seção 7 de Greenblatt et al. 2024 (colusão). Proponha uma medida de resistência à colusão e explique seu custo de utilidade esperado.

  5. Articule um caso de segurança de controle para uma implantação que utiliza U = classe GPT-4, T = classe GPT-3.5, H = 1% das saídas auditadas. Identifique a suposição mais forte da qual o caso depende.

Termos-chave

Termo O que as pessoas dizem O que realmente significa
Controle de IA "segurança sob subversão" Projeto de protocolo que limita resultados inaceitáveis sob um U de pior caso
Modelo não confiável (U) "o modelo forte" O modelo capaz do qual queremos extrair trabalho, mas em quem não confiamos
Modelo confiável (T) "o modelo fraco" Um modelo mais fraco, sabidamente não adversarial, usado como editor/monitor
Humano confiável (H) "o orçamento de auditoria" Trabalho especializado limitado; caro; o sinal de verdade fundamental
Edição Confiável "T edita U" Protocolo onde T funciona como filtro/portão nas saídas de U; H é acionado em saídas ambíguas
Monitoramento Não Confiável "U monitora U" Protocolo onde uma segunda instância de U avalia as saídas; resistente à colusão apenas com investimento extra
Caso de segurança de controle "o argumento formal" Argumento escrito de que um protocolo limita o sucesso do adversário sob um U de pior caso

Leitura Adicional

0 lifetime access. Curriculum based on AI Engineering from Scratch by Rohit Ghumare (MIT, used under attribution).