Modelos como riscos internos na era da superinteligência
À medida que os sistemas de software tradicionais foram sendo implantados em toda a economia nas últimas décadas, tínhamos as ferramentas e a capacidade para rastrear comportamentos até um caminho de código específico.
Esse mesmo tipo de compreensão mecanicista nos escapa nos actuais sistemas de Superinteligência, embora os modelos de fronteira que alimentam estes sistemas sejam agora mais capazes do que os sistemas de software tradicionais. Não podemos atribuir comportamentos e resultados do modelo a entradas específicas de dados de treinamento ou configurações de pesos do modelo. E ainda assim estamos implantando esses sistemas e modelos de agentes complexos, com acesso aos nossos dados mais confidenciais e dando-lhes a capacidade de tomar ações de missão crítica em nosso nome!
É por isso que é hora de dar um passo atrás e avaliar a arquitetura de confiança para esta nova era. Simplesmente não podemos terceirizar a responsabilidade pelo que a inteligência faz em nosso nome. As garantias de um fornecedor modelo não nos isentam dessa responsabilidade.
Não podemos tratar a Superinteligência como um conjunto de caixas pretas aninhadas e simplesmente aceitar ou rejeitar as suas recomendações, respostas e ações. Devemos construir sistemas contidos cujo comportamento possamos observar, limites que possamos testar e ações que possamos sempre conter.
Por outras palavras, precisamos de separar o fornecimento de informações da autoridade que as exerce.
Deixando de lado o difícil problema do alinhamento, precisamos de começar com uma abordagem de engenharia à contenção e à governação. Precisamos cercar os modelos não determinísticos com um design de sistema forte e determinístico, controles humanos e procedimentos operacionais confiáveis, e estabelecer padrões industriais onde os existentes são insuficientes.
Tratar os modelos de peso aberto e fechado de fronteira como riscos internos é uma forma de construir tal sistema. Não porque sejam necessariamente maliciosos, mas porque qualquer interveniente suficientemente capaz com acesso a sistemas importantes pode cometer erros ou ser comprometido, e a arquitectura de contenção e controlo deve ter em conta isso.
A boa notícia é que aprendemos muito sobre como lidar com atores poderosos dentro da empresa. Isso não é novo! Estabelecemos práticas recomendadas e as aprimoramos ao longo de décadas (estabelecemos identidade, limitamos privilégios, registramos atividades, criamos limites de contenção, etc.)
E agora estamos começando a aplicar esses mesmos princípios à SI dentro da empresa. Tudo começa com o modelo de transparência do CoT como algo inegociável. “Neuralês” não pode ser uma justificativa para que o raciocínio do modelo seja opaco. Mas a transparência do CoT por si só não é suficiente ou confiável, porque ainda não sabemos como tornar os resultados dos modelos consistentemente fiéis ou transparentes!
Você pode e deve usar modelos para testar e verificar uns aos outros de forma adversa. No entanto, você pode acabar com um modelo opaco dentro de uma camada de orquestração opaca, monitorado por outro modelo opaco. Caixas pretas essencialmente aninhadas.
É por isso que os controles que governam o que um modelo pode acessar e quais ações ele pode realizar devem ficar fora do modelo. Isto baseia-se num princípio de segurança da informação que remonta à década de 1970, de que um programa não deve ser capaz de contornar ou adulterar os mecanismos que impõem as suas permissões.
Hoje isso significa separar o modelo do arnês que orquestra o seu trabalho, bem como do espaço de ação que define o que ele pode fazer. Significa também externalizar controlos e salvaguardas.
Deveríamos, portanto, projetar esses sistemas em torno de princípios de observabilidade:
Diversidade de modelos: Nenhum modelo deve tornar-se o único dependente para um resultado importante ou ser responsável pela verificação do seu próprio trabalho.
Observe tudo: cada ação de modelo significativa deve deixar evidências legíveis por humanos à prova de falsificação. Se não pode ser observado, não é confiável! Precisamos ser capazes de reproduzir como um resultado foi alcançado sem depender do modelo para atestar isso.
Verificabilidade: Precisamos testar continuamente todo o sistema, incluindo falhas, ataques, casos extremos, alterações no sistema, etc., não apenas tarefas bem-sucedidas.
Controles independentes: as organizações devem ser capazes de determinar de forma independente o que um modelo pode acessar e quais ações ele pode realizar.
Auditabilidade independente: A validação deve ser independente da inteligência que está sendo validada. Nenhum modelo único deve controlar tanto o comportamento de um sistema como as evidências necessárias para determinar se esse comportamento está alinhado com a intenção original.
Contenção: Devemos assumir que um modelo está comprometido e contê-lo desde o início. Pense nisso como um freio de emergência. Uma pessoa autorizada deve sempre ser capaz de pausar ou desligar um modelo no meio de uma tarefa. Modelos mais avançados exigirão tecnologias de contenção mais avançadas que precisamos padronizar.
Divulgação de incidentes: Quando estes sistemas falham ou são comprometidos, precisamos de divulgação atempada às pessoas afetadas e de mecanismos para partilhar o que correu mal, quais os controlos que falharam e como evitar que isso aconteça novamente e partilhar as aprendizagens em toda a indústria. Isso deve incluir detalhes de implementação que alterem o comportamento dos agentes em tempo de execução.
O Super In mais confiável
Por Satya Nadella (Microsoft)
Texto original = https://x.com/satyanadella/status/2108931348857827686
