La fórmula de la factura
El «45 %» por sí solo asusta, pero no sirve de nada. Calculemos qué significa en un equipo real.
Supongamos que cada mes se fusionan 200 unidades de código con superficie de seguridad relevante: manejo de entrada, renderizado de salida, consultas a base de datos, registro. De ellas, el 60 % se hace con un asistente de IA. El 45 % es una tasa medida sobre tareas de generación, y el cálculo da por supuesto que una de esas unidades de código equivale más o menos a una tarea de generación.
Unidades hechas con IA: 200 × 0,60 = 120
De ellas, vulnerables (45 %): 120 × 0,45 = 54 / mes
Si la revisión + el análisis estático detectan el 80 %
(supuesto generoso):
Se cuela: 54 × 0,20 = ~11 / mes
En un año: ~130
(Cálculo propio, con los supuestos de arriba. El 45 % sale de una medición longitudinal sobre más de 150 modelos y 80 tareas.)
Once vulnerabilidades coladas al mes. Esa es la factura, y no aparece en el precio de la herramienta.
Pero la parte importante no es la multiplicación. Es que no decide el 45 %, sino en qué clase de vulnerabilidad cae tu código. En esa misma medición, la consulta parametrizada llega al 82 % de tasa segura y la cripto al 86 %, pero el XSS se queda en el 15 % y el log injection en el 13 %. Quien renderiza HTML y escribe registros está en el lado malo. Quien trabaja con base de datos, en el bueno.
El centro de gravedad del riesgo se ha movido
La lista de riesgos más conocida del área se actualizó en agosto de 2026, y el cambio dice más que la propia lista.
Destacan dos movimientos:
- El exceso de atribuciones («excessive agency») subió del sexto puesto al tercero.
- El manejo indebido de la salida bajó del quinto al décimo.
Es decir, para el sector el centro de gravedad del riesgo se ha desplazado de la salida del modelo a los permisos del agent. La pregunta principal ya no es qué escribe el modelo , sino qué es capaz de llegar a hacer con ello.
Dos cosas que conviene saber de la lista:
Los años bailan. La edición vigente salió en agosto de 2026. La anterior, que todo el mundo cita como «la de 2025», se hizo en realidad en noviembre de 2024. Si alguien se apoya en «la lista de 2025», hay buenas probabilidades de que esté citando un documento de hace dos años.
Y por primera vez tiene datos de incidentes detrás. En esta edición la votación de expertos pesó un 75 %, y el 25 % restante salió de los datos de 6.639 incidentes reales procedentes de bases de datos públicas de vulnerabilidades.
Y la frase que enmarca la lista es el mejor resumen de todo el tema:
«No intentes construir un modelo al que no se pueda engañar. Construye el sistema a su alrededor de forma que, cuando lo engañen — y lo harán —, no se rompa nada importante.»
Dos casos que ocurrieron de verdad
En lugar del riesgo teórico, conviene mirar dos casos documentados.
El archivo que tomó el control
En el verano de 2025, un investigador comunicó una vulnerabilidad en la extensión de IA de un entorno de desarrollo popular que es un ejemplo de manual.
El ataque va así: una instrucción colocada en un archivo fuente, una página web, un issue o una respuesta de herramienta — incluso como texto invisible — convence al asistente de reescribir el archivo de configuración del proyecto y activar dentro la aprobación automática. En palabras de quien lo descubrió, ese ajuste «desactiva todas las confirmaciones del usuario, y a partir de ahí podemos ejecutar comandos de shell, navegar, etcétera».
Desde ahí se puede ejecutar cualquier comando en la máquina del desarrollador. Y se le llama gusano porque el código que escribe así puede llevarse la instrucción más lejos.
El fabricante lo confirmó y lo corrigió en agosto de 2025. La lección, en cambio, no ha caducado: el texto de un archivo que está en el repo también puede ser una instrucción.
Cuando el agent se convirtió en el arma
En agosto de 2025 entró código malicioso en el instalador de una gran familia de paquetes de código abierto. Es el método lo que convierte esto en la columna vertebral del artículo.
El malware llamó a las propias herramientas de línea de comandos de IA instaladas — con los flags que saltan los permisos — para que buscaran y leyeran secretos del sistema de archivos. No explotó ninguna vulnerabilidad en ellas. Las usó tal y como están diseñadas.
El balance: más de mil tokens de acceso válidos, decenas de claves de nube y de gestores de paquetes, unos veinte mil archivos filtrados y, en la segunda oleada, más de 5.500 repos privados que pasaron a ser públicos. La ventana de exposición en la primera fase fue de unas ocho horas.
Este es el caso de manual del exceso de atribuciones. Un agent que corre en la máquina de un desarrollador no solo puede equivocarse: también puede ser una herramienta en manos de otra persona.
El plazo que ya corre
Esta es la actualidad del artículo, y entró en vigor en septiembre de 2026.
Según el reglamento europeo de ciberresiliencia, desde el 11 de septiembre de 2026 los fabricantes de productos con elementos digitales tienen que notificar las vulnerabilidades explotadas activamente y los incidentes graves:
| Plazo | Qué hay que hacer |
|---|---|
| 24 horas | alerta temprana, desde que se tiene conocimiento |
| 72 horas | notificación completa |
| 14 días | informe final en caso de vulnerabilidad explotada activamente, tras publicarse la corrección |
| 1 mes | informe final en caso de incidente grave, contado desde la notificación de 72 horas |
La notificación va por una plataforma común, con un único envío. Los responsables del mantenimiento de software de código abierto quedan cubiertos desde el 11 de diciembre de 2027.
Importante: esto es un reglamento, no una directiva. Se aplica directamente en todos los Estados miembros, sin margen de transposición y sin plazo nacional propio. Lo que el Estado miembro sí tiene que designar es adónde va la notificación y quién es la autoridad de vigilancia del mercado, y ahí no todos están en el mismo punto. Despliega el que te afecte:
Hungría — la designación está hecha, y la dirección también
La notificación va al Instituto Nacional de Ciberseguridad, que opera dentro del Servicio Especial de Seguridad Nacional y que la agencia europea registra como CSIRT coordinador. La dirección de notificación para este reglamento es un correo específico, no la atención general.
La ejecución nacional también está: el Parlamento aprobó la Ley CXXXV de 2025 el 10 de diciembre de 2025 y se publicó el 29 de diciembre. La ley atribuye las funciones de autoridad notificante y de vigilancia del mercado a la Autoridad de Supervisión de Actividades Reguladas, es decir, ni a la autoridad de protección de datos ni al instituto de ciberseguridad.
Para una pyme lo que cuenta de ahí es que los dos papeles están separados: el incidente lo notificas al instituto de ciberseguridad, pero de la conformidad del producto respondes ante otra autoridad.
España — el deber de notificar ya corre, la designación todavía no
La notificación va al equipo de respuesta del instituto nacional de ciberseguridad, INCIBE-CERT, que es el CSIRT coordinador. Esa parte funciona.
El real decreto de designación, en cambio, seguía siendo proyecto en septiembre de 2026. El texto atribuiría la autoridad notificante al Centro Criptológico Nacional y la vigilancia del mercado a la secretaría de Estado de telecomunicaciones e infraestructuras digitales; la CNMC lo informó el 13 de mayo de 2026, pero no ha aparecido en el BOE.
Es decir: en España la obligación de notificar que arrancó el 11 de septiembre de 2026 está viva mientras la autoridad de vigilancia del mercado no está formalmente designada. Eso no es una exención: las obligaciones del reglamento se aplican directamente, lo que llega tarde es el lado interno de la ejecución.
La consecuencia práctica de esto no es el cumplimiento legal, sino la preparación: puedes notificar en veinticuatro horas solo si sabes qué corre en tu lado, en qué versión y quién responde de ello.
La rutina mínima de defensa
1. EL AGENT NO DEBE RECIBIR MÁS DE LO QUE NECESITA.
Ha pasado a ser el 3.er riesgo más alto. Por defecto,
aprobación estricta, sin red, en contenedor o en VM
si la tarea es arriesgada.
2. EL FLAG QUE SALTA PERMISOS ES UNA DECISIÓN, NO COMODIDAD.
El ataque documentado usó exactamente esos flags.
3. COMPROBAR CADA IMPORT NUEVO en el registro de paquetes,
lockfile y verificación de hash en el build.
4. EL OUTPUT ENCODING Y EL REGISTRO LLEVAN RONDA APARTE.
15 % y 13 % de tasa segura. Aquí está el mayor hueco.
5. BÚSQUEDA DE SECRETOS EN EL CI, no en el code review.
Nadie va a encontrarlos en un PR de cientos de líneas.
6. LO QUE ESTÁ EN EL REPO ES ENTRADA.
Issue, comentario, documentación, respuesta de herramienta:
todo puede llevar instrucciones. El texto no es solo dato.
7. HAY QUE SABER QUÉ CORRE EN TU LADO Y EN QUÉ VERSIÓN.
Solo así puedes notificar dentro de las 24 horas.
Lo que no debes creerte de ti mismo
En una encuesta de 2023, el 77 % de 404 profesionales de TI pensaba que las herramientas de IA mejoran la seguridad del código.
Ese mismo año, en un experimento controlado, quienes usaron IA escribieron código menos seguro, y además creyeron con más probabilidad que habían escrito código seguro.
En ese experimento hubo también un resultado secundario que es el consejo más práctico de todo el tema: quienes confiaron menos en la IA y dedicaron más esfuerzo a formular su propia petición dejaron menos vulnerabilidades en el código.
Malentendidos habituales
- «Los modelos modernos ya escriben código seguro.» La compilación ha mejorado mucho, la tasa de seguridad está esencialmente plana desde 2023.
- «Modelo más grande, código más seguro.» El tamaño del modelo tiene un efecto muy pequeño en esto.
- «El riesgo del código de IA es teórico.» Hay dos casos documentados: en uno, el texto de un archivo tomó el control; en el otro, se usaron los agents instalados para robar datos.
- «El prompt injection es un problema de los chatbots.» En los casos documentados el portador fue un archivo fuente, un issue y una respuesta de herramienta.
- «El CRA ya llegará más adelante.» Las obligaciones de notificación corren desde el 11 de septiembre de 2026, y se trata de un reglamento: no hay prórroga de transposición.
Lo que conviene llevarse
La factura de seguridad no está en el precio de la herramienta, sino en las aproximadamente once vulnerabilidades que se cuelan cada mes, y en la clase de vulnerabilidad en la que te toca trabajar. El centro de gravedad del riesgo se ha desplazado de la salida del modelo a los permisos del agent: hoy el ajuste más importante es lo que la herramienta no puede hacer. Y desde septiembre de 2026 el reloj de la notificación también corre.
Los pasos concretos de esa revisión los detalla el post revisar el código generado , uno a uno; y la superficie de ataque aparte que abren los nombres de paquete inventados la recorre el post slopsquatting , con las cifras.