Seguridad de IA: categorías de ataque, brechas defensivas y cómo responder

La seguridad de IA abarca las prácticas, herramientas y marcos usados para proteger sistemas de inteligencia artificial de manipulación, explotación y acceso no autorizado. Para equipos de seguridad gestionando despliegues de IA en 2026, la superficie de amenaza ha crecido considerablemente: los adversarios ahora apuntan no solo a la infraestructura que corre IA, sino a los modelos mismos, sus datos de entrenamiento y el pipeline de inferencia. Este post mapea las categorías de ataque, las brechas en las defensas actuales y dónde enfocar el esfuerzo de mitigación.

Las cuatro categorías de ataque

NIST publicó Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations (AI.100-2) en enero de 2024, estableciendo cuatro categorías principales de ataque contra sistemas ML. Esa taxonomía sigue siendo la referencia base para profesionales evaluando riesgo IA/ML.

Ataques de evasión ocurren post-despliegue. Un adversario construye entradas específicamente para causar clasificación errónea o comportamiento inesperado sin modificar el modelo. Ejemplo canónico: modificar imágenes de señales de tránsito con perturbaciones imperceptibles de píxel para causar que sistemas de vehículos autónomos lean mal una señal de alto. Contra LLMs, los ataques de evasión típicamente toman la forma de sufijos adversarios —cadenas de caracteres añadidas a prompts que desplazan confiablemente las salidas del modelo a pesar de no contener instrucción legible para humanos—.

Ataques de envenenamiento apuntan a la fase de entrenamiento. Al inyectar muestras maliciosas en datos de entrenamiento o datasets de fine-tuning, un atacante puede introducir backdoors que se activan en entradas gatillo específicas mientras dejan intacto el rendimiento general. NIST nota que el envenenamiento puede lograrse controlando “unas pocas docenas de muestras de entrenamiento” en datasets grandes —una barra baja para un adversario bien posicionado—.

Ataques de privacidad sondean modelos desplegados para extraer datos de entrenamiento o internos del modelo. La inferencia de membresía determina si un registro específico estaba en el conjunto de entrenamiento. Los ataques de extracción de modelo reconstruyen un modelo propietario consultándolo a escala. Ambas clases han producido exploits funcionales contra APIs comerciales.

Ataques de abuso alimentan información falsa a fuentes que el sistema de IA consumirá: bases de conocimiento, corpus RAG o páginas web que el modelo trata como verdad. La investigación etiquetada “PoisonedRAG” demostró que insertar cinco documentos maliciosos en un corpus de millones causó que un LLM aumentado por recuperación devolviera respuestas falsas especificadas por el atacante para consultas dirigidas el 90% del tiempo.

El reporte de NIST es inequívoco sobre la postura defensiva: “no hay todavía manera infalible de proteger a la IA del extravío”. Las mitigaciones publicadas “actualmente carecen de garantías robustas de que mitigan completamente los riesgos”.

Inyección de prompts: la prioridad operacional

El OWASP LLM Top 10 para 2025 ↗ coloca a la inyección de prompts en la posición uno (LLM01). La clasificación refleja tanto frecuencia como severidad en despliegues de producción. A diferencia de las cuatro categorías anteriores, la inyección de prompts no requiere acceso en tiempo de entrenamiento —se ejecuta a través de canales normales de inferencia usando entradas que el sistema está diseñado para aceptar—.

Inyección directa manipula el comportamiento del modelo a través de entradas de usuario construidas: jailbreaks, framing de role-play, overrides de instrucción. Inyección indirecta es operacionalmente más peligrosa: instrucciones maliciosas embebidas en contenido externo que el sistema de IA recupera y procesa. Un documento, página web o correo que el modelo lee en nombre del usuario puede contener instrucciones que alteran el comportamiento para toda la sesión —exfiltrando contexto, tomando acciones no autorizadas mediante herramientas conectadas, o propagando instrucciones inyectadas a consultas subsecuentes—.

Para agentes de IA con acceso a herramientas —sistemas que pueden ejecutar código, navegar la web o gestionar archivos—, la inyección indirecta eleva de divulgación de información a ejecución de acción arbitraria. El ataque tiene éxito silenciosamente desde la perspectiva del usuario.

La guía de mitigación de OWASP se centra en restringir el comportamiento del modelo mediante prompts de sistema detallados, imponer mínimo privilegio para acceso a herramientas, segregar contenido externo no confiable, validar formatos de salida y requerir aprobación humana para acciones de alto riesgo. La guía reconoce que “la prevención infalible sigue siendo incierta debido a cómo opera fundamentalmente la IA generativa”. Defensa en profundidad, no un control único, es la postura operacional.

aisec.blog ↗ rastrea el desarrollo de ataques en esta área, incluyendo inyección multimodal, investigación de sufijos adversarios y técnicas de explotación de agentes.

Riesgo de cadena de suministro en sistemas ML

Los sistemas de IA cargan exposición de cadena de suministro en múltiples capas: pesos de modelos preentrenados, frameworks ML (PyTorch, TensorFlow, ONNX), stacks de servicio de modelos (vLLM, TGI, Triton), librerías de orquestación (LangChain, LlamaIndex), y dependencias de bases de datos vectoriales. Cada capa es un punto de entrada independiente de las propiedades de seguridad del modelo.

Los CVEs a nivel de framework en infraestructura de servicio ML han aparecido con frecuencia creciente. Comprometer un stack de servicio logra ejecución de código en el host que corre el modelo, evadiendo controles a nivel de modelo por completo. Fallos de deserialización, path traversal y vulnerabilidades SSRF han aparecido en componentes ML ampliamente usados en los últimos dos años.

El riesgo de cadena de suministro se extiende a los pesos del modelo. Los archivos de modelo en formato pickle —el formato de serialización por defecto de PyTorch— pueden embeber código Python arbitrario que se ejecuta al cargar. Hugging Face ha promovido Safetensors como alternativa más segura, pero los pesos pickle siguen siendo comunes. Cualquier archivo de modelo cargado de una fuente externa o comunitaria sin verificación es un ejecutable sin firmar.

mlcves.com ↗ mantiene una base de datos consultable de CVEs específicos de ML entre frameworks y stacks de servicio, organizada por producto y severidad, útil para rastrear exposición en un inventario de componentes conocidos.

Gestionar el riesgo de seguridad de IA: el marco NIST

NIST publicó el AI Risk Management Framework (AI RMF 1.0) ↗ en enero de 2023 y lo extendió con un Perfil de IA Generativa en julio de 2024 abordando riesgos específicos de modelos fundacionales y sistemas RAG. El marco organiza la gestión de riesgo en cuatro funciones: Gobernar, Mapear, Medir y Gestionar.

Para equipos de operaciones de seguridad, las salidas prácticas son:

• Mapear componentes de IA y sus flujos de datos antes del despliegue, identificando dónde entra contenido externo al pipeline.
• Medir el comportamiento del modelo contra fronteras de uso aceptable definidas y marcar deriva de distribuciones de salida esperadas.
• Gestionar monitoreo en runtime para patrones de salida anómalos —secuencias inusuales de llamada a herramientas, respuestas fuera de esquema, referencias inesperadas a datos—.
• Gobernar el acceso a sistemas de IA y sus herramientas conectadas, con logs de auditoría cubriendo entradas y salidas del modelo.

Prioridades de mitigación

Ningún control solo cierra la brecha de seguridad de IA. La mejor práctica actual apila varios:

1. Validación de entrada y filtrado de salida. Rechaza o marca entradas que coincidan con patrones de inyección conocidos. Valida que las salidas se ajusten a esquemas esperados antes de actuar sobre ellas.
2. Acceso de mínimo privilegio a herramientas. Los agentes de IA deben tener los permisos mínimos necesarios. Revoca acceso a APIs sensibles o sistemas de archivo a menos que sea específicamente requerido.
3. Monitoreo en runtime. Loguea entradas y salidas del modelo. La detección de anomalías sobre patrones de respuesta puede sacar a la superficie intentos de inyección indirecta y deriva conductual antes de que el daño se acumule.
4. Endurecimiento de dependencias. Fija versiones de framework ML, audita archivos de modelo antes de cargar, prefiere Safetensors sobre pickle, y rastrea CVEs en tu stack de servicio proactivamente.
5. Red team antes del despliegue. La prueba adversaria que incluye inyección indirecta, explotación multi-paso de agente y simulación de cadena de suministro debe preceder al rollout a producción de cualquier sistema de IA con acceso a herramientas.