Casi todo el esfuerzo de seguridad sobre sistemas de IA se concentra en el momento de la consulta: qué escribe el usuario, qué responde el modelo, qué filtros hay en medio. Es razonable, porque es lo que se puede observar. El problema es que hay una familia de ataques que ya terminó cuando el sistema entra en producción, y para la que no existe ningún registro que revisar después.
El envenenamiento de datos consiste en introducir contenido manipulado en el material que forma o alimenta al modelo, de modo que el comportamiento indeseado quede incorporado desde el origen. No hay intrusión que detectar ni tráfico anómalo que correlacionar: hay un conjunto de datos que alguien incorporó y que nadie revisó a fondo, porque revisarlo era caro y no parecía necesario.
Tres puntos de entrada, tres niveles de exposición real
El corpus de preentrenamiento
Es el caso del que más se habla y el menos relevante para la mayoría, porque casi ninguna organización entrena un modelo base. Aun así conviene entenderlo, porque define el riesgo que heredas del proveedor. Los corpus de preentrenamiento se construyen a partir de material público a gran escala, y ese material es editable por terceros. La conclusión práctica es limitada pero clara: el modelo que consumes llega con un comportamiento que no auditaste y que no puedes auditar, y esa es una razón de peso para no apoyar controles críticos exclusivamente en el criterio del modelo.
Las fuentes de ajuste fino
Aquí sí decide tu equipo, y aquí es donde vemos la exposición más concreta. El ajuste fino se alimenta de documentación interna, transcripciones de soporte, tickets, correos y —el caso más delicado— conversaciones que los propios usuarios marcaron como buenas respuestas. Cuando ese canal de retroalimentación está abierto al público, cualquiera puede aportar ejemplos de entrenamiento con la etiqueta que quiera. Es una entrada de datos que atraviesa el perímetro y que rara vez se trata como tal.
El mismo razonamiento aplica a los conjuntos descargados de repositorios abiertos. Se incorporan con la misma ligereza con la que hace una década se incorporaban dependencias de código, y por las mismas razones: están disponibles, funcionan y revisarlas no es el trabajo de nadie en particular.
La base vectorial de RAG
Es el punto más expuesto y el que menos atención recibe. En una arquitectura de recuperación, el índice vectorial determina qué texto entra al contexto del modelo en cada consulta. Contaminarlo no requiere entrenar nada: basta con lograr que un documento manipulado quede indexado y se recupere cuando corresponda. Si el proceso de ingesta toma documentos de una carpeta compartida, de un wiki interno abierto a colaboradores o de un buzón de correo, la barrera de entrada es baja.
Este vector tiene una propiedad que lo hace especialmente incómodo: el atacante no necesita acertar el momento. Deposita el contenido y espera a que alguien haga la pregunta adecuada. Además, el efecto es inmediato y no requiere un ciclo de reentrenamiento. La contracara es que también se corrige rápido, siempre que sepas qué documentos entraron. Sobre cómo estructurar esa capa escribimos en nuestro artículo sobre RAG con control de acceso.
Por qué la detección posterior funciona mal
Un modelo contaminado no se comporta de forma anómala. Ese es el punto central y la razón por la que las herramientas de monitoreo habituales aportan poco. El objetivo del atacante suele ser un comportamiento condicionado: el sistema responde con normalidad salvo cuando aparece un patrón específico, elegido para no ocurrir por casualidad. Las métricas agregadas de calidad no lo detectan, porque el rendimiento promedio no cambia.
A eso se suma la ausencia de diferencial. En software puedes comparar el binario desplegado con el código fuente y ver qué cambió. Con un modelo ajustado no existe esa operación: los pesos son distintos a los de ayer por definición, y ningún análisis de esos números te dirá cuál de los miles de ejemplos de entrenamiento causó qué. La única trazabilidad disponible es la que hayas construido antes, sobre los datos.
Con un modelo no puedes auditar el resultado, solo el proceso. Si no registraste qué entró, no hay análisis posterior que lo reconstruya.
Los controles que sí aplican: procedencia
Todos los controles útiles en este terreno son, en el fondo, el mismo control aplicado en distintos puntos: saber de dónde viene cada cosa y poder demostrarlo.
- Inventario de fuentes con responsable nombrado. Cada conjunto de datos que alimenta un entrenamiento, un ajuste o un índice necesita origen, fecha de incorporación y una persona que respondió por él. Sin esto, ninguno de los controles siguientes es verificable.
- Versiones congeladas y verificables. Trabaja sobre instantáneas inmutables con integridad comprobable, no sobre carpetas vivas. La pregunta que debes poder responder es con qué datos exactos se produjo la versión del modelo que está en producción hoy.
- Separación entre fuentes confiables y aportadas. El material que llega de usuarios, de proveedores o de internet no debería mezclarse con el material curado sin una etapa de revisión explícita y sin quedar marcado como tal en el índice.
- Control de escritura sobre el índice vectorial. Trata la ingesta como una interfaz privilegiada: quién puede escribir, desde qué proceso, con qué registro. Es el punto donde una corrección tardía todavía es barata.
- Evaluación con casos propios y versionados. Un conjunto de pruebas que incluya los temas sensibles de tu negocio, ejecutado en cada cambio de datos o de modelo. No detecta un disparador desconocido, pero sí detecta desviaciones en lo que te importa.
La conclusión operativa es que este riesgo se gestiona con disciplina de cadena de suministro, no con detección. Si tu organización ya tiene un proceso para aprobar dependencias de software, el trabajo consiste en extenderlo a conjuntos de datos, corpus indexados y modelos, con las mismas preguntas de siempre: quién lo publicó, qué versión estamos usando, quién autorizó su incorporación y qué haríamos si mañana resulta estar contaminado. Esa última pregunta es la que más incomoda, porque exige tener la capacidad de reconstruir el índice o de volver a una versión anterior del modelo. Conviene comprobar que existe antes de necesitarla, y encaja de forma natural en el sistema de gestión que describe ISO/IEC 42001 llevada a la práctica.