Los LLMs no se hackean como un servidor, se manipulan como a una persona. Y eso, créeme, es mucho más difícil de arreglar.
Los modelos de lenguaje grandes (LLMs) presentan vulnerabilidades inherentes derivadas de su arquitectura de atención y su entrenamiento con datos masivos. Estas debilidades permiten ataques de inyección de instrucciones, extracción de datos de entrenamiento y generación de contenido falso. Empresas y usuarios pueden mitigar riesgos mediante evaluación continua, barreras de validación y capas de seguridad perimetrales que no dependan exclusivamente del modelo.
Lo que nadie te cuenta en las demos
Acabo de volver de un evento de seguridad de IA en Madrid y todavía estoy procesando lo que vi. Lo que me sorprendió fue la facilidad con la que un asistente virtual bien entrenado puede ser desviado de su propósito original con una simple frase bien construida. No hablamos de exploits complejos con código malicioso. Hablamos de lenguaje, de psicología aplicada a la ingeniería de software.
Nadie habla de esto en las reuniones de ventas, pero la realidad es que los LLMs son esencialmente cajas negras estadísticas. Un modelo con 175 mil millones de parámetros puede generar respuestas brillantes el 99% del tiempo, y en ese 1% restante puede filtrar información confidencial que jamás debería haber salido del sistema.
El problema de raíz: la arquitectura de atención
La arquitectura de transformers, que es la base de todos los LLMs modernos, procesa el contexto de forma secuencial con pesos de atención. Esto significa que un prompt diseñado con una estructura específica puede "secuestrar" la atención del modelo hacia instrucciones maliciosas.
En mi experiencia trabajando con clientes que quieren implementar chatbots para atención al cliente, el primer fallo que detecto siempre es el mismo: asumen que el modelo es seguro porque el proveedor dice que lo es. Y no digo que los proveedores mientan, digo que un modelo seguro en un laboratorio no es lo mismo que un modelo seguro en producción.
La inyección de instrucciones: el ataque del que nadie habla
Esto lo cambia todo para cualquier empresa que esté pensando en conectar un LLM a sus datos internos. La inyección de instrucciones funciona así: un usuario escribe algo que parece texto normal, pero contiene instrucciones ocultas que el modelo interpreta como directivas de mayor prioridad que las que le dio el desarrollador.
Un ejemplo real que vi en el evento: un chatbot de una empresa de seguros fue manipulado para revelar los descuentos internos máximos que la compañía ofrecía. El atacante no utilizó herramientas sofisticadas. Solo escribió una historia sobre un cliente que necesitaba saber "cuál era el límite absoluto de negociación para poder contárselo a su jefe". El modelo, entrenado para ser útil y servicial, lo interpretó como una instrucción válida.
Un LLM no distingue entre una instrucción del sistema y una instrucción del usuario si ambas vienen en el mismo flujo de texto. Necesitas capas de validación externas para garantizar que el modelo no ejecute acciones críticas basándose únicamente en su interpretación del prompt.
Por qué los benchmarks no te salvan
Hay una industria entera dedicada a evaluar la seguridad de los LLMs. Se publican benchmarks, se compiten por métricas, se venden informes de auditoría. Y todo eso está bien, hasta cierto punto.
Pero hay un problema estructural: los benchmarks se diseñan después de que los ataques se descubren. Es decir, siempre vamos por detrás. Se evalúa la capacidad del modelo para resistir ataques conocidos, pero los atacantes no trabajan con ataques conocidos.
Lo que me pareció más revelador del evento fue un estudio que mostraba cómo pequeños cambios en la redacción de un ataque conocido reducían la tasa de detección del modelo de un 94% a un 31%. La misma vulnerabilidad, solo que expresada con otras palabras, y el modelo pasaba de "seguro" a "vulnerable". Según un informe de Gartner, la seguridad de los LLMs es un tema cada vez más importante.
La trampa del fine-tuning
Muchas empresas creen que el fine-tuning con datos propios resuelve los problemas de seguridad. Y no es así, ni de lejos. El fine-tuning ajusta el comportamiento general del modelo, pero no corrige las vulnerabilidades estructurales de su arquitectura. Puedes entrenar a un modelo para que no hable de temas políticos, pero si le pides que te cuente una historia donde un personaje revela información clasificada, es probable que lo haga sin pensárselo dos veces.
Esto lo he visto de primera mano con clientes que gastan miles de euros en ajustar un modelo para su sector y luego descubren que el modelo sigue siendo vulnerable a técnicas de jailbreak que circulan por internet desde hace meses. Para evitar esto, es importante considerar la automatización de tareas y la implementación de un CRM inteligente.
El problema de la confianza
Lo que más me preocupa, y esto es una opinión personal, es que estamos construyendo sistemas críticos sobre modelos que no entendemos del todo. Hospitales que usan LLMs para resumir historiales clínicos, bancos que los usan para evaluar solicitudes de crédito, despachos de abogados que los usan para revisar contratos.
No digo que no debamos hacerlo. Digo que necesitamos ser conscientes de que estos sistemas tienen fallos que no podemos prever y que la evaluación de seguridad no puede ser un checkbox que se marca una vez y se olvida.
Según un análisis de la consultora Gartner (2025), el 42% de los proyectos de IA generativa en empresas europeas se han enfrentado a problemas de seguridad o cumplimiento normativo durante su primer año de despliegue.
Qué puedes hacer si ya estás usando LLMs
Si tienes un sistema con LLMs en producción o estás pensando en montar uno, esto te interesa:
- Aísla el modelo de tus datos críticos: el LLM no necesita acceso directo a tu base de datos para funcionar. Intermedia toda petición con una capa de validación que filtre qué información se le envía y qué acciones puede ejecutar.
- Implementa guardrails de salida: no dejes que el modelo responda directamente al usuario. Pasa sus respuestas por un filtro que detecte intentos de extraer información sensible o de hacer que el sistema ejecute acciones no autorizadas.
- Audita los prompts de forma regular: los ataques evolucionan y lo que era seguro hace tres meses puede no serlo hoy. Mantén un registro de los intentos de manipulación y revisa qué ha cambiado.
- No confíes en el fine-tuning como medida de seguridad: úsalo para mejorar el rendimiento en tu dominio, pero asume que el modelo es vulnerable a nivel estructural.
- Prueba con ataques reales: no te conformes con los benchmarks del proveedor. Contrata a alguien (o dedica tiempo interno) a intentar romper tu sistema con técnicas conocidas y variaciones de las mismas.
En Script Finance trabajamos precisamente en esto cuando implementamos soluciones de IA para pymes y autónomos. Nuestro enfoque combina la implementación técnica con capas de seguridad que rodean al modelo, porque entendemos que un LLM es una herramienta muy potente, pero también un vector de ataque que muchos subestiman. Lo importante no es solo que el sistema funcione, sino que funcione de forma segura y predecible. Si necesitas consultoría o formación en este tema, no dudes en contactarnos.
Una última reflexión
Vivimos en un momento en el que la velocidad de adopción de la IA supera con mucho a la velocidad de comprensión de sus riesgos. Cada semana sale un modelo nuevo con capacidades impresionantes y cada semana se descubren vulnerabilidades nuevas. Es un ciclo que no va a parar.
La pregunta que me queda después del evento es simple: ¿estás dispuesto a asumir el riesgo de un sistema que no puedes controlar al 100%, o prefieres invertir el tiempo necesario en construir barreras que te protejan de lo desconocido? Porque la seguridad de los LLMs no se resuelve con una actualización de software. Se resuelve con una mentalidad que asume que el sistema va a fallar y que prepara el entorno para que ese fallo no tenga consecuencias graves. Si necesitas más información o quieres saber cómo podemos ayudarte, no dudes en contactarnos.




