Data and Model Poisoning

Corrupción que permanece en el sistema

Data and Model Poisoning aborda la manipulación o corrupción de datos y artefactos que introduce comportamiento dañino, sesgos relevantes o debilidades persistentes en un sistema AI. La condición queda incorporada a un activo reutilizable: datos, pesos, adaptadores, corpus, índices o memoria. No se limita a una respuesta incorrecta de una interacción aislada.

NIST AI 100-2e2025 ofrece una taxonomía de ataques de machine learning. La entrada de OWASP LLM 2026 utiliza además un alcance que incluye procesos inseguros como origen de corrupción. Al comparar fuentes debe aclararse si se habla de un ataque intencional o de una falla de integridad más amplia.

Qué se altera

Durante entrenamiento o fine-tuning, los datos pueden condicionar qué asociaciones y comportamientos aprende un modelo. En la distribución de modelos, puede cambiar el artefacto o alguno de los componentes que determinan su carga y uso. Que el nombre público permanezca igual no demuestra que se sirva el mismo contenido.

En una aplicación con retrieval, alterar un corpus o un índice puede cambiar la evidencia que futuras consultas seleccionan sin modificar los pesos del modelo. No conviene describir todo ese recorrido como reentrenamiento: los activos, las transformaciones y las posibilidades de recuperación son distintos.

Una evaluación aparentemente normal puede omitir la población o condición afectada. Un resultado aislado tampoco basta para afirmar que un modelo fue envenenado. La investigación necesita identificar el activo, el cambio, el mecanismo plausible y la evidencia que discrimina otras causas.

Poisoning y calidad de datos

Datos ausentes, etiquetas equivocadas y documentos obsoletos pueden producir resultados malos sin que sea útil clasificarlos automáticamente como poisoning. La pregunta de calidad de datos es más amplia que una amenaza de integridad, y un error accidental no demuestra un adversario.

La intención tampoco resuelve por sí sola todas las clasificaciones: una incorporación insegura puede dejar una corrupción duradera aunque no se haya probado quién la indujo. El informe debe separar la condición observada, el impacto, la hipótesis de origen y la terminología de la fuente empleada.

MLOps / LLMOps Operations distingue drift, regresión e incidente. Una distribución cambiante o una actualización con un bug no es evidencia suficiente de poisoning. Esas alternativas deben seguir abiertas cuando la causa todavía es desconocida.

Persistent Memory y Context Poisoning

Una memoria puede conservar una preferencia, un resumen o una regla que próximas sesiones incorporan como contexto. Si contenido no autorizado modifica ese estado y obtiene influencia posterior, el problema trasciende un turno. La publicación de OWASP Agentic Applications incluye Memory & Context Poisoning entre las preocupaciones de sistemas agentes.

Agent Memory conserva el mecanismo general de retención y recuperación. Aquí se examina su integridad: quién puede escribir, qué procedencia conserva, a qué tareas se aplica y cómo una revisión puede invalidar una entrada. No se crea un canonical separado por cada backend de memoria.

Prompt Injection puede inducir la escritura inicial. Sin embargo, una inyección no implica siempre persistencia, y una corrupción de memoria puede llegar por otra ruta de ingestión. La relación causal debe demostrarse para el sistema investigado.

Ejemplo: una excepción de pagos persistida

Un asistente de Commerce aprende de tickets para preparar futuros diagnósticos. Un ticket contiene una supuesta excepción que pide omitir un control de autorización. Si el sistema guarda esa frase como decisión aprobada, futuras investigaciones pueden recibirla sin el ticket original ni su contexto de confianza.

El error de diseño incluye promover material consultado a una regla duradera. La memoria debería conservar procedencia y alcance, y el consumidor no debería tratar una nota como una autorización técnica. Persistent Instructions explica por qué disponer de texto reutilizable no establece automáticamente su autoridad.

El ejemplo no demuestra que toda memoria sea insegura ni exige eliminarla. Permite preguntar qué actor podía escribir, qué validación faltó y qué información necesitan futuras sesiones para no repetir la atribución equivocada.

Prevención e investigación

La revisión puede seguir las transiciones de un activo: adquisición, transformación, evaluación, promoción y consumo. Versiones, procedencia, acceso de escritura y criterios de aceptación ayudan a relacionar el comportamiento con una entrada concreta. Son controles seleccionables, no una plataforma obligatoria.

AI Supply Chain Risk examina cómo llegan modelos, datasets y componentes externos. La cadena puede introducir poisoning, pero también otros problemas: una dependencia vulnerable o una herramienta que filtra datos no requiere haber alterado el comportamiento aprendido del modelo.

La recuperación depende del activo afectado. Puede requerir aislar una fuente, invalidar una memoria o índice, reconstruir un derivado, reemplazar un artefacto o evaluar nuevamente una versión. Borrar el registro original no demuestra que desaparecieron las copias o los efectos. Tampoco corresponde reentrenar por defecto si la corrupción estaba únicamente en una fuente recuperable.

Evidencia y límites

Conviene comparar referencias conocidas, conservar versiones y diseñar casos relacionados con el mecanismo sospechado. Una prueba con datos sintéticos puede observar si una entrada no autorizada persiste y afecta una ejecución posterior. AI Evaluation Fundamentals ayuda a interpretar qué generalización permite ese resultado.

Los detectores y pruebas tienen falsos negativos y límites de cobertura. Un hash demuestra identidad respecto de una referencia, no comportamiento seguro. Un score favorable tampoco demuestra que un artefacto carezca de condiciones ocultas. La conclusión debe describir qué se verificó y qué quedó sin resolver.

Fuentes y alcance

• NIST AI 100-2e2025.
• OWASP LLM Top 10 2026: Data and Model Poisoning.
• OWASP Top 10 for Agentic Applications.

Fuentes consultadas el 2026-11-05. El ejemplo y la organización de la investigación son síntesis editorial. No todo problema de datos se reclasifica como ataque ni se presupone una mitigación perfecta.