Capítulo 1 — Por qué la seguridad de la IA es diferente

Primera entrega del recorrido capítulo por capítulo de LLM Primer VII: Seguridad de la IA. El capítulo que sostiene que la seguridad de la IA no es simplemente la seguridad tradicional con un adjetivo de ML pegado detrás — el sustrato ha cambiado, y cada capítulo posterior se deriva de ese cambio.

Por qué existe este capítulo

Durante tres décadas, la ingeniería de seguridad ha descansado sobre un cimiento estable: código y datos son cosas distintas, las vulnerabilidades son discrepancias entre el comportamiento especificado y el real, y los parches las cierran. Los grandes modelos de lenguaje rompen este cimiento de una forma específica. El comportamiento que hay que defender no está codificado en código fuente sino en miles de millones de pesos aprendidos, ejecutados contra entradas que mezclan instrucciones confiables con contenido no confiable en la misma cadena. La «vulnerabilidad» a menudo no es un bug — es el modelo haciendo exactamente aquello para lo que fue entrenado, en un contexto que sus diseñadores no anticiparon. No hay parche para «el modelo fue demasiado servicial». Solo hay rediseño, reentrenamiento o contención adicional. Este capítulo nombra las diferencias estructurales que conforman todo lo que viene después.

1.1 El sustrato ha cambiado

La seguridad tradicional de aplicaciones funciona porque el comportamiento está especificado en código y los defectos son localizables. La inyección SQL tiene una corrección estructural — las consultas parametrizadas — porque existe una distinción sintáctica entre consulta y parámetro. Un modelo de lenguaje no tiene tal especificación. Tiene un objetivo de entrenamiento y una distribución de pesos, y su comportamiento sobre cualquier entrada concreta es emergente. Cuando un modelo rechaza una formulación y accede a otra, no hay una línea que corregir. La pregunta de seguridad pasa de «¿hay un bug en esta ruta de código?» a «¿de qué es capaz este sistema y bajo qué condiciones esa capacidad se vuelve peligrosa?». La seguridad tradicional también asumía el determinismo como línea base; aquí la línea base es probabilística. Un filtro de seguridad que triunfa sobre mil casos de prueba puede fallar en el mil-y-uno porque el sampling tomó otra trayectoria. El defensor razona en distribuciones y en intervalos de confianza, no en pruebas de inalcanzabilidad. El OWASP Top 10 para aplicaciones LLM, revisado en 2025, es un intento de nombrar esta nueva capa — con la inyección de prompts en el LLM01 y el consumo no acotado en el LLM10 — pero es un piso por encima del piso web ya existente, no un reemplazo.

1.2 La superficie de ataque se amplía

Una aplicación integrada con un LLM introduce superficies que antes no existían. El prompt en sí es una concatenación de instrucciones del desarrollador, contexto recuperado, entrada del usuario y salidas de herramientas — todo como tokens que el modelo lee sin fronteras de confianza nativas. Si el usuario puede influir en cualquier porción, comparte el mismo canal que el desarrollador. La ruta de recuperación es la segunda superficie nueva: cada documento indexado se convierte en una entrada indirecta, y cualquiera que pueda influir en lo que entra al índice puede influir en lo que el modelo ve. Greshake y sus colegas nombraron esto en 2023 como inyección indirecta de prompts y demostraron que el canal era tanto real como difícil de cerrar. La frontera de uso de herramientas es la tercera: cada herramienta concedida al modelo es un privilegio cuyas consecuencias salen del texto de respuesta y llegan a sistemas reales. El pipeline de entrenamiento es la cuarta, ya que cualquier dato usado para actualizar el modelo pasa a formar parte de la frontera de confianza. El artefacto del modelo es la quinta — binarios grandes cuya deserialización, como demostró CVE-2024-3568, puede ejecutar código al cargarse. El manejo de la salida es la sexta, dado que el contenido generado por el modelo y reenviado aguas abajo es entrada no confiable con otro nombre. MITRE ATLAS cataloga las tácticas y técnicas contra esta superficie ampliada.

1.3 Los modelos se están convirtiendo en infraestructura

Entre 2012 y 2022, los modelos eran funcionalidades dentro de aplicaciones. Un sistema de recomendación que fallara producía peores recomendaciones. Los grandes modelos de lenguaje, especialmente con uso de herramientas, han cambiado eso. El modelo es cada vez más la capa de orquestación — lee documentos, decide qué herramienta llamar, redacta el mensaje, genera el código que otro componente ejecuta. Es a menudo el componente más poderoso del sistema y también el más maleable, guiado por entradas en lenguaje natural que cualquiera puede redactar. Una base de datos tradicional tiene lenguajes de consulta y controles de acceso; un LLM actuando como orquestador no tiene ninguna de esas restricciones intrínsecas, solo las que la aplicación circundante ha añadido. Eso es lo que significa aquí «infraestructura»: componentes portantes cuyo compromiso se propaga. La infraestructura recibe SLOs definidos, logging exhaustivo, control de cambios y respuesta a incidentes. La mayoría de los despliegues de LLM a lo largo de 2024 y 2025 aún no habían alcanzado esa madurez. El marco de infraestructura también llega al aprovisionamiento: cuando una organización empotra un servicio LLM gestionado en su stack, la disciplina de actualización de modelos del proveedor, sus puertas de evaluación y sus prácticas de divulgación pasan a formar parte del perfil de riesgo del comprador.

Lo que prepara el Capítulo 1

El resto del libro es una respuesta a los desplazamientos estructurales aquí nombrados. El capítulo 2 introduce el modelado de amenazas adaptado a sistemas LLM — los marcos STRIDE y PASTA orientados hacia activos, adversarios y superficies de ataque que no aparecen en los diagramas convencionales. El capítulo 3 recorre la dimensión de datos a lo largo de todo su ciclo de vida. Los capítulos 4 a 6 recorren el interior de prompt e interacción: inyección, filtrado y RAG. Los capítulos 7 a 9 recorren la capa del modelo. Los capítulos 10 a 12 recorren la arquitectura del sistema alrededor. Los capítulos 13 a 15 añaden el perímetro regulatorio, de IA responsable y organizacional. El capítulo 16 recorre el ajuste fino como su propia superficie de seguridad, y el capítulo 17 mira las amenazas que aún están tomando forma. Todo el arco descansa sobre la premisa que este capítulo ha establecido: el sustrato ha cambiado, y la disciplina tiene que cambiar con él.

Próximamente — Capítulo 2: Modelado de amenazas para sistemas LLM. Las cuatro preguntas de Shostack, STRIDE y PASTA contra los activos de un LLM, y MITRE ATLAS como catálogo de tácticas para los adversarios que atrae esta nueva superficie.