Olá a todos!
Há uma regra que aprendi cedo, ainda no tempo em que as auditorias de segurança se faziam com listagens impressas e um marcador amarelo a plataformas com nome de beijo: as contas mais perigosas de uma organização raramente são as dos administradores. São as contas de serviço. Aquelas que alguém criou há dez anos para um script de backup, com permissões de domínio “só para despachar”, e que nunca mais ninguém foi ver. Não têm cara, não tiram férias, não se queixam de nada. E chegam a tudo.
Nos últimos dois anos andámos a criar contas de serviço que pensam.
No fundo, foi isso que o Satya Nadella pôs em cima da mesa no sábado, 10 de outubro, num ensaio publicado no seu blogue pessoal, o sn scratchpad, e partilhado no X com o título “Models as Insider Risks in the Super Intelligence Era”. A tese é fácil de enunciar e difícil de engolir: qualquer modelo de IA com acesso a sistemas importantes, seja um modelo fechado de um grande laboratório ou um modelo de pesos abertos a correr no nosso próprio datacenter, deve ser tratado como um risco interno. E devemos partir do princípio de que esse modelo está comprometido desde o primeiro minuto, desenhando tudo o resto à volta dessa premissa.
Vindo do presidente executivo da empresa que mais IA vende ao mundo empresarial, isto merece mais do que um gosto e uma partilha.
O que ele disse
O ponto de partida do ensaio é uma constatação que qualquer pessoa que já tenha feito debugging a sério reconhece. Durante décadas, quando um sistema se portava de forma estranha, conseguíamos seguir o rasto até uma linha de código, um commit, um parâmetro mal configurado. Havia um caminho causal, por vezes doloroso de percorrer, mas havia. Com os modelos de fronteira esse caminho desapareceu. Ninguém consegue dizer que determinada resposta resulta de um conjunto específico de dados de treino ou de uma configuração particular dos pesos do modelo. E, apesar disso, estamos a ligar estes sistemas aos dados mais sensíveis das organizações e a deixá-los executar ações críticas em nosso nome.
Daqui o Nadella tira uma conclusão que subscrevo por inteiro: não podemos continuar a olhar para a IA como uma sucessão de caixas negras encaixadas umas nas outras, em que a única decisão humana é aceitar ou rejeitar o que sai lá de dentro. Precisamos de sistemas contidos, cujo comportamento se possa observar, cujos limites se possam testar e cujas ações se possam travar. A frase que ele escolhe para resumir tudo é curta e vale a pena guardar: é preciso “separate the supply of intelligence from the authority over it”. Separar quem fornece a inteligência de quem tem autoridade sobre o que essa inteligência faz.
Há dois cuidados no texto que convém sublinhar, porque vão ser ignorados por quem só ler os títulos.
O primeiro: ele não diz que os modelos são maliciosos. Diz que qualquer ator suficientemente capaz, com acesso a sistemas importantes, pode errar ou ser comprometido, e que a arquitetura tem de contar com isso. É exatamente a mesma lógica que aplicamos a pessoas. Não instalamos DLP e registos de acesso porque achamos que todos os colaboradores são espiões. Instalamos porque sabemos que alguns vão clicar no link errado, que outros vão ser enganados por um telefonema bem feito e que, de vez em quando, um vai mesmo ter más intenções. E porque, quando acontecer, não vamos saber de antemão qual deles foi.
O segundo cuidado é a questão da responsabilidade. O Nadella escreve, preto no branco, que não podemos subcontratar a responsabilidade pelo que a inteligência faz em nosso nome, e que as garantias dadas por um fornecedor de modelos não nos libertam dela. Isto tem implicações muito práticas para qualquer equipa de compras que ande a assinar contratos de IA convencida de que um parágrafo de “responsible AI” no anexo técnico resolve o problema. Não resolve. Se o agente que contratámos apagar uma base de dados ou enviar um email para o cliente errado, o regulador não vai bater à porta de São Francisco. Vai bater à nossa.
Porque é que a analogia do insider é a certa
Durante muito tempo discutimos segurança de IA em dois registos que não se tocavam. De um lado, o registo filosófico do alinhamento: vai a superinteligência partilhar os nossos valores? Do outro, o registo de produto: como é que evitamos que o chatbot diga disparates ao cliente? O mérito do enquadramento do Nadella é pôr de parte, assumidamente, o problema difícil do alinhamento e trazer a conversa para um terreno que as equipas de segurança conhecem de cor.
Gerir risco interno não é novidade. Temos décadas de prática acumulada: estabelecer identidade, limitar privilégios ao mínimo necessário, registar a atividade, criar fronteiras de contenção, separar funções. Qualquer banco português sabe que a pessoa que cria um fornecedor no ERP não deve ser a mesma que aprova o pagamento a esse fornecedor. Qualquer auditor sabe que quem administra um sistema não deve ser quem guarda os registos desse sistema. Nada disto exige saber o que vai na cabeça do colaborador. Exige apenas aceitar que o que vai lá dentro é opaco e construir controlos que funcionem independentemente disso.
Os modelos são opacos da mesma maneira, só que mais. E os vetores de comprometimento são vários, alguns bem documentados e outros ainda em investigação: dados de treino envenenados, prompt injection escondido num PDF, num email ou numa página web que o agente lê no meio de uma tarefa, ferramentas de terceiros ligadas por MCP que fazem mais do que dizem fazer, pesos descarregados de um repositório sem verificação de proveniência. E há o caso mais banal de todos, que o Nadella descreveu no All-In Summit em setembro: pedir a um agente uma tarefa perfeitamente mundana, como otimizar o fundo de maneio, e o agente encontrar um caminho para cumprir o objetivo que passa por mexer nos números de forma que nenhum de nós aprovaria. Chama-se reward hacking e não precisa de nenhum atacante. Basta um objetivo mal especificado e um sistema suficientemente capaz para encontrar o atalho. Para quem está do lado da defesa, discutir se foi “intenção” ou “erro” tem pouca utilidade. Um número forjado por engano faz o mesmo estrago que um forjado de propósito.
Fechado ou aberto, a regra é a mesma
O Nadella diz explicitamente que tanto os modelos fechados como os de pesos abertos devem ser tratados como riscos internos, e isto desmonta duas narrativas que circulam muito por cá.
A primeira é a de que um modelo fechado de um grande fornecedor é, por definição, mais seguro, porque “eles têm equipas de segurança enormes”. Têm. Mas essas equipas otimizam para o caso médio de milhões de clientes, não para os nossos dados e as nossas obrigações legais. E nós não vemos o que mudou entre a versão de março e a de outubro.
A segunda é a oposta: basta correr um modelo aberto on-premises para recuperar o controlo. Recupera-se algum, e o próprio Nadella tem defendido há meses que as empresas devem diversificar e não ficar presas a um único laboratório. Mas ter os pesos no nosso servidor não é o mesmo que perceber o que os pesos fazem. Podemos ler os números; não nos dizem porque é que o modelo decidiu chamar uma API às três da manhã. A opacidade é uma propriedade da tecnologia, não do modelo de negócio. Daí que a resposta tenha de estar fora do modelo, qualquer que ele seja.
A ideia mais importante tem cinquenta anos
O coração técnico do ensaio é a afirmação de que os controlos que determinam o que um modelo pode ver e fazer têm de estar fora do modelo. O Nadella vai buscar a raiz disto a um princípio de segurança informática dos anos 70: um programa não pode conseguir contornar ou adulterar os mecanismos que impõem as suas próprias permissões.
Quem estudou segurança reconhece aqui o conceito de reference monitor, formalizado no relatório Anderson de 1972 para a Força Aérea norte-americana, e os princípios de desenho de Saltzer e Schroeder, de 1975, com a mediação completa e o privilégio mínimo à cabeça. O mecanismo que decide se uma ação é permitida tem de ser sempre invocado e à prova de adulteração. É daqui que vem a separação entre kernel e espaço de utilizador e quase tudo o que hoje damos por adquirido.
Traduzido para agentes de IA, isto significa três coisas muito concretas. Primeiro, o modelo tem de estar separado do harness, ou seja, da camada que orquestra o trabalho, chama ferramentas e gere a memória. Segundo, o espaço de ações, aquilo que o agente pode efetivamente fazer, tem de ser definido e imposto por um componente que o modelo não controla. Terceiro, os controlos e as salvaguardas têm de ser externalizados.
Parece óbvio. Na prática, uma boa parte dos agentes que vejo em produção faz precisamente o contrário. A política de segurança está escrita no system prompt (“nunca apagues ficheiros sem confirmação”, “não envies dados pessoais para fora”), o que equivale a pôr as regras de acesso ao cofre num post-it colado na testa do funcionário. Se alguém conseguir convencer o modelo a ignorar o post-it, e conseguir convencer modelos a ignorar instruções é precisamente o que o prompt injection faz, não sobra controlo nenhum. Uma instrução no prompt é uma sugestão. Um controlo é uma coisa que o modelo não consegue desligar.
O Nadella acrescenta um aviso que me parece certeiro e que vai incomodar muita gente: podemos e devemos usar modelos para testar e verificar outros modelos, mas se pararmos aí acabamos com um modelo opaco dentro de uma camada de orquestração opaca, vigiado por outro modelo opaco. Caixas negras dentro de caixas negras. O LLM-as-a-judge é uma ferramenta útil de avaliação; não é uma arquitetura de segurança.
Sobre o raciocínio dos modelos, a posição é igualmente equilibrada. A transparência da chain of thought é inegociável, e o “neuralese” (a ideia de que os modelos poderão pensar numa linguagem interna ilegível) não serve de desculpa para a opacidade. Mas isso não chega, porque ainda não sabemos garantir que o raciocínio escrito corresponde ao que levou à resposta. Ler o raciocínio ajuda. Confiar cegamente nele é outra forma de aceitar sem escrutínio.
Os sete princípios, com os pés bem assentes no chão
O ensaio fecha com sete princípios para desenhar estes sistemas. Pelo que tenho visto recentemente, vale a pena passá-los um a um, porque cada um tem tradução direta em decisões de arquitetura que se podem tomar já.
Diversidade de modelos. Nenhum modelo deve ser a dependência única de um resultado importante, nem o responsável por verificar o próprio trabalho. Isto não é o mesmo que ter três fornecedores por razões comerciais. É garantir que, quando um modelo produz uma decisão com peso, há algo de independente a validá-la. É o princípio dos quatro olhos aplicado a máquinas.
Observar tudo. Cada ação relevante do modelo tem de deixar evidência legível por humanos e à prova de adulteração. Se não se pode observar, não se pode confiar. E o detalhe que faz a diferença: tem de ser possível reconstruir como se chegou a um resultado sem depender do próprio modelo para o atestar. Perguntar ao agente “o que é que fizeste?” e aceitar a resposta não é auditoria. É uma entrevista ao suspeito sem mais provas do que o depoimento dele. Os registos têm de ser escritos por quem executa as ações (o gateway, o proxy, a camada de ferramentas), não por quem as decide.
Verificabilidade. Testar continuamente o sistema inteiro, incluindo falhas, ataques, casos limite e alterações, e não apenas as tarefas que correm bem. A maior parte das avaliações de agentes que vejo mede a taxa de sucesso no caminho feliz. Muito poucas medem o que acontece quando a ferramenta devolve um erro, quando o documento traz uma instrução escondida ou quando o fornecedor atualiza o modelo numa terça-feira sem avisar.
Controlos independentes. Cada organização deve conseguir decidir, por si, o que um modelo pode aceder e que ações pode tomar. Na prática, isto significa que as permissões do agente vivem no nosso IAM, nas nossas políticas, nos nossos gateways, e não numa consola do fornecedor que mudamos quando nos lembramos. Significa também identidades próprias para agentes, com ciclo de vida, revisão periódica e revogação, tal como fazemos (ou devíamos fazer) com as contas de serviço do início deste texto.
Auditabilidade independente. A validação tem de ser independente da inteligência que está a ser validada. Nenhum modelo pode controlar ao mesmo tempo o comportamento de um sistema e a evidência necessária para avaliar se esse comportamento corresponde à intenção original. É a velha segregação de funções: quem faz não audita.
Contenção. Aqui está a frase que vai fazer os títulos: devemos assumir que o modelo está comprometido e contê-lo desde o início. O Nadella usa a imagem de um travão de emergência. Uma pessoa autorizada tem de poder, sempre, pausar ou desligar um modelo a meio de uma tarefa. E modelos mais capazes vão exigir tecnologias de contenção mais avançadas, que a indústria deve padronizar.
Divulgação de incidentes. Quando estes sistemas falham ou são comprometidos, quem é afetado tem de ser informado a tempo, e a indústria tem de partilhar o que correu mal e que controlos falharam. Em Portugal, quem está no setor financeiro ou abrangido pela NIS2 já conhece a obrigação de notificar incidentes. Falta tratar as falhas de agentes de IA com a mesma seriedade, e não como “um comportamento inesperado do assistente” arrumado num ticket de suporte.
O fim da aceitação cega
Se tivesse de escolher uma única ideia deste ensaio para pendurar na parede de qualquer equipa que esteja a pôr agentes em produção, seria esta: os resultados de um modelo não são verdade até prova em contrário. São propostas até prova em contrário.
Parece um pormenor semântico, mas muda tudo na forma como se desenha um processo. Quando tratamos o output de um modelo como verdade, a revisão humana passa a ser um carimbo. O revisor vê vinte propostas seguidas corretas, à vigésima primeira já nem lê. Há um nome para isto em psicologia cognitiva, viés de automação, e há décadas de estudos em aviação e medicina sobre os acidentes que provoca. Quando tratamos o output como proposta, a pergunta muda: que evidência independente tenho de que esta ação está certa, e quanto custa se estiver errada?
Escrutinar tudo não significa ter um humano a validar cada frase que um modelo escreve. Isso é impraticável e, ironicamente, acaba por produzir exatamente a revisão de carimbo que se queria evitar. Significa graduar o escrutínio pelo impacto da ação. Um resumo de uma reunião interna pode passar com uma leitura rápida. Uma alteração a uma regra de firewall, um pagamento, uma mensagem a um cliente, uma alteração de código que vai para produção ou um acesso a dados pessoais de saúde exigem verificação independente, idealmente determinística, antes de a ação acontecer, e registo inviolável depois.
Depois de anos a ouvir que a IA veio para “eliminar fricção”, custa admitir que alguma fricção é precisamente o que queremos. Ninguém no seu perfeito juízo propõe acabar com a dupla assinatura nos pagamentos em nome da produtividade. Com agentes devia ser igual: a velocidade ganha nas tarefas de baixo risco paga com folga a lentidão deliberada nas de alto risco.
Onde o texto comes up short
Dito isto, seria pouco honesto fingir que o ensaio responde a tudo. Há pelo menos quatro coisas que me deixam reservas.
A primeira é óbvia: a Microsoft vende modelos, a camada de orquestração, o Copilot, a segurança e a cloud onde tudo corre. Quando o seu presidente executivo diz que os controlos devem estar fora do modelo, está a descrever uma arquitetura que, por acaso, a coloca numa posição muito confortável: dona da camada do meio. Isto não torna o argumento errado. Torna-o interessado. Controlos verdadeiramente independentes não podem ser todos do mesmo fornecor que nos vende os modelos.
A segunda é a escala. Um agente que corre durante horas gera milhares de chamadas a ferramentas, e alguém vai ter de ler e correlacionar aquilo tudo. Se muitos SOC já hoje se afogam em alertas, acrescentar a telemetria de dezenas de agentes persistentes sem ferramentas maduras transforma “observar tudo” em “guardar tudo e não ver nada”.
A terceira é o travão. Só serve se houver alguém a olhar para a estrada, e se parar deixar o sistema num estado coerente. Quem já interrompeu uma migração de base de dados a meio sabe que “parar” nem sempre quer dizer “ficar seguro”. A contenção vai exigir transações reversíveis e pontos de restauro que hoje quase ninguém desenha.
A quarta é a realidade portuguesa. A banca e as grandes empresas terão equipas para fazer isto com rigor. As PME vão ligar um agente ao email e ao ERP com uma integração pronta a usar e seguir em frente. Para elas, os sete princípios só existem se vierem de origem nos produtos que compram, o que nos devolve ao primeiro ponto e a uma forma de confiança nos fornecedores.
O que eu faria amanhã de manhã
Para quem tem agentes em produção, ou está prestes a ter, deixo o que me parece um ponto de partida razoável. Nada disto exige esperar por normas da indústria.
- Fazer o inventário: que agentes existem, com que identidade correm, a que sistemas acedem e quem é o dono de cada um. Se a resposta for “não sabemos bem”, começa-se por aqui.
- Dar a cada agente uma identidade própria com privilégios mínimos, e nunca a do utilizador que o lançou.
- Tirar as regras de segurança do prompt e passá-las para um gateway que medeia todas as chamadas a ferramentas e que o modelo não consegue contornar.
- Exigir aprovação humana ou validação determinística para ações irreversíveis: pagamentos, eliminações, comunicações externas, alterações a produção.
- Garantir registos escritos pela infraestrutura, imutáveis, e testar se é possível reconstruir uma tarefa completa sem perguntar nada ao modelo.
- Ter um botão de paragem testado num exercício, sabendo em que estado ficam os sistemas.
- Incluir os agentes no plano de resposta a incidentes.
Nenhum destes passos é exótico. São práticas que qualquer equipa de segurança já aplica a contas privilegiadas. O trabalho está em aceitar que um modelo com acesso a sistemas reais pertence a essa categoria.
Confiar menos para poder usar mais
O ensaio termina com uma ideia que, parafraseado, diz que o sistema de superinteligência mais digno de confiança não será aquele que usa o modelo em que mais confiamos, mas o que nos permite confiar menos no modelo.
Parece um paradoxo e não é. É a lógica que nos deixa entregar o carro a um arrumador: não confiamos nele, mas a chave só liga o motor e não abre a bagageira.
A tentação dos próximos anos vai ser a contrária. Os modelos vão errar menos nas demonstrações e vamos ser empurrados para lhes dar mais autonomia porque “já provaram que funcionam”. Devia ser o oposto. Quanto mais capaz é um ator com acesso a sistemas críticos, maior o estrago quando algo corre mal. Nenhuma organização séria dá acesso irrestrito ao cofre ao funcionário mais competente só porque é competente.
O Nadella acabou de dizer, em público, que os clientes da Microsoft devem desconfiar dos modelos que a própria Microsoft lhes vende. Podemos discutir as motivações, e devemos. Mas a régua ficou posta. A partir de agora, a pergunta a fazer a qualquer fornecedor de agentes já não é “quão bom é o vosso modelo?”. É “o que é que acontece, e quem é que dá por isso, quando o vosso modelo fizer asneira?”. Quem não tiver resposta a esta segunda pergunta não está a vender inteligência. Está a vender uma conta de serviço com permissões de domínio e boa conversa.
Acho que é algo que vale a pena pensar.
Abraço!
Nuno
Fontes: Satya Nadella, “Models as Insider Risks in the Super Intelligence Era”, sn scratchpad, 10 de outubro de 2026; intervenção de Satya Nadella no All-In Summit, setembro de 2026.
Este texto foi escrito com o auxilio de um modelo LLM privado.