ENISA e IA de frontera: 5 consecuencias para el CRA

En enero de 2026, curl cerró su programa de divulgación coordinada de vulnerabilidades. Los informes generados por IA habían desbordado a los mantenedores, y el proyecto decidió que la recepción de avisos costaba más de lo que aportaba. ENISA cita ahora ese cierre en una publicación oficial. Esta es la parte que te afecta a ti: un fabricante bajo el CRA no puede tomar la misma decisión. El Reglamento de Ciberresiliencia convierte la recepción de notificaciones de vulnerabilidades en una obligación legal desde el 11 de diciembre de 2027. curl eligió una salida. Tú no tendrás una.

Esa es una de las cinco colisiones entre el nuevo documento de postura de ENISA y tus obligaciones bajo el CRA. ENISA publicó su visión sobre la ciberseguridad en la era de la IA de frontera en julio de 2026. Las 16 páginas se dirigen a autoridades nacionales, responsables políticos de la UE, defensores y proveedores de servicios. Ninguna sección está escrita para fabricantes de producto. Las consecuencias llegan a tu mesa de todas formas.

Qué ha publicado ENISA en realidad

El documento es una nota de postura de 16 páginas, elaborada junto con la Red de CSIRT de la UE y EU-CyCLONe entre mayo y junio de 2026. Su aviso legal indica que no crea ninguna obligación normativa. Trátalo como una señal de hacia dónde se dirige la orientación operativa de ENISA, y léelo junto a las obligaciones del CRA que ya te vinculan.

La afirmación central es medible. La ventana entre el descubrimiento de una vulnerabilidad y su explotación ha pasado de años a meses, y de meses a minutos. Los datos que cita ENISA sitúan la conversión en arma en 15 minutos tras la divulgación, y la exfiltración mediana en 72 minutos tras el acceso inicial. NCSC-NL añade que los agentes autónomos eliminan la ventaja del defensor de descubrir el fallo antes que nadie. Una vez que un agente de IA encuentra una vulnerabilidad, construir el exploit es un cálculo, no un proyecto de ingeniería. Algunos exploits ya existen antes que el propio parche, algo que el documento llama tiempo de explotación negativo.

ENISA es sincera sobre la otra cara de la ecuación. El documento afirma que la propia capacidad de ENISA, junto con la de los fabricantes y los CSIRT nacionales, necesita reforzarse o replantearse para asumir la ola de vulnerabilidades descubiertas que se avecina. La agencia responsable de la Plataforma Única de Notificación te está diciendo, por escrito, que el volumen va a poner a prueba a todo el mundo.

Las cinco secciones siguientes toman cada una un hallazgo del documento y lo llevan hasta una obligación del CRA.

1. curl cerró su recepción de vulnerabilidades. Tú no puedes

A principios de 2026, los informes de vulnerabilidades generados por IA ya habían empezado a desbordar partes del proceso de divulgación en el software de código abierto. El documento nombra el daño. Una plataforma global de recompensas por errores pausó las nuevas presentaciones del Internet Bug Bounty tras una oleada de informes asistidos por IA de calidad desigual, y curl cerró su programa CVD en enero de 2026 porque los mantenedores no podían absorber el volumen y el ruido. El problema es la dilución de la señal. Los revisores humanos dedican su tiempo a separar los hallazgos reales de las presentaciones repetitivas, superficiales o sin validar.

Un proyecto de código abierto puede cerrar la puerta. Bajo el CRA, tú no puedes. El Reglamento te obliga a mantener y hacer cumplir una política de divulgación coordinada de vulnerabilidades, y a publicar una dirección de contacto para notificar vulnerabilidades en tu producto. Ambos deberes se aplican desde el 11 de diciembre de 2027. Esta es la verdad incómoda: el CRA se redactó bajo el supuesto de que las notificaciones son escasas y valiosas. El documento describe un mundo en el que llegan por centenares, escritas por máquinas y sin verificar. La obligación se mantiene. El supuesto en el que se basaba ha desaparecido.

Así que tu política CVD necesita una cláusula para la era de la IA. Debe incluir tres cosas:

• Requisitos de validación: define qué debe contener una notificación para entrar en clasificación. Producto y versión afectados, pasos de reproducción o una prueba de concepto, y el impacto observado. Una notificación que no los incluya recibe una solicitud de información adicional, no un puesto en la cola de clasificación.
• Deduplicación antes de la clasificación: las herramientas de IA reenvían el mismo fallo con muchas redacciones distintas. Agrupa primero las notificaciones entrantes contra tus hallazgos ya conocidos, y cuenta grupos, no correos.
• Compromisos de clasificación por gravedad: publica plazos de respuesta que puedas mantener con diez veces el volumen actual. Un SLA de confirmación que incumples cada semana es peor evidencia que uno modesto que sí cumples.

Una matización más del documento. ENISA constata que los últimos meses trajeron una mejora real en la calidad de los informes de IA, así que una regla general de "sin informes de IA" descarta señal útil. Filtra por completitud y reproducibilidad, no por quién lo escribió. Publicar la mecánica de recepción a través de security.txt mantiene auditable el deber del punto de contacto.

2. La IA está inflando lo que significa "vulnerabilidad explotable conocida"

El documento incluye una cifra que cambia la ingeniería de lanzamientos. Una organización del sector le dijo a ENISA que pasó de unos 80 CVEs en el primer trimestre de 2025 a cerca de 500 en el primer trimestre de 2026, y después a unos 500 al día en cuanto empezó a usar herramientas con IA de frontera. ENISA lo llama la devaluación económica del descubrimiento: encontrar fallos se está industrializando, así que el volumen de divulgaciones crece más rápido de lo que nadie puede corregir.

El CRA prohíbe introducir en el mercado un producto con vulnerabilidades explotables conocidas. Dos palabras sostienen esa regla. La IA amplía conocidas de forma mecánica: cada ejecución de un escáner contra tu SBOM saca a la luz más hallazgos, cada trimestre. Lo que la IA no cambia es explotables, y ahí es donde vive ahora tu evidencia de cumplimiento. El trabajo de puntuación de gravedad de separar la gravedad inherente de la probabilidad de explotación deja de ser una optimización y se convierte en la propia puerta de lanzamiento.

El argumento del encadenamiento corta en las dos direcciones. ENISA advierte que las vulnerabilidades de bajo riesgo ya no se pueden descartar como inofensivas, porque los modelos las encadenan hasta formar exploits que funcionan. Así que "CVSS bajo, ignorar" muere como regla de clasificación. Pero una puerta de CI basada en el recuento bruto de CVEs también muere: con 500 hallazgos al día bloquea cada lanzamiento para siempre. Lo que sobrevive es la explotabilidad documentada por hallazgo. El documento nombra los dos instrumentos: EPSS de FIRST para la probabilidad de explotación, y VEX para registrar si tu producto está afectado siquiera.

3. Cada parche que publicas traza el mapa del agujero en tus versiones antiguas

La sección del documento sobre la conversión en arma de vulnerabilidades N-day sostiene que las diferencias entre parches y los cambios binarios han alimentado históricamente la ingeniería inversa y el desarrollo de exploits, y que la ventana de explotación se abre antes del despliegue del parche. La IA de frontera comprime esa ingeniería inversa, de días de trabajo especializado a un cálculo. El documento también señala que el análisis asistido por IA acelera la comprensión del código en sistemas heredados.

Ahora coloca tu propia línea de producto en ese cuadro. Publicas una corrección de seguridad para la versión N. La diferencia describe la vulnerabilidad con precisión. Si la versión N-1 comparte el código afectado y ya está fuera de su periodo de soporte, tu propio parche es la mejor guía de explotación disponible contra tu propia base instalada. A velocidad humana, este era un riesgo conocido pero lento. A velocidad de máquina, es cuestión del mismo día.

Eso cambia el significado de dos decisiones del CRA:

• El periodo de soporte, de cinco años como mínimo en la mayoría de los casos, define qué versiones siguen recibiendo correcciones. Las versiones fuera de ese periodo no desaparecen del terreno. Siguen siendo accesibles, y cada corrección que publicas para las versiones soportadas les enseña algo sobre ellas a los atacantes. La proliferación de versiones es ahora superficie de ataque, así que menos versiones soportadas y de vida más larga ganan a muchas versiones de vida corta. Consulta periodo de soporte para ver cómo se fija la duración.
• La divulgación del fin de soporte que debes a los compradores antes de la compra pasa a ser información operativa, no papeleo de estantería. Un comprador que sigue usando el producto más allá de la fecha que divulgaste está usando un producto que tu propio flujo de parches describe a los atacantes. Dilo en la divulgación. La página de divulgación del fin de soporte explica dónde debe aparecer la fecha.

El consejo de NCSC Ireland en el documento es directo: revisa los inventarios de activos, prioriza la disciplina de parcheo y evalúa la exposición a componentes sin soporte. Para un fabricante, el deber equivalente es evitar que la brecha entre la "rama con parches" y la "rama abandonada" se ensanche en silencio.

4. Los parches escritos por IA se siguen distribuyendo bajo tu marcado CE

ENISA espera que la corrección adopte las mismas herramientas que el descubrimiento. El resultado es el cuello de botella de verificación que describe el documento: los equipos técnicos afrontan un reto de escala al auditar y validar los parches generados por IA para que no introduzcan nuevas vulnerabilidades en el código. El documento también describe la presión desde el otro lado, una brecha de autoridad en la que los comités de cambios humanos no pueden autorizar intervenciones en los minutos disponibles para contrarrestar exploits autónomos.

Al CRA no le importa quién o qué escribe tu código. Tiene una opinión firme sobre quién responde por él. El Reglamento exige pruebas de seguridad eficaces y periódicas de tu producto, y la declaración de conformidad que firmas bajo la evaluación de conformidad cubre cada parche que distribuyes durante el periodo de soporte. Una corrección generada por IA que abre un agujero nuevo es tu no conformidad, a velocidad de máquina.

La consecuencia práctica es esta: tu pipeline de parches necesita evidencia de pruebas que escale con el volumen de parches. La revisión humana de cada línea escrita por IA no va a escalar hasta 500 hallazgos al día. Las pruebas de seguridad documentadas y automatizadas en la ruta del parche sí lo hacen, y producen los artefactos que necesita tu expediente técnico. Si adoptas corrección asistida por IA, registra qué parches fueron generados por máquina y qué validación superó cada uno. Cuando un regulador te pregunte cómo mantuviste honesto tu deber de pruebas a esa velocidad, la respuesta es un registro, no una declaración de política.

5. Tus notificaciones de vulnerabilidades se convierten en un historial público

La última consecuencia es la más discreta del documento. ENISA escribe que los datos correlacionados de la EUVD pueden identificar puntos calientes en la cadena de suministro, debilidades sistémicas y tendencias de vulnerabilidades aceleradas por el descubrimiento asistido por IA. Y una frase más adelante añade que la notificación relacionada con el CRA puede ayudar a validar las afirmaciones de refuerzo de un proveedor frente a la explotabilidad real y los patrones de incidentes.

Léelo como fabricante. Desde el 11 de septiembre de 2026 notificas las vulnerabilidades explotadas activamente y los incidentes graves en un plazo de 24 horas a través de la Plataforma Única de Notificación, después un seguimiento a las 72 horas, y después un informe final en un plazo de 14 días desde la corrección. Cada notificación llega a una infraestructura que ENISA planea correlacionar. Con el tiempo, esa correlación es un historial de seguridad por proveedor: con qué frecuencia te explotaron, con qué rapidez corregiste y cómo se compara tu historial con tus afirmaciones.

De ahí se derivan dos comportamientos:

• Escribe afirmaciones de seguridad de producto que puedas defender con tu propio historial de notificaciones. "Reforzado" y "seguro por diseño" en una ficha técnica acabarán apareciendo junto a tu fila en la EUVD. Un marketing que se adelanta a los datos se convierte en una conversación con la autoridad de vigilancia del mercado.
• Trata la calidad de tus notificaciones como reputación, no como papeleo. Una notificación de 72 horas precisa y con medidas correctoras reales se lee de forma muy distinta a una mínima, y el objetivo declarado de ENISA es cerrar la brecha entre la divulgación y la respuesta coordinada usando estos datos. La propia cadena de notificación se puso en marcha por fases este año, con la incorporación por parte de ENISA de sus primeras Autoridades de Numeración CVE en mayo de 2026.

El resumen ejecutivo del documento dice que la SRP debe usarse, una vez esté operativa, para afrontar los retos de los nuevos desarrollos. ENISA se ha comprometido a ello por escrito. Tus notificaciones son la materia prima.

Este artículo tiene únicamente carácter informativo y no constituye asesoramiento jurídico. Para orientación específica sobre cumplimiento normativo, consulta con un abogado cualificado.