A construção de classificadores para Sistemas de Apoio a Decisão parte da premissa fundamental de que o conjunto de treinamento é uma amostra confiável e íntegra da realidade. O algoritmo de aprendizado busca generalizar padrões a partir desses dados históricos, assumindo que eles não sofreram manipulação. Portanto, a qualidade da tomada de decisão final está diretamente atrelada a essa base: o sistema opera sob a hipótese de que as correlações estatísticas aprendidas são genuínas, sem considerar a possibilidade de interferências maliciosas na fonte dos dados.
Essa confiança implícita nos dados abre espaço para o campo do Adversarial Machine Learning (Aprendizado de Máquina Adversário), que estuda técnicas utilizadas para enganar modelos de aprendizado. É nesse contexto que o ataque de Data Poisoning (Envenenamento de Dados) se torna crítico. Ao contrário de ataques que tentam burlar o sistema depois de pronto, o data poisoning ataca a fase de aprendizado. O resultado é um modelo que, embora pareça funcional, foi treinado para cometer erros específicos, comprometendo a confiabilidade do apoio à decisão.
O Data Poisoning é classificado como um ataque de injeção que ocorre estritamente na fase de treinamento do modelo. Diferente de ataques de “Evasão” (Evasion Attacks), que tentam enganar um modelo já treinado durante o seu uso, o envenenamento busca comprometer a própria formação do conhecimento do algoritmo. O atacante insere dados corrompidos (as “amostras venenosas”) no conjunto de treinamento para que o classificador aprenda regras de decisão falhas desde a origem. Isso torna o ataque persistente: uma vez treinado com dados envenenados, o modelo carrega o viés malicioso até que seja retirado do zero com uma base limpa.
Dentro de Sistemas de Apoio a Decisão, os ataques de envenenamento geralmente possuem dois objetivos distintos:
Ataque à Disponibilidade (Availability Attack): O objetivo principal é degradar a performance global do modelo até torná-lo inutilizável. O atacante insere uma quantidade massiva de ruído ou dados conflitantes no conjunto de treinamento para maximizar a taxa de erro do classificador, invalidando a confiabilidade do Sistema de Apoio à Decisão como um todo.
Ataque à Integridade (Integrity Attack): O foco é introduzir falhas pontuais sem comprometer as métricas gerais de acurácia do sistema. Também conhecido como Backdoor Attack, essa estratégia busca ensinar o modelo a classificar erroneamente apenas inputs que contenham um “gatilho” específico, permitindo que o sistema continue funcionando normalmente para dados legítimos enquanto esconde uma vulnerabilidade crítica.
A execução técnica do Data Poisoning opera manipulando diretamente a geometria do aprendizado do modelo. Os mecanismos principais incluem:
Inversão de Rótulos (Label Flipping): É uma das estratégias de injeção mais eficazes pela sua simplicidade. Nela, o atacante não precisa gerar dados sintéticos; ele corrompe a integridade dos rótulos existentes. Selecionam-se instâncias legítimas de uma classe (ex: “Classe A”) e altera-se sua classificação para a classe oposta (“Classe B”), mantendo as características (features) inalteradas. Isso obriga o algoritmo a aprender e validar estatisticamente relações contraditórias.
Manipulação da Fronteira de Decisão (Decision Boundary): O objetivo matemático da injeção é deslocar o hiperplano ou linha que separa as classes no espaço vetorial. Ao introduzir as amostras envenenadas, o atacante “puxa” essa fronteira para uma direção desejada, fazendo com que a região de classificação de uma classe invada o espaço da outra. O resultado é que novas instâncias legítimas, que cairiam nessa zona invadida, serão classificadas incorretamente com alto grau de confiança pelo sistema.
A presença de classificadores envenenados em ambientes de produção gera consequências severas para a eficácia do apoio à decisão. Os principais impactos operacionais incluem:
Indução ao Erro Sistêmico: Diferente de erros estatísticos aleatórios, o poisoning cria um viés direcionado. O SAD passa a recomendar ações prejudiciais, como aprovar uma transação fraudulenta ou sugerir um diagnóstico médico incorreto, com base em uma lógica matemática corrompida. O sistema deixa de ser uma ferramenta de suporte e se torna um vetor de risco para a organização.
Falha Silenciosa e Perda de Confiança: O aspecto mais crítico desse ataque é que ele não gera travamentos ou mensagens de erro. O sistema continua operando com alta “confiança probabilística”, induzindo o operador humano a acatar a sugestão errada. A descoberta tardia dessa manipulação pode destruir a credibilidade da ferramenta, levando os gestores a abandonarem o uso do sistema por falta de confiabilidade.
Alto Custo de Recuperação (Desaprendizado): Corrigir um modelo envenenado é muito mais complexo do que corrigir um bug de código tradicional. Como o conhecimento do modelo fica diluído em seus parâmetros (pesos), muitas vezes é matematicamente inviável “desaprender” apenas o dado tóxico. Isso obriga a equipe a descartar o modelo comprometido, auditar toda a base histórica e realizar o retreino completo do zero, gerando custos elevados de processamento e tempo.
A proteção contra o Data Poisoning exige uma abordagem em camadas, combinando técnicas algorítmicas com boas práticas de segurança da informação. As principais estratégias incluem:
Sanitização de Dados (Data Sanitization): É a primeira linha de defesa técnica. Consiste em aplicar algoritmos de detecção de anomalias antes do treinamento para identificar e remover amostras suspeitas (outliers). A premissa é que dados envenenados, para serem eficazes, geralmente apresentam desvios estatísticos significativos em relação à distribuição normal da classe que tentam imitar. A higienização busca descartar essas instâncias tóxicas antes que elas sejam processadas pelo modelo.
Treinamento Adversarial: Esta técnica busca aumentar a robustez intrínseca do classificador. Durante a fase de aprendizado, o modelo não é exposto apenas a dados “normais”, mas também a exemplos maliciosos simulados e cenários de pior caso. Isso força o algoritmo a aprender fronteiras de decisão mais estáveis e menos sensíveis a pequenas perturbações ou ruídos, tornando o ataque de envenenamento muito mais difícil de ser executado com sucesso.
Monitoramento Contínuo: A defesa deve permanecer ativa após a implantação. É crucial monitorar métricas de performance e distribuição dos dados em tempo real para detectar o Concept Drift (mudança de conceito). Se a acurácia do classificador cair bruscamente ou se o perfil dos dados de entrada mudar sem explicação natural, o sistema deve alertar sobre um possível ataque em andamento, permitindo intervenção humana ou rollback do modelo.
Controle de Acesso e Segurança da Pipeline: Diferente das defesas anteriores focadas no algoritmo, esta foca na infraestrutura. O envenenamento só é possível se o atacante conseguir inserir dados na base de treino. Portanto, implementar controles rígidos de acesso (autenticação forte, logs de auditoria e princípios de privilégio mínimo) sobre os repositórios de dados e a pipeline de Machine Learning é a medida preventiva mais eficaz para garantir a procedência e a integridade da informação desde a origem.
Para demonstrar os efeitos práticos do Data Poisoning, realizaremos uma simulação controlada onde comparamos o desempenho de um modelo treinado com dados íntegros versus um modelo submetido a manipulação. Essa abordagem permite visualizar tecnicamente como a alteração na “fronteira de decisão” prejudica a capacidade do sistema de identificar transações ilícitas, evidenciando a fragilidade do apoio à decisão quando a fonte de dados é comprometida.
Para a realização deste estudo, selecionamos o conjunto de dados Credit Card Fraud Detection, obtido publicamente na plataforma Kaggle. Esta base agrega transações reais realizadas por portadores de cartões de crédito europeus ao longo de dois dias em setembro de 2013. Uma característica crítica deste dataset para a nossa análise é o seu extremo desbalanceamento: a classe positiva, que representa as fraudes, corresponde a apenas 0,172% do volume total de transações. Para garantir a validade do experimento, os dados foram particionados em conjuntos de treinamento e teste utilizando amostragem estratificada, assegurando que a proporção original de fraudes fosse preservada estatisticamente em ambas as divisões, evitando vieses na avaliação do modelo.
Para estabelecer a linha de base (baseline), treinamos o algoritmo de árvore de decisão com os dados originais. Utilizamos parâmetros específicos para lidar com o desequilíbrio das classes (class_weight=’balanced’) e garantir a reprodutibilidade (random_state=42).
Simulamos o acesso do atacante à base de treino para executar o Label Flipping. A estratégia consiste em selecionar aleatoriamente 20% das transações que são fraudes reais (Classe 1) e inverter seus rótulos para “Transação Legítima” (Classe 0). Isso insere ruído na definição do que constitui uma fraude, confundindo o aprendizado do modelo.
Reiniciamos o classificador e realizamos o treinamento com os mesmos hiperparâmetros do cenário base, porém utilizando o vetor de alvos corrompido (y_train_poisoned).
Para tangibilizar o impacto do ataque e ir além das métricas puramente numéricas, implementamos uma rotina de visualização gráfica utilizando as bibliotecas matplotlib e seaborn.
Para mensurar o prejuízo concreto causado pelo ataque de Data Poisoning ao Sistema de Apoio a Decisão, analisamos as métricas de desempenho do modelo no conjunto de teste (íntegro). A comparação visual entre o modelo limpo e o modelo envenenado revela como a manipulação do treinamento comprometeu a capacidade do sistema de identificar transações fraudulentas.
A Matriz de Confusão é crítica neste cenário, pois o custo de não detectar uma fraude (Falso Negativo) é muito superior ao custo de bloquear erroneamente uma transação legítima (Falso Positivo).
Observando a Figura 1, a comparação entre as matrizes evidencia o sucesso do ataque:
- Impacto Absoluto: O modelo original detectou corretamente 105 transações fraudulentas. Sob efeito do ataque, esse número caiu para 81, enquanto o número de fraudes ignoradas (Falsos Negativos) subiu de 43 para 67.
- Queda no Recall (Revocação): Essa degradação visual reflete diretamente na métrica mais importante para este tipo de SAD.
Modelo Limpo: Apresentava 70.95% de eficácia na detecção de fraudes.
Modelo Envenenado: A eficácia caiu para 54.73%.
O envenenamento da base de treino causou uma perda de aproximadamente 16 pontos percentuais na capacidade de detecção do sistema. No contexto de negócio, isso significa que o Sistema de Apoio à Decisão passou a operar com uma “zona cega” muito maior, validando automaticamente quase metade das fraudes apresentadas, o que representa um risco financeiro inaceitável.
A Curva ROC (Receiver Operating Characteristic) ilustra a capacidade diagnóstica do classificador em diferentes limiares de decisão. A Área Sob a Curva (AUC) resume essa qualidade em um único número. A Figura 2 demonstra a degradação global da performance do classificador:
Queda da AUC: O modelo limpo (linha azul sólida) apresenta uma AUC de 0.85, indicando uma boa capacidade discriminatória entre transações legítimas e fraudes. O modelo envenenado (linha vermelha tracejada) sofreu uma queda na AUC para 0.77.
Perda de Capacidade Discriminatória: A linha vermelha permanece consistentemente abaixo da linha azul. Isso indica que, para qualquer taxa de falsos alarmes (Falso Positivo) que o banco esteja disposto a tolerar, o modelo envenenado sempre detectará menos fraudes (menor Recall) do que o modelo limpo. A “barriga” inicial da curva azul, que indica alta detecção com poucos erros, foi achatada no modelo envenenado.
Os resultados visuais comprovam que a injeção de dados rotulados incorretamente alterou a estrutura da Árvore de Decisão. O algoritmo aprendeu regras falhas que tornaram a sua fronteira de decisão mais permissiva em relação a padrões fraudulentos. O sistema continua operacional, mas sua confiabilidade para o apoio à decisão foi severamente comprometida, passando a atuar em favor dos objetivos do atacante ao ocultar fraudes reais.
Ao longo desta página, exploramos como a confiança cega nos dados pode se tornar o “calcanhar de Aquiles” dos Sistemas de Apoio à Decisão. O foco central deste trabalho foi demonstrar as vulnerabilidades inerentes aos algoritmos de classificação em Sistemas de Apoio à Decisão.
Através da simulação foi possível observar que a tarefa de classificar é altamente sensível à integridade dos dados. Partimos da premissa de que algoritmos de classificação aprendem o que ensinamos a eles. Em nossa jornada, da teoria do Data Poisoning à simulação prática com detecção de fraudes, notou-se uma realidade preocupante: a matemática do aprendizado pode ser usada contra nós. Ao manipularmos os rótulos durante o treinamento, provamos que é possível deslocar a “fronteira de decisão”, levando o classificador a errar sistematicamente.
Para quem projeta sistemas de decisão baseado em classificação, a mensagem final é clara: a segurança não é uma etapa posterior ao desenvolvimento. Garantir a integridade do dado desde a origem é o caminho para assegurar que a decisão sugerida pela máquina seja, de fato, confiável.
ALVES, Aline; DUCATTI, Beatriz; MATHEUS, Heitor; SATO, Sofia; OLIVEIRA, Thyago. Estudo de caso: detecção de fraude em cartões de crédito. [S.l.]: Google Colab, 2025. Disponível em: https://colab.research.google.com/drive/1LP1pg5jvmU7fDS3G5hK3szXRiqaAyFSH?usp=sharing.
ALJANABI, Mohammad et al. Data poisoning: issues, challenges, and needs. IET Conference Proceedings, [S.l.], p. 359-363, 2024. Disponível em: https://doi.org/10.1049/icp.2024.0951.
KRANTZ, Tom; JONKER, Alexandra. What is data poisoning? [S.l.]: IBM. Disponível em: https://www.ibm.com/think/topics/data-poisoning.
MACHINE LEARNING GROUP – ULB. Credit card fraud detection. Versão 2. [S.l.]: Kaggle, 2018. Conjunto de dados. Disponível em: https://www.kaggle.com/datasets/mlg-ulb/creditcardfraud.
