Tiempo de lectura: 13 minutos
TL;DR
El 9 de diciembre de 2026 — dentro de unos meses — la nueva Directiva de Responsabilidad por Productos Defectuosos ((UE) 2024/2853, «PLD») empieza a aplicarse a los productos introducidos en el mercado de la UE. Por primera vez, el software es explícitamente un producto sometido a responsabilidad objetiva: aplicaciones independientes, firmware, SaaS, sistemas de IA, incluso archivos de fabricación digital. Un producto es legalmente defectuoso si no ofrece la ciberseguridad que una persona tiene derecho a esperar — y la directiva dice sin rodeos que no publicar las actualizaciones de seguridad de una vulnerabilidad bajo tu control puede convertir tu producto en defectuoso. El daño indemnizable ahora incluye la destrucción o corrupción de tus datos personales (no profesionales) y el daño psicológico certificado médicamente, desaparece la antigua franquicia de 500 €, los tribunales pueden ordenarte revelar evidencia técnica, la defectuosidad se presume cuando el caso es demasiado complejo técnicamente para el demandante, y nada de esto se puede excluir en tu EULA. No existe equivalente en EE. UU.: allí la responsabilidad por productos sigue siendo derecho estatal de daños donde «¿es el software un producto?» sigue sin resolverse, y la Estrategia Cibernética estadounidense de 2026 revirtió explícitamente el plan de la administración anterior de trasladar la responsabilidad a los fabricantes de software. Los dos mayores mercados de software del planeta conducen ahora en direcciones opuestas — y si vendes en la UE, tu programa de gestión de vulnerabilidades acaba de convertirse en tu expediente de defensa legal. Aquí va mi lectura como profesional de seguridad.
El descargo de siempre, por partida doble: no soy abogado y esto no es asesoramiento jurídico — es un profesional de seguridad leyendo un régimen de responsabilidad como un atacante lee un diagrama de red, buscando dónde cae realmente la presión. Si vendes software en la UE, habla con abogados de verdad. Lo que sí puedo contarte es qué cambia operativamente para quienes construyen y aseguran productos, porque llevo más de veinte años viendo a la industria tratar la seguridad como una promesa de mejor esfuerzo respaldada por un descargo de responsabilidad. Esa era tiene fecha de caducidad en Europa, y la fecha es el 9 de diciembre de 2026.
Llevo tiempo dando vueltas a este tema en el blog — quién asume el riesgo cuando la IA escribe tu código, por qué las empresas no tienen estrategia de IA pero sí mucha exposición a la IA, qué pasa cuando nadie responde por las acciones de un agente. La PLD es la UE respondiendo a buena parte de esas preguntas con un instrumento contundente: alguien en la cadena de suministro siempre es responsable, y nunca es la víctima.
Este post tiene un complemento. Unas semanas después de escribirlo por primera vez, entró en vigor la mitad regulatoria del empuje europeo: la aplicación de la Ley de IA para modelos GPAI, en vigor desde el 2 de agosto. Un regulador que te multa y un tribunal que te pasa la factura son dos puertas distintas — aquel post es el regulador; este es el tribunal.
Qué ha cambiado: de 1985 a 2024
La antigua directiva de responsabilidad por productos es de 1985 — el año del Amiga y del C64 en su apogeo. Se escribió para tostadoras y cortacéspedes: productos físicos, daños físicos. El software se le escapaba casi por completo. Si el código era siquiera un «producto» se debatió durante cuatro décadas, la pérdida de datos pura no era daño indemnizable, había un umbral de 500 € para reclamaciones materiales, y probar que un defecto concreto en un sistema complejo causó tu daño era cosa tuya, solo, contra la ventaja informativa del fabricante.
La Directiva (UE) 2024/2853 sustituye todo eso para los productos introducidos en el mercado desde el 9 de diciembre de 2026 (lo que se comercializó antes sigue bajo las reglas de 1985 — un régimen dual de larga cola que conviene entender). Los Estados miembros deben transponerla a su derecho nacional para esa misma fecha, y van previsiblemente tarde: a mediados de 2026, Hungría ha transpuesto, unos pocos países (Croacia, Eslovaquia, Bulgaria) tienen borradores en marcha, y buena parte de la UE no ha publicado nada. Transponer tarde no salvará a nadie — el plazo y la dirección están fijados.
Los cambios de titular, vistos desde la silla de quien construye:
El software es un producto. Punto. Software independiente, firmware embebido, apps móviles, sistemas de IA, funcionalidad SaaS y en la nube, servicios digitales conexos integrados en un producto (piensa en el servicio de monitorización de salud detrás de los sensores de un wearable), e incluso archivos de fabricación digital (el CAD que imprime la pieza en 3D). Si lo introduces en el mercado de la UE, se aplica responsabilidad objetiva — sin culpa, sin necesidad de negligencia. El demandante necesita defecto, daño y nexo causal. No tu intención, no tu proceso, no tus disculpas.
Siempre hay alguien que responde. La responsabilidad cae en cascada: primero el fabricante (que incluye al desarrollador de software); para fabricantes de fuera de la UE, el importador o el representante autorizado; en su defecto, el proveedor de servicios logísticos; incluso distribuidores y marketplaces online si no identifican a quién tienen aguas arriba en el plazo de un mes. La UE ha cerrado deliberadamente la vía de escape de «el fabricante es una sociedad pantalla en otra jurisdicción». Si desarrollas desde fuera de la UE y vendes dentro, tu representante europeo sostiene tu responsabilidad.
Figura 1. La cascada: la responsabilidad fluye del fabricante → importador / representante autorizado → proveedor de servicios logísticos → distribuidor / marketplace hasta caer en alguien alcanzable en la UE. Las sociedades pantalla de fuera de la UE no rompen la cadena, y nada de esto se puede excluir por contrato.
No puedes pactarlo fuera. La responsabilidad frente al perjudicado no puede excluirse ni limitarse. ¿El bloque en mayúsculas AS IS, WITHOUT WARRANTY OF ANY KIND al final de la licencia? En este régimen, decorativo.
La parte de seguridad: la defectuosidad ahora habla CVE
Esta es la sección por la que escribí este post. La directiva no trata la seguridad como un añadido; la incrusta en la definición legal de «defectuoso».
Un producto es defectuoso cuando no ofrece la seguridad que una persona tiene derecho a esperar, y la evaluación incluye explícitamente, entre otros factores, los requisitos pertinentes de ciberseguridad y la capacidad del producto de resistir acciones previsibles de terceros — es decir, ataques. Léelo otra vez: un ataque previsible que explota una debilidad que deberías haber corregido forma parte del análisis del defecto. El exploit no te exculpa; su previsibilidad te acusa.
Figura 2. Lo que un demandante debe alinear para la responsabilidad objetiva — defecto Y daño Y causalidad — y los fallos de seguridad que vuelven el software «defectuoso»: ciberseguridad ausente, actualizaciones no publicadas, una debilidad previsible explotada o el incumplimiento de la CRA/NIS2. El daño ahora incluye datos destruidos y daño psicológico; la causalidad puede presumirse.
Tres consecuencias que pondría en la pared de cualquier equipo de producto:
1. Las vulnerabilidades sin parchear son ahora una categoría legal, no solo un elemento del backlog. La directiva responsabiliza a los fabricantes de los productos después de venderlos, en la medida en que el producto siga bajo su control — actualizaciones de software, upgrades, comportamiento en la nube y cambios derivados de machine learning cuentan. No suministrar las actualizaciones de seguridad necesarias para mantener la seguridad puede convertir por sí mismo el producto en defectuoso. El modelo mental pasa de «lanzamos, el usuario asume el riesgo» a «el producto lleva un deber de cuidado continuo mientras podamos empujarle código».
2. Tu postura de cumplimiento alimenta el análisis del defecto. La PLD encaja con la Cyber Resilience Act, NIS2 y normas sectoriales como el Reglamento de Productos Sanitarios. Incumplir requisitos obligatorios de seguridad ya no trae solo multas regulatorias — se convierte en evidencia de defectuosidad en una demanda privada de daños, y el incumplimiento de requisitos obligatorios de seguridad puede activar una presunción de defecto. La CRA te dice cómo construir y mantener; la PLD es con lo que el demandante te golpea cuando no lo hiciste. Cumplimiento regulatorio y responsabilidad civil eran carriles separados. Acaban de fusionarse.
3. La defensa de los riesgos del desarrollo tiene un agujero con forma de software. Los fabricantes conservan la clásica defensa del «estado de los conocimientos científicos y técnicos» — el defecto era incognoscible cuando lo lanzamos. Pero no te rescata de defectos que emergen de actualizaciones de software o comportamiento evolutivo de ML bajo tu control tras la venta. Y la «modificación sustancial» de un producto — que una actualización mayor puede ser — reinicia el reloj de la responsabilidad. Para un SaaS de despliegue continuo con un modelo que aprende en el bucle, el tope de 10 años es menos una línea de meta y más una cinta de correr.
La parte de privacidad: la pérdida de datos ya es daño
Aquí está la disposición durmiente. El daño indemnizable bajo la nueva PLD incluye la destrucción o corrupción de datos no usados con fines profesionales. Junto a muerte, lesiones personales — ahora incluyendo daño psicológico certificado médicamente — y daños materiales, con la franquicia de 500 € eliminada.
Piensa en lo que eso cubre en la práctica:
- Un ransomware arrasa un NAS doméstico por una vulnerabilidad conocida y sin parchear en su firmware → las fotos familiares que cifró son daño indemnizable en una reclamación de responsabilidad objetiva contra el fabricante.
- Un cliente de sincronización defectuoso corrompe una década de documentos personales → daño.
- Una actualización de un hub IoT deja los dispositivos inservibles y borra los datos locales → daño.
Y esto se acumula junto al RGPD, no lo sustituye. El artículo 82 del RGPD ya da indemnización por tratamiento ilícito; la PLD añade una vía paralela donde la reclamación no es «trataste mis datos ilícitamente» sino «tu producto defectuoso destruyó mis datos«. Otra teoría del demandado, sin necesidad de probar una infracción del RGPD, responsabilidad objetiva en vez del baile de la accountability del responsable del tratamiento — y las organizaciones de consumidores pueden llevarlo como acciones colectivas. Un incidente masivo causado por un producto con cadencia de parcheo negligente ya no es solo un problema de relaciones públicas y una posible multa de la agencia de protección de datos; es una responsabilidad con forma de demanda colectiva y daños por usuario que ahora incluyen los propios datos.
La maquinaria probatoria es lo que le da mordiente. Los tribunales pueden ordenar la exhibición de documentación técnica y evidencia — logs, análisis de riesgos, informes internos de vulnerabilidades — presentada de forma accesible; si te niegas, la defectuosidad se presume. Y cuando el demandante afronta dificultades excesivas para probar el defecto o la causalidad por complejidad técnica o científica — lo que describe esencialmente a todo sistema de IA y a la mayoría del software distribuido — los tribunales también pueden presumir esos elementos. La asimetría de información que protegió silenciosamente a los fabricantes de software durante cuarenta años era un fallo de diseño, y la UE lo ha parcheado.
Un matiz más para mi rincón de la industria: la Directiva de Responsabilidad en IA está muerta — la Comisión anunció su retirada a principios de 2025 y la descartó formalmente más adelante ese año. Así que para los sistemas de IA en la UE, la pila de responsabilidad en 2026 es exactamente esta PLD (los sistemas de IA son software, el software es un producto) más los deberes regulatorios de la Ley de IA más las reglas nacionales basadas en culpa. La presunción por complejidad de la PLD se escribió prácticamente pensando en «explíquele a un juez la cadena de decisión de su modelo».
¿Hay equivalente en EE. UU.? No — y cada vez es menos equivalente
Respuesta corta: no. Respuesta larga: EE. UU. tiene responsabilidad por productos, pero nada como esto, y la brecha se ensancha a propósito.
La responsabilidad por productos en EE. UU. es derecho estatal de daños — responsabilidad objetiva, negligencia y teorías de garantía, moldeadas por el Restatement of Torts §402A y un mosaico de cincuenta variaciones estatales. No hay ley federal de responsabilidad por productos, no hay régimen armonizado al estilo europeo. Y críticamente para nosotros:
- Si el software es siquiera un «producto» sigue sin resolverse. La tradición de responsabilidad objetiva del Restatement cubre bienes tangibles; los tribunales siguen divididos sobre apps, plataformas y algoritmos, y los fabricantes alegan que el software es un servicio precisamente para quedar fuera del terreno de products liability. La UE zanjó por ley en 2024 la cuestión que los tribunales estadounidenses siguen litigando caso a caso.
- La doctrina de la pérdida económica bloquea casi todo lo que la PLD acaba de abrir. En la mayoría de estados, si un producto defectuoso solo se daña a sí mismo o causa daño puramente económico o de datos, la vía de daños está cerrada — te empujan al contrato, donde te espera el EULA.
- Y el EULA funciona. Las licencias de software estadounidenses viven de descargos y límites de responsabilidad ampliamente ejecutables. El instrumento exacto que la PLD anula es el muro de carga del modelo de riesgo de la industria del software estadounidense.
Lo que EE. UU. sí tiene es un mosaico de presión: la aplicación de la Sección 5 de la FTC contra empresas con seguridad descuidada, leyes estatales de seguridad IoT como la SB-327 de California, ciberseguridad premercado de la FDA para productos sanitarios, la etiqueta voluntaria Cyber Trust Mark. Real, pero disperso, mayormente regulatorio en vez de responsabilidad privada, y nada que le dé a un consumidor una reclamación de responsabilidad objetiva por un disco duro destruido.
La trayectoria es la parte interesante. La Estrategia Nacional de Ciberseguridad de EE. UU. de 2023 (Pilar 3) proponía exactamente el movimiento europeo: trasladar la responsabilidad a los fabricantes de software inseguro, con un safe harbor para quienes demostraran desarrollo seguro. Fue el lenguaje más audaz sobre responsabilidad del software que jamás salió de la Casa Blanca — y nunca se legisló. La Cyber Strategy for America de marzo de 2026 se apartó después explícitamente de ella: desregulación, «la ciberdefensa no debe reducirse a un checklist costoso», reducción de cargas de cumplimiento, sin traslado de responsabilidad, sin safe harbor.
Así que a mediados de 2026 la divergencia es política oficial en ambos lados: la UE convirtió el software inseguro en producto defectuoso; EE. UU. decidió no hacerlo. Si vendes globalmente, construirás de todos modos al listón europeo — la misma lógica del efecto Bruselas que el RGPD — porque mantener dos posturas de seguridad es más caro que mantener una. Lo que significa que la PLD está fijando de facto el suelo global de la responsabilidad del software, desde Bruselas, sin que el Congreso de EE. UU. vote nunca.
Open source: casi a salvo, con un cable trampa comercial
La directiva excluye el software libre y de código abierto desarrollado o suministrado fuera de una actividad comercial. El mantenedor aficionado, el proyecto académico, la librería comunitaria en GitHub — fuera del ámbito, y con razón; responsabilidad objetiva sobre mantenedores no remunerados habría sido un evento de extinción para el procomún.
Pero el cable trampa es la palabra comercial. Cobra por el software, vende soporte alrededor, o monetiza datos personales más allá de lo necesario para seguridad/compatibilidad, y la exención se evapora. Y en el momento en que un componente OSS se integra en un producto comercial, el integrador asume la responsabilidad por él. El SBOM de tu producto es ahora un mapa de responsabilidad: cada dependencia que contiene es un componente por el que tú respondes en un tribunal europeo. Escribí sobre la trampa de las dependencias en código generado por IA — la PLD es ese post con un juzgado adjunto. «La vulnerabilidad estaba en una librería upstream» nunca fue gran excusa técnicamente; desde diciembre tampoco lo es legalmente.
Mi lectura: qué deberían hacer los equipos de seguridad
Quita la jerga legal y la PLD es una lista de exigencias operativas. La mayoría son cosas que los buenos equipos de seguridad ya predican; la diferencia es que «no nos dio tiempo» ahora tiene un precio con un tribunal adjunto.
1. Tu programa de gestión de vulnerabilidades es ahora tu expediente de defensa legal. Parcheo con SLA, decisiones de triaje documentadas, política de EOL y ventanas de soporte, gestión de divulgación coordinada — dejan de ser líneas de un modelo de madurez y se convierten en la evidencia que exhibirás bajo una orden de disclosure. Gestiona vulnerabilidades asumiendo que cada decisión puede leerse en voz alta ante un juez, porque bajo el régimen de exhibición, puede. Si no puedes demostrar por qué despriorizaste el bug que luego destruyó los datos de alguien, la maquinaria de presunciones hace el resto.
2. La capacidad de actualizar es una frontera de responsabilidad. «Bajo el control del fabricante» es la frase que sostiene toda la directiva. Si puedes empujar actualizaciones, cargas con el deber; cuánto tiempo prometes hacerlo es tu política de ciclo de vida de soporte. Defínela, publícala, cúmplela, y trata el fin de soporte como un evento formal, fechado y comunicado — no como un cese silencioso de parches. Y fíjate en el incentivo perverso que conviene diseñar fuera: habrá equipos tentados de reducir su capacidad de actualización para encoger la ventana de control. Respuesta equivocada — la CRA exige soporte de seguridad por su cuenta. La única salida es a través.
3. Los logs son ahora evidencia exculpatoria. La misma telemetría que llevo exigiendo para la seguridad de agentes hace doble servicio aquí: probar qué hizo tu producto, cuándo lo supiste y cómo de rápido actuaste es cómo se rebate una presunción de defecto. Un producto que no puede reconstruir su propio comportamiento no puede defenderse — ni en el SOC ni en el juzgado.
4. Los artefactos de cumplimiento cortan por los dos lados — mantenlos honestos. El trabajo de conformidad CRA, los análisis de riesgos, los modelos de amenazas: son tu defensa cuando son reales, y la Prueba A del demandante cuando son aspiracionales. Un modelo de amenazas que lista un riesgo que luego ignoraste demostrablemente es peor que no tener documento. Escribe lo que harás; haz lo que escribiste.
5. Si eres un fabricante estadounidense, no te relajes. Tu regulador doméstico acaba de retirarse, pero tu importador o representante autorizado en la UE sostiene tu responsabilidad objetiva, y te devolverá ese riesgo vía contratos, auditorías y requisitos de seguros. La cadena comercial transmitirá la presión de la PLD a través del Atlántico más rápido que cualquier regulación.
¿Y entonces qué?
Durante cuarenta años, el software ha sido la única disciplina de ingeniería de mercado masivo autorizada a vender al público productos defectuosos a sabiendas y descargar las consecuencias en un click-through. Los puentes no pueden hacerlo, los coches no pueden hacerlo, las tostadoras no pueden hacerlo. Desde el 9 de diciembre de 2026, en la UE, el software tampoco.
La lectura cínica es «más burocracia europea». No me la compro, y ya sabes que no soy un fan reflejo de la regulación. La responsabilidad objetiva no es un checklist — es lo contrario de uno. No te dice cómo construir; te dice que si lo que construyes hace daño a alguien, pagas, y te deja ingeniar tu propio camino hasta ese listón. Ese es el trato bajo el que ha operado cualquier otro campo de la ingeniería durante un siglo, y esos campos respondieron inventando la ingeniería de seguridad, no colapsando.
Mientras tanto, EE. UU. acaba de apostar en sentido contrario: que los incentivos de mercado sin responsabilidad producirán software seguro. Ese experimento lo llevamos ejecutando cuatro décadas. El resultado es la lista de CVE.
Los fabricantes que trataron la seguridad como ingeniería desde el principio tienen poco que temer de diciembre. Los que la trataron como un descargo de responsabilidad están a punto de descubrir que su EULA nunca fue un muro de carga. Parchea como si fuera un deber legal — porque en Europa, ahora lo es.
Mantente paranoico. Publica parches. Guarda tus logs.
- X (Twitter): @SimonRoses
Lecturas adicionales:
- Directiva (UE) 2024/2853 — texto completo en EUR-Lex
- Reed Smith — The new EU PLD: implications for software, digital products and cybersecurity
- Gibson Dunn — EU PLD: responding to software, AI and complex supply chains
- Hogan Lovells — EU introduces comprehensive digital-era Product Liability Directive
- Wolf Theiss — EU PLD transposition tracker 2026
- Taylor Wessing — OSS and liability under the new PLD
- IBA — Liability for software under the new European PLD
- ICLG — Product Liability Laws and Regulations 2026: USA
- Mayer Brown — Trump administration’s 2026 Cyber Strategy for America
- IAPP — European Commission withdraws AI Liability Directive
¿Preguntas o comentarios? Contacta vía:
- Web: vulnex.com
- Estrategia de Seguridad IA: vulnex.ai
- Twitter/X: @SimonRoses
- LinkedIn: linkedin.com/in/simonroses
- GitHub: github.com/vulnex
¿Necesitas preparar tu producto para la era PLD/CRA? VULNEX ofrece:
- Evaluaciones de seguridad de producto y aplicaciones (análisis de brechas secure-by-design, revisión de SBOM y cadena de suministro)
- Diseño de programas de gestión de vulnerabilidades (parcheo con SLA, gestión de divulgación, política de ciclo de vida de soporte)
- Evaluaciones de seguridad de sistemas de IA y modelado de amenazas consciente de la responsabilidad legal
- Ejercicios de red team y automatización de seguridad
Para estrategia de seguridad en IA — donde el riesgo de modelos y agentes se cruza con las decisiones de consejo — visita vulnex.ai.
Contacto: info@vulnex.com
