Tu software es un producto desde diciembre. Tus contratos todavía no lo reflejan.

Qué cambió el 9 de diciembre de 2026

La Directiva (UE) 2024/2853 sustituye desde el 9 de diciembre de 2026 a las normas de responsabilidad por productos defectuosos de 1985. Se aplica a los productos introducidos en el mercado o puestos en servicio a partir de esa fecha (artículo 2, apartado 1), que además es el plazo que tenía cada Estado miembro para incorporarla a su derecho nacional (artículo 22, apartado 1). Los productos vendidos antes siguen bajo el régimen antiguo (artículo 21), y eso es lo único que te da margen para planificar.

El cambio que importa son cuatro palabras en las definiciones. Ahora un producto es «todo bien mueble, aunque esté integrado en otro bien mueble o en un bien inmueble o interconectado con ellos», y la lista que sigue incluye expresamente el software (artículo 4, apartado 1). El considerando 13 va más allá y cierra las tres salidas que suelen buscar las empresas. El software cuenta «con independencia del modo de suministro o uso»: en un dispositivo, por red, a través de infraestructura en la nube o como software como servicio. A quien desarrolla o produce software —incluidos los proveedores de sistemas de IA en el sentido del AI Act— «se le debe considerar fabricante».

Así que la forma de tu negocio no decide esto. Una empresa de veinte personas que escribió una herramienta de control de stock para un distribuidor, un autónomo que ofrece una app de reservas por suscripción, un integrador que escribió el panel que su máquina necesita para funcionar: todos ellos están introduciendo un producto en el mercado en el sentido que usa la directiva.

Hay tres líneas finas que conviene conocer antes de asustarte o relajarte. Primero, la información no es un producto, y tampoco lo es el contenido de un archivo digital ni el mero código fuente: una lista de precios, un libro electrónico, un artículo que publicas. Segundo, un archivo digital de fabricación sí es un producto, porque contiene las instrucciones que gobiernan una máquina (considerando 16): el archivo CAD que hace funcionar una fresadora CNC o una impresora 3D entra dentro del ámbito, y uno defectuoso que produce una pieza que lesiona a alguien genera responsabilidad. Tercero, un «servicio relacionado» —un servicio digital integrado en un producto de tal forma que su ausencia impide que el producto haga una de sus funciones (artículo 4, apartado 3)— cuenta como parte del producto, aunque los servicios como tales no.

Lo que esto sustituye no era poca cosa. La directiva de 1985 ya hacía responsable al vendedor de los daños causados por bienes defectuosos sin necesidad de probar culpa. Lo que nunca resolvió fue si lo que vendías podía ser intangible, si una actualización formaba parte de ello y qué pasaba cuando el defecto aparecía dos años después de la entrega porque el sistema seguía aprendiendo. Esas preguntas ya tienen respuesta, y la respuesta cae del lado del fabricante.

Quién puede reclamar y por qué tus clientes empresariales, en general, no

Empecemos por quién puede reclamar. La directiva no crea un derecho general a indemnización para cualquiera que pierda dinero porque tu software falló. El artículo 1 lo limita a los daños «sufridos por personas físicas», y el artículo 5, apartado 1, atribuye el derecho a reclamar a una persona física. Una empresa que perdió una semana de producción no es el reclamante para el que se escribió esta directiva.

El artículo 6 recorta todavía más la lista de daños indemnizables. La indemnización cubre la muerte y las lesiones personales, incluidos los daños a la salud psicológica reconocidos médicamente. Cubre los daños en bienes, con tres exclusiones, una de las cuales son los bienes «utilizados exclusivamente con fines profesionales» (artículo 6, apartado 1, letra b, inciso iii). Cubre la destrucción o corrupción de datos, pero solo de datos «no utilizados con fines profesionales» (artículo 6, apartado 1, letra c). El análisis de las disposiciones sobre software del Instituto de Derecho Europeo deja clara la consecuencia: el daño puramente económico no es indemnizable, y tampoco lo son la mayoría de los perjuicios que se asocian a una mala IA: discriminación, manipulación, una recomendación equivocada que le costó una operación a alguien.

Vuelve sobre esa tabla, porque le da la vuelta al miedo más común. Si vendes solo a empresas y nada de lo que entregas puede lesionar a una persona ni dañar bienes privados, la nueva directiva añade muy poco a tu exposición. Tu cliente empresarial conserva todas las vías contractuales que ya tenía —el artículo 2, apartado 4, letra b, dice que las normas nacionales de contrato y de responsabilidad por culpa siguen intactas—, y ahí es donde siempre se han dirimido las disputas reales con un cliente empresarial.

Donde aprieta la directiva es en el momento en que tu producto toca a un particular. El sistema de reservas de una clínica que usan los pacientes, una máquina junto a la que trabaja un operario, la app de fidelización de una tienda en el móvil de un cliente, un sistema de seguimiento de repartos cuyo fallo manda a un conductor por una carretera cortada de noche. Ese es el perímetro que conviene dibujar en una pizarra antes de decidir cuánto de este artículo te afecta.

Dos detalles afinan el dibujo. El régimen antiguo tenía un umbral mínimo de daño; el resumen de la revisión del Parlamento Europeo confirma que el suelo de 500 € ha desaparecido, así que las reclamaciones pequeñas pasan a ser viables. Y una persona física incluye también a tu propia plantilla, lo que significa que una herramienta interna que daña a un empleado no queda protegida porque ningún cliente llegara a tocarla.

Tres mecanismos que te mantienen expuesto después de la entrega

Que la responsabilidad acabe el día que facturas es una idea cómoda. Con el software, la directiva no funciona así, y el motivo es el control: un producto que todavía puedes cambiar es un producto que sigue en tus manos.

El primer mecanismo es el aprendizaje. Cuando un tribunal valora si un producto es defectuoso, debe tener en cuenta «el efecto sobre el producto de cualquier capacidad de seguir aprendiendo o de adquirir nuevas características después de su introducción en el mercado o su puesta en servicio» (artículo 7, apartado 2, letra c). El resumen oficial de EUR-Lex lo dice sin rodeos: el fabricante responde de los defectos que aparecen por el aprendizaje continuo de un sistema de IA, cuando el sistema permanece bajo su control. Un modelo que a los tres meses empieza a dar peores respuestas no es una incidencia de mantenimiento que puedas facturar aparte. Es una cuestión de carácter defectuoso del producto que suministraste.

El segundo es la seguridad. El artículo 7, apartado 2, letra f, incorpora los «requisitos de ciberseguridad relevantes para la seguridad» a la hora de valorar si algo es defectuoso. Una versión de tu herramienta con un agujero conocido es más difícil de defender que otra que simplemente era imperfecta. Esto encaja con el Cyber Resilience Act, y por eso quien asesora sobre maquinaria o dispositivos conectados lee las dos normas juntas.

El tercero es la trampa de las actualizaciones, y es la que hace tropezar a las empresas pequeñas. El artículo 11 permite al fabricante librarse de la responsabilidad si demuestra que el defecto no existía cuando el producto se introdujo en el mercado. El artículo 11, apartado 2, elimina esa salida para cuatro cosas: un servicio relacionado, el software incluidas sus actualizaciones y mejoras, la falta de las actualizaciones necesarias para mantener el producto seguro y una modificación sustancial, siempre mientras el producto esté bajo tu control. Así que en el momento en que ofreces soporte y actualizaciones mensuales, mantienes vivo el reloj. No ofrecerlos tampoco te salva, porque la falta de una actualización de seguridad necesaria está en la lista.

Junto a todo esto hay un alivio. El artículo 7, apartado 3, dice que un producto no es defectuoso por el único motivo de que después apareciera uno mejor, actualización incluida. Sacar la versión 4 no condena retroactivamente a la versión 3.

Vamos con los números, y con los supuestos a la vista para que los sustituyas por los tuyos. Supongamos que llevas una empresa de doce personas que vende planificación de turnos a residencias: 40 clientes a 250 € al mes, es decir, 120.000 € al año. Mantener el expediente que te defiende significa notas de versión, evidencias de pruebas, el registro de parches de seguridad y el registro fechado de cada decisión de soporte. Pongamos cuatro horas al mes de un desarrollador a 45 € la hora: 180 € al mes, 2.160 € al año, alrededor del 1,8 % de los ingresos. Una reclamación discutida pide dos años de ese expediente, montado en semanas y no en meses. Los 2.160 € te compran la capacidad de responder. Lo que no te compran es un abogado, y por eso el mismo ejercicio debería terminar con una llamada a tu aseguradora y no a tu asesor.

Tu cláusula de exención de responsabilidad no sobrevive al artículo 15

La mayoría de las empresas de software pequeñas llevan en sus condiciones una versión de la misma frase: el software se entrega tal cual y el proveedor no asume responsabilidad por daños indirectos. Durante veinte años ha hecho un trabajo silencioso y muy útil. El artículo 15 la elimina precisamente en el escenario donde más importaba.

El artículo 15 dice que los Estados miembros deben garantizar que la responsabilidad de un operador económico según la directiva «no sea, frente a la persona perjudicada, limitada ni excluida por una disposición contractual ni por el derecho nacional». Dirige la cláusula a un paciente que resultó herido o a una familia a la que se le destruyeron los archivos y no hace nada. La cláusula sigue rigiendo tu relación con un cliente empresarial en cuanto al alcance de la garantía, los niveles de servicio y qué cuenta como defecto para el contrato, pero no puede alcanzar a la persona que protege la directiva.

Eso genera dos tareas distintas, y confundirlas es el error habitual. La primera tarea es el contrato que firmas con la empresa que compra tu software. Ahí el reparto sigue funcionando: indemnizaciones, límites, el reparto de responsabilidad sobre actualizaciones y parches de seguridad y quién responde de qué componente. El artículo 12, apartado 1, hace que los operadores responsables del mismo daño respondan de forma solidaria, lo que significa que la persona perjudicada puede venir primero a por ti y dejar que tú reclames al resto. Una cláusula de repetición es lo que convierte eso en un problema con solución y no en un golpe de tesorería.

La segunda tarea afecta a la empresa pequeña que está al otro lado de esa cláusula. El artículo 12, apartado 2, da una protección real, aunque estrecha, a la microempresa o pequeña empresa que suministró un componente de software defectuoso: el fabricante que lo integró no tiene derecho de repetición contra ella, siempre que el proveedor del software fuera una microempresa o pequeña empresa en el momento de introducirlo en el mercado y el contrato hubiera renunciado a esa repetición. Si eres el proveedor de componente de diez personas, esa renuncia merece la pena pedirla por escrito. Si eres el integrador, merece la pena leerla antes de firmar.

Hay una cláusula más que pertenece a esta misma revisión. El artículo 8, apartado 3, hace responsable al distribuidor cuando no se puede identificar a un operador de la UE en la cadena y el distribuidor no designa uno en el mes siguiente a la solicitud de la persona perjudicada. Si revendes software fabricado fuera de la UE y tu documentación no dice quién es el importador o el representante autorizado, cuatro semanas de silencio te convierten en el demandado.

Nada de esto exige tener un despacho de abogados en nómina para arreglarlo. Exige leer tus condiciones generales una vez, marcar los párrafos que pretenden excluir la responsabilidad y decidir cuáles hacían un trabajo real y cuáles eran decoración.

Los documentos deciden el caso

Cuando se presenta una reclamación, los hechos técnicos tienen ya dos años y la persona que escribió ese módulo se ha ido. Con lo que cuenta un tribunal es con lo que tú guardaste. La directiva lo empeora más de lo que parece, porque no se limita a permitir que la otra parte pida documentos: une consecuencias a no tenerlos.

El artículo 9, apartado 1, obliga al demandado a aportar las pruebas pertinentes de que disponga una vez que el reclamante ha presentado hechos suficientes para que la reclamación resulte verosímil. La proporcionalidad y los secretos comerciales están protegidos, y el tribunal puede ordenar medidas para mantenerlos confidenciales. Esa parte es manejable. El artículo 10 es donde la cosa se afila: si el demandado no aporta las pruebas del artículo 9, apartado 1, el producto se presume defectuoso (artículo 10, apartado 2, letra a). La misma presunción se aplica si el reclamante demuestra que el producto incumplió requisitos de seguridad obligatorios destinados a prevenir el daño sufrido, o que se produjo un mal funcionamiento evidente en un uso razonablemente previsible.

El artículo 10, apartado 4, cierra el círculo para el software y la IA en concreto. Cuando el reclamante se enfrenta a «dificultades excesivas» para probar el defecto o el nexo causal, en particular por complejidad técnica o científica, y puede demostrar que es probable, el tribunal presume uno de los dos o ambos. El modelo de caja negra es el ejemplo que todo el mundo cita. Las presunciones son rebatibles, y lo que las rebate son tus pruebas, pero una carpeta vacía no es una prueba: es una concesión.

La única defensa real que tienes en cuanto al fondo está en el artículo 11, apartado 1, letra e: no hay responsabilidad si el estado de los conocimientos científicos y técnicos en el momento pertinente no permitía descubrir el defecto. Es la razón por la que no se espera que una empresa hubiera previsto una vulnerabilidad que nadie había encontrado. Hay dos límites. Los Estados miembros pueden apartarse y mantener o introducir normas más estrictas (artículo 20), así que la defensa no es uniforme en toda la UE. Y solo funciona si puedes demostrar qué sabías y cuándo, que vuelve a ser una cuestión de documentación.

Los plazos marcan la regla de conservación. La reclamación debe presentarse en los tres años siguientes a que la persona perjudicada conozca el daño, el defecto y quién es el responsable (artículo 16, apartado 1), pero el límite máximo es de diez años desde la introducción en el mercado (artículo 17, apartado 1), ampliado a 25 años cuando una lesión personal tarda en manifestarse (artículo 17, apartado 2). Diez años es la cifra con la que hay que diseñar.

1. Registro de cada versión: fecha, qué cambió, qué se probó y quién lo validó.
2. Evidencias de prueba de los modos de fallo que pueden causar daño a alguien, no solo los que incomodan a los usuarios.
3. Registro de seguridad: vulnerabilidades conocidas, fechas de los parches y cualquier actualización que decidiste no lanzar, con el motivo.
4. Decisiones de soporte por escrito y con fecha, incluidas aquellas en las que dijiste a un cliente que su petición estaba fuera de alcance.
5. Lista de proveedores y componentes, con quién suministró qué y quién es el operador de la UE para todo lo fabricado fuera de ella.

Diez años de notas de versión salen más baratos que una vista en la que no puedes explicar qué entregaste.

La regla de conservación que se deriva de los artículos 9, 10 y 17

Cuándo no se aplica y cuándo lo correcto es esperar

Muchas empresas pequeñas leerán esto, revisarán su situación y, con razón, no harán casi nada. Llegar a esa conclusión de forma deliberada merece una hora, porque la alternativa es un proyecto de cumplimiento inútil o un disgusto serio.

Puedes dejar el expediente a un lado si tu software nunca llega a una persona física ajena a tu plantilla y no puede dañar bienes ni datos privados. Una herramienta que solo usa un profesional formado, dentro de su propia empresa, para producir trabajo para otras empresas, queda en gran medida fuera de las categorías de daño del artículo 6. Lo mismo para un distribuidor puro que nunca pone su marca, modifica ni revende con su nombre, con la obligación de identificación en el plazo de un mes del artículo 8, apartado 3, como la excepción que sí debes respetar.

El software libre y de código abierto desarrollado o suministrado al margen de una actividad comercial queda excluido (artículo 2, apartado 2). La exclusión es más estrecha de lo que sugiere el eslogan. El considerando 14 dice que el software suministrado a cambio de un precio, o de datos personales utilizados para algo más que mejorar su seguridad, compatibilidad o interoperabilidad, cuenta como actividad comercial y vuelve al ámbito. Un producto de núcleo abierto con una versión de pago es un producto comercial. Una biblioteca que publicas gratis y de la que además vendes soporte es la zona gris sobre la que merece la pena preguntar a un abogado.

Los productos introducidos en el mercado antes del 9 de diciembre de 2026 siguen bajo las normas de 1985 (artículo 21), lo que supone un alivio real para una base instalada. Pero quedan dos puertas abiertas. El artículo 8, apartado 2, considera fabricante del producto a quien lo modifica sustancialmente fuera del control del fabricante, y una modificación sustancial se define por referencia a un cambio de rendimiento, finalidad o tipo más un peligro modificado o incrementado (artículo 4, apartado 18). Personalizar una plataforma antigua para un cliente nuevo puede meter un producto viejo en el régimen nuevo. Y las actualizaciones que lances después de esa fecha son software suministrado después de esa fecha.

Una última cosa que puedes saltarte: esta directiva no trae certificado, ni registro, ni presentación, ni tasa. No hay que enviar nada a ninguna autoridad. Es una norma de responsabilidad que se activa cuando algo va mal, así que el trabajo es interno y el plazo era el día en que se aplicó. Un consultor que te venda una insignia de cumplimiento por esto te está vendiendo una insignia.

Qué hacer el lunes

El trabajo es lo bastante pequeño para empezarlo en una sola tarde, y empieza con una lista, no con un documento. Apunta cada producto que suministras y que toca alguien de fuera de tu empresa: la app, el portal de cliente, el panel que viene con la máquina, el archivo que gobierna la cortadora del cliente. Junto a cada uno, anota quién podría sufrir un daño y qué podría perder. Esa lista es todo el alcance de tu exposición, y la mayoría de las empresas descubre que es más corta de lo que temía y distinta de lo que suponía.

Después cruza tu papel con lo que cambia.

Dos hábitos sostienen el resto. Pon a una persona designada al frente de las decisiones de actualización y de fin de soporte, porque el artículo 11, apartado 2, convierte «dejamos de parchearlo» en una cuestión de responsabilidad y no en una interna. Y mete la conversación con la aseguradora en el calendario: las coberturas de responsabilidad por productos pensadas para hardware suelen excluir el software, los datos y el daño psicológico que la directiva ahora reconoce, y un corredor al que no le has preguntado por funciones de IA no te va a mencionar ese hueco. Con independencia de lo que diga hoy tu póliza, averígualo antes de que llegue una carta: es el único punto de esta lista en el que llegar tarde sale caro en vez de resultar bochornoso.

Preguntas frecuentes

¿Se aplica al software como servicio o solo al software instalado?

Se aplica a los dos. El considerando 13 afirma que el software cuenta como producto «con independencia del modo de suministro o uso», ya esté almacenado en un dispositivo, se acceda por red o se suministre como servicio. No hay ninguna exención de SaaS que encontrar.

¿Tengo que registrar, certificar o notificar algo?

No. La directiva crea responsabilidad y deberes de aportación de pruebas dentro de un procedimiento judicial; no establece registro, certificado ni presentación alguna. Tus obligaciones entran en juego cuando una persona reclama daños, y por eso la preparación práctica son registros internos y no una presentación ante una autoridad.

Mi producto es libre y de código abierto. ¿Queda fuera del ámbito?

Si lo desarrollas o lo suministras al margen de una actividad comercial, sí (artículo 2, apartado 2). La exclusión se estrecha en el momento en que entra dinero o datos personales: el considerando 14 devuelve al ámbito el software suministrado a cambio de un precio, o de datos personales usados para algo más que mejorar la seguridad, la compatibilidad o la interoperabilidad. Una versión alojada de pago de un proyecto de código abierto es un producto comercial.

¿Cuánto tiempo tengo que conservar los registros?

Cuenta con diez años desde la introducción del producto en el mercado, porque es cuando caduca el límite máximo del artículo 17, apartado 1. Cuando una lesión personal tarda años en manifestarse, el artículo 17, apartado 2, lo amplía a 25 años. Los tres años son solo el plazo del que dispone la persona perjudicada para actuar desde que conoce el daño.

¿Puede demandarme un cliente empresarial al amparo de esta directiva?

No por esta vía. Los artículos 1 y 5, apartado 1, atribuyen el derecho a reclamar a personas físicas, y el artículo 6 excluye los bienes y los datos utilizados con fines profesionales. Eso no significa que un cliente empresarial se quede sin remedio —el artículo 2, apartado 4, letra b, no toca las reclamaciones por presupuesto, garantía o contrato—, pero se dirimen sobre el contrato, no sobre esta directiva.

Si tu empresa construye, integra o revende software y quieres un segundo par de ojos sobre dónde está realmente la exposición, cuéntanos qué entregas y quién lo toca. Construimos y mantenemos automatizaciones para pymes, y preferimos mapear esto antes de que llegue una carta que después.