Opinion
Há um pressuposto tácito na adoção acelerada de modelos de IA generativa: o de que um modelo é mais um componente de software – complexo, mas um componente. Mas o seu comportamento não é escrito em código; é destilado a partir de dados. Se a integridade desses dados falha, falha a integridade do próprio sistema – e a falha pode permanecer latente, à espera de um gatilho (trigger)
Por Henrique Carreiro . 03/02/2026
|
O envenenamento de dados (data poisoning) é precisamente isso: a introdução deliberada de exemplos maliciosos no pré-treino dos modelos, no fine-tuning ou até no corpus que alimenta embeddings, para induzir vieses, degradação seletiva ou backdoors acionados por frases específicas. Em outubro de 2025, um estudo conjunto do UK AI Security Institute, da Anthropic e do Alan Turing Institute mostrou que bastaram 250 documentos maliciosos para inserir um backdoor em modelos entre 600M e 13B parâmetros; no setup descrito, esses 250 documentos (cerca de 420 mil tokens) representaram aproximadamente 0,00016% do total de tokens de treino. Este detalhe altera a economia do ataque. Em vez de “controlar uma percentagem” do corpus, um adversário pode plantar poucas sementes em locais bem escolhidos: conteúdo público preparado para ser recolhido, contributos em datasets de instruções obtidos por crowd-sourcing, ou uma fase de afinação conduzida por um fornecedor. Trabalhos de investigação recentes sobre envenenamento durante o instruction tuning descrevem como gatilhos discretos podem ser aprendidos, ainda que preservando a aparência “limpa” do conteúdo, tornando a deteção por filtragem e inspeção superficial pouco fiável. Esta fiabilidade é corroída por uma assimetria fundamental: a injeção é estatisticamente invisível nos agregados de dados (não altera médias nem variâncias) e é semanticamente camuflada para revisores humanos. Tratam-se de ataques clean-label: o texto lê-se como legítimo para o revisor, mas carrega a lógica tóxica para a máquina. Onde o filtro vê sintaxe válida, o modelo vê uma instrução imperativa oculta. O problema, a prazo, é sistémico. Treinamos modelos sobre cadeias longas (web, fornecedores, logs internos); afinamos com datasets reaproveitados; e colocamo-los a produzir texto e código que regressam ao ecossistema digital. A superfície de ataque vai-se acumulando: o mesmo veneno pode reaparecer por reutilização de corpora, por transfer learning e por “modelos derivados”. Uma alteração pequena, mas persistente, tende a sobreviver aos ciclos de atualização. O risco mais sério surge quando um backdoor se manifesta num contexto operacional. Pode não aparecer em testes de aceitação nem em avaliações genéricas; pode emergir apenas quando a frase certa entra num e-mail, num ticket ou numa página web lida por um agente. Em SOC, em pipelines de DevSecOps assistidos por IA, ou em triagens automatizadas, isso transforma o envenenamento num problema de cadeia de fornecimento, com impacto na disponibilidade e, sobretudo, na integridade das decisões. O cenário torna-se crítico pela ausência de reversibilidade. Ao contrário do software, onde uma vulnerabilidade se resolve com um patch, não existe um método limpo para fazer uma rede neuronal “desaprender” um conceito sem degradar as suas capacidades gerais (catastrophic forgetting). A descoberta tardia de um backdoor não exige apenas uma correção; exige, frequentemente, o descarte do modelo e o custo proibitivo de um treino integral. As respostas defensivas convergem para uma conclusão pragmática: tratar dados como infraestrutura crítica. As orientações conjuntas da CISA/NSA/FBI recomendam práticas clássicas — prova de proveniência, assinaturas digitais, cifragem, controlo de acesso, armazenamento seguro, e rastreio da cadeia de fornecimento — aplicadas ao ciclo de vida dos dados usados para treinar e operar modelos de IA generativa. O Reino Unido está a traduzir princípios semelhantes para um código de prática que cobre o ciclo de vida de sistemas de IA, do desenho ao fim de vida. Se houver uma crise, ela não virá de um “modelo rebelde”, mas de uma rastreabilidade deficiente daquilo que o alimentou. A maturidade mede-se menos em benchmarks e mais em perguntas simples: de onde veio cada dataset, quem o tocou, que transformações sofreu, que sinais de adulteração foram procurados, e que testes de backdoor foram feitos antes de o pôr em produção. Estes são, daqui para a frente, os dados fulcrais que esperamos no model card de cada modelo, independentemente de qual o fornecedor. Não se trata de exigência esotérica: é higiene básica. |