Estado real, 22 de septiembre de 2026. El Plan IA360 se presentó el día anterior, el 21 de septiembre. De los catorce proyectos que anuncia, el del Instituto de Seguridad de la IA solo tiene una fecha comprometida: la constitución de su núcleo técnico antes de que acabe 2026. No hay reglamento del Instituto, ni calendario de evaluaciones, ni nada que obligue a una empresa a hacer lo que sigue. Lo que sigue no depende de que el Instituto llegue a funcionar.
Dentro del Plan IA360 hay una función que no es la más citada pero sí la más operativa: el Instituto de Seguridad de la IA hará la evaluación de los modelos más avanzados antes y después de su despliegue. Es una distinción que interesa a cualquier empresa a punto de poner un chatbot, un agente o un asistente delante de sus clientes, aunque su sistema no tenga nada que ver con esos modelos más avanzados: la pregunta de fondo es la misma, solo que a otra escala, y es esta: ¿aguanta un intento deliberado de romperlo?
Qué hará el Instituto, resumido
El proyecto tractor 4 del plan crea el Instituto como una unidad técnico-científica dentro de la AESIA, que asume su dirección, apoyada en convenios con el INCIBE, el Centro Criptológico Nacional, el Departamento de Seguridad Nacional, la Agencia Española de Protección de Datos y el Barcelona Supercomputing Center. Su función central es evaluar los modelos más avanzados antes y después de su despliegue, con acceso previo obtenido mediante acuerdos voluntarios con los desarrolladores, e informar periódicamente a la Administración General del Estado sobre sus capacidades y riesgos. A eso se suma trabajar en una metodología común de evaluación, coordinar cómo se responde ante un incidente con modelos o agentes avanzados, y cooperar con los institutos homólogos de terceros países. El objetivo declarado es «dotar a España de capacidad propia para evaluar los modelos más avanzados antes y después de su llegada al mercado». El único hito con fecha es la constitución del núcleo técnico, antes de que acabe 2026, seguido de un despliegue modular por sectores que el plan no detalla más: no hay, a día de hoy, calendario publicado de primeras evaluaciones.
La misma lógica, a escala de empresa
Un chatbot o un agente conectado a tus datos y a tus herramientas no falla como falla una aplicación tradicional: no se rompe por un fallo de programación, se rompe por lenguaje. Un usuario le pide que «ignore las instrucciones anteriores», le hace creer que es otro sistema, o lo va llevando paso a paso hasta que suelta información que no debería soltar. Un test de seguridad convencional no detecta nada de esto porque no está mirando en el sitio correcto. Antes de poner un sistema así en producción, igual que el Instituto evaluará un modelo antes de que llegue al mercado, conviene comprobar si aguanta ese tipo de ataque, con las mismas preguntas con las que trabaja un ejercicio de AI Red Teaming: ¿puede alguien inyectarle instrucciones por un documento, un correo o una web? ¿Puede saltarse sus límites con la conversación adecuada? ¿Filtra datos de otros usuarios o del contexto en el que opera? ¿Puede un tercero inducirlo a ejecutar una acción no autorizada sobre un sistema conectado?
Lo que compara cada escala
| Aspecto | A escala del Instituto | A escala de tu empresa |
|---|---|---|
| Qué evalúa | Modelos más avanzados, antes de llegar al mercado | Tu chatbot, agente o asistente, antes de producción |
| Cómo accede | Acuerdos voluntarios de acceso previo con desarrolladores | Acceso directo: es tu propio sistema |
| Qué busca | Capacidades y riesgos de los modelos más avanzados | Fuga de datos, acciones no autorizadas, daño reputacional |
| Quién lo hace | El Instituto, con apoyo de cinco organismos | Un ejercicio de red teaming dirigido a tu superficie de ataque real |
| Cuándo | Antes y después del despliegue del modelo | Antes de producción, en cada actualización relevante y de forma periódica |
No es un trámite de una sola vez
La evaluación no termina el día del lanzamiento. Conviene repetirla ante cada actualización relevante del sistema —un cambio de modelo, una herramienta nueva que el agente puede usar, un canal de entrada distinto— y de forma periódica aunque nada haya cambiado explícitamente, porque las técnicas de ataque también evolucionan. Un ejercicio bien dirigido empieza mapeando qué modelo usas, qué herramientas y datos puede tocar el sistema y quién puede hablarle; sigue con pruebas dirigidas a esa superficie concreta, no con una batería genérica; entrega un informe con los hallazgos priorizados por severidad e impacto real en el negocio; y termina acompañando la corrección de lo prioritario, con una segunda ronda sobre lo que quedó abierto.
Este ejercicio no sustituye una auditoría legal de cumplimiento ni certifica nada frente a un tercero: es la parte de laboratorio, la que produce evidencia técnica reproducible de cómo se comporta un sistema bajo ataque. Sirve, sobre todo, para dos cosas prácticas: reducir el riesgo real de un incidente —fuga de datos, una acción no autorizada de un agente, una captura de pantalla de un jailbreak circulando por redes— y tener algo concreto que enseñar si un cliente o un socio pregunta cómo se evalúa la seguridad de tu IA antes de confiarle un proceso.
Preguntas frecuentes
¿Es lo mismo que un pentest de seguridad tradicional?
No. Un pentest busca vulnerabilidades de infraestructura: puertos abiertos, configuraciones débiles, software sin actualizar. Un sistema de IA se ataca con lenguaje —instrucciones, contexto, conversación— y ese tipo de fallo no lo detecta un pentest convencional.
¿Hay que esperar a que el Instituto empiece a funcionar?
No. El Instituto evaluará los modelos más avanzados para el conjunto del mercado, con un calendario que hoy no existe más allá del núcleo técnico de 2026. Evaluar tu propio sistema antes de ponerlo en producción no depende de ese organismo ni de ningún otro.
¿Y si el sistema falla en la prueba?
Es frecuente encontrar algo que corregir, y es justo el motivo por el que conviene hacer la prueba antes del lanzamiento y no después de un incidente. El informe prioriza los hallazgos por severidad e impacto, para saber qué corregir primero.
¿Sirve para una empresa pequeña con un chatbot sencillo?
Sí, con el alcance ajustado. Un chatbot de atención al cliente sin acceso a sistemas internos tiene una superficie de ataque más pequeña que un agente conectado al ERP, pero la pregunta de fondo es la misma en los dos casos: ¿qué pasa si alguien intenta romperlo a propósito?
Proyecto tractor 4, ámbito de Seguridad, del Plan IA360 (PDF oficial de La Moncloa). Para el resto del plan, la guía completa del Plan IA360.
Última verificación del contenido: 22 de septiembre de 2026.