Tu IA obedece a cualquiera que sepa pedírselo.La lista de los diez grandes riesgos de seguridad de la IA, explicada con casos reales y con lo que puedes hacer para evitarlos.
En diciembre de 2023, un usuario consiguió con un par de mensajes que el chatbot de un concesionario de Chevrolet en California aceptara venderle un Tahoe por un dólar. Fue una broma, pero el fallo que la hizo posible es el mismo que hoy se usa para sacar datos de las empresas a través de sus asistentes de IA.
Los diez riesgos de seguridad de la IA
La versión en audio de este artículo, en menos de seis minutos.
La venta no se llegó a hacer, pero a Air Canada sí le costó dinero: su chatbot le prometió a un cliente un reembolso que la aerolínea en realidad no hacía, y un tribunal obligó a la aerolínea a pagarlo, porque todo lo que dice su web, chatbot incluido, es responsabilidad suya.
La fundación OWASP, conocida por su lista de riesgos de seguridad web, publica otra con los diez riesgos más importantes de las aplicaciones que funcionan con un modelo de lenguaje, como ChatGPT o Copilot. Se llama OWASP Top 10 para LLM (LLM son las siglas en inglés de «gran modelo de lenguaje»), cada riesgo lleva un código del LLM01 al LLM10. Puedes leerla entera en su web; aquí te la resumimos.
Por qué un chatbot obedece a quien no debe
Un modelo de lenguaje lo recibe todo como texto: las instrucciones de la empresa, la pregunta del usuario y los documentos o correos que lee por el camino. No sabe distinguir bien qué es una orden y qué es un dato, así que una instrucción escondida en un correo puede pesar más que las de la propia empresa. A esto se le llama inyección de instrucciones.
La inyección de instrucciones, como las estafas, difícilmente se resolverá nunca del todo.
Lo reconoce la propia OpenAI con un ejemplo: un usuario pide a su agente de IA que prepare una respuesta automática de vacaciones, el agente lee por el camino un correo con instrucciones ocultas y acaba enviando una carta de dimisión al jefe en nombre del usuario.
Los diez riesgos, uno a uno
LLM01 · Inyección de instrucciones (prompt injection)
Es lo del Tahoe. La orden puede escribirla el propio usuario o ir escondida en un PDF, una web o un correo que lee el asistente, y la segunda es la más peligrosa porque nadie la ve. En 2025 Microsoft tuvo que corregir un fallo así en Copilot que permitía sacar información de las empresas.
LLM02 · Revelación de información sensible
Empleados de Samsung pegaron información interna en ChatGPT y la empresa acabó prohibiendo su uso. Dentro de la empresa pasa algo parecido: si el asistente busca en toda la documentación sin mirar quién pregunta, cualquiera puede acabar viendo las nóminas. La solución es que el asistente solo consulte lo que ese usuario ya tiene permiso para ver.
LLM03 · Cadena de suministro
En Hugging Face, la gran web de descarga de modelos de IA, aparecieron un centenar de modelos con código malicioso que daban acceso remoto al ordenador de quien los abría. Un modelo descargado es software de terceros: hay que bajarlo de fuentes fiables y en formatos que no ejecuten código al abrirse.
LLM04 · Envenenamiento de datos
Quien consiga colar textos manipulados entre los datos con los que se entrena un modelo puede cambiar cómo se comporta. Y hacen falta pocos: Anthropic demostró que bastan 250 documentos para que un modelo empiece a soltar frases sin sentido cada vez que lee una palabra concreta. Hay que saber de dónde sale cada documento.
LLM05 · Gestión incorrecta de las respuestas
Pasa cuando lo que responde el modelo se usa sin revisar, por ejemplo ejecutándolo como código. Una función de LangChain, una herramienta muy usada para programar con IA, hacía justo eso, y con una pregunta bien preparada se podía hacer cualquier cosa en el servidor. La respuesta del modelo merece la misma desconfianza que un formulario rellenado por un desconocido.
LLM06 · Exceso de autonomía
Es dar a un agente más permisos de los que necesita. En Notion se demostró que un PDF con instrucciones ocultas podía hacer que su agente sacara datos confidenciales de la empresa sin ningún fallo de programación de por medio. Cada agente debe poder hacer solo lo imprescindible, y enviar, borrar o pagar debería pasar siempre por una persona.
LLM07 · Filtración de las instrucciones internas
Al día siguiente de presentarse el chat de Bing, un estudiante consiguió que el chat le enseñara sus instrucciones internas, incluido el nombre en clave que tenía prohibido revelar. Da por hecho que las instrucciones de tu asistente acabarán viéndose y no metas en ellas contraseñas ni datos internos.
LLM08 · Debilidades en las bases de datos de búsqueda
Muchos asistentes guardan la documentación en una base de datos especial que les permite encontrar rápido los fragmentos que más se parecen a cada pregunta. Si en ella se mezclan documentos de clientes o departamentos distintos, o cualquiera puede añadir textos, el asistente acabará enseñando lo que no debe. Hay que separar la información y controlar quién puede añadir contenido.
LLM09 · Desinformación
Es lo de Air Canada. Los modelos se equivocan con mucha seguridad y a veces se inventan datos. Ayuda que el asistente diga de dónde saca cada respuesta y que conteste «no lo sé» cuando no la encuentra.
LLM10 · Consumo sin límites
Cada consulta cuesta dinero o potencia de cálculo, y un abuso o un agente que se queda en bucle pueden disparar la factura o tumbar el servicio. Se evita con límites de uso por usuario y avisos cuando el consumo se dispara.
documentos manipulados bastaron para alterar modelos de hasta 13.000 millones de parámetros.
Anthropic, octubre de 2025Cómo protegerse de algo que no tiene solución
Filtrar frases sospechosas no basta, porque la misma orden se puede escribir de mil maneras. Herramientas como Prompt Guard paran los intentos más burdos, pero lo sensato es dar por hecho que el ataque va a llegar y preparar la aplicación para que haga el menor daño posible.
Eso se consigue con cinco medidas:
- Separar el contenido que llega de fuera de las instrucciones, para que el sistema sepa qué es un dato y qué es una orden.
- Dar a cada herramienta el permiso mínimo. Un agente que resume correos no necesita poder enviarlos.
- Comprobar los permisos fuera del modelo, en el sistema que ejecuta la acción y con la identidad del usuario real.
- Pedir confirmación a una persona antes de enviar, borrar o pagar.
- Registrarlo todo y revisarlo, porque un ataque que funciona no da ningún error.
Y hay que probarlo con ataques conocidos cada vez que cambies algo.
Y si el modelo está en tus servidores
Muchas empresas instalan el modelo en sus propios servidores para que los datos no salgan de casa (aquí explicamos qué servidor hace falta). Es buena idea, pero no te protege de todo: unos riesgos bajan y otros pasan a ser cosa tuya.
| Riesgo | Con un proveedor externo | Con el modelo en tus servidores |
|---|---|---|
| LLM02 Información sensible | Los datos salen hacia el proveedor y dependes de su contrato. | No salen, pero los permisos de acceso siguen siendo cosa tuya. |
| LLM03 Cadena de suministro | El proveedor elige y protege el modelo. | Lo descargas tú, así que comprobar su origen es tarea tuya. |
| LLM04 Envenenamiento | El entrenamiento no lo controlas. | Si lo ajustas con tus datos, vigilar esos datos es tarea tuya. |
| LLM07 Instrucciones internas | Viajan al proveedor en cada consulta. | Se quedan dentro, aunque el modelo puede seguir revelándolas. |
| LLM10 Consumo sin límites | El abuso se nota en la factura. | No hay factura, pero si el servidor se satura, el servicio cae para todos. |
Eso sí, la inyección de instrucciones y el exceso de permisos son igual de peligrosos en tus servidores que en la nube.
Qué registrar para enterarte a tiempo
Estos ataques no dan errores: el modelo hace lo que le piden y nadie nota nada. Por eso conviene guardar quién hizo cada consulta, qué documentos leyó el asistente y qué acciones ejecutó, y enviarlo al sistema de alertas de seguridad (un SIEM como QRadar o Wazuh). Con eso, el sistema puede avisarte cuando:
- un agente envía o modifica algo justo después de leer un documento externo, como en el caso de la carta de dimisión;
- una respuesta incluye documentos de un departamento al que el usuario no pertenece;
- un usuario o un agente consume de repente mucho más de lo habitual.
Por dónde empezar
Haz inventario de qué datos usa tu aplicación, qué puede hacer y dónde guarda las claves. Luego revisa los permisos, pon límites de uso y prepara las pruebas y las alertas. Y como muchas de estas aplicaciones funcionan como una API más, repasa también el OWASP API Security Top 10.
Todo esto se practica en nuestro curso Seguridad de IA: OWASP para LLM y red teaming, y si prefieres que diseñemos contigo los agentes, tienes nuestro servicio de agentes de IA seguros.
Preguntas frecuentes
¿Qué es el OWASP Top 10 para LLM?
Es la lista de los diez riesgos de seguridad más importantes de las aplicaciones que usan modelos de lenguaje, publicada por la fundación OWASP, que la revisa cada cierto tiempo.
¿Se puede evitar del todo la inyección de instrucciones?
Hoy no. Se puede limitar el daño con permisos mínimos, revisando las respuestas del modelo, pidiendo confirmación humana para las acciones importantes y vigilando lo que ocurre.
¿Es más seguro tener el modelo en tus servidores?
Evita que los datos salgan hacia un proveedor externo, pero no protege contra la inyección de instrucciones ni contra el exceso de permisos, y te obliga a vigilar de dónde descargas el modelo y cuánto se usa.
¿Tienes un asistente o un agente funcionando?
Cuéntanos qué datos usa, qué puede hacer y con qué permisos, y te diremos por dónde empezaríamos a protegerlo. Si lo que quieres es que tu equipo aprenda a atacarlo y a defenderlo, para eso está nuestro curso Seguridad de IA: OWASP para LLM y red teaming.
Formación y servicios de seguridad de IA · sixe.esBlog!
Nuestra mision
SIXE garantiza que tus infraestructuras basadas en tecnologías IBM®, Red Hat®, Canonical® y SUSE® permanezcan estables, seguras y optimizadas durante todo el tiempo que las necesites.
En SIXE, nos comprometemos con la sostenibilidad. Por eso te ayudamos a diseñar, implementar y mantener soluciones tecnológicas duraderas y eficientes.
