Desde diciembre, tu software responde como un producto defectuoso.
La Directiva (UE) 2024/2853 mete los programas informáticos dentro de la definición de «producto». Eso significa responsabilidad sin culpa, que no se puede excluir por contrato, y de la que no exonera que el defecto apareciera después si la causa fue no publicar una actualización de seguridad. España todavía no la ha transpuesto.
- 01Desde el 9 de diciembre de 2026, los programas informáticos son producto a efectos de responsabilidad objetiva. Se aplica a lo que se introduzca en el mercado o se ponga en servicio a partir de esa fecha.
- 02Responsabilidad sin culpa: quien reclama no tiene que probar que lo hiciste mal, sino que el producto no ofrecía la seguridad que cabía esperar.
- 03No se puede excluir ni limitar por contrato frente a la persona perjudicada. La cláusula de limitación de responsabilidad de tu contrato no vale para esto.
- 04No actualizar es responder. No exonera que el defecto apareciera después de vender si se debe a la falta de actualizaciones de seguridad y el producto seguía bajo tu control.
- 05Alcanza también a quien desarrolla software para su propio uso. Y España todavía no ha transpuesto la directiva.
No es una ley de IA. Es la de productos defectuosos, y ahora el software es un producto.
El régimen de responsabilidad por productos defectuosos lleva cuarenta años funcionando igual: si un producto no ofrece la seguridad que cabe esperar y causa un daño, su fabricante responde sin necesidad de probar culpa. Bastaba con acreditar el defecto, el daño y la relación entre los dos. Lo que no estaba claro es si un programa era un producto.
La Directiva (UE) 2024/2853, de 23 de octubre de 2024, lo zanja en la propia definición. Su artículo 4, punto 1, dice que producto es «cualquier bien mueble […]; incluye la electricidad, los archivos de fabricación digital, las materias primas y los programas informáticos». No hay matices ni excepciones por tipo de software: el sistema operativo, la aplicación de gestión, el firmware de una máquina y el modelo que hay detrás de un asistente son producto.
Y no solo el software suelto. El artículo 4, punto 3, crea la figura del servicio conexo —un servicio digital integrado en un producto sin el cual el producto no puede hacer alguna de sus funciones— y el punto 4 lo mete dentro de la definición de componente. La nube que hace funcionar el aparato forma parte del aparato.
La fecha, y qué queda a cada lado de ella
El artículo 2.1 es escueto: la directiva «será aplicable a los productos introducidos en el mercado o puestos en servicio después del 9 de diciembre de 2026». El artículo 21 deroga la Directiva 85/374/CEE con efectos de esa misma fecha, pero añade que seguirá aplicándose a lo que se introdujera antes.
De ahí sale la consecuencia que conviene tener clara: no hay un apagón, hay dos regímenes conviviendo durante años, y lo que decide cuál se aplica es la fecha en que ese producto concreto —esa versión concreta— salió al mercado.
Lo que se mueve, punto por punto.
A la izquierda, el régimen que decae el 9 de diciembre de 2026. A la derecha, el que entra.
| Aspecto | Régimen anterior | Desde el 9 de diciembre de 2026 |
|---|---|---|
| ¿Es producto un programa? | Discutido. No estaba en la definición. | Sí, expresamente — art. 4, punto 1. |
| Servicios conexos y actualizaciones | Fuera del cuadro. | Componente del producto — arts. 4, puntos 3 y 4. |
| Defecto sobrevenido | Exoneraba: si no existía al comercializar, no se respondía. | No exonera si se debe a software, a su falta de actualización de seguridad o a un servicio conexo bajo tu control — art. 11.2. |
| Daños indemnizables | Muerte, lesiones y daños a bienes de uso privado, con franquicia. | Lo mismo, más daño psicológico reconocido médicamente y destrucción o corrupción de datos no profesionales — art. 6.1. |
| Carga de la prueba | Íntegra para quien reclama. | Sigue siendo suya, pero con presunciones a su favor y exhibición forzosa de pruebas — arts. 9 y 10. |
| Plazos | 3 años desde el conocimiento; 10 desde la puesta en circulación. | Igual, con una excepción: 25 años si la lesión es latente — arts. 16 y 17. |
| Margen del legislador español | Directiva de mínimos en algunos puntos. | Armonización máxima — art. 3. No se puede endurecer ni suavizar. |
La última fila es la que más gente pasa por alto. El artículo 3 prohíbe a los Estados apartarse de la directiva «incluidas disposiciones más o menos estrictas». Cuando España transponga, no podrá suavizar nada para dar aire al sector: el texto que hay es el que habrá.
No publicar el parche es una forma de responder.
Si tuvieras que quedarte con un solo artículo de toda la directiva, es el 11.2.
El artículo 11.1, letra c), mantiene la exoneración de siempre: no respondes si demuestras que «es probable que el carácter defectuoso que haya causado el daño no existiera en el momento en que el producto fue introducido en el mercado […] o que ese carácter defectuoso se originase después de ese momento». Es la defensa clásica del fabricante: cuando salió de mi fábrica estaba bien.
El apartado 2 la desactiva para el software. Dice que no quedas exento cuando el defecto se deba a alguna de estas causas, siempre que estén bajo tu control: un servicio conexo; los programas informáticos, incluidas sus actualizaciones o mejoras; la falta de actualizaciones o mejoras de los programas informáticos necesarias para mantener la seguridad; o una modificación sustancial del producto.
Léelo despacio, porque es una inversión completa de la lógica anterior. Antes, el paso del tiempo te protegía: cuanto más viejo el producto, más fácil sostener que el problema no venía de origen. Ahora, mientras conserves la capacidad de publicar una actualización —y el artículo 4, punto 5, letra b), define «control del fabricante» precisamente como la capacidad de suministrar actualizaciones, por ti mismo o a través de un tercero—, el tiempo juega en tu contra. Una vulnerabilidad conocida y no parcheada es un defecto del que respondes.
Qué implica esto en la práctica
Que el ciclo de vida del producto deja de ser una decisión solo comercial. Decidir hasta cuándo se mantiene una versión, cuándo se declara el fin de soporte y cómo se avisa a quien la usa pasa a tener consecuencias de responsabilidad civil. Y que la traza importa: si no puedes demostrar cuándo supiste de un fallo, cuándo publicaste el arreglo y a quién se lo comunicaste, no tienes con qué defenderte.
Conviene decir también lo que el artículo 7.3 aclara, porque evita el pánico contrario: un producto no es defectuoso por el solo hecho de que después exista uno mejor, ni porque haya salido una versión posterior. La obligación es de seguridad, no de estar siempre a la última.
Te van a pedir tu documentación, y no enseñarla tiene precio.
La directiva no invierte formalmente la carga de la prueba, pero monta un sistema de presunciones que en la práctica se le parece bastante.
El artículo 10.1 mantiene la regla: quien reclama debe probar el defecto, el daño y el nexo causal. Lo que cambia es todo lo que viene después.
El artículo 9 obliga a los Estados a garantizar que, cuando quien reclama presente hechos y pruebas suficientes para hacer verosímil su demanda, se exija al demandado exhibir las pruebas pertinentes de que disponga. Hay contrapesos —proporcionalidad, protección de secretos comerciales, medidas de confidencialidad—, pero la obligación existe.
Y el artículo 10.2, letra a), cierra el círculo: se presume el carácter defectuoso del producto cuando el demandado no exhibe esas pruebas. No es una multa procesal: es perder el pleito en su punto central.
Hay dos presunciones más que conviene conocer. Se presume el defecto cuando el daño se causó por «un mal funcionamiento manifiesto del producto durante un uso razonablemente previsible» (art. 10.2, letra c), y el juez debe presumir el defecto o el nexo causal cuando quien reclama se enfrente a «dificultades excesivas, en particular debido a la complejidad técnica o científica» y demuestre que es probable que el producto sea defectuoso (art. 10.4). Todas admiten prueba en contrario (art. 10.5).
La consecuencia operativa es incómoda pero simple: la documentación técnica que hoy tienes para ti, mañana es la prueba de tu defensa. Registros de versiones, avisos de seguridad, decisiones de diseño, pruebas superadas. Si no existe, la presunción corre en tu contra.
Más gente de la que parece, y solidariamente.
| Quién | Cuándo responde | Base |
|---|---|---|
| El fabricante | Quien desarrolla, fabrica o produce el producto. También quien pone su nombre o su marca en él. Y quien lo produce para su propio uso. | Art. 4, punto 10 |
| El fabricante de un componente | Cuando su componente está integrado o interconectado bajo el control del fabricante del producto y ha causado que este sea defectuoso. | Art. 8.1.b |
| Quien modifica sustancialmente | Quien modifica un producto fuera del control del fabricante y luego lo comercializa o pone en servicio pasa a ser considerado fabricante. | Art. 8.2 |
| Importador y representante autorizado | Cuando el fabricante está establecido fuera de la Unión. Si no hay ninguno, el prestador de servicios logísticos. | Art. 8.1.c |
| El distribuidor | Solo si no se puede identificar a un operador de los anteriores establecido en la Unión y no identifica a quien le suministró en el plazo de un mes. | Art. 8.3 |
Cuando responden varios, lo hacen solidariamente (art. 12.1): quien reclama puede ir a por cualquiera por el total, y luego ese repite contra los demás (art. 14).
Hay una excepción que interesa especialmente a quien vende componentes de software siendo pequeño. El artículo 12.2 impide el derecho de repetición contra el fabricante de un componente de programa informático defectuoso cuando, en el momento de introducirlo en el mercado, era microempresa o pequeña empresa y así se pactó contractualmente con quien lo integró. Es una protección real, pero solo funciona si está escrita en el contrato: no opera sola.
La cláusula de limitación de responsabilidad no te cubre esto.
El artículo 15 no deja resquicio: los Estados garantizarán que la responsabilidad del operador económico «no esté limitada o excluida, en relación con la persona perjudicada, por una disposición contractual o por el Derecho nacional».
Conviene entender bien el alcance, porque se exagera en las dos direcciones. No significa que tus contratos dejen de valer: entre tú y tu cliente siguen rigiendo, y el reparto interno del riesgo entre empresas sigue siendo tuyo. Lo que significa es que frente a la persona física perjudicada —que muchas veces no es tu cliente, sino el empleado de tu cliente, o el paciente, o quien pasaba por allí— esa cláusula es papel mojado.
El límite de exposición real no lo pone el contrato, entonces, sino qué daños son indemnizables. Y ahí el artículo 6.1 acota: muerte o lesiones corporales, incluido el daño psicológico reconocido médicamente; daños a bienes, excepto los utilizados exclusivamente con fines profesionales; y destrucción o corrupción de datos que no se usen con fines profesionales.
Léelo en positivo y sabrás dónde estás: si tu software solo toca bienes y datos profesionales y no puede lesionar a nadie, tu exposición por esta vía es baja. Si puede causar un daño personal —salud, seguridad física, vehículos, maquinaria, domótica, cualquier cosa que llegue a un consumidor— o toca datos personales de uso privado, estás de lleno.
Sin transponer, con el plazo encima.
El artículo 22 da a los Estados hasta el 9 de diciembre de 2026 para poner en vigor las disposiciones necesarias. En España lo que hay que reformar son los artículos 128 a 149 del texto refundido de la Ley General para la Defensa de los Consumidores y Usuarios, herederos de la Ley 22/1994, que es donde vive hoy el régimen de la directiva de 1985.
A la fecha de la última verificación de este artículo, no consta norma española de transposición: la ficha del BOE de la directiva no registra ninguna, y el portal de participación pública del ministerio competente por materia no tiene abierta ninguna consulta previa sobre esto. Puede haber trabajo en fases que todavía no se publican; lo que se puede afirmar es que a día de hoy no hay texto público.
Que no esté transpuesta no aplaza nada relevante para ti, y este es el error más caro que se puede cometer aquí. La fecha del artículo 2.1 —que la directiva se aplica a los productos introducidos en el mercado después del 9 de diciembre de 2026— es una fecha de la directiva, no de la ley española. Un producto que salga al mercado el 10 de diciembre nace ya bajo el régimen nuevo, y si la ley española llega tarde, eso abre discusiones sobre efecto directo e interpretación conforme que se resuelven en un juzgado y no en tu planificación.
Dicho de otro modo: el retraso del legislador es un problema para ti, no una prórroga.
Cuatro cosas, y ninguna es comprar nada.
Ordenadas por lo que cuesta hacerlas frente a lo que evitan.
Ninguna de las cuatro requiere comprar software. Tres son de orden interno y la cuarta es de abogado. Si alguien te vende una herramienta para «cumplir la directiva de productos defectuosos», desconfía: no hay nada que presentar ni ningún registro donde inscribirse.
Lo que nos preguntan siempre.
De dónde sale cada dato.
Todo lo que se afirma aquí está en el articulado de la directiva, no en un resumen. Abajo, las fuentes primarias y el registro de cambios.
Nosotros también ponemos software en el mercado. Esto no lo hemos leído: nos lo estamos aplicando.
Miramos qué pones en el mercado, qué dice tu contrato hoy y qué habría que cambiar antes de diciembre. Aunque la conclusión sea que no te hace falta nada nuestro.