La Directiva (UE) 2024/2853 clasifica el software y los sistemas de inteligencia artificial como “productos” sujetos a responsabilidad objetiva. Esto cambia concretamente el perfil de riesgo de las empresas de software: en caso de daños causados por una vulnerabilidad, el fabricante responde incluso sin culpa, a menos que logre demostrar que el defecto no era identificable con los conocimientos técnicos disponibles en el momento de la puesta en circulación. El test de penetración (penetration test) es la herramienta que genera dicha demostración de forma documentada y defendible.
Este artículo forma parte de la miniguía sobre la Directiva (UE) 2024/2853. Para obtener una visión general, consulte el centro de información de la directiva, o profundice en los capítulos sobre productos digitales y responsabilidad del software.
Cuándo se considera defectuoso un producto de software
La directiva define como defectuoso aquel producto que no ofrece la seguridad que el público puede esperar legítimamente, teniendo en cuenta también los requisitos de ciberseguridad aplicables. Para el software, esto significa que una vulnerabilidad explotable —incluso si aún no ha sido explotada— puede ser suficiente para calificar el producto como defectuoso en el momento de su lanzamiento.
El test de penetración, realizado antes de la puesta en el mercado y después de cada modificación sustancial, permite documentar que las defensas del producto han sido verificadas de forma sistemática y que las vulnerabilidades conocidas o razonablemente identificables han sido abordadas. Sin esta documentación, el fabricante se encuentra en la posición de tener que demostrar la ausencia de defectos sin pruebas concretas.
Carga de la prueba y documentación técnica
La directiva introduce un mecanismo de acceso a las pruebas que puede obligar al fabricante a presentar la documentación técnica en caso de litigio. Si dicha documentación no existe o está incompleta, se presume el defecto. Si, por el contrario, existe y está actualizada, el fabricante puede invocar la eximente del “estado de los conocimientos técnicos”: en el momento del lanzamiento, el defecto no era identificable con los métodos disponibles.
Un informe de test de penetración fechado, firmado por un equipo independiente y correlacionado con las versiones del software probadas, es la forma más directa de esta documentación. No basta con un análisis automatizado: se requiere una actividad manual y creativa que simule el comportamiento de un atacante real.
Responsabilidad cuando interviene un atacante externo
La directiva mantiene la responsabilidad del fabricante incluso cuando el daño es causado conjuntamente por el defecto del producto y la acción de un tercero, por ejemplo, un atacante que explota una vulnerabilidad no corregida. La presencia de un hacker en la cadena causal no exime al productor.
El test de penetración sirve precisamente para simular este escenario: si una vulnerabilidad es identificable con técnicas ofensivas estándar, el fabricante no puede argumentar que era imprevisible. Documentar que se realizó la prueba —y que las vulnerabilidades detectadas fueron corregidas— reduce concretamente la exposición a reclamaciones por daños físicos, psicológicos o destrucción de datos.
Test de penetración o análisis de vulnerabilidades: qué necesita la directiva
El análisis de vulnerabilidades (vulnerability assessment) identifica vulnerabilidades conocidas mediante escaneos automatizados y comparaciones con bases de datos públicas. Es útil para el monitoreo continuo, pero no produce las evidencias que la directiva exige en caso de litigio.
El test de penetración añade el componente manual y ofensivo: un evaluador experto verifica si las vulnerabilidades son efectivamente explotables en el contexto específico del producto, concatena varias debilidades para simular un ataque real y documenta el camino seguido. Es esta profundidad de análisis —y su trazabilidad— lo que convierte al test de penetración en la herramienta adecuada para responder a las solicitudes de prueba previstas por la directiva.
Para productos de software y aplicaciones web, el Web Application Penetration Testing de ISGroup cubre esta necesidad con metodologías OSSTMM y OWASP, informes estructurados y soporte para la remediación.
Información adicional de interés
- Guía de la Directiva (UE) 2024/2853 — el marco completo sobre la responsabilidad objetiva para productos, incluyendo software e IA.
- Productos digitales y directiva UE — cómo se aplica la directiva a software, aplicaciones y componentes digitales integrados.
- Responsabilidad del software — análisis de las obligaciones específicas para los fabricantes de software.
- Análisis de vulnerabilidades y directiva UE — cuándo es suficiente el VA y cuándo se necesita el test de penetración.
Preguntas frecuentes
- ¿Con qué frecuencia debe realizarse el test de penetración para ser útil a efectos de la directiva?
- La directiva no establece una periodicidad, pero el criterio es la modificación sustancial: cada lanzamiento que cambie funcionalidades relevantes para la seguridad requiere una nueva prueba. Un test realizado en una versión anterior no cubre las vulnerabilidades introducidas posteriormente.
- ¿Debe ser realizado el test de penetración por un tercero externo?
- La directiva no lo impone explícitamente, pero en caso de litigio, un informe producido por un equipo independiente tiene un peso probatorio significativamente mayor que un análisis interno. La independencia del evaluador refuerza la credibilidad de la documentación.
- ¿Cubre el test de penetración también los sistemas de inteligencia artificial?
- Sí, en la medida en que el sistema de IA esté clasificado como producto según la directiva. Para los componentes de IA integrados en software, la prueba debe incluir los vectores de ataque específicos del modelo —como la inyección de prompts o la manipulación de entradas— además de las vulnerabilidades tradicionales de la aplicación.
- ¿Qué sucede si el test de penetración identifica vulnerabilidades que no se corrigen antes del lanzamiento?
- El informe documenta las vulnerabilidades conocidas en el momento del lanzamiento. Si el fabricante decide lanzar el producto de todos modos sin corregir dichas vulnerabilidades, la documentación se convierte en una prueba en su contra: demuestra que el defecto era conocido y no fue abordado.
[Callforaction-WAPT-Footer]