Código IA acelera entregas e amplia instabilidade: planilhas ensinam cibersegurança
Governança

Código IA acelera entregas e amplia instabilidade: planilhas ensinam cibersegurança

Pesquisas apontam falhas de segurança em 45% do código gerado por IA. A crise das planilhas corporativas sugere que o gargalo não está na ferramenta, e sim na governança que não a acompanhou.

Em outubro de 2020, o serviço de saúde pública da Inglaterra deixou de reportar 15.841 resultados positivos de covid-19. A causa não foi um ataque cibernético nem negligência clínica: os resultados eram consolidados em arquivos Excel no formato XLS, criado em 1987 e limitado a cerca de 65 mil linhas. Atingido o limite, os registros excedentes desapareciam do processo, conforme apurou a BBC. Pesquisadores da Universidade de Warwick estimaram depois que o atraso no rastreamento de contatos daí decorrente pode ter causado mais de 125 mil infecções adicionais e 1.500 mortes.

Mini Banner - Assine a MIT Technology Review0

O caso não é isolado, e é essa recorrência que o torna relevante para o debate sobre Inteligência Artificial. A Fannie Mae reapresentou mais de um bilhão de dólares em resultados por um erro de planilha. No episódio da “Baleia de Londres”, no JPMorgan, o modelo de risco dividia volatilidade por uma soma em vez de uma média, em planilhas transferidas manualmente e jamais auditadas de forma independente. E a tese de que dívida pública acima de 90% do PIB derruba o crescimento, que foi a sustentação técnica de políticas de austeridade em vários países e que dependia parcialmente de um intervalo de células mal selecionado, como demonstraram Thomas Herndon, Michael Ash e Robert Pollin, da Universidade de Massachusetts Amherst, ao obter a planilha original.

A planilha, porém, foi apenas a face visível de um fenômeno maior. O Microsoft Access levou o mesmo princípio adiante, permitindo que profissionais sem formação em engenharia construíssem bancos de dados relacionais completos. O resultado é uma cena que qualquer gestor de TI com duas décadas de carreira reconhece: o analista que ergueu sozinho um sistema departamental para um processo crítico, num arquivo em diretório compartilhado, sem documentação, controle de versão, dono formal ou auditoria. O sistema funcionava, virou infraestrutura, e a extensão da dependência só aparecia quando o autor deixava a empresa. A literatura chamou o fenômeno de end-user computing; a versão menos gentil ficou conhecida como Shadow IT ou TI das sombras.

O denominador comum desses episódios não é incompetência individual. É estrutural: a ferramenta permitia criar artefatos de alta consequência sem exigir o processo que garante confiabilidade. Nenhum daqueles sistemas passou por revisão por pares, teste de regressão ou auditoria. Não porque alguém decidiu suprimi-los, mas porque a ferramenta não os pedia. Planilhas e bancos departamentais democratizaram a criação de software nos anos 1990 como os assistentes de código a democratizam agora, e a literatura sobre aquele ciclo funciona como prognóstico.

Uma constante de trinta anos na literatura de erros

Raymond Panko, da Universidade do Havaí, dedicou décadas ao estudo de erros em planilhas. Sua síntese apresentada no EuSpRIG chega a três conclusões: erros são raros por célula, mas quase certos em modelos grandes; são difíceis de detectar depois de cometidos; e organizações são superconfiantes quanto à correção do que produzem. Em experimentos controlados, participantes estimavam entre 10% e 18% de chance de terem errado, quando a maioria esmagadora havia errado. A terceira conclusão é a mais transferível ao presente.

O estudo de Neil Perry, Megha Srivastava, Deepak Kumar e Dan Boneh, apresentado na ACM CCS 2023, foi o primeiro grande experimento com usuários reais de assistentes de código. Participantes com acesso à ferramenta escreveram código significativamente menos seguro que o grupo de controle e, ao mesmo tempo, declararam-se mais confiantes de que seu código era seguro. Três décadas separam esse achado dos experimentos de Panko: a distância entre confiança e competência não mudou de tamanho, mudou de suporte técnico.

O achado tampouco é recente. Em “Asleep at the Keyboard?”, pesquisadores da Universidade de Nova York já haviam encontrado proporção expressiva de trechos vulneráveis em sugestões do GitHub Copilot para cenários do catálogo CWE, padrão estável entre gerações de modelos e metodologias.

O que os dados dizem sobre o código gerado por IA

Sobre a qualidade do artefato, o GenAI Code Security Report da Veracode avaliou mais de cem modelos de linguagem em dezenas de tarefas de codificação em Java, Python, C# e JavaScript e encontrou vulnerabilidades do OWASP Top 10 em 45% das gerações. A atualização publicada em 2026, com modelos de fronteira mais recentes, manteve o mesmo patamar, o achado mais desconfortável do trabalho, porque desfaz a hipótese de que a capacidade geral crescente resolveria a segurança por arrasto. As falhas concentram-se em classes previsíveis, como cross-site scripting, injeção em logs e criptografia obsoleta, e variam por linguagem, com Java em posição especialmente ruim. A hipótese dos autores é que os modelos absorveram o acervo público de código legado anterior às práticas modernas de segurança.

No eixo da produtividade, a evidência é mais disputada, e convém expor a divergência. A METR conduziu ensaio randomizado com desenvolvedores experientes em repositórios que já dominavam: o uso de IA associou-se a tarefas 19% mais lentas, enquanto os participantes estimavam ter ganhado cerca de 20% de velocidade. A organização revisou depois o desenho do estudo, reconhecendo vieses de seleção. Já o relatório DORA 2025, do Google Cloud, encontrou associação entre maior adoção de IA e maior throughput, acompanhada, contudo, por aumento da instabilidade da entrega. Mas o mesmo relatório registra que ela aumenta a instabilidade da entrega e não reduz atrito nem esgotamento, e conclui que a IA funciona como amplificador: potencializa organizações maduras e agrava disfunções das demais.

As duas leituras convergem num ponto pouco explorado: o ganho, quando existe, é local e individual; o passivo é sistêmico. Foi essa assimetria que tornou o end-user computing ingovernável por duas décadas.

Dois riscos sem precedentes no end-user computing

Até aqui o argumento é de continuidade. Dois vetores, porém, não têm análogo naquela geração de ferramentas, e são eles que convertem um problema de qualidade em problema de segurança. O primeiro é a alucinação de dependências. Pesquisadores liderados por Joseph Spracklen, da Universidade do Texas em San Antonio, geraram centenas de milhares de amostras de código com 16 modelos e checaram cada pacote sugerido. Cerca de um em cada cinco não existia em registro público algum, mais de 200 mil nomes fictícios, conforme o trabalho apresentado no USENIX Security 2025. O achado crítico não é o volume, é a reprodutibilidade: os mesmos nomes inventados reaparecem quando o prompt é repetido.

A falha estatística vira, assim, alvo previsível. Daí o slopsquatting: o atacante registra o pacote que o modelo já demonstrou que vai sugerir e aguarda a instalação. O ataque inverte a lógica dos controles clássicos, porque SBOMs, listas de permissão e varreduras de CVE só enxergam ameaças existentes, enquanto aqui o componente malicioso nasce depois da alucinação e antes da instalação. Uma nota da Cloud Security Alliance e replicações de 2026 indicam que a dispersão entre modelos diminuiu, mas que o vetor persiste, agravado por agentes que instalam dependências sem revisão humana.

O segundo vetor é a automação ofensiva. Em novembro de 2025, a Anthropic reportou ter detectado e interrompido uma campanha de espionagem atribuída ao grupo estatal chinês GTG-1002, que empregou o modelo Claude Code em arquitetura agêntica contra cerca de trinta organizações de tecnologia, finanças, química e governo. Segundo o relatório, a IA conduziu entre 80% e 90% das operações táticas. Parte da comunidade técnica questiona o grau de ineditismo e de autonomia descrito pela empresa, e a ressalva é legítima: é relato de fornecedor, sem verificação forense independente. Ainda assim, o ponto econômico permanece de pé: a automação reduz o custo marginal de campanhas direcionadas, e defesas dimensionadas para o ritmo humano passam a enfrentar adversários em ritmo de máquina.

Monocultura de código, um risco sistêmico ainda mal medido

Há um terceiro efeito, menos discutido e potencialmente mais grave. Heartbleed e Log4Shell foram catastróficos porque um único componente estava em toda parte. O erro humano, ao menos, é diverso: cada equipe erra à sua maneira, e essa diversidade limita a correlação das falhas. Um padrão inseguro emitido por um modelo amplamente adotado replica-se em milhares de repositórios ao mesmo tempo, atravessando setores e jurisdições. É uma fragilidade sistêmica sem métrica consolidada nem literatura madura: enquanto o debate público se concentra em vibe coding e produtividade individual, a exposição correlacionada segue fora dos painéis de risco corporativo.

A governança necessária já existe, e não foi aplicada

A resposta institucional ao end-user computing, construída sob pressão da Sarbanes-Oxley, do Comitê de Basileia e das exigências de auditoria, produziu um repertório que se transfere quase integralmente ao problema atual.

Proveniência antes de tudo. Nenhuma organização controlou planilhas proibindo planilhas; controlou sabendo quais eram materiais. O equivalente hoje é registrar qual código foi gerado por IA, sob qual modelo, e com que raio de impacto. Sem metadados de proveniência não há auditoria possível, apenas confiança declarada.

Controles proporcionais ao risco. Um protótipo e um serviço de autenticação não podem ter o mesmo regime. O erro histórico foi oscilar entre a proibição inaplicável e a permissividade total. Código gerado por IA em superfície exposta ou em fluxo de dados sensível exige revisão humana qualificada, análise estática obrigatória e testes dirigidos às classes de falha já mapeadas pela literatura.

Fechamento do elo de dependências. Lockfiles com verificação de integridade, espelhos internos de registro, quarentena para pacotes recém-publicados, desativação de scripts de ciclo de vida e validação explícita da existência de cada dependência sugerida, sobretudo em pipelines agênticos.

Reinvestimento na verificação. É o ponto cultural, e o mais difícil: se a IA desloca o trabalho de escrever para revisar, a organização precisa investir exatamente na competência deslocada. O estudo de Perry e colegas traz um achado quase irônico: os participantes que confiavam menos no assistente e interagiam de forma mais crítica com ele entregaram código com menos vulnerabilidades. Ceticismo calibrado é habilidade treinável, e quase nenhuma trilha de formação o ensina.

Responsabilidade sobre o artefato. O AI Act europeu, o Cyber Resilience Act e referenciais técnicos do NIST e da OpenSSF apontam, por caminhos distintos, para maior rastreabilidade, supervisão e responsabilidade ao longo do ciclo de vida tecnológico. No Brasil, princípios semelhantes aparecem no debate regulatório em torno do PL 2338/2023, ainda em tramitação.

O prazo, desta vez, é definido pelo atacante

A abstração é o motor do progresso em computação. Cada camada, como o compilador, o framework, a planilha ou o modelo de linguagem, poupou trabalho e ampliou alcance. O preço, cobrado com atraso, é que cada camada também afasta o autor da consequência daquilo que autorizou.

O Access transformou analistas em desenvolvedores sem transformá-los em engenheiros. A IA generativa faz o mesmo na escala de uma indústria inteira e ainda entrega ao adversário a mesma alavanca. A questão para conselhos e diretorias não é se as organizações vão usar IA para escrever código. Elas já usam, com ou sem política formal, como usavam planilhas. É se conseguirão construir, em anos e não em décadas, a governança que a onda anterior levou uma geração para amadurecer. Da última vez, o prazo foi dado pelos auditores. Desta vez, quem o define é o atacante.

Último vídeo

Nossos tópicos