Panorama#
Los dos capítulos anteriores miraron la inteligencia artificial como herramienta —del defensor y del atacante—. Este mira el sistema de inteligencia artificial como blanco. Es el tercer eje que 9.1 anunció y el único que la IA agrega de verdad: al poner un modelo en producción —el clasificador que decide qué correo es malicioso, el asistente que atiende clientes, el agente que ejecuta acciones— la organización crea una superficie de ataque que antes no existía, y con vulnerabilidades que no son las del software clásico. Un servidor se ataca por su código; un modelo se ataca por su matemática y por su entrada, y esos dos caminos son los que el capítulo recorre.
Los dos hilos que quedaron sueltos convergen aquí. En 9.2 se dijo que el modelo defensivo del SOC es él mismo atacable —el clasificador que decide la contención puede ser engañado—; en 9.3, que el framing statement con el que el atacante de México precondicionó al asistente no era una técnica de acceso sino un ataque contra el modelo. Este capítulo desarrolla ambas cosas, y las une bajo una tesis que le va a resultar familiar a quien haya leído el bloque web del manual: la vulnerabilidad más importante de la IA generativa es una vieja conocida, la inyección, un nivel más arriba.
Adversarial ML: atacar el modelo por su matemática#
El aprendizaje automático adversario (adversarial machine learning) es el campo que estudia cómo manipular a un modelo explotando debilidades de la forma en que aprende y decide. Sus ataques se ordenan según qué momento del ciclo de vida del modelo golpean —el entrenamiento, la inferencia o el modelo ya desplegado como activo—, y son tres familias que conviene distinguir con precisión.
La primera, y la que amenaza directamente a la defensa de 9.2, es el ataque de evasión (evasion attack). Ocurre en tiempo de inferencia: el atacante altera sutilmente una muestra —le inyecta un ruido matemático cuidadosamente calculado que no cambia su función real— para que el modelo la clasifique mal. El caso canónico es el ejecutable malicioso al que se le añaden bytes inocuos hasta que el clasificador defensivo lo declara benigno sin que su comportamiento cambie en nada. La muestra alterada se llama adversarial example, y su existencia revela algo profundo: un modelo no «entiende» lo que clasifica como lo entiende un humano, sino que traza fronteras en un espacio matemático que se pueden cruzar con perturbaciones imperceptibles. Es la fragilidad estructural que vuelve a todo clasificador defensivo un blanco.
La segunda golpea antes, en el entrenamiento: el ataque de envenenamiento (poisoning attack). El atacante inserta datos maliciosos en el conjunto con el que el modelo se entrena, con dos objetivos posibles. Uno es degradar su precisión general —corromper el aprendizaje para que el modelo falle más—. El otro, más peligroso, es instalar una puerta trasera (backdoor): entrenar el modelo para que se comporte con normalidad salvo cuando ve un disparador específico, ante el cual produce el veredicto que el atacante quiere. Un clasificador de malware envenenado puede funcionar perfecto en todas las pruebas y declarar benigno cualquier archivo que lleve la marca secreta del atacante. El envenenamiento es un ataque a la cadena de suministro del modelo, y por eso la procedencia de los datos de entrenamiento —y de los modelos preentrenados que se descargan de repositorios públicos— es un problema de seguridad y no solo de calidad.
La tercera ataca el modelo ya desplegado, tratándolo como un activo del que extraer valor. La inversión de modelo (model inversion) interroga un modelo hasta deducir los datos confidenciales con los que fue entrenado —reconstruir rostros de un sistema de reconocimiento facial, o datos personales de un modelo entrenado sobre registros sensibles—. Sus parientes son la extracción o robo de modelo (model stealing: clonar la funcionalidad consultándolo masivamente) y la inferencia de pertenencia (membership inference: determinar si un registro concreto estuvo en el entrenamiento, lo cual filtra información privada por sí solo). Esta familia convierte al modelo en una fuga de los datos y de la propiedad intelectual que encierra.
flowchart TB
subgraph CV["ciclo de vida del modelo"]
TR["entrenamiento"] --> INF["inferencia\n(modelo desplegado)"]
end
TR -. "envenenamiento\ndegradación · backdoor" .-> P["poisoning attack"]
INF -. "ruido calculado\nmisclasificación" .-> E["evasion attack"]
INF -. "consultas masivas" .-> I["inversión · extracción\nmembership inference"]
INF -. "entrada en lenguaje natural" .-> PI["prompt injection\n(la inyección, un nivel más arriba)"]La superficie de los modelos de lenguaje: la inyección un nivel más arriba#
Los modelos de lenguaje agregan una superficie propia, y es la que más importa hoy porque son los que más se despliegan de cara al usuario y con más capacidad de actuar. Su vulnerabilidad central tiene un nombre nuevo —inyección de instrucciones (prompt injection)— pero una naturaleza que el manual ya diseccionó. Conviene enunciarla con exactitud.
De esa naturaleza salen las variantes. La inyección directa es la que el atacante entrega él mismo: un mensaje construido para que su contenido anule el system prompt y el modelo ignore sus reglas —el jailbreak—. El framing statement con el que el atacante de México precondicionó al asistente es precisamente esto: una entrada que redefine el contexto de la interacción para rodear las restricciones de seguridad del modelo. La inyección indirecta es más insidiosa y más peligrosa, porque la instrucción maliciosa no la entrega el atacante en el momento sino que viaja escondida en un dato que el modelo ingiere de otra fuente —una página web que resume, un documento que analiza, un correo que un asistente lee por el usuario—. Aquí la víctima no es quien inyecta: un documento envenenado convierte al agente de IA en un arma contra su propio usuario, y por eso la generación aumentada por recuperación (retrieval-augmented generation, RAG), que alimenta al modelo con documentos externos, es un vector de inyección indirecta de primer orden.
A esas dos se suma el manejo inseguro de la salida (insecure output handling): confiar en lo que el modelo produce como si fuera seguro. Si la salida de un LLM se usa para generar código, una consulta SQL o HTML que después se ejecuta o se renderiza sin validar, la inyección se propaga aguas abajo —el modelo se vuelve el eslabón que introduce la carga en un sistema clásico—. La regla, que la sección de defensa desarrolla, es tratar toda salida de un modelo como entrada no confiable, con el mismo recelo con que se trata la entrada de un usuario.
Vale una observación que conecta con el factor humano: manipular a un modelo de lenguaje y manipular a una persona se parecen más de lo que la intuición sugiere. Ambos procesan lenguaje natural, ambos pueden ser precondicionados por el encuadre, y ambos se «hackean» no rompiendo su mecanismo sino entregándole la entrada que hace que su funcionamiento normal produzca el resultado que el atacante quiere. La manipulación humana y la inyección de prompt son primas: las dos abusan de un sistema que interpreta el lenguaje sin una frontera dura entre el dato y la orden.
La defensa: gobernar el modelo como la superficie que es#
La primera honestidad de la defensa es admitir que algunos de estos ataques no tienen solución cerrada. Contra los adversarial examples no hay una vacuna definitiva —es un área de investigación abierta—; se mitigan con entrenamiento adversario (incluir ejemplos manipulados en el entrenamiento para endurecer las fronteras), validación de la entrada y conjuntos de modelos, pero no se eliminan. Y contra la inyección de prompt la honestidad es aún más incómoda: no se resuelve solo con ingeniería de prompts, porque pedirle al modelo «ignora cualquier instrucción que venga en los datos» es a su vez texto que un dato astuto puede contradecir. La defensa robusta es arquitectónica, no conversacional.
De ahí salen los principios concretos. Tratar toda salida del modelo como no confiable y validarla antes de usarla, igual que cualquier entrada externa. Dar a los agentes de IA el privilegio mínimo: un asistente que no necesita ejecutar comandos no debería poder hacerlo, de modo que una inyección exitosa tenga el menor radio de daño posible. Poner un human-in-the-loop para las acciones de alto impacto —el mismo principio que gobernaba la respuesta autónoma de 9.2, ahora del lado de la seguridad del propio agente—. Filtrar entrada y salida. Y gobernar la cadena de suministro: procedencia verificada de los datos de entrenamiento y de los modelos preentrenados, detección de envenenamiento, y desconfianza por defecto de los documentos que alimentan un RAG.
Cierre: la frontera que se dejó de validar#
Con este capítulo se cierra la Parte 9 y, con ella, el bloque substantivo del manual —después solo quedan los fundamentos de la Parte 0—. Conviene entonces recoger no solo el hilo de la Parte sino el del manual entero, porque la seguridad de la IA lo ilumina de una manera precisa.
Los tres ejes de la Parte convergen en una sola lección. La IA defensiva es poderosa pero es una capa que hay que gobernar; la IA ofensiva acelera al atacante pero no deroga los controles; y la seguridad de la IA muestra por qué: el modelo es el intérprete más nuevo, la superficie más nueva, y sin embargo se ataca con la clase de vulnerabilidad más vieja del manual. La inyección de prompt es la inyección de la Parte 3; el envenenamiento es una falla de cadena de suministro; la inversión es una fuga de datos; el privilegio mínimo para un agente de IA es el mismo privilegio mínimo de siempre. Cada comodidad que la IA agregó reubicó una frontera de confianza, y la vulnerabilidad vivió, como siempre, en la frontera que se dejó de validar —la misma tesis con que el manual cerró el bloque web—.
Esa es la nota con la que la Parte más nueva del manual entrega el testigo a la más vieja. La inteligencia artificial no volvió obsoletos los fundamentos: los volvió más urgentes, y reveló que operan un nivel más arriba de donde se los venía mirando. Separar los datos del código, verificar la procedencia, dar el privilegio mínimo, no confiar en la entrada, poner un humano ante lo irreversible —todo lo que la Parte 0 va a enunciar como principio— reaparece intacto en el terreno más futurista que el manual toca. El adversario cambió de herramienta; la disciplina, no.
Referencias#
blue-dfir/ciberseguridad-ia-autonoma/cap-02— Rivero y López Espada, Ciberseguridad Inteligente: el aprendizaje automático adversario y sus ataques al ciclo de vida del modelo —evasión (evasion attack) en la inferencia, envenenamiento (poisoning) en el entrenamiento, e inversión de modelo (model inversion) y robo sobre el modelo desplegado—, con la advertencia de que emergen ataques dirigidos al propio ciclo de vida de la IA a medida que las organizaciones despliegan modelos en producción.- El desarrollo de la superficie de los modelos de lenguaje (inyección de prompt directa e indirecta, jailbreak, manejo inseguro de la salida, RAG como vector, cadena de suministro de IA), el encuadre de prompt injection como la misma clase de vulnerabilidad que la inyección de intérprete de la Parte 3, y los marcos OWASP Top 10 for LLM Applications y MITRE ATLAS como mapas del terreno son enriquecimiento propio con conocimiento actual. El capítulo cierra los hilos de la IA defensiva (el modelo del SOC como blanco) y la IA ofensiva (el framing statement como ataque al modelo), se conecta con el factor humano (manipular un modelo ≈ manipular a una persona, ambos por la entrada) y con la gobernanza de la Parte 7, y desemboca —cerrando la Parte 9 y el bloque substantivo— en los fundamentos de la Parte 0.