- Comentario al documentoLa responsabilidad del fabricante por los defectos en los productos se ha mantenido prácticamente invariable desde 1985 cuando ve la luz la Directiva 85/374/CEE. Quizá la nueva tecnología basada en inteligencia artificial suponga un punto de inflexión en su regulación en la medida en que deben replantearse conceptos tales como «producto», «defecto», «productor», «fundamento de la responsabilidad», «riesgos del desarrollo» o la «solidaridad». Las recomendaciones del Grupo de Expertos en responsabilidad y nuevas tecnologías (NTF), en su Informe «Liability for AI an other emerging digital technologies» (noviembre, 2019), van en la línea de, por un lado, excluir que el fabricante pueda oponer la excepción de los riesgos del desarrollo y, por otro, en establecer un doble fundamento de responsabilidad: riesgo y culpa. En el primer caso, me parece que eliminar esa excepción haciendo recaer todo el coste en el fabricante, alegando que es él el que se beneficia, es peligroso. Por un lado, porque es él el que invierte en alta tecnología y contribuye a su desarrollo y, por otro, porque conduce a una mayor socialización del daño. En el segundo caso, habrá que delimitar de forma muy precisa los diferentes ámbitos de aplicación de cada fundamento de responsabilidad para que no se complique todavía más la vida procesal a la víctima del daño. Aunque el Informe parte de la base de que las normas a la sazón vigente han resultado efectivas, lo cierto es que se ha creado un grupo de expertos dentro del seno del grupo de expertos que debe asesorar en la mejor adaptación de la Directiva 85/374/CEE al entorno digital. Quizá es que, a pesar de esas afirmaciones, no resulte tan evidente el tema. Veremos. Nuevos informes vendrán, seguramente, en el futuro.
I. EL RÉGIMEN DE RESPONSABILIDAD POR PRODUCTOS DEFECTUOSOS Y LA ATRIBUCIÓN DE PERSONALIDAD A LOS SISTEMAS EXPERTOS
En relación con el robot como entidad corpórea, se plantean cuestiones relacionadas con los daños que se puedan causar a terceros por los defectos que la máquina inteligente pudiera presentar. En este extremo, debe tenerse presente la posible atribución de personalidad electrónica a la que aludía la Resolución del Parlamento europeo de 16 de febrero de 2017 (2) . Este planteamiento cuestiona que se pueda, entonces, calificar al sistema experto del que tratamos como «producto». En efecto, incluirlo en la categoría de «producto» supone considerarlo un «objeto de derecho»; no un «sujeto de derecho» o una ePersona. Si esto fuera así, las normas relativas a la responsabilidad del fabricante por los daños causados por los productos no podrían aplicarse, pues, parten de «productos» que son «bienes muebles» y, principalmente, «cosas corporales». Me parece, además, evidente que la decisión política de atribuir personalidad, en su caso, a una entidad robotizada o a un sistema experto no debería ser solo para determinados efectos, sino que, en materia de responsabilidad, debería ser «a todos los efectos» para evitar las incoherencias del sistema.
En esta línea de pensamiento, si se atribuyera personalidad o se incluyera a los sistemas autónomos en la categoría de «sujeto de derecho» (3) , la regulación de la responsabilidad del fabricante debería darse sobre la base de que de los actos «imputables» a aquéllos, que causan daños, debería responder el fabricante cuando la causa de éstos se halla en un defecto presente en el «sujeto de derecho». Sea lo que fuere, lo cierto es que calificar al «robot» como «sujeto de derecho» o atribuirle «personalidad» supone un desafío importante para las normas reguladoras de los daños por «productos» defectuosos. De hecho, implicaría tener un doble régimen de responsabilidad: uno, para los «productos» defectuosos y, otro, para los «sujetos de derechos» defectuosos reformulándose, en este último caso, completamente el régimen. Así, por ejemplo, junto a múltiples cuestiones que suscitaría esta nueva perspectiva, nos podemos preguntar ¿debería responder solo el fabricante del «sujeto de derecho» acabado y no los productores de partes componentes pues solo el primero respondería por los daños imputables al sistema experto? ¿tendría sentido distinguir los tipos de defectos? ¿seguiría siendo válido el «consumer expectation test» en la determinación del concepto de defecto? Y tantas otras.
Sea lo que fuere, el Informe «Liability for Artificial Intelligence and other emerging digital technologies» del Grupo de Expertos (NTF) publicado en noviembre 2019 considera no necesaria la atribución de personalidad jurídica a estas nuevas tecnologías emergentes (4) porque, en definitiva, siempre se puede atribuir la responsabilidad a una persona física o jurídica que es la que está en situación de controlar el riesgo de que esa tecnología cause daños. Asimismo, se están evaluando la conocida como Directiva de máquinas (5) y la Directiva de seguridad general de los productos (6) . De los diferentes documentos que vienen siendo publicados parece que existe un común denominador, cual es el mantener el sistema de responsabilidad objetiva del productor (strict liability), si bien, el Informe al que me he referido combina este régimen con otro de responsabilidad por culpa cuando se considere que se ha infringido un deber de cuidado (fault liability) (7) .
Pese a lo advertido, vamos a partir aquí, en todo lo que exponemos seguidamente, en relación con la responsabilidad del fabricante de la consideración del robot como «producto», lo que permite aplicar las normas de la Directiva 85/374/CEE (LA LEY 1943/1985), de25 de julio de 1985 sobre responsabilidad por productos defectuosos (8) .
II. EL SOFTWARE COMO «PRODUCTO DEFECTUOSO» Y COMO «ELEMENTO INTEGRANTE DE UN BIEN»
Desde la perspectiva jurídica, en la mayor parte de casos, el «robot» será considerado un «bien mueble» que, además, puede calificarse de «producto». Si carece de «corpus», es decir, no se trata de un programa de ordenador embebido en un bien, en cuyo caso no existe problema alguno en orden a la aplicación de las normas reguladoras de la responsabilidad generada por los daños de los productos (9) , se plantea la cuestión de si se pueden aplicar aquéllas cuando el programa de ordenador en sí mismo, esto es, el stand-alone-software, es «defectuoso». Esta cuestión ha revivido con motivo de la responsabilidad por los daños que se pudieran ocasionar por el manejo de sistemas de IA al estar basados éstos en programas informáticos entendiéndose que se puede interpretar de forma amplia el art. 2 de la Directiva 85/374/CEE (LA LEY 1943/1985) para comprender al software de la misma manera que se contempla un bien intangible como es la electricidad (10) . Entender que éstos son defectuosos y, por consiguiente, que se les aplique la Directiva 85/374/CEE, mejor dicho, las normas nacionales que la implementan (11) , me parece posible si no se tiene en cuenta el tipo de daños que pueden resarcirse con base en dichas normas, esto es, daños causados por muerte o lesiones corporales, daños causados a una cosa o la destrucción de una cosa que no sea el propio producto defectuoso, siempre que esa cosa se destine al uso o consumo privado y el perjudicado la haya utilizado principalmente para su uso o consumo privado (art. 9 (LA LEY 1943/1985)). Es difícilmente pensable que el defecto que presente un stand-alone-software genere estos tipos de daños, en todo caso, puede generar daños económicamente puros como sería el caso de los algoritmos de alta frecuencia que emiten órdenes y contraórdenes al mercado, pero éstos no están comprendidos, como queda de manifiesto, en el ámbito de aplicación ni de la Directiva ni tampoco de las normas nacionales, habida cuenta de que la primera es una norma «de armonización máxima». Por tanto, para que se produzcan el tipo de daños previstos por las normas en caso de productos defectuosos, el software debe ser un elemento componente del bien corpóreo de que se trate, tomando la consideración su diseñador de productor de una parte integrante (art. 3 (LA LEY 1943/1985)), y llegando a responder si el fabricante del producto acabado demuestra que el defecto se debe al diseño de la parte integrante (art. 7 letra f) (LA LEY 1943/1985). La tecnología basada en IA no es un producto terminado, sino que está en constante evolución, incluso una vez que se ha puesto en circulación en el mercado. Hay constantes actualizaciones, mejoras y adaptaciones del contenido digital que hacen que la noción de producto, cuando se trata de tecnología emergente, no se corresponda con su concepto legal. Estas actualizaciones y mejoras son programas informáticos que se incluirían en la noción de «parte componente del producto».
En este extremo, es menester tener presente la Directiva (UE) 2019/770, del Parlamento europeo y del Consejo de 20 de mayo de 2019 relativa a determinados aspectos de los contratos de suministro de contenidos y servicios digitales (12) en cuyo Art. 2.3 (LA LEY 8797/2019) se define a los «bienes con elementos digitales» como «todo objeto mueble tangible que incorpore contenidos o servicios digitales o esté interconectado con ellos de tal modo que la ausencia de dichos contenidos o servicios digitales impediría que los bienes realizasen sus funciones». La propia norma considera como «contenido digital» al programa de ordenador, como advierte el considerando núm. 19, siempre que su código fuente sea cerrado y no abierto (considerando núm. 32 (LA LEY 8797/2019) (13) ), lo que tiene pleno sentido, habida cuenta de lo que significa que el código fuente sea abierto o accesible a terceros que pueden introducir cambios, en definitiva, pueden manipularlo.
En estos casos, hay que tener en cuenta que si el contenido digital, es decir, el software está incorporado al bien de suerte que la ausencia de este contenido impide que el bien realice sus funciones, la Directiva (UE) 2019/770 (LA LEY 8797/2019) no resultará de aplicación a dicho contenido (art. 3.4 (LA LEY 8797/2019)). La norma aplicable es la Directiva (UE) 2019/771, del Parlamento europeo y del Consejo de 20 de mayo de 2019, relativa a determinados aspectos de los contratos de compraventa de bienes (14) , en cuyo art. 3.3 (LA LEY 8796/2019) se recoge el supuesto que describimos. Esta norma se aplica con independencia de que el contenido o servicio digital no sea suministrado por el vendedor sino por un tercero que bien puede ser un intermediario como, por ejemplo, el proveedor de servicios en la nube que suministra un servicio digital al particular para poder acceder al contenido digital que se integra en el bien. Los daños que, en su caso, pudieran derivarse por la conexión con estos servicios o por un servicio digital no conforme no son resarcibles sobre la base de la responsabilidad por productos defectuosos pues estos intermediarios, proveedores de servicios de la sociedad de la información, no tienen la consideración de «productor» a los efectos de ese régimen ni el servicio digital puede calificarse de «producto» (15) .
El bien que integra el contenido digital —y sin el cual no puede funcionar o no hacerlo adecuadamente— puede presentar un defecto de seguridad referido al diseño del software que, además, implique que no pueda ser usado para la finalidad prevista, es decir, se trate de los denominados «productos ineficaces». En este supuesto, además de un defecto que causa daños conforme a las normas sobre responsabilidad por productos defectuosos, existirá una falta de conformidad que abre la vía a poder reclamar por ella al vendedor del bien (arts. 6 a 8 Directiva 2019/771 (LA LEY 8796/2019)). En los derechos nacionales, se planteará la concurrencia entre diferentes regímenes de responsabilidad (16) . Así, para el derecho español, cuando el particular sea un consumidor o usuario, deben recordarse los arts. 117.2 (LA LEY 11922/2007) y 128 TRLGDCU (LA LEY 11922/2007). Por lo tanto, se compatibilizan el régimen de responsabilidad extracontractual por los daños ocasionados por productos defectuosos y el de responsabilidad contractual por falta de conformidad.
III. DIVERSOS FUNDAMENTOS DE RESPONSABILIDAD EN FUNCIÓN DEL TIPO DE DEFECTO Y RIESGOS DEL DESARROLLO
1. Planteamiento del informe del grupo de expertos
De los diversos documentos de la UE que se han venido publicando, parece que la responsabilidad objetiva del productor seguirá siendo la principal regla de responsabilidad (17) , pero combinada, como sugiere la NFT, en caso de incumplimiento de un deber de cuidado con una regla de responsabilidad basada en la culpa. Este enfoque deja una pregunta abierta, es decir, cómo combinar adecuadamente ambos fundamentos de responsabilidad en el campo de los productos que causan daños. Junto con esta regla básica, el Informe NTF introduce un nuevo término, el de «operador». Que se refiere a una persona que tiene el control del riesgo relacionado con la operación del sistema de IA y que se beneficia de dicha operación. El término abarca conceptos tradicionales como propietario, poseedor o usuario. Con los sistemas de inteligencia artificial, a menudo hay más de una persona que «opera» la tecnología; por ejemplo, el usuario opera el vehículo autónomo, pero también hay otra persona que brinda servicios de soporte, actualiza el software, define las características de la tecnología o supervisa el sistema de aprendizaje automático. El primero es considerado como »frontend operator» y el segundo como «backend operator». Los expertos consideran que la responsabilidad objetiva debería corresponder a quien tiene más control sobre los riesgos que plantea la operación. En mi opinión, los expertos pensaban que el «frontend operator» es el usuario y el «backend operator» es el productor, el diseñador, el proveedor de servicios en línea o cualquier otra persona. Además, los operadores de sistemas de inteligencia artificial deben cumplir con una serie de deberes de cuidado, cuya infracción desencadena una responsabilidad basada en culpa. Para todas las categorías de «operadores», los deberes son: elegir el sistema correcto para la tarea y las habilidades correctas, mantenimiento y seguimiento del sistema. Los productores, independientemente de que actúen o no como operadores, deben diseñar, describir, informar y comercializar los productos de una manera que permita a los operadores cumplir con esas obligaciones y monitorear el producto después de ponerlo en circulación.
Este doble fundamento de responsabilidad (objetiva y por culpa) conduce a algunas preguntas que no son fáciles de resolver, cuando, por ejemplo, el productor es responsable como «frontend operator» además de por la violación de un deber de cuidado. Por otro lado, el usuario podría ser considerado responsable, junto al productor, sobre la base de su culpa al elegir el sistema para la tarea que quiere desarrollar o debido a sus malas habilidades para operar el sistema. Además, a veces hay relaciones contractuales entre los operadores frontend y backend. Desde la perspectiva de la víctima, hay una concurrencia de acciones frente a múltiples infractores (incertidumbre subjetiva, causas alternativas) que los legisladores nacionales deben considerar si, en llegado el caso, modifican sus sistemas legales.
El Informe de «Responsabilidad por Inteligencia Artificial» del NTF, en mi parecer, plantea preguntas interesantes sobre la responsabilidad del fabricante que deben resolverse en el futuro. Considera la responsabilidad objetiva del productor porque él es quien está en una mejor posición para controlar el riesgo y, además, se beneficia de la gestión de la nueva tecnología sin estar exento de los llamados «riesgos de desarrollo», lo que me parece obviamente excesivo y puede representar un freno importante a la innovación tecnológica. Sin embargo, si el productor puede ser considerado como «operador», puede ser responsable ante la víctima por el daño causado por la violación de un deber de cuidado. Por lo tanto, este doble régimen debería estar bien articulado. Por otro lado, aunque la regla general permanece, es decir, que la víctima debe probar la causa del daño, la reversión de la carga de la prueba de la causalidad y de la culpa del demandado se establece cuando es desproporcionadamente difícil o costoso demostrar que el nivel de seguridad, que se espera, no se ha dado (18) .
Finalmente, el Informe sugiere la introducción de un deber de monitorear los sistemas de IA después de ponerlo en circulación. Este deber fue rechazado por el TJCE al decidir si el legislador francés había brindado más protección que la establecida por la Directiva 85/374/CEE (LA LEY 1943/1985) al implementarlo. Sin embargo, este deber de controlar los productos fue introducido por la UE en otros sectores, como medicamentos, dispositivos médicos (19) o alimentos. Creo que esta recomendación debería ser muy bienvenida en la medida en que las nuevas tecnologías emergentes ya no se consideren como producto terminado. En cualquier caso, la violación de este deber de cuidado desencadena la responsabilidad por culpa.
2. Concepto de defecto. Updates y upgrades
El Art. 6.1 de la Directiva 85/374/CEE (LA LEY 1943/1985) introduce una noción de defecto del producto como un defecto de seguridad, seguridad que al perjudicado cabría legítimamente esperar (20) . Esta noción abstracta, también conocida como «consumer expectation test» interpretada por el TJUE como las «razonables expectativas del público en sentido amplio» (reasonable expectations of the publicatlarge) (21) , se adapta a las circunstancias concretas del caso a partir de tres criterios: la presentación del producto, el uso razonablemente previsible del mismo y el momento de su puesta en circulación (22) .
El momento de puesta en circulación del producto, que es un elemento central alrededor del cual pivota la responsabilidad del fabricante, plantea la cuestión de quién es el sujeto responsable si las actualizaciones (updates) y las mejoras (upgrades) del sistema experto son defectuosas, pero éste ya se había puesto en circulación (23) . En mi opinión, las propias actualizaciones, mejoras o modernizaciones deben ser consideradas como «producto» en la medida en que son programas informáticos y éstos se comprenden en el concepto legal de «producto» en la interpretación amplia que he indicado. Además, son programas embebidos en un bien. En este sentido, el momento relevante para determinar si presentaban o no un defecto es el momento relativo a la puesta en circulación de la propia actualización, mejora o modernización. En definitiva, hay diferentes momentos de puesta en circulación que deberán tenerse en cuenta.
Por su parte, el NTF se cuestiona en caso de sistemas sofisticados basados en IA con capacidades de aprendizaje y de toma de decisiones propia cuando se desvían del camino previsible, si esa desviación debe tratarse como un defecto (24) . Podrían ser tratados como un defecto de diseño si cuando se diseñó el sistema, la imprevisibilidad no fue contemplada. Entonces se podría tratar de un defecto de diseño.
Definido el defecto como lo hace la Directiva 85/374/CEE (LA LEY 1943/1985), no sería necesario diferenciar entre tipos de defectos como se hace en el derecho norteamericano de los daños por productos defectuosos (25) . Sin embargo, tanto nuestra doctrina como la jurisprudencia admiten distinguir los tipos de defectos, ya que, en la práctica, la víctima a la hora de probar el defecto del producto, que le ocasionó el daño, hará referencia al momento o fase de la fabricación del bien en el que se localiza el defecto y qué lo originó. En esta dirección, se suelen diferenciar, como es conocido, tres tipos de defectos: de diseño, de fabricación y de información.
3. Tipos de defectos
Me parece que debería diferenciarse el tipo de defecto para poder aplicar un criterio de imputación basado en la culpa o en una actividad anormalmente peligrosa. Y no simplemente aplicar a cualquier tipo de defecto el mismo fundamento de responsabilidad (riesgo creado) y que, en cualquier caso, siempre se pueda exonerar alegando la excepción de los riesgos del desarrollo. Seguidamente, me adentro en la postura en este trabajo mantenida.
A) Defecto de fabricación
El defecto de fabricación acaece cuando no se han tenido en cuenta las características propias del diseño y que sí cumplen los ejemplares de la misma serie (v.gr. una incorrecta instalación del software en un vehículo autónomo o presencia de virus en el software que ocasionan accidentes). Así, en el derecho español, el art. 137.2 TRLGDCU (LA LEY 11922/2007) explicita que: «en todo caso, un producto es defectuoso si no ofrece la seguridad normalmente ofrecida por los demás ejemplares de la misma serie». Lo determinante es la comparación del producto con los demás ejemplares de la misma serie (26) . Además, las consecuencias de un defecto en la fabricación de un sistema autónomo como, por ejemplo, un vehículo o dron autónomo, pueden ser graves tanto para las personas (los pasajeros del vehículo autónomo pues ya no cabe aludir a su conductor) como para los bienes. Basta constatar que se aparta de los otros ejemplares de la misma serie para declarar la responsabilidad del fabricante siendo irrelevante el grado de diligencia empleado en la producción y comercialización del producto en cuestión. El fabricante responderá por este defecto sobre la base de un criterio de imputación objetivo, si bien podrá alegar que el estado de los conocimientos científicos y técnicos existentes en el momento de la puesta en circulación no permitían apreciar la existencia del defecto (art. 140.1 letra f TRLGDCU (LA LEY 11922/2007), art. 7 letra e Directiva 85/374/CEE (LA LEY 1943/1985)).
Conocido es que en la fabricación de máquinas y robots deben aplicarse las normas ISO y las normas IEC, las cuales, en Europa, se aplican en el Derecho interno por mor de la conocida Directiva de máquinas 2006/42 (LA LEY 5808/2006) que, en este momento, se encuentra bajo revisión. En concreto, hay que tener presentes las siguientes: robots industriales, ISO 10218-1 e ISO 10218-2:2011, robots de cuidado personal, ISO 13482:2014, robots colaboradores, ISO/TS 15066:2016, robots cortacéspedes, IEC 60335-2-107, robots quirúrgicos, IEC 80601-2-78 y robots para rehabilitación, IEC 80601-2-77. Estos estándares de carácter técnico, como cualquier otro que pueda haber en el futuro, no son suficientes, a mi entender, para que el fabricante pueda exonerarse de responsabilidad por los denominados riesgos del desarrollo. Más bien, representan unos criterios mínimos de seguridad que deben cumplirse en la fabricación, que no suponen necesariamente que ese sea el estado de la ciencia y de la técnica en el momento de la puesta en circulación del robot (27) , el cual, además puede modificarse a sí mismo y reescribir su algoritmo en su adaptación al entorno. De hecho, en el informe de evaluación de la Directiva de máquinas se afirma que esta norma aplicada a los robots inteligentes y los sistemas autónomos presenta obstáculos (28) .
En la medida en que los robots corpóreos son cada vez más sofisticados, el acento hay que ponerlo sobre todo en su diseño, de suerte que los defectos, que hagan que el robot o máquina sea considerado «defectuoso/a», sean más frecuentemente defectos de diseño que de fabricación. Precisamente, gracias a las tecnologías emergentes, el proceso de fabricación es mucho más preciso y el riesgo de fabricar productos defectuosos puede disminuir considerablemente.
B) Defecto de diseño
En relación con el defecto de diseño del producto, puede considerarse que las expectativas del consumidor no aportan nada nuevo ni diferente que no haga ya la obligación de informar del fabricante acerca de los riesgos e instrucciones para el correcto manejo del robot como, en general, de cualquier producto. Si toda la información existe, las expectativas del consumidor no deben verse defraudadas.
En cambio, tener en cuenta el criterio de beneficio/riesgo en los defectos de diseño impone al fabricante la obligación de elaborar el diseño más seguro posible aun cuando los riesgos sean conocidos y se pudieran advertir al consumidor. Así, el «reasonable alternative design test» (29) se revela como el más adecuado en caso de defectos de diseño. Esto supone dejar de lado el régimen de responsabilidad objetiva para introducir otro más cercano al de la culpa que, teniendo en cuenta las dificultades de prueba del diseño alternativo razonable para el perjudicado (30) , podría hacer pensar en un régimen de responsabilidad por culpa con inversión de la carga de la prueba para el fabricante que será quien tendrá que probar que no existía, en el momento de la puesta en circulación del robot, un diseño alternativo razonable que permitiera evitar el daño ocasionado. En este caso, no podría exonerarse de responsabilidad alegando la excepción de los riesgos del desarrollo, pues le bastaría con probar la inexistencia de un diseño alternativo.
C) Defecto de información
El grado de sofisticación de los sistemas expertos implica una precisión mayor en las advertencias, informaciones e instrucciones que el fabricante deba suministrar al adquirente del robot, esto es, más información, pero también más técnica, con necesidad incluso de algún tipo de conocimiento específico, por parte del poseedor de la máquina inteligente, para comprender completamente la información suministrada. Ésta se torna más compleja, lo que puede llevar a que el defecto de información sea, junto al defecto de diseño, un tipo de defecto más frecuente que el defecto de fabricación cuando de robots y máquinas inteligentes se trate. Sea lo que fuere, lo cierto es que una futura información «personalizada» en función de las preferencias, necesidades, capacidades del cliente, con base en el análisis de datos masivos almacenados por el fabricante, puede facilitar su comprensión por parte de aquél (31) .
Hay que tener en cuenta que un producto puede estar correctamente diseñado y fabricado y aún así presentar toda una serie de riesgos muy difíciles de eliminar o de imposible eliminación porque no existe ningún proceso de fabricación o diseño alternativo que permita fabricar ese producto de forma más segura de acuerdo con los conocimientos de la ciencia y de la técnica que existan en ese momento. De estos riesgos debe informarse tanto a los profesionales como al público en general, sin que esos productos dejen de ser adquiridos pues en la relación riesgo/beneficio, gana el segundo respecto del primero.
Por tanto, respecto de máquinas inteligentes la información adquiere una gran relevancia. Valorar si existe un defecto de información supone preguntarse acerca de la conducta del fabricante pues es él que el suministra la información y decide cómo suministrarla. Los defectos de información tienen más sentido en un sistema de responsabilidad por culpa que en uno de responsabilidad por riesgo (32) , el cual, en aras a la protección del perjudicado, debería integrar la inversión de la carga de la prueba para el fabricante de la completud y legibilidad de la información. Esto supondría que el fabricante solo debería responder por la falta de información de los riesgos razonablemente previsibles, de suerte que de aquellos desconocidos porque, de acuerdo con el estado de la ciencia y de la técnica no se podían conocer y, consiguientemente, no pudo informar al perjudicado, no debería responder, es decir, debería poder exonerarse de responsabilidad alegando la excepción de los riesgos del desarrollo.
El perjudicado no podrá alegar frente al fabricante del producto como defecto de información, la ausencia de información o la incorrección en el suministro de la misma del fabricante directamente al intermediario (vendedor), sino que el defecto de información que puede hacer valer el perjudicado frente al fabricante debe referirse a la información que éste debe proporcionarle directamente a él. Por tanto, el fabricante no podrá exonerarse de responsabilidad alegando que él suministró la información necesaria al intermediario como, en cambio, sí puede en determinados casos, en el derecho angloamericano (learned intermediary rules). En el Derecho europeo, no sería posible.
4. En busca del equilibrio: inversión en tecnología versus coste del daño que se pudiera ocasionar
Con base en todo lo afirmado, si se sigue haciendo recaer, como en la normativa vigente, la responsabilidad sobre el fabricante del producto, la inversión en alta tecnología, por parte de éste, podría verse reducida sino frenada. En búsqueda del equilibrio entre inversión en investigación tecnológica y responsabilidad frente a terceros, la solución no debe ser tampoco inmunizar al fabricante (33) , como propone Ryan Calo (34) , en caso de determinados defectos, sino que, quizá la opción, podría ser diferenciar según «el fundamento de responsabilidad en función del tipo de defecto». En el caso de defecto de diseño y de información la responsabilidad debería partir del criterio de la culpa con una posible inversión de la carga de la prueba de haber empleado toda la diligencia debida, aunque los diversos mecanismos que se proponen para aliviar la carga de la prueba permiten cuestionar si es realmente necesaria su inversión; mientras que, en el supuesto, del defecto de fabricación, el criterio del riesgo sería el más adecuado. Sólo en este último caso y en el defecto de información, el fabricante de producto acabado que lo pone en circulación en el mercado podría alegar como causa de exoneración de la responsabilidad que el estado de los conocimientos científicos y técnicos no permitía conocer la existencia del defecto; no, para el defecto de diseño, respecto del cual la regla del «diseño alternativo razonable» cobraría especial relieve (35) . Se combinarían así dos criterios: el consumer expectation test (para los defectos de fabricación y de información, el reasonable alternative design test (para el defecto de diseño).
IV. CONCEPTO DE «PRODUCTOR». RESPONSABILIDAD PROPORCIONAL
Otro concepto que quizá merezca revisión sea el del «productor». Según las normas de responsabilidad civil del fabricante, éste, de acuerdo con el concepto legal de productor (art. 3 Directiva 85/374/EEC (LA LEY 1943/1985)), es el que responde por los daños que ocasione un producto defectuoso frente a terceros. Si se hace recaer exclusivamente en él la responsabilidad cuando el defecto no es propiamente de fabricación y, además, en el diseño, por ejemplo, han intervenido varias personas identificadas individualmente (v. gr. creador del algoritmo, programador, diseñador, fabricante de alguna pieza, …) o bien grupo o equipo de investigación, puede existir cierta falta de interés en invertir en la fabricación de robots u otras máquinas inteligentes.
Si se considera que gran parte de defectos, en caso de robots y máquinas inteligentes, puedan provenir de defectos de diseño o de concepción podría ampliarse el concepto de «productor» incorporando al «ingeniero-diseñador», siempre que sea un tercero ajeno a la esfera del primero, es decir, no trabaje para él (36) . En el Informe del NTF el «diseñador» del sistema experto puede ser considerado «operador», en particular, el «backend operator». Si tiene el control de la operación y se beneficia de ella, su responsabilidad será objetiva (37) . Cada vez es más frecuente, el empleo de un softwareopen source a partir del cual crear el robot (open robots) y, en estos casos, cualquiera puede introducir modificaciones, innovaciones, añadir determinados aspectos a los protocolos públicos, etc… La incertidumbre subjetiva incide en la existencia y prueba del «nexo causal» entre el defecto y el daño ocasionado.
En el ámbito de los daños por productos defectuosos (38) , aspectos relacionados con la prueba del daño, defecto y nexo causal, siendo una de las propuestas la aplicación de la regla mencionada del market share liability, de cara a una posible modificación de la Directiva 85/374/CEE (LA LEY 1943/1985) ya se plantearon, en 1999, con ocasión del Libro verde presentado por la Comisión sobre la responsabilidad civil por productos defectuosos (39) . Siendo conscientes, entonces, de las dificultades de la prueba del nexo causal para la víctima en casos de daños por productos defectuosos se plantearon posibles alternativas a la legislación, a la sazón, todavía vigente: i) una presunción legal del nexo causal cuando la víctima pruebe el defecto y el daño; ii) una presunción legal del defecto cuando la víctima pruebe la existencia del daño; iii) imponer al productor la obligación de facilitar todo tipo de documentación e información útil para que la víctima pueda beneficiarse de elementos concretos para demostrar su caso (Discovery rule); iv) con objeto de facilitar la carga de la prueba por parte de la víctima, imponer al productor el pago de los gastos periciales bajo determinadas condiciones: por ejemplo, la víctima podría pedir al juez que el productor adelante los gastos necesarios para practicar las diligencias de la prueba, a condición de que la víctima reembolse los gastos (más los posibles intereses) en caso de que no prospere la reclamación (costas judiciales) (40) .
La comunicación M2M podría facilitar la prueba, como hemos indicado con anterioridad, de la causalidad natural entre tipo de defecto y daño ocasionado. Cada vez es más frecuente el empleo de un softwareopen source a partir del cual crear el robot (open robots) y, en estos casos, cualquiera puede introducir modificaciones, innovaciones, añadir determinados aspectos a los protocolos públicos, etc… (41) . La incertidumbre subjetiva incide en la existencia y prueba del «nexo causal» entre el defecto y el daño ocasionado. Por eso, aunque no esté exenta de críticas (42) , la distribución de la responsabilidad por cuota de mercado o market share liability no me parece que deba estar ausente de este debate (43) . Por otro lado, está más en la línea de evitar el one-size-fits-all acercándose a una norma más «personalizada» (44) .
De todos modos, como he advertido, en la medida en que el software se considere una parte integrante del «producto», y, además, esencial, el productor del producto final podrá verse exonerado de responsabilidad si el defecto se debe al diseño de una pieza, siendo en este caso, el programa de ordenador. Así, el diseñador de éste podría responder directamente en cuanto «fabricante de una pieza integrante» del robot por los daños ocasionados (45) . En estos casos, el perjudicado deberá probar la existencia de un defecto en el programa de ordenador, esto es, en el algoritmo, lo que se revela, en la práctica, harto difícil (46) . Además, debe tenerse presente la constante actualización de los programas que contiene el sistema experto. Al final, puede ser difícil averiguar qué programa posee el defecto.
Sin embargo, el que se encuentra en mejor posición para probar que existía un diseño alternativo razonable es el propio diseñador. De ahí que, el criterio propuesto de responsabilidad por culpa con inversión de la carga de la prueba nos parezca el más adecuado. Sin embargo, se sigue proponiendo la aplicación de la responsabilidad objetiva lo que supone que sea la víctima la que tenga que probar el defecto, el daño y el nexo causal entre ambos. Ya se han visto los problemas de determinación del nexo causal y de prueba a los que se enfrentan las víctimas. Si es difícil la prueba del no defecto mediante la no existencia de un diseño alternativo razonable, para el perjudicado que ha sufrido los daños y que no tiene los conocimientos adecuados, además de ser mucho más difícil es también mucho más costoso. Quién está en mejor posición para soportar la prueba y a bajo coste es el diseñador del programa y no la víctima (cheapest cost avoider). De ahí que insista en que se replantee el criterio de imputación en el sentido apuntado más arriba. El acceso a la «black box» del sistema autónomo no elimina las dificultades de prueba del defecto para el perjudicado sobre todo en el caso de aquellos sistemas cuya lógica computacional se muestra elusiva o cuando es un algoritmo el que escribe otro algoritmo como sucede en el supuesto de los algoritmos genéticos (47) .
En el caso de sistemas expertos que toman decisiones y actúan consecuentemente con independencia de la voluntad humana, el control no estará ni en el «frontend operator» ni en el «backend operator», sino en el que lo diseñó e, incluso, a veces ni siquiera en él. En estos casos, la regla «harm within de risk» presentada en otro lugar puede ser una vía de solución más cercana a la realidad (48) .
V. CULPA DE LA VÍCTIMA
La responsabilidad objetiva prescinde de la culpa del agente causante del daño. Sencillamente, éste responde de los posibles eventos que cause el desarrollo de su actividad «anormalmente peligrosa». Sólo se exonerará de su responsabilidad si puede probar que el daño se debe a caso fortuito o fuerza mayor, culpa exclusiva de la víctima o hecho de un tercero (art. 8.2 Directiva 85/374/CEE (LA LEY 1943/1985)). Una vez concurren todos los requisitos que fundamentan la responsabilidad, quien ha causado un daño a otro debe responder salvo que pueda oponer una causa de exoneración. Una de las causas más frecuente total o parcialmente, en la práctica, es la culpa de la propia víctima. Ahora bien, no se puede hablar propiamente de causas de exoneración si no concurren todos los requisitos en los que se fundamenta la responsabilidad. Por lo tanto, decir que la culpa exclusiva de la víctima o el hecho de un tercero o la fuerza mayor son causas de exoneración de la responsabilidad, como suele manifestarse, es impropio, puesto que lo que, en realidad, sucede es que no nace uno de los requisitos necesario para que el causante del daño responda que es la culpa. Sin embargo, sí son causas de exoneración de la responsabilidad objetiva (art. 7:102 PETL) (49) .
Así, en el caso que nos ocupa, la víctima puede resultar responsable si los daños se deben a que no adoptó las medidas de seguridad en el uso del sistema experto como, por ejemplo, cambios periódicos de passwords, el implemento de las actualizaciones o la implementación de softwares de seguridad como firewalls para evitar las quiebras de seguridad del sistema por hackers, la instalación de virus o malware. También en el caso en que usen los sistemas expertos sin atender a las instrucciones e información facilitada por su productor (50) . En el caso de robots con código fuente abierto, la manipulación del programa por la propia víctima puede ser fuente de daños que permita exonerar de responsabilidad al fabricante-programador.
VI. CONCLUSIÓN
En materia de responsabilidad por los daños ocasionados por defectos de los robots o máquinas inteligentes debería procederse a una importante revisión. En algunos de los posibles aspectos a contemplar nos hemos entretenido en este trabajo.
Aunque el Informe del NTF «Liability for Artificial Intelligence and other emerging digital technologies» parte de la base de que la aplicación de la Directiva 85/374/CEE (LA LEY 1943/1985) ha resultado efectiva para la protección de los consumidores y la seguridad de los productos (51) , sí que entrevé que las nuevas tecnologías desafían conceptos importantes como el de producto, el de defecto o el fundamento de la responsabilidad cuando el productor mantiene cierto grado de control del producto una vez ha sido éste puesto en circulación. Por otro lado, la excepción de los riesgos del desarrollo está en el punto de mira. La tendencia es a impedir que el fabricante pueda alegarla. No debería hacerse, antes bien deberían diferenciarse los tipos de defectos para decidir respecto de cuál o cuáles no operaría. Sea lo que fuere, el Informe recomienda la combinación de un seguro obligatorio con uno voluntario además de la creación de un fondo de compensación que resarciera a aquellas víctimas que han sufrido un daño que finalmente por no darse los presupuestos no han sido compensadas.
De todos modos, este Informe no hace ningún planteamiento acerca de cómo deben implementarse sus recomendaciones en los derechos nacionales. Es más, se ha creado un grupo propio dentro del grupo de expertos cuya misión es aportar su «expertise» respecto de la aplicación de la Directiva 85/374/CEE (LA LEY 1943/1985) en el entorno tecnológico basado en IA. Probablemente a este primer Informe seguirán otros que seguirán desentrañando las cuestiones que la IA plantea para le responsabilidad civil. Todo ello, por supuesto, abocará a una modificación de la mencionada Directiva y consiguientemente de los derechos nacionales. En el caso del derecho español, la regulación debería desanclarse del derecho de consumo, es decir, el perjudicado no debería ser siempre y en todo caso un consumidor.