Em um momento em que modelos generativos se tornam centrais na estratégia de inovação de empresas em todo o mundo, cresce também o interesse, e a preocupação, com os riscos que envolvem os próprios dados usados para treiná-los. Entre essas ameaças, o data poisoning desponta como um dos ataques mais sofisticados e silenciosos do ecossistema de IA: ele contamina bases de dados e influencia o comportamento dos modelos sem deixar rastros aparentes.
Para entender os mecanismos desse tipo de ataque e as implicações para a segurança corporativa, a TI Inside conversou com Caroline Maneta, líder de Plataforma de Segurança da Dell Technologies no Brasil. Na entrevista, ela explica como o envenenamento de dados se infiltra nos pipelines de treinamento, por que é tão difícil de detectar e quais práticas e frameworks, como NIST AI RMF e ISO 42001, vêm sendo adotados para fortalecer a governança e a rastreabilidade dos dados no ciclo de vida da inteligência artificial.
O que é exatamente o data poisoning e por que ele é tão difícil de detectar em modelos generativos?
Data poisoning é um tipo de ataque onde o invasor coloca ou muda exemplos dentro do conjunto de dados usados para treinar o modelo, com a intenção de influenciar como ele vai se comportar. Essa contaminação pode ser usada para enviesar as respostas, criar “portas dos fundos” (backdoors) que acionam respostas específicas ou simplesmente piorar a qualidade geral do modelo. Nos modelos generativos, detectar esse tipo de ataque é ainda mais complicado por três motivos principais: primeiro, porque esses modelos são treinados com uma quantidade gigantesca e muito variada de dados, o que torna impossível conferir manualmente ou até automaticamente cada pedacinho de informação; segundo, porque os efeitos dessas manipulações são geralmente sutis e espalhados, causando pequenas mudanças que afetam o modelo de formas complexas e só aparecem em situações bem específicas, dificultando encontrar a origem; e terceiro, porque os datasets são formados de várias fontes diferentes e estão sempre mudando, com pipelines iterativos, então um dado contaminado pode se espalhar e influenciar versões futuras do modelo sem deixar um rastro claro para ser detectado.
Veja também: Ataque vs Defesa: O papel da IA na segurança corporativa
Em que ponto da cadeia de treinamento um atacante pode inserir dados contaminados — e como isso passa despercebido?
O envenenamento de dados pode acontecer em quase qualquer etapa do ciclo de dados: desde a coleta e entrada dos dados, passando pelo processamento e curadoria, até o armazenamento e ajuste dos conjuntos usados no treino. No pré-processamento, existem scripts automáticos para limpar e filtrar os dados, mas dá para burlar isso usando formatos ou tokens que escapam das regras. No armazenamento intermediário, se não houver auditoria, dá para alterar ou inserir amostras sem que ninguém note. E durante o fine-tuning, também podem ser injetados dados falsos que mudam o comportamento do modelo de forma sutil. O problema é que, no geral, o pipeline confia demais nas fontes dos dados, e os sistemas só ficam de olho no desempenho, não na integridade real do que entra. Sem verificação de origem nem auditoria automática, a contaminação pode passar despercebida entre milhares ou milhões de dados legítimos.
Há diferença entre manipular dados públicos (como repositórios abertos) e corromper datasets proprietários?
A diferença significativa é que dados públicos são o alvo mais fácil, uma vez que qualquer um pode acessar e eles entram automaticamente nos pipelines, então são particularmente perigosos na fase de pré-treinamento, embora o estrago acabe sendo espalhado e meio diluído entre muitos modelos. Já os dados proprietários têm superfície de ataque menor, mas se alguém consegue acesso interno (ou compromete a curadoria) o dano pode ser sério: amostras direcionadas que distorcem respostas, vazam segredos ou introduzem vieses em sistemas críticos. No fim das contas, o data poisoning é difícil de pegar porque explora justamente o ponto menos auditado, que são os próprios dados, tirando proveito da confiança e da complexidade dos pipelines de treinamento.
Quais são as principais técnicas usadas hoje para envenenar dados de IA?
Basicamente, as técnicas de data poisoning vão desde colocar exemplos manipulados direto no treino dos modelos, contaminar modelos ou checkpoints usados no fine-tuning, criar exemplos adversariais que exploram fraquezas do modelo, mexer em rótulos ou no feedback humano até sabotar a cadeia de suprimentos de dados (repositórios, scripts de ingestão ou serviços de anotação). Fora isso, ataques também acontecem em produção, mandando entradas maliciosas na inferência para fazer o sistema agir de maneira indesejada. Em resumo: atacam em todas as etapas — dados, modelos, rótulos e infraestrutura — para provocar erros, vieses ou vazamentos.
Como os atacantes conseguem manter persistência mesmo após novas iterações do modelo?
A persistência desses ataques funciona assim: atacantes plantam backdoors com gatilhos que disparam comportamentos específicos mesmo depois de re-treinos; contaminam checkpoints ou modelos-base que vão ser reutilizados por outros times; reintroduzem ou “reossificam” dados maliciosos em pipelines que não têm versionamento nem auditoria; e comprometem os fluxos de anotação para que a contaminação se repita em futuras iterações. Ou seja, eles garantem que o problema sobreviva ao tempo atacando modelos, checkpoints, dados e processos de curadoria.
Que tipo de manipulação real pode ser feita com um dataset adulterado — distorção ideológica, erro técnico, vazamento?
Um dataset adulterado pode induzir vieses ideológicos, degradar precisão técnica e consistência, implantar backdoors que retornam respostas programadas a gatilhos, e fazer com que o modelo memorize e exponha informações sensíveis. Pode também provocar contaminação cruzada que afeta múltiplos modelos derivados.
É possível direcionar o comportamento de um modelo (como um assistente ou recomendador) por meio de dados tóxicos?
Sim, dados manipulados, especialmente quando mexem em exemplos de treino, rótulos ou feedbacks, podem fazer um assistente ou recomendador favorecer certos conteúdos, reproduzir vieses, executar ações indesejadas ou disparar respostas previstas por um gatilho.
Já existem casos documentados de data poisoning com impacto econômico ou reputacional em empresas? Existe um “mercado paralelo” de datasets contaminados ou isso ainda está restrito a ataques direcionados?
Não posso mencionar casos específicos que eu tenha conhecimento, mas o que posso afirmar é que as empresas devem adotar um trabalho de prevenção contínuo. O foco deve ser na identificação de vetores de risco e nas medidas de mitigação.
Como empresas que desenvolvem IA generativa estão protegendo seus pipelines de dados?
Recomendamos que as empresas mantenham controles contínuos de integridade e auditoria nos pipelines: validação automática dos datasets, versionamento e verificação da origem dos dados, segmentação de acesso (RBAC), criptografia em trânsito e em repouso, e monitoramento de anomalias durante o treinamento. Além disso, endurecer (hardening) os ambientes de orquestração e aplicar controle rígido sobre quem pode inserir ou alterar dados. De modo geral, automatizar checagens e limitar privilégios para reduzir riscos. Essas práticas podem ser complementadas por soluções que ofereçam automação na proteção e recuperação de ambientes críticos, como os pipelines baseados em Kubernetes. Ferramentas como o Dell PowerProtect Data Manager e o Data Domain, por exemplo, contribuem para a resiliência dos dados e a continuidade operacional. Já a criptografia de dados em repouso em sistemas de armazenamento, como no Dell PowerMax e no Dell PowerStore, ajuda a assegurar a confidencialidade e integridade das informações armazenadas, reforçando a defesa contra ameaças como o envenenamento de dados e a manipulação nos ciclos de treinamento.
Quais frameworks de segurança ou auditoria (ISO 42001, NIST AI RMF, etc.) endereçam esse tipo de risco?
Os principais frameworks que tratam do risco de data poisoning em IA são o NIST AI RMF e a ISO/IEC 42001. O NIST foca em identificar e mitigar ameaças ao longo do ciclo de vida do modelo, incluindo auditoria dos dados, rastreabilidade e integridade — tratando o poisoning como ataque à cadeia de suprimentos. Já a ISO/IEC 42001 define políticas de governança para garantir qualidade, explicabilidade e revisão contínua das fontes de dados. Juntas com a ISO/IEC 27001 (que cobre segurança da informação), essas normas ajudam a proteger os pipelines com rastreabilidade, versionamento e validação sistemática dos dados. Esses frameworks são fundamentais, e nós investimos em treinamento de IA em todo o nosso serviço de consultoria, certificando que as equipes dos nossos clientes compreendam essas estruturas chave, como o NIST AI RMF e a ISO, para garantir a implementação eficaz dessas práticas de segurança e governança.
A criptografia ou a rastreabilidade dos dados de origem (proveniência) são suficientes para evitar envenenamento?
Criptografia e rastreabilidade ajudam a diminuir o risco de adulteração, mas não conseguem impedir que dados maliciosos, que parecem legítimos, sejam inseridos. Para proteger de verdade, é preciso ter curadoria ativa, validação semântica dos dados, auditoria dos pipelines e monitoramento constante de comportamentos estranhos tanto durante o treinamento quanto na inferência.
O data poisoning pode ser considerado uma forma de ataque à cadeia de suprimentos digital?
O envenenamento de dados aproveita as falhas e vulnerabilidades em várias etapas essenciais do processo de coleta, curadoria e integração dos dados usados para treinar modelos de IA. Ele pode acontecer desde o momento em que os dados são coletados em repositórios abertos e públicos até quando modelos pré-treinados são reutilizados por outras equipes. Como esses pontos fazem parte da cadeia de suprimentos digital da IA, qualquer falha ou brecha neles pode comprometer o resultado final do modelo, afetando sua confiabilidade, segurança e desempenho.
Quais setores são mais vulneráveis — saúde, defesa, finanças, marketing?
Setores que trabalham com grandes quantidades de dados, dados sensíveis ou que dependem de decisões automatizadas — como saúde, finanças e defesa — são os que mais correm risco. Isso porque, se alguém manipular os dados nesses campos, pode causar prejuízos sérios, criar vieses que afetam pessoas de forma injusta e até trazer problemas legais e regulatórios. Ou seja, nesses setores, qualquer falha na integridade dos dados pode ter consequências muito graves, tanto para as pessoas envolvidas quanto para as empresas e órgãos responsáveis.
Como os profissionais de cibersegurança podem atuar em conjunto com cientistas de dados para detectar sinais precoces de manipulação?
As empresas precisam colocar práticas de segurança em todas as fases do ciclo de vida dos modelos. Isso inclui fazer modelagem de ameaças para mapear possíveis riscos nos pipelines, usar ferramentas que monitoram e detectam anomalias tanto nos datasets quanto nas métricas de treinamento, revisar regularmente os logs e as versões dos dados para identificar qualquer coisa estranha, e promover revisões cruzadas entre as equipes de segurança e de ciência de dados. Assim, fica muito mais fácil detectar padrões suspeitos e agir rápido para evitar problemas maiores.
Siga TI Inside no Instagram e tenha acesso a conteúdos exclusivos do mercado.
