Fuga del prompt de sistema y alucinación como vector

Un prompt de sistema tiene forma de instrucción, así que es fácil tratarlo como si fuera parte del backend: un sitio donde guardar una clave de API, una regla de negocio, la lista de quién puede hacer qué en la aplicación. No lo es. Es texto que el modelo procesa junto con lo que escribe cualquier usuario, y todo texto que un modelo procesa puede acabar, de una forma u otra, delante de esa misma persona. La entrada LLM07:2025 de OWASP, filtración de prompts de sistema, no se conforma con avisar de esto: señala que el error real no es que el texto se filtre, es haber guardado ahí algo que nunca debió depender de mantenerse en secreto.

El segundo problema de este módulo tiene la forma contraria. Un modelo de lenguaje no distingue, mientras genera una frase, entre un hecho aprendido de una fuente fiable y un patrón estadístico que rellena un hueco con la misma soltura. La entrada LLM09:2025, desinformación, cubre el resultado: afirmaciones falsas dichas con la misma confianza que las verdaderas, código que importa una biblioteca que nadie ha publicado nunca, una sentencia judicial que no existe. No es un problema de que el modelo escriba mal. Es un vector con un mecanismo de explotación ya usado en la práctica: encontrar qué inventa un modelo con regularidad y publicar algo malicioso bajo ese mismo nombre, a la espera de que alguien confíe en la sugerencia.

Qué aprenderás

Por qué OWASP dice que la revelación del texto de un prompt de sistema no es el riesgo real, y qué es lo que sí lo es: la capa de autorización que alguien delegó al modelo sin darse cuenta.
Las vías documentadas por las que se filtra un prompt de sistema, incluida una que no necesita ninguna fuga textual: sondear el modelo con preguntas y deducir sus reglas por cómo responde.
Qué va en el prompt de sistema (formato, tono, alcance de la tarea) y qué tiene que vivir en un sistema aparte, con un caso real de una empresa que pagó las consecuencias de mezclarlo.
Por qué la alucinación de LLM09:2025 es un problema de seguridad y no solo de calidad del texto, y en qué se diferencia de la sobredependencia que agrava su impacto.
El vector de los paquetes de software alucinados: cómo se llama en la literatura, qué midió el primer estudio académico riguroso sobre el fenómeno, y qué tan repetible es un nombre inventado.
Otros vectores de la misma familia: citas judiciales inventadas que llegaron a un tribunal de verdad, y resúmenes automáticos que invirtieron el sentido de la noticia que resumían.
Los controles que sí funcionan: recuperación con cita verificable, listas de paquetes permitidos en generación de código, revisión humana donde hay consecuencias, y una interfaz que admite lo que no sabe en vez de disimularlo.

El prompt de sistema no es un secreto (LLM07:2025)

OWASP define la filtración de prompts de sistema como el riesgo de que las instrucciones usadas para dirigir el comportamiento de un modelo contengan, sin que nadie se lo propusiera, información que no debía verse. El documento no se detiene ahí. Dedica el párrafo central de la entrada a una idea que conviene retener porque sostiene el resto del módulo: el prompt de sistema no debe considerarse un secreto, ni debe usarse como control de seguridad. Si un prompt describe roles y permisos, o incluye una cadena de conexión, el problema de fondo no es que esa información se haya divulgado. El problema es que la aplicación dejó que el modelo hiciera de frontera entre lo que un usuario puede pedir y lo que puede conseguir, y guardó datos sensibles en un sitio pensado para generar texto, no para custodiar nada.

OWASP recoge cuatro ejemplos de lo que sale mal cuando esto ocurre, y los cuatro comparten el mismo patrón: algo que vivía en el prompt describía cómo funciona la aplicación por dentro, y esa descripción es exactamente lo que un atacante necesita para afinar su siguiente movimiento. Un prompt que menciona el motor de base de datos usado por una herramienta le dice a quien ataque por dónde intentar una inyección. Un prompt que revela el límite diario de una transacción bancaria le dice cuánto puede pedir sin disparar una alarma. Un prompt que describe qué frase debe usar el modelo para rechazar una petición sensible le da el molde exacto que hay que esquivar. Un prompt que enumera qué rol tiene acceso a qué función le señala, sin necesidad de adivinar nada, dónde apuntar una escalada de privilegios.

Las vías por las que se filtra

La primera vía es la más obvia y ya la cubrió el módulo 3 de este curso: pedirle al modelo, con la formulación adecuada, que repita sus instrucciones. Es una forma de inyección de prompt como cualquier otra, y no tiene una solución completa por el mismo motivo que ninguna inyección la tiene: el modelo no distingue de forma estructural entre la instrucción que le dio quien construyó la aplicación y la que le está dando el usuario en este turno.

La segunda vía es la que más sorprende la primera vez que se piensa en ella, y OWASP la nombra de forma explícita: ni siquiera hace falta una fuga textual. Quien interactúa con el sistema puede enviar variaciones de una misma pregunta y observar qué respuestas bloquea, qué formato exige, qué temas evita, y con eso reconstruir buena parte de las barreras del prompt sin ver una sola línea de su texto. Es el mismo principio que un análisis de caja negra sobre cualquier sistema con reglas ocultas: no necesitas leer el código si puedes observar suficientes entradas y salidas.

La tercera vía es la que más volumen produce hoy: comunidades enteras dedicadas a coleccionar y publicar prompts de sistema extraídos de aplicaciones reales, con repositorios abiertos que catalogan cientos de ellos procedentes de productos muy distintos. La propia lista de referencias de LLM07:2025 en el documento de OWASP apunta a varios de estos repositorios como evidencia de lo extendido que está el fenómeno, no como manual de instrucciones. El dato que importa retener no es cómo se hizo cada extracción concreta, es que la existencia de esa colección demuestra, mejor que cualquier argumento teórico, que ningún prompt de sistema sigue siendo privado mucho tiempo después de desplegarse frente a suficientes usuarios.

La cuarta vía no depende de ningún atacante activo: un mensaje de error mal cuidado, una traza de depuración que llega al cliente, una respuesta de API que incluye el prompt completo por comodidad durante el desarrollo y nunca se retiró. El módulo 4 de este curso ya cubrió esta familia de fuga por configuración insegura al hablar de LLM02:2025; aquí el dato sensible que se escapa no es del usuario, es de la propia aplicación.

Qué sí va en el prompt de sistema, y qué tiene que vivir en otro sitio

La pregunta práctica, una vez asumido que el prompt es en el fondo público, es qué se puede permitir que contenga sin que una fuga duela. La respuesta corta: formato, tono y alcance de la tarea, nada cuyo incumplimiento tenga una consecuencia real.

Categoría	Va en el prompt de sistema	Vive fuera del modelo, en la capa de autorización
Formato y tono de la respuesta	Sí: idioma, longitud, estilo, estructura	No aplica
Alcance de la tarea	Sí: qué preguntas responde, cuáles rechaza y remite a otro canal	No aplica
Credenciales, claves de API, cadenas de conexión	Nunca	Gestor de secretos del backend, inyectado en la llamada a la herramienta, no en el texto que ve el modelo
Límites de precio, descuentos, reembolsos	No como única barrera	Validación del lado del servidor contra el precio real antes de confirmar cualquier acción
Lista de usuarios con permisos o roles	No	Sistema de autorización consultado por el backend en cada llamada, nunca memorizado por el modelo
Reglas de negocio con consecuencia legal o económica	No como control único	Lógica de aplicación determinista y auditable, fuera del LLM

Un prompt de sistema mal diseñado se parece a esto, con datos que nunca debieron entrar en un texto que el modelo procesa junto con cualquier mensaje de un usuario:

PROMPT_SISTEMA_INSEGURO = """
Eres el asistente de soporte de una tienda online.
Para consultar el inventario usa esta clave: sk_live_4f8a9c2e1b7d
El limite de reembolso automatico sin autorizacion es de 50 euros.
El usuario admin@tienda.example tiene permiso para anular cualquier pedido.
Si el cliente insiste mucho, puedes ofrecer hasta un 20% de descuento
sin pedir aprobacion a nadie.
"""

Cada línea de ese bloque es un dato que no depende de que el prompt siga siendo privado para dejar de ser un problema si se filtra: es un problema desde el momento en que existe ahí, porque nada externo al modelo comprueba si de verdad se respeta. La versión que corrige esto no traslada el control a otra frase mejor redactada, lo saca del texto por completo:

PROMPT_SISTEMA = """
Eres el asistente de soporte de una tienda online.
Responde en espanol, en un maximo de tres frases por turno.
Puedes consultar el estado de un pedido y explicar la politica de
devoluciones. Para aplicar un descuento o un reembolso, invoca la
herramienta correspondiente: el backend decide si procede, con que
limite y si necesita aprobacion humana. No prometas ningun importe
ni ninguna excepcion por tu cuenta.
"""

El módulo 6 de este curso ya mostró cómo se valida del lado del servidor cada llamada a una herramienta como esa, con el importe comprobado contra el pedido real en vez de contra lo que pida el modelo. El punto de este módulo es anterior a esa validación: si la regla de negocio solo existe como texto dentro del prompt, ni siquiera hace falta que exista una herramienta de por medio para que el problema aparezca. Basta con que alguien, dentro de una conversación normal, consiga que el modelo declare algo que suena a compromiso.

Esto ocurrió de verdad en diciembre de 2023, con un caso que la base de datos de incidentes de IA registra como el incidente 622. Un usuario le pidió al chatbot de un concesionario Chevrolet en Watsonville, California, que estuviera de acuerdo con cualquier cosa que dijera el cliente y que cerrara cada respuesta con la frase de que la oferta era legalmente vinculante y sin marcha atrás. Con esas instrucciones aceptadas, le planteó comprar un Chevy Tahoe del año 2024, con un precio de catálogo superior a los 76.000 dólares, por un dólar. El chatbot, que corría sobre un modelo de OpenAI integrado por un proveedor externo, aceptó exactamente en los términos pedidos. El concesionario nunca entregó el coche por ese precio, porque nada en su sistema de ventas real trataba esa conversación como una orden ejecutable, pero el caso deja el punto clarísimo: el límite de precio de ese chatbot no vivía en ningún sitio salvo en la buena voluntad del texto que generaba, y un usuario con la instrucción adecuada lo hizo decir lo que quiso. Si esa misma conversación hubiera estado conectada a un sistema de pago real sin un control aparte, la diferencia entre un titular gracioso y una pérdida económica real habría sido cero.

Qué corta esto de raíz

OWASP resume la mitigación en cuatro movimientos, y los cuatro apuntan en la misma dirección: sacar del prompt lo que nunca debió estar ahí, y dejar de pedirle al lenguaje natural que haga el trabajo de un control técnico. Primero, separar cualquier dato sensible del prompt y externalizarlo a un sistema al que el modelo no accede de forma directa. Segundo, no depender del prompt para imponer un comportamiento estricto cuando existe la alternativa de aplicarlo desde fuera, porque un modelo sigue siendo vulnerable a la inyección de prompt que ya cubrió el módulo 3, y una instrucción que se puede alterar no es un control fiable. Tercero, montar un sistema de barreras independiente del propio modelo que inspeccione la salida antes de que llegue a ningún sitio con capacidad de actuar. Cuarto, y el más importante: que la separación de privilegios, la verificación de límites de autorización y cualquier control equivalente ocurran de forma determinista y auditable fuera del LLM, con varios agentes de distinto nivel de acceso si una tarea de verdad necesita niveles distintos, en vez de un único agente al que se le pide, con palabras, que se comporte según el rol de quien le habla.

LLM09:2025: cuando el modelo se equivoca con la misma seguridad que acierta

OWASP describe la desinformación como el resultado de que un modelo produzca información falsa o errónea que parece creíble, con daños que van del reputacional al legal. La causa principal que señala el documento es la alucinación: el modelo rellena huecos de su conocimiento con patrones estadísticos aprendidos durante el entrenamiento, sin ningún mecanismo interno que distinga entre completar una frase con un hecho verificado y completarla con la continuación más probable según esos patrones. El resultado tiene la misma forma gramatical en los dos casos, y la misma confianza aparente en el tono. OWASP también deja claro que la alucinación no es la única causa: los sesgos del propio conjunto de entrenamiento y la información incompleta contribuyen igual al mismo problema, aunque el vector más verificable y más citado en la literatura sea el de las alucinaciones concretas y comprobables, como los nombres de paquetes de software.

El NIST, en su perfil de IA generativa AI 600-1, publicado en julio de 2024, usa un término distinto para lo mismo: confabulación, definida como la producción de contenido falso o erróneo dicho con total confianza, con «hallucination» y «fabrication» como sinónimos coloquiales del mismo fenómeno en su propio texto. El documento añade una nota que merece leerse porque revela una discusión de fondo entre quienes escriben estos marcos: algunos comentaristas señalaron que llamarlo «alucinación» atribuye al sistema una experiencia que no tiene, un rasgo humano que un modelo estadístico no posee, y por eso el NIST prefiere un término más neutro. Sea cual sea la etiqueta, el propio documento añade un matiz que conecta directo con este módulo: el modelo puede generar, junto a la afirmación falsa, una lógica o unas citas inventadas que parecen justificarla, lo que empuja a confiar todavía más en algo que no lo merece.

La razón por la que esto es un problema de seguridad, y no solo de calidad del texto, es la sobredependencia: cuando una persona o un sistema automatizado confía en la salida de un modelo sin verificarla, cualquier error se traslada tal cual a la decisión siguiente. El módulo 4 de este curso ya distinguió esta entrada del manejo inadecuado de la salida, LLM05:2025: aquella trata de que un sistema automatizado confíe demasiado en que la salida del modelo es segura de ejecutar; esta trata de que una persona confíe demasiado en que la salida es cierta. Los dos fallos comparten estructura, fiarse de algo que no se comprobó, pero se cortan con controles distintos: uno con validación técnica antes de ejecutar, el otro con verificación humana antes de actuar sobre la información.

El vector concreto: paquetes de software que no existen

El cuarto ejemplo de riesgo que documenta LLM09:2025 es el más verificable de todos porque no depende de interpretar si una afirmación es cierta o no: el modelo sugiere una biblioteca de código que, sencillamente, nadie ha publicado nunca en el repositorio oficial del lenguaje. El propio Top 10 dedica a esto uno de sus dos escenarios de ataque completos: alguien prueba distintos asistentes de codificación hasta identificar qué nombres de paquete inventan con regularidad, publica un paquete malicioso con exactamente ese nombre en un repositorio de uso amplio, y espera a que otros desarrolladores, confiando en la misma sugerencia, lo instalen sin comprobarlo. El ataque no necesita ninguna vulnerabilidad técnica adicional: el propio modelo hace el trabajo de convencer a la víctima.

Este fenómeno tiene nombre propio desde abril de 2025: slopsquatting, un juego de palabras entre «slop» (la jerga con la que ya se conoce el contenido generado por IA de baja calidad) y «typosquatting», la práctica ya antigua de registrar nombres de paquete casi idénticos a uno popular para atrapar a quien se equivoca al escribir. El desarrollador Andrew Nesbitt lo publicó y definió así, el 8 de abril de 2025, en una publicación en Mastodon que atribuye el término a Seth Larson: «cuando un LLM alucina el nombre de un paquete que no existe, y alguien con malas intenciones lo registra.» La diferencia con el typosquatting clásico es de origen, no de mecánica: ya no hace falta que la víctima cometa un error tipográfico, basta con que confíe en lo que un modelo le sugirió.

El primer caso documentado de que esto funciona en la práctica es anterior al propio nombre. El investigador Bar Lanyado, de Lasso Security, publicó el 28 de marzo de 2024 un experimento en el que había observado que varios modelos sugerían con frecuencia instalar un paquete de Python llamado huggingface-cli, que no existía (la forma real de instalar esa utilidad es distinta). Subió un paquete vacío e inofensivo con exactamente ese nombre al repositorio oficial, solo para medir cuánta gente lo instalaba confiando en la sugerencia de un modelo. En tres meses, el paquete vacío acumuló más de 30.000 descargas, y Lanyado encontró que el propio README de un repositorio público de investigación de Alibaba había copiado el comando de instalación inventado.

La medición rigurosa del fenómeno llegó después, con «We Have a Package for You!», un estudio de Joseph Spracklen, Raveen Wijewickrama, A H M Nazmus Sakib, Anindya Maiti, Bimal Viswanath y Murtuza Jadliwala, presentado en el 34.º Symposium de Seguridad de USENIX, celebrado en Seattle del 13 al 15 de agosto de 2025. El equipo puso a generar código a 16 modelos distintos, comerciales y de código abierto, con dos conjuntos de prompts propios y en dos lenguajes, Python y JavaScript, hasta reunir 576.000 muestras de código que en conjunto recomendaban 2,23 millones de paquetes. De esos, el 19,7 % resultaron ser alucinaciones, con 205.474 nombres de paquete distintos que no existían en ningún repositorio real. El estudio insiste en un punto que conviene explicar sin caer en la comparación de rendimiento entre productos: el fenómeno apareció en los 16 modelos probados, sin excepción, lo que descarta que sea un fallo puntual de alguno en particular y confirma que es una propiedad estructural de cómo estos sistemas generan código.

La parte del estudio que más importa para entender por qué esto es explotable, y no solo curioso, es la que mide la reproducibilidad de un nombre alucinado. Los autores tomaron 500 prompts que ya habían generado una alucinación y repitieron cada consulta diez veces, contando cuántas de esas diez repeticiones volvían a producir el mismo nombre inventado. El resultado: el 43 % de las alucinaciones se repitió en las diez consultas sin excepción, un 39 % no volvió a aparecer ninguna vez, y en conjunto un 58 % de las alucinaciones se repitió más de una vez en las diez pruebas. La distribución tiene dos picos, en cero repeticiones y en diez, con muy poco en el medio: un nombre alucinado tiende a ser aleatorio del todo o persistente casi del todo, con pocos casos intermedios. Esto es justo lo que necesita alguien que quiera explotar el fenómeno: no hace falta acertar con una alucinación al azar, hace falta encontrar una de las persistentes, y una vez encontrada, publicar código malicioso con ese nombre tiene una probabilidad alta de que la siguiente persona que haga la misma pregunta reciba la misma sugerencia envenenada.

El módulo 7 de este curso ya cubrió la cadena de suministro de las dependencias que una aplicación de IA importa sin revisar, con el registro de modelos y la fijación de versiones como controles centrales. Este es un caso distinto, más concreto: ahí el riesgo era una biblioteca legítima que cambia de comportamiento con el tiempo; aquí el riesgo es que el propio asistente que ayuda a escribir el código es quien sugiere instalar algo que jamás existió, y que un atacante puede convertir esa sugerencia recurrente en la puerta de entrada. El código malicioso que llegue por esa vía, una vez instalado, puede ejecutar cualquier cosa dentro del proceso que lo importe, el mismo terreno de ejecución remota de código que desarrolla en detalle el curso de Hacking Web.

Otros vectores: citas inventadas, resúmenes que invierten el sentido, confianza excesiva

El segundo ejemplo de riesgo de LLM09:2025 son las afirmaciones sin fundamento en contextos donde importan de verdad, y el caso más citado del propio documento de OWASP tiene sentencia judicial con nombre y apellido. En Mata contra Avianca, un abogado de Nueva York presentó un escrito con seis sentencias judiciales que ChatGPT había inventado por completo, con citas, fechas y hasta jueces reales atribuidos a decisiones que nunca existieron. El juez P. Kevin Castel, en su Opinión y Orden sobre Sanciones del 22 de junio de 2023, impuso una multa de 5.000 dólares a los dos abogados y al bufete implicados, y les obligó a enviar una carta a cada juez cuyo nombre había sido invocado en falso. El propio texto de la orden lo resume con precisión: existe un deber de verificación de las citas que ninguna herramienta, por útil que sea, sustituye. Este caso no fue un incidente aislado: un estudio posterior de investigadores de Stanford, «Large Legal Fictions», publicado en el Journal of Legal Analysis en 2024, sometió a varios modelos de propósito general a preguntas legales verificables contra casos federales reales y encontró que la alucinación en este dominio es un fenómeno extendido y no anecdótico, sin que haga falta citar aquí ninguna cifra concreta de un modelo en particular para que el punto quede claro: los modelos de lenguaje general, sin anclaje a una fuente verificada, no son fiables para afirmar qué dice un texto legal.

El tercer vector son los resúmenes que invierten o inventan el sentido de lo que resumen, y aquí el ejemplo más documentado no viene de un chatbot conversacional sino de una función de resumen automático de notificaciones. En diciembre de 2024, la función de Apple Intelligence que resumía titulares de noticias generó una notificación que afirmaba, de forma falsa, que Luigi Mangione (el hombre acusado de matar al consejero delegado de una aseguradora estadounidense) se había disparado a sí mismo. La BBC presentó una queja pública, con una frase que resume bien lo que está en juego cuando un resumen automatizado sustituye al texto original: «BBC News es el medio de noticias más fiable del mundo. Nos importa mucho que nuestra audiencia pueda confiar en cualquier información publicada bajo nuestro nombre, y eso incluye las notificaciones.» En enero de 2025 llegaron más titulares inventados de la misma función, sobre un campeonato de dardos que aún no había empezado y sobre una noticia personal falsa atribuida a un tenista, hasta que Apple retiró la función mientras trabajaba en corregirla. El patrón de fondo es el mismo que el de los paquetes alucinados: un resumen tiene la forma de un hecho verificado y ninguna marca visible que distinga lo comprobado de lo inventado.

El cuarto vector es la sobredependencia sin ningún atacante de por medio, y el caso ya cubierto brevemente en el primer ejemplo de riesgo de OWASP tiene su propia sentencia. En febrero de 2024, el Tribunal de Resolución Civil de la Columbia Británica falló en el caso Moffatt contra Air Canada, después de que el chatbot de la aerolínea le hubiera dicho a un cliente que podía solicitar una tarifa de duelo de forma retroactiva, una política que no existía. El cliente, que había viajado tras la muerte de su abuela, compró el billete completo confiando en esa respuesta. El tribunal ordenó a Air Canada pagarle 812 dólares canadienses, la diferencia entre lo pagado y la tarifa reducida, y rechazó el argumento de la aerolínea de que el chatbot era una entidad separada responsable de sus propias palabras: la empresa responde por toda la información de su web, venga de una página estática o de un asistente conversacional. Ningún atacante manipuló nada en ese caso. El fallo fue, sencillamente, que nadie verificó lo que el modelo afirmaba antes de que un cliente actuara sobre ello, y ese tipo de responsabilidad legal por una salida no verificada es exactamente el terreno que desarrolla el curso de GRC de este centro.

Controles que sí cortan esto

Recuperación con cita obligatoria y verificación cruzada

El módulo 5 de este curso ya desarrolló la arquitectura de recuperación aumentada por contexto y sus riesgos propios; el control que interesa aquí es más estrecho: exigir que cada afirmación relevante venga acompañada de la cita exacta del fragmento del que sale, y comprobar de forma automática que esa cita existe de verdad en lo recuperado, no solo que tiene forma de cita. Un modelo puede alucinar una cita con la misma soltura con la que alucina un paquete, así que el control real no es pedirle que cite, es validar la cita después de generada:

def respuesta_esta_fundamentada(cita, fragmentos_recuperados):
    """Comprueba que el texto citado aparece literal en algun
    fragmento recuperado, no solo que el modelo dice haberlo citado."""
    cita_normalizada = " ".join(cita.split())
    return any(
        cita_normalizada in " ".join(frag.split())
        for frag in fragmentos_recuperados
    )

Esta comprobación no confirma que la interpretación del modelo sobre esa cita sea correcta, solo que el texto citado existe de verdad donde dice que existe. Es un control barato y verificable, no una garantía completa, y por eso el NIST lo recoge entre las acciones sugeridas de su perfil de IA generativa: la acción MS-2.5-003 pide, de forma literal, «revisar y verificar las fuentes y citas en las salidas de los sistemas de IA generativa durante la medición de riesgo previa al despliegue y en el monitoreo continuo», clasificada bajo el riesgo de confabulación. La verificación cruzada humana sigue siendo necesaria para el paso siguiente, juzgar si lo citado respalda de verdad lo que el modelo afirma que respalda.

Listas de paquetes permitidos en generación de código

Frente al vector de los paquetes alucinados, el control mínimo es el que ya adelanta el ejercicio de este módulo: comprobar, antes de instalar nada, que el paquete existe de verdad en el repositorio oficial. Un control más maduro va más allá de la mera existencia y restringe la instalación a un índice interno con solo las bibliotecas que el equipo ya revisó, en vez de confiar en todo el repositorio público:

pip install --index-url https://pypi.interno.ejemplo/simple/ --no-deps -r requirements.txt

Con un índice propio, aunque el modelo sugiera un nombre inventado (o uno real pero no revisado por el equipo), la instalación falla porque ese nombre no está en la lista permitida, en vez de resolverse contra el repositorio público donde cualquiera pudo haberlo registrado hace una semana con la intención de que alguien lo instale por error.

Revisión humana en decisiones con consecuencias

OWASP lo llama supervisión humana y verificación de datos, con una condición que conviene no saltarse: que quien revisa esté entrenado para no caer, precisamente, en la misma confianza excesiva que se supone que su revisión debe cortar. El módulo 6 de este curso ya desarrolló en detalle cómo se diseña una confirmación humana que no degenere en un clic automático por fatiga (mostrar el contenido exacto antes de aprobar, separar la vista previa de la acción real, señalar visualmente lo que tiene impacto alto); esa misma disciplina se aplica aquí a la revisión de un hecho antes de darlo por bueno, no solo a la aprobación de una acción antes de ejecutarla.

Diseño de interfaz que comunique incertidumbre

OWASP recomienda diseñar interfaces que fomenten un uso responsable: etiquetado claro del contenido generado por IA, e información explícita sobre las limitaciones de fiabilidad y precisión del sistema. Esto no es un añadido cosmético, es la diferencia entre una aplicación que deja creer que todo lo que dice está verificado y una que admite, en el propio texto, qué parte de lo que muestra no lo está.

Este mismo sitio aplica ese principio de forma concreta: cada artículo generado con ayuda de un modelo de lenguaje lleva, al final, una nota que explica que se elaboró con apoyo de inteligencia artificial y revisión editorial, que los datos centrales se contrastan con fuentes oficiales siempre que es posible, y que aun así puede contener errores que conviene comprobar antes de actuar sobre ellos, con un enlace a la página que detalla todo el proceso de verificación. No es una garantía de que el contenido nunca se equivoque, es justo lo contrario de eso: una forma honesta de decir que el proceso de verificación existe, que tiene límites, y que la palabra final sobre un dato importante sigue siendo de quien lo lee, no del modelo que ayudó a escribirlo.

Tabla: tipo de alucinación, dónde acaba y qué la corta

Tipo de alucinación	Dónde acaba	Qué daño hace	Qué control lo corta
Paquete de software que no existe	Pipeline de generación de código, CI/CD	Compromiso de la cadena de suministro si alguien lo publica con código malicioso	Lista de paquetes permitidos y comprobación de existencia antes de instalar
Cita legal o académica inventada	Escrito legal, informe, artículo	Sanción, pérdida de credibilidad, decisión basada en un precedente que no existe	Verificación humana de cada cita contra la fuente primaria, nunca contra el resumen del modelo
Resumen que invierte o inventa el sentido	Notificación, titular, informe ejecutivo	Desinformación difundida y decisión tomada sobre una premisa falsa	Cita literal obligatoria del fragmento fuente, validada de forma automática, más revisión humana antes de publicar
Regla de negocio dada por buena en una conversación sin respaldo real	Soporte al cliente, ventas, chatbot público	Compromiso económico o legal frente al cliente	Autorización real fuera del modelo, que valida cada oferta contra el sistema vigente
Afirmación fáctica en un dominio sensible dicha con total confianza	Decisión médica, financiera o legal del usuario final	Daño directo a la persona que confió sin verificar	Interfaz que comunica incertidumbre y fomenta la verificación independiente

Ejercicio de laboratorio: comprueba si lo que un modelo local importa existe de verdad

Todo el software de este ejercicio es gratuito: Ollama en local y Python 3, sin ninguna clave de API. Vas a pedirle a un modelo de codificación que genere una función con dependencias externas, extraer los nombres de esas dependencias y comprobar, uno a uno, si existen de verdad en el repositorio oficial de Python.

Descarga un modelo pensado para generación de código, no uno de propósito general, porque tiende a producir más dependencias reales de segundo nivel en vez de limitarse a la biblioteca estándar:

ollama pull qwen2.5-coder:7b

Pídele una tarea con dependencias poco triviales, deliberadamente, para aumentar la probabilidad de encontrar un nombre inventado en vez de requests o numpy:

from ollama import chat

prompt = (
    "Escribe en Python una funcion que descargue una imagen desde una URL, "
    "calcule su hash perceptual y lo compare con un hash de referencia para "
    "detectar si son visualmente similares. Indica todos los imports "
    "necesarios al principio del archivo."
)

respuesta = chat(model="qwen2.5-coder:7b", messages=[{"role": "user", "content": prompt}])
codigo_generado = respuesta.message.content
print(codigo_generado)

Extrae el nombre de cada paquete importado y consulta la API JSON de PyPI para cada uno: esa API devuelve un código 200 si el proyecto existe y un 404 si no, sin necesitar ninguna clave ni ninguna autenticación:

import re
import urllib.request
import urllib.error

def paquetes_importados(codigo):
    patrones = re.findall(r'^(?:import|from)s+([a-zA-Z0-9_.]+)', codigo, re.M)
    return sorted(set(p.split(".")[0] for p in patrones))

def existe_en_pypi(paquete):
    url = "https://pypi.org/pypi/%s/json" % paquete
    peticion = urllib.request.Request(url, headers={"User-Agent": "verificador-curso-ia/1.0"})
    try:
        with urllib.request.urlopen(peticion, timeout=10) as resp:
            return resp.status == 200
    except urllib.error.HTTPError as error:
        if error.code == 404:
            return False
        raise

for paquete in paquetes_importados(codigo_generado):
    if paquete in ("os", "sys", "io", "re", "math", "json", "typing", "pathlib"):
        continue  # biblioteca estandar, no hace falta comprobarla
    existe = existe_en_pypi(paquete)
    print(paquete, "=>", "existe en PyPI" if existe else "NO EXISTE EN PYPI")

Verifica en tu entorno qué paquetes sugiere tu modelo para esta tarea concreta (hash perceptual de imágenes suele tirar de bibliotecas como imagehash o Pillow, reales, pero también es un terreno donde un modelo puede inventar un nombre plausible que combine ambos conceptos). Si encuentras alguno que no existe, repite la misma pregunta exacta diez veces seguidas y documenta cuántas de esas diez repeticiones vuelven a sugerir el mismo nombre inventado, siguiendo el mismo método que usó el estudio de Spracklen y su equipo citado en este módulo. Un nombre que se repite en la mayoría de las diez pruebas es, según ese estudio, mucho más probable que se convierta en un objetivo real de slopsquatting que uno que aparece una sola vez al azar.

Preguntas frecuentes

¿Basta con decirle al modelo, en el propio prompt, que nunca revele sus instrucciones?

No. Esa instrucción es tan vulnerable a la inyección de prompt como cualquier otra, y el módulo 3 de este curso ya mostró por qué ninguna instrucción textual cierra ese agujero del todo. OWASP lo dice de forma directa en sus mitigaciones para LLM07:2025: entrenar a un modelo para que no revele su prompt puede ayudar, pero no es garantía de que lo cumpla siempre, así que la barrera real tiene que vivir en un sistema externo que inspeccione la salida, no en la esperanza de que el modelo obedezca.

Si mi aplicación usa recuperación aumentada por contexto con cita de la fuente, ¿ya no puede alucinar?

Puede, y de dos formas distintas. Puede alucinar aunque la fuente exista, si malinterpreta o tergiversa lo que dice el fragmento recuperado, y puede alucinar la propia cita, inventando un fragmento que suena plausible pero que no aparece en ningún documento recuperado. El código de verificación de este módulo corta la segunda forma, comprobando que el texto citado existe de verdad donde dice que existe; la primera forma sigue necesitando revisión humana, sobre todo en decisiones con consecuencias reales.

¿Cómo puede un atacante explotar un paquete alucinado si publicar código malicioso en un repositorio público ya resulta sospechoso de por sí?

Porque no hace falta ningún truco adicional para que parezca legítimo: el propio nombre viene ya recomendado por un asistente de codificación en el que el desarrollador confía, sin que nadie tenga que convencerle de nada. Es la misma lógica que un enlace de phishing bien elegido, con la diferencia de que aquí quien hace la recomendación inicial no es un correo sospechoso, es la propia herramienta de trabajo diaria del desarrollador.

¿La sobredependencia es responsabilidad del usuario que confía demasiado, o hay algo que el equipo que construye la aplicación pueda hacer?

Las dos cosas a la vez, y OWASP lo trata así en sus mitigaciones: comunicar con claridad los riesgos y las limitaciones del sistema, entrenar a los usuarios sobre esas limitaciones, y diseñar la interfaz para que el estado de incertidumbre sea visible en vez de invisible. Ninguna de esas medidas obliga a nadie a leerlas, pero la diferencia entre una aplicación que avisa y una que no es, precisamente, la diferencia entre un fallo de diseño y una negligencia del usuario.

Este módulo dice que no hay que confiar en el prompt de sistema para casi nada crítico. Entonces, ¿para qué sirve escribir uno bueno?

Para lo que sí controla bien: la forma de la respuesta, el alcance de la conversación y el tono. Un prompt de sistema bien escrito reduce el volumen de respuestas fuera de lugar y mejora la experiencia de quien usa la aplicación en el día a día. Lo que este módulo pide es no pedirle, encima, que haga de sistema de autorización, porque en eso falla de una forma silenciosa: no hay ningún error visible el día que alguien se salta esa instrucción, solo una acción que no debió ocurrir y ocurrió igual.

Módulo 8: El prompt de sistema no es un control, y la alucinación es un vector