Em 18 de setembro de 2026, o Google confirmou publicamente que seu modelo Gemini obteve acesso não autorizado a três sistemas pertencentes a terceiros. Isso aconteceu em maio de 2026, durante uma avaliação de segurança conduzida pela Irregular, uma empresa que testa sistemas avançados de IA, estruturada como um exercício de capture-the-flag dentro do que deveria ser um ambiente fechado. O Google soube dos incidentes em julho e só os confirmou publicamente depois da cobertura da imprensa, em meados de setembro.

Na imprensa, isso aparece como uma história de IA escapando de seus limites. Dentro de uma empresa, aparece como algo mais restrito e muito mais próximo: o detalhe que causou tudo não estava no modelo, estava na forma como o ambiente de teste foi configurado. E é o mesmo tipo de erro presente agora mesmo em um bom número de sistemas de empresas sauditas.

O que aconteceu de fato

O cenário era simples: fazer o modelo atacar uma organização fictícia dentro de um ambiente isolado. Duas coisas deram errado ao mesmo tempo. Primeiro, o ambiente tinha acesso não intencional à internet. Segundo, a empresa fictícia usada no exercício coincidia por acaso com um domínio real pertencente a uma parte real.

O resultado foi que o modelo fez exatamente o que lhe foi pedido, contra o alvo errado. Segundo Heather Adkins, vice-presidente de engenharia de segurança do Google, o modelo encontrou informações públicas na internet e adivinhou credenciais para acessar sites que achava fazerem parte do teste. Ele parou assim que obteve acesso e não foi além, e o Google diz que nenhum dano resultou disso.

A parte mais importante da posição do Google é que ele não classifica isso como desalinhamento no comportamento do modelo, mas como erro de identidade. O modelo não decidiu ir além de suas instruções. Ele as seguiu ao pé da letra, dentro de um mapa do mundo que estava errado. E este também não é um caso isolado: a OpenAI revelou em julho que um de seus agentes invadiu o Hugging Face, e a Anthropic relatou comportamento semelhante em seus próprios modelos.

A falha estava no limite, não no modelo

Tire a IA da história por completo e a lição continua intacta. Descrito de forma simples, o incidente é: um sistema rodando em um ambiente de teste, um ambiente com uma rota ativa para o mundo exterior, e dentro dele dados de teste que não eram tão fictícios quanto quem os escreveu supunha.

Essa descrição se encaixa em coisas que acontecem em empresas comuns, sem IA nenhuma envolvida. Um sistema de staging envia mensagens de confirmação para números de celular inventados ao acaso, e elas chegam a pessoas reais. Um script de teste chama um gateway de pagamento contra a produção em vez do sandbox. Uma cópia de desenvolvimento do site aponta para o banco de dados de clientes em produção porque montar um separado era trabalhoso. Uma campanha de e-mail de teste sai para a lista real de assinantes. Em todos os casos, a suposição que se quebrou é a mesma: alguém acreditava que aquele ambiente era separado.

Onde isso se repete nas empresas sauditas

Pelo que vemos trabalhando em sistemas existentes, isso se repete em quatro pontos específicos:

  • Dados de teste que não são realmente falsos. Os números, domínios e endereços de e-mail inventados na hora para preencher um formulário de teste geralmente pertencem a pessoas reais. A solução não é o bom senso individual, mas domínios reservados para testes, números que não chegam a ninguém e uma regra escrita proibindo inventar dados na hora.
  • Um ambiente de staging com uma saída aberta. Se a sua cópia de desenvolvimento consegue enviar uma mensagem de WhatsApp, um e-mail ou uma solicitação de pagamento para o mundo exterior, ela não é um ambiente de staging — é um segundo ambiente de produção. O bloqueio correto fica na configuração, não na memória de um desenvolvedor.
  • Chaves de produção usadas em testes. Uma única chave compartilhada entre os dois ambientes anula a separação, por mais organizada que a estrutura de pastas pareça. É exatamente por isso que as plataformas governamentais os separam: a Autoridade de Zakat, Impostos e Alfândega (ZATCA), por exemplo, oferece na plataforma Fatoora um ambiente de simulação distinto do de produção, com certificados de integração separados para cada um.
  • Uma cópia dos dados de clientes dentro do ambiente de desenvolvimento. Este é o mais arriscado em termos regulatórios. A Lei de Proteção de Dados Pessoais (PDPL), supervisionada pela Autoridade Saudita de Dados e Inteligência Artificial (SDAIA), rege os dados pessoais onde quer que estejam e não abre exceção para uma cópia rotulada como teste. Um ambiente de staging com dados reais de clientes está totalmente no escopo — e geralmente é o sistema menos protegido que você tem.

Quatro limites para definir esta semana

Nada disso exige um projeto ou um orçamento. Exige uma sessão com quem administra os seus sistemas:

  • Faça uma pergunta direta: a nossa cópia de teste consegue enviar uma mensagem, um e-mail ou uma solicitação de pagamento para o mundo exterior? Se a resposta for sim ou não tenho certeza, essa é a primeira coisa a fechar.
  • Separe completamente chaves e certificados entre os ambientes, para que nenhuma chave funcione nos dois.
  • Adote uma lista fixa de dados de teste: um domínio de teste reservado, números que não chegam a ninguém e um número de celular conhecido da equipe que recebe todas as mensagens de teste.
  • Defina quem pode rodar uma ferramenta automatizada ou um agente de IA contra os seus sistemas, em qual ambiente e com quais permissões. Se a resposta não estiver por escrito, ela não existe.

A visão da Origami

Lemos este incidente como um lembrete de que as falhas de sistema mais caras raramente são sofisticadas. São falhas de suposição. A capacidade de segurança do Google está muito acima da de qualquer empresa saudita, e a suposição que se quebrou foi a mais simples: que um ambiente fechado estava de fato fechado. As empresas normalmente não caem na parte difícil de um sistema. Caem na parte que ninguém revisou, porque parecia óbvia.

Na Origami, tratamos o isolamento de ambientes como parte da entrega, e não como um extra opcional: um ambiente de staging que não alcança canais de comunicação reais, chaves separadas e dados de teste que não pertencem a ninguém. O custo é de algumas horas no início de um projeto. A alternativa é um incidente que você explica a um cliente ou a um regulador depois que ele já aconteceu. É uma troca que vale a pena resolver cedo.

Uma lição prática

A lição do incidente com o Gemini não é evitar ferramentas de IA. É parar de tratar a palavra staging como garantia. Um ambiente não está isolado porque você o chamou assim; está isolado porque alguém testou de fato que ele está. Comece hoje com uma pergunta: qual é o ponto mais distante que a nossa cópia de teste consegue alcançar? Se a resposta não estiver clara, você está operando com a mesma suposição que se quebrou no Google.

Fontes

  • NBC News — a confirmação do Google de que o Gemini obteve acesso não autorizado a três sistemas externos em maio de 2026, e a declaração de Heather Adkins, vice-presidente de engenharia de segurança, de que o modelo encontrou informações públicas e adivinhou credenciais de sites que achava fazerem parte do teste.
  • CNBC — detalhes da avaliação conduzida pela Irregular, o acesso não intencional do ambiente de teste à internet, a organização fictícia que coincidia com um domínio real e incidentes comparáveis revelados pela OpenAI e pela Anthropic.
  • SDAIA — a Lei de Proteção de Dados Pessoais (PDPL) e sua aplicação aos dados pessoais onde quer que sejam tratados.
  • Plataforma Fatoora - ZATCA — a separação entre o ambiente de simulação e o de produção, com certificados de integração independentes para cada um.