I. Transparencia, explicabilidad y trazabilidad de la IA
En los principales instrumentos éticos internacionales sobre inteligencia artificial que hemos analizado en otras ocasiones (2) se mencionan como principios fundamentales la transparencia, explicabilidad y trazabilidad de la IA. Así, por ejemplo, en las Recomendaciones éticas de IA de UNESCO (3) .Las recomendaciones diferencian entre valores y principios, para a continuación establecer los ámbitos de actuaciones en lo que los estado deben concretar estos, para continuar estableciendo la necesidad del establecimiento de sistemas de evaluación y seguimiento ético de la IA, en los términos que desarrolla, siendo de especial relevancia que los mismos sean trasversales no solo a todos los intervinientes en el proceso, sino a todos los estratos sociales, culturales y de género, fortaleciendo la trasparecía y la accesibilidad.
Dentro del apartado de los principios se menciona la transparencia y explicabilidad. Resaltar que no se establece una pretensión absoluta en esta materia, sino que «debería ser siempre adecuado al contexto y al efecto, ya que puede ser necesario encontrar un equilibrio entre la transparencia y la explicabilidad y otros principios como la privacidad, la seguridad y la protección». Esto sin embargo no supone un cheque en blanco ya que instrumento enlaza directamente este principio con el de la responsabilidad y rendición de cuentas. Aunque su colocación en este principio no es completamente acertada las recomendaciones sí que exigen «los actores de la IA deberían informar a los usuarios cuando un producto o servicio se proporcione directamente o con la ayuda de sistemas de IA de manera adecuada y oportuna».
Las Normas de Derecho civil sobre robótica. Resolución del Parlamento Europeo, de 16 de febrero de 2017, con recomendaciones destinadas a la Comisión sobre normas de Derecho civil sobre robótica (2015/2103(INL)) (4) comienzan desde el monstruo de Frankenstein creado por Mary Shelley al mito clásico de Pigmalión, pasando por el Golem de Praga o el robot de Karel Čapek —que fue quien acuñó el término—, manifestando que los seres humanos han fantaseado siempre con la posibilidad de construir máquinas inteligentes, sobre todo androides humanoides. Y reconoce que ante una nueva era se hace necesario el impulso legislativo e incluso dar una definición generalmente aceptada de robot y de inteligencia artificial que sea flexible y no lastre la innovación. Una normativa en materia de responsabilidad, transparencia y rendición de cuentas que reflejen los valores humanistas intrínsecamente europeos y universales y asume el liderazgo europeo en una posible normativa que refleje los valores éticos.
Las posibles tensiones o riesgos en este ámbito serían: la seguridad y la salud humanas; la libertad, la intimidad, la integridad y la dignidad; la autodeterminación y la no discriminación, y la protección de los datos personales. Añade además, los principios de beneficencia, no maleficencia, autonomía y justicia, así como en los principios consagrados en la Carta de los Derechos Fundamentales de la Unión Europea (LA LEY 12415/2007), como la dignidad humana, la igualdad, la justicia y la equidad, la no discriminación, el consentimiento informado, la vida privada y familiar y la protección de datos, así como en otros principios y valores inherentes al Derecho de la Unión, como la no estigmatización, la transparencia, la autonomía, la responsabilidad individual, y la responsabilidad social, sin olvidar las actuales prácticas y códigos éticos. Y estos principios deben regar el normativo. Se destaca el principio de transparencia en cuanto a la necesidad de justificación de las decisiones adoptadas por una IA.
Asimismo las actividades de investigación en materia de robótica deben respetar los derechos fundamentales y deberán llevarse a cabo conforme a los principios de precaución, transparencia y participación en toma de decisiones, rendición de cuentas, seguridad, reversibilidad (esto es, la posibilidad de deshacer la última acción o secuencia de acciones, permite al usuario anular las acciones no deseadas y volver a la fase «buena» de su trabajo), privacidad e intimidad y evaluación y control de riesgos.
La Resolución del Parlamento Europeo, de 14 de marzo de 2017 (LA LEY 12303/2018), sobre las implicaciones de los macrodatos en los derechos fundamentales (Parlamento Europeo, 2017b) (5) establece la responsabilidad algorítmica y la transparencia deben implicar la aplicación de medidas técnicas y operativas para una IA fiable por lo que respecta al tratamiento y la analítica de datos por los sectores público y privado.
A su vez las directrices de ética para una IA confiable de 18 de diciembre de 2018 el grupo de expertos Grupo de Expertos de Alto Nivel en IA (AI-HLEG, 2018) (6) abordan el principio de explicabilidad o de operar de manera transparente: la transparencia es la llave para que la ciudadanía mantenga la confianza en sistemas de IA. Esto implica que sean sistemas auditables, comprensibles e inteligibles por humanos. Siendo la explicabilidad un prerrequisito para que los individuos consientan interactuar con inteligencia artificial. Por consiguiente, mediante la transparencia, la explicabilidad, se deberá describir las posibles decisiones y cambios que tienen un impacto moral significativo en los humanos.
A su vez, la Resolución del Parlamento Europeo, de 20 de octubre de 2020, con recomendaciones destinadas a la Comisión sobre un marco de los aspectos éticos de la inteligencia artificial, la robótica y las tecnologías conexas (2020/2012(INL)) recuerda que el derecho a la información de los consumidores constituye un principio fundamental en virtud del Derecho de la Unión, y subraya que, en consecuencia, debe respetarse plenamente en relación con la inteligencia artificial, la robótica y las tecnologías conexas; opina que ello ha de incluir en particular la transparencia en lo que respecta a la interacción con los sistemas de inteligencia artificial, incluidos los procesos de automatización.
Menciona asimismo las condiciones de explicabilidad, auditabilidad, trazabilidad y transparencia en cuanto que no siempre es posible explicar por qué un modelo ha dado lugar a un resultado o una decisión en concreto, como por ejemplo en el caso de los algoritmos de «caja negra»; estima, por consiguiente, que el respeto de estos principios es condición necesaria para poder asegurar la rendición de cuentas. Y sostiene que los valores éticos de la equidad, la exactitud, la confidencialidad y la transparencia deben ser la base de estas tecnologías.
De igual manera, el ya lejano Libro Blanco sobre la inteligencia artificial - un enfoque europeo orientado a la excelencia y la confianza, Bruselas, 19.2.2020 COM (2020) 65 final menciona entre los siete requisitos esenciales contemplados en los que se basa la confianza en el sistema, la transparencia.
Y la Carta ética europea sobre el uso de la inteligencia artificial en los sistemas judiciales y su entorno adoptado por el CEPEJ durante su 31 Reunión plenaria (Estrasburgo, 3-4 de diciembre de 2018) (7) igualmente reconoce como uno de los principios fundamentales la transparencia, imparcialidad y justicia: hacer que los métodos de procesamiento de datos sean accesibles y comprensibles, autorizar auditorías externas.
Así, se debe alcanzar un equilibrio entre la propiedad intelectual de ciertos métodos de procesamiento
y la necesidad de transparencia (acceso al proceso de diseño), imparcialidad (ausencia de sesgo), justicia y integridad intelectual (priorizar los intereses de la justicia).
En cuanto a la Carta de Derechos Digitales (LA LEY 16317/2021) española: La inteligencia artificial deberá asegurar las condiciones de transparencia, auditabilidad, explicabilidad, trazabilidad, supervisión humana y gobernanza. En todo caso, la información facilitada deberá ser accesible y comprensible y deberán garantizarse la accesibilidad, usabilidad y fiabilidad.
Así, en relación con la actuación administrativa:
- a) Que las decisiones y actividades en el entorno digital respeten los principios de buen gobierno y el derecho a una buena Administración digital, así como los principios éticos que guían el diseño y los usos de la inteligencia artificial.
- b) La transparencia sobre el uso de instrumentos de inteligencia artificial y sobre su funcionamiento y alcance en cada procedimiento concreto y, en particular, acerca de los datos utilizados, su margen de error, su ámbito de aplicación y su carácter decisorio o no decisorio. La ley podrá regular las condiciones de transparencia y el acceso al código fuente, especialmente con objeto de verificar que no produce resultados discriminatorios.
- c) Obtener una motivación comprensible en lenguaje natural de las decisiones que se adopten en el entorno digital, con justificación de las normas jurídicas relevantes, tecnología empleada, así como de los criterios de aplicación de estas al caso. El interesado tendrá derecho a que se motive o se explique la decisión administrativa cuando esta se separe del criterio propuesto por un sistema automatizado o inteligente.
- d) Que la adopción de decisiones discrecionales quede reservada a personas, salvo que normativamente se prevea la adopción de decisiones automatizadas con garantías adecuadas
La inteligencia artificial deberá asegurar un enfoque centrado en la persona y su inalienable dignidad, perseguirá el bien común y asegurará cumplir con el principio de no maleficencia. A ello hemos de añadir como decíamos el Título XXV en cuanto «Derechos ante la inteligencia artificial» que plasma:
1º «La inteligencia artificial deberá asegurar un enfoque centrado en la persona y su inalienable dignidad, perseguirá el bien común y asegurará cumplir con el principio de no maleficencia».
a) Se deberá garantizar el derecho a la no discriminación cualquiera que fuera su origen, causa o naturaleza, en relación con las decisiones, uso de datos y procesos basados en inteligencia artificial.
b) Se establecerán condiciones de transparencia, auditabilidad, explicabilidad, trazabilidad, supervisión humana y gobernanza. En todo caso, la información facilitada deberá ser accesible y comprensible.
c) Deberán garantizarse la accesibilidad, usabilidad y fiabilidad.
3. Las personas tienen derecho a solicitar una supervisión e intervención humana y a impugnar las decisiones automatizadas tomadas por sistemas de inteligencia artificial que produzcan efectos en su esfera personal y patrimonial.
De esta manera se configuran como principios éticos fundamentales en el ordenamiento español en cuanto a la inteligencia artificial el enfoque en la persona y en su dignidad, la no discriminación, transparencia, auditabilidad, explicabilidad, trazabilidad, supervisión humana, gobernanza, accesibilidad, universalidad, comprensibilidad, usabilidad, fiabilidad y supervisión y control humana.
Por su parte, la Declaración Europea sobre los principios y derechos digitales se establecen una serie de compromisos, que son plenamente coincidente con gran parte del contenido del reglamento sobre IA. Entre los citados compromisos se concretan en
b) velar por un nivel adecuado de transparencia en el uso de los algoritmos y la inteligencia artificial y porque las personas estén informadas y capacitadas para utilizarlos cuando interactúen con ellos;
En definitiva, se consagran en general como principios éticos la Transparencia y explicabilidad. Los principios de transparencia y explicabilidad supone que los sistemas puedan ser enteramente comprendidos por un ser humano, desde la forma en la captación y tratamiento los datos, sean o no personales, hasta la manera en la que se toman las decisiones, así como las consecuencias de estas y sus interdependencias. Este principio garantiza que la persona tenga y mantenga el control informado global sobre la existencia y la actividad de una solución de inteligencia artificial. La explicabilidad de la tecnología hace referencia a la capacidad de explicar en términos humanos la toma de decisiones de la inteligencia artificial.
La transparencia incluye el acceso al funcionamiento y resultados, explicabilidad, trazabilidad y auditabilidad del uso público y privado de la IA. Se puede traducir también en datos y posibles algoritmos de código abierto, contratación pública abierta e información de cuándo se interactúa con una IA o cuándo adopta decisiones sobre las personas.
En este sentido la Ley Europea de Inteligencia Artificial (LA LEY 16665/2024) impone unos requisitos con obligaciones de documentación, etiquetado y el registro, la transparencia y la comunicación de información a los usuarios.
Pero, esa comprensión del algoritmo, sus consecuencias de las decisiones, actividad, explicabilidad, y trazabilidad, ¿supone necesariamente la necesidad de acceso al código fuente?
Sobre esto, de lo poco escrito y en materia de inteligencia artificial y derecho siempre hay que mencionar como autor indispensable al magistrado ERCILLA GARCÍA (8) quien considera que los parámetros, reglas e instrucciones de un algoritmo son «como la receta de un plato: nos dicen qué ingredientes necesitamos y cómo combinarlos para obtener el resultado deseado. Sin embargo, no nos proporcionan información sobre cómo se creó la receta en primer lugar, ni nos permiten modificarla de manera significativa.
En contraste, tener acceso al código fuente de un algoritmo es como tener acceso a la cocina donde se creó la receta. Nos permite ver exactamente cómo se combinan los ingredientes, modificar la receta si es necesario, e incluso crear nuestras propias recetas a partir de los ingredientes disponibles. En términos de algoritmos, tener acceso al código fuente nos permite ver exactamente cómo se procesan los datos, modificar el algoritmo si es necesario, e incluso crear nuestros propios algoritmos a partir de los componentes disponibles». Y se defiende que el acceso al código, por lo tanto, permitiría, fiscalizar la realidad en la implementación de esos parámetros, reglas e instrucciones, así como verificar que la misma se ha hecho correctamente y no ha habido errores
Por nuestra parte en este artículo, y con base en cierta jurisprudencia norteamericana y cuestiones periciales argumentaremos que el acceso al código fuente ha de ser como opción subsidiaria tras descartar otras opciones previas.
II. Normativa
El Reglamento Europeo de inteligencia artificial (LA LEY 16665/2024) (9) según el cual, en su art. 4 bis, en cuanto a la «Transparencia», «los sistemas de IA se desarrollarán y utilizarán facilitando una trazabilidad y explicabilidad adecuadas, haciendo que las personas sean conscientes de que se comunican o interactúan con un sistema de IA, informando debidamente a los usuarios sobre las capacidades y limitaciones de dicho sistema de IA e informando a las personas afectadas de sus derechos».
O por ejemplo en su Art. 13 apartado 1º: la transparencia significará que, en el momento de la introducción en el mercado del sistema de IA de alto riesgo, se utilizarán todos los medios técnicos disponibles de conformidad con el estado actual de la técnica generalmente reconocido para garantizar que el proveedor y el usuario puedan interpretar la información de salida del sistema de IA de alto riesgo. El usuario de estar capacitado para comprender y utilizar adecuadamente el sistema de IA sabiendo, en general, cómo funciona el sistema de IA y qué datos trata, lo que le permitirá explicar las decisiones adoptadas por el sistema de IA a la persona afectada de conformidad con el artículo 68, letra c).
A este respecto, hemos de recordar la nueva normativa de Ley 15/2022, de 12 de julio, integral para la igualdad de trato y la no discriminación (LA LEY 15917/2022) a la resolución del recurso, según el cual, en su artículo 23: […] las administraciones públicas favorecerán la puesta en marcha de mecanismos para que los algoritmos involucrados en la toma de decisiones que se utilicen en las administraciones públicas tengan en cuenta criterios de minimización de sesgos, transparencia y rendición de cuentas, siempre que sea factible técnicamente. En estos mecanismos se incluirán su diseño y datos de entrenamiento, y abordarán su potencial impacto discriminatorio. Para lograr este fin, se promoverá la realización de evaluaciones de impacto que determinen el posible sesgo discriminatorio.
2. Las administraciones públicas, en el marco de sus competencias en el ámbito de los algoritmos involucrados en procesos de toma de decisiones, priorizarán la transparencia en el diseño y la implementación y la capacidad de interpretación de las decisiones adoptadas por los mismos.
3. Las administraciones públicas y las empresas promoverán el uso de una Inteligencia Artificial ética, confiable y respetuosa con los derechos fundamentales, siguiendo especialmente las recomendaciones de la Unión Europea en este sentido.
4. Se promoverá un sello de calidad de los algoritmos.
Como cuenta ERCILLA GARCIA (2023) se ha introducido en el Estatuto de Trabajadores el derecho del Comité de Empresa a d) Ser informado por la empresa de los parámetros, reglas e instrucciones en los que se basan los algoritmos o sistemas de inteligencia artificial que afectan a la toma de decisiones que pueden incidir en las condiciones de trabajo, el acceso y mantenimiento del empleo, incluida la elaboración de perfiles.
Lo cierto es, que este derecho del comité de empresa en cuanto a la información de parámetros, reglas e instrucciones, recuerda mucho al Art. 13.2 del RGPD (LA LEY 6637/2016)Reglamento (UE) 2016/679 del Parlamento Europeo y del Consejo de 27 de abril de 2016 relativo a la protección de las personas físicas en lo que respecta al tratamiento de datos personales y a la libre circulación de estos datos (LA LEY 6637/2016)f) de la obligación de facilitar por el responsable de tratamiento en caso de decisiones automatizadas y elaboración de perfiles información significativa sobre la lógica aplicada, así como la importancia y las consecuencias previstas de dicho tratamiento para el interesado.
Se considera que quizás el legislador si asimila ambos términos en cuanto reglas, parámetros e instrucciones a lógica, importancia y consecuencias, lo más entendible y recomendable habría sido una unificación de términos con el RGPD.
Está claro, además, que por ejemplo en justicia, Art. 120.3 de la Constitución Española (LA LEY 2500/1978) establece que las sentencias siempre serán motivadas. Por ello, no podría haber un algoritmo opaco o al menos no comprensible, porque la gente tiene derecho a saber la motivación de una resolución judicial y el proceso lógico deductivo por el cual se ha llegado a ella.
III. Aspectos periciales
Resultará evidente al lector, que la prueba de hechos en lo relativo al correcto o incorrecto funcionamiento de una Inteligencia Artificial accederá al proceso, en general, a través de un dictamen pericial informático. Y ello es lo lógico, dado que se trata de una materia muy técnica y específica, en la que, a buen seguro, el juzgador necesitará auxilio de un perito informático especializado.
Así pues, hay tres preguntas que, a priori, deberá despejar toda prueba pericial en lo relativo a una Inteligencia Artificial:
- a) El software informático sometido a examen, ¿es realmente una Inteligencia Artificial según la definición legal?
- b) ¿Qué procesos concretos son los que, supuestamente, han producido un resultado erróneo?
- c) De existir un resultado erróneo en un proceso, ¿se debe a un fallo de diseño, y/o implementación, y/o configuración, y/o puesta en marcha, y/o uso inapropiado?
Lo primero a dilucidar es si, efectivamente, el software analizado es una Inteligencia Artificial. Ello, que puede parecer a priori sencillo, no lo es en absoluto, debido a las divergencias existentes entre el concepto legal de IA y el concepto de IA en el ámbito de la ingeniería informática, no coincidentes plenamente, y sujeto a matices. Asimismo, el fenómeno de tratar de pasar software por una IA para captar ayudas públicas o inversores forma parte de la realidad actual.
La definición legal de Inteligencia Artificial parte del Reglamento (UE) 2024/1689 del Parlamento Europeo y del Consejo, de 13 de junio de 2024, por el que se establecen normas armonizadas en materia de inteligencia artificial (LA LEY 16665/2024) y por el que se modifican los Reglamentos (CE) n.o 300/2008 (LA LEY 3589/2008) (UE) n.o 167/2013 (LA LEY 2703/2013) (UE) n.o 168/2013 (UE) 2018/858 (UE) 2018/1139 y (UE) 2019/2144 y las Directivas 2014/90/UE (LA LEY 13360/2014) (UE) 2016/797 (LA LEY 8246/2016) y (UE) 2020/1828 (Reglamento de Inteligencia Artificial (LA LEY 16665/2024)). Su artículo 3.1. define un sistema de IA como:
«Sistema basado en una máquina que está diseñado para funcionar con distintos niveles de autonomía y que puede mostrar capacidad de adaptación tras el despliegue, y que, para objetivos explícitos o implícitos, infiere de la información de entrada que recibe la manera de generar resultados de salida, como predicciones, contenidos, recomendaciones o decisiones, que pueden influir en entornos físicos o virtuales»
Así, tenemos el primer aspecto distintivo: tiene que estar basado en una máquina (hardware). Por tanto, el sistema de IA no es algo etéreo, sino que debe encontrarse en un soporte físico concreto. Si bien la definición de «máquina» es bastante difuso, en este contexto cabe entender que se refiere al término informático, más preciso, «hardware», esto es, los componentes físicos de una computadora, o a la propia computadora.
Otro aspecto para tener en cuenta es el de los «distintos niveles de autonomía». A este respecto, en ingeniería informática se distinguen, a muy grandes rasgos:
- a) Software estándar: Aquel que carece de autonomía. Un operador humano introduce inputs, el software resuelve según el algoritmo diseñado para resolver el proceso concreto, realiza una serie de acciones, y puede devolver una serie de outputs al operador. Por ejemplo, el software de facturación en una pyme.
- b) Autómatas: Aquel que opera de forma autónoma respecto de un operador humano. Los inputs provienen de sensores y aparatos electrónicos y realiza acciones concretas según el algoritmo diseñado para resolver las distintas situaciones, todo ello sin intervención humana «ex ante» ni «ex post». Por ejemplo, un robot industrial.
- c) Sistemas híbridos: Aquellos que combinan software estándar y autómatas dentro del mismo sistema informático. Así, parte de la acción a realizar se lleva a cabo por el software estándar, y otra parte por el autómata, siendo el software estándar parte de los inputs y/o outputs del autómata. Por ejemplo: robots industriales conectados a un software ERP de gestión integral para la fabricación de vehículos. Otro ejemplo: ChatGPT, el cual fusiona un procesador de textos para la interacción con el operador humano, y una inteligencia artificial conectada de forma remota.
Aún tras esta clasificación, una Inteligencia Artificial, según su definición legal, podría encajar en cualquiera de las tres definiciones, pese a que desde el punto de vista de la ingeniería informática una IA es, en general, una tipología de autómata.
Examinemos ahora, el tercer aspecto controvertido, relativo a la «capacidad de adaptación tras el despliegue». Este punto debe entenderse desde el punto de vista de la capacidad de auto alterar el algoritmo de partida que figura en su diseño y en su código inicial. Y es aquí donde está el núcleo probatorio a dirimir: debe acreditarse que el software informático sometido a examen realiza acciones distintas de su algoritmo inicial para resolver una tarea concreta, o es susceptible de hacerlo. En caso contrario, estaríamos ante un autómata, no una IA.
Pasemos pues, a considerar esos procesos inicialmente previstos en el software informático: los algoritmos. Erróneamente se consideran términos equivalentes «software» y «algoritmo», cuando la realidad es que un «software» concreto implementa uno o más algoritmos para producir una serie de resultados. La precisión no es baladí. Ahora bien, ¿qué es realmente un algoritmo?
Precisar primero, que ya se comete un error «ab initio», puesto que no es lo mismo «algoritmo» que «algoritmo informático». Un algoritmo no es más que un conjunto de instrucciones detalladas, ordenadas, sistemáticas y definidas de antemano para la realización de una determinada tarea. Un ejemplo de algoritmo lo constituye una receta de cocina e incluso las normas de derecho procesal relativas a un proceso penal. Por tanto, cabe precisar aún más, definiendo qué es un algoritmo informático.
Así pues, un algoritmo informático es un conjunto de instrucciones detalladas, ordenadas, sistemáticas y predefinidas al objeto de que una computadora pueda realizar una tarea de forma automatizada, sin intervención humana. Por computadora cabrá entender cualquier dispositivo electrónico capaz de entender y procesar instrucciones informáticas, realizadas en un concreto lenguaje de programación y plasmadas en un determinado código fuente.
Todo algoritmo informático presenta unas características mínimas comunes, que son:
- a) Precisos: Deben ser precisos y sin ambigüedades. De lo contrario producirán resultados indeseados y potencialmente perjudiciales.
- b) Ordenados: Presentan una secuencia ordenada de acciones hasta llegar al resultado. Un cambio en la secuencia puede producir efectos indeseados.
- c) Finitos: Contienen un número limitado de pasos. De lo contrario el sistema entrará en bucle y no sólo no alcanzará la solución, sino que puede producir efectos potencialmente dañinos.
- d) Concretos: Dados unos datos de partida y un proceso, debe alcanzarse un resultado determinado y perfectamente definido. De lo contrario el sistema informático o la inteligencia artificial pueden caer en la indeterminación, especialmente grave cuando el resultado de un algoritmo es el dato de partida de otro. Con ello se produce el muy temido «efecto avalancha».
- e) Previsibles: Dada una concreta información de partida el algoritmo debe proporcionar siempre el mismo resultado. La imprevisibilidad de un sistema informático o inteligencia artificial puede producir daños potencialmente muy graves.
Todos estos aspectos deberán ser examinados por el perito informático para el conjunto de algoritmos de una IA sometidos a examen, así como su impacto en el resto de los algoritmos que intervienen en la casuística a examinar. Un mal algoritmo puede producir multitud de efectos colaterales tanto de amplificación como de minimización de potenciales daños y errores, lo que debe ser examinado en detalle.
En definitiva, se trata de un procedimiento paso a paso para conseguir un fin concreto y es la base de la fase de diseño de todo software. Por ello, los distintos algoritmos que definen las tareas a realizar por un software informático o una inteligencia artificial quedan plasmadas en el correspondiente proyecto técnico, que es lo primero que un perito informático debe examinar para arrojar luz sobre la controversia.
Por tanto, resultará del máximo interés comparar el algoritmo inicial previsto en el diseño de una Inteligencia Artificial, plasmado en el proyecto técnico informático. Y ello por cuanto debe dilucidarse si una acción errónea de una IA se debe a un fallo de diseño o a una adaptación incontrolada de la propia IA, que ha auto variado su algoritmo en base a la capacidad de aprendizaje que tenga. A colación conviene traer de la definición legal aquello de «sistema basado en una máquina»: dos inteligencias artificiales con un mismo diseño, ubicadas en máquinas distintas, pueden variar de distinta forma sus algoritmos, en un remedo de «personalidad» propia. Por tanto, resulta perentorio comparar el diseño con las acciones de una IA individualizada y concreta.
Para esta comparación resulta indispensable el proyecto técnico informático de la Inteligencia Artificial. Un proyecto técnico informático es un conjunto de planos, esquemas, y textos explicativos, utilizados para definir las características de un producto informático (hardware y/o software), su fabricación y desarrollo, su instalación y puesta en marcha y/o las condiciones de realización de dicho proyecto.
El objetivo del proyecto técnico informático es estudiar e investigar si es o no posible de realizar la tarea propuesta, desde el punto de vista técnico, funcional y normativo, así como su coste y viabilidad. Todas estas tareas son exigibles según la lex artis de la ingeniería informática, que además obliga a identificar a los autores de dicho proyecto como responsables del mismo y la posesión de una cualificación profesional suficiente.
Para la composición y estructura del proyecto técnico informático tomaremos como referencia el «Reglamento de procedimiento de visado de proyectos y labores» del Colegio Profesional de Ingenieros Técnicos en Informática de Andalucía, aprobada por Asamblea General Extraordinaria del 18/10/2023 y modificada sucesivamente hasta la Asamblea General Extraordinaria del 24/05/2019 (10) . Su apartado 3.3. denominado «Proyectos», indica el siguiente literal:
«Los proyectos de productos, obras y edificios, instalaciones, servicios o software (soporte lógico), deben satisfacer las características establecidas en la Norma UNE 157001 "Criterios Generales para la elaboración de proyectos" y su familia de normas asociada, para garantizar que éstos son adecuados al uso a que están destinados. El Proyecto constará, en general, de los siguientes documentos básicos: Índice General, Memoria, Anexos, Planos, Pliego de Condiciones, Estado de Mediciones, Presupuesto y, cuando proceda, Estudios con Entidad Propia. El mayor o menor desarrollo de los apartados generales indicados en esta norma paraguas UNE 157001, dependerá del tipo de proyecto de que se trate y de su destino.»
Así, en virtud de dicho reglamento y de la norma UNE 157001, todo proyecto informático, incluido los de Inteligencia Artificial, deberá contar con la siguiente estructura básica:
- a) Memoria del Proyecto: Es el documento que constituye la columna vertebral del proyecto, siendo el apartado descriptivo y explicativo del mismo. En él se expone cual es el objeto del proyecto, a quien se destina o dónde se instalará. Se indican los antecedentes, especificaciones y estudios previos, las hipótesis de las que se parte y la selección de estas, así como las conclusiones y resultados definitivos. También incluye los procesos de transporte, montaje y puesta en marcha, así como la identificación y firma del ingeniero informático proyectista. La Memoria deberá ser claramente comprensible, no sólo por profesionales especialistas sino por terceros y, muy especialmente, por el cliente.
- b) Anexos al Proyecto: Incluye todos los documentos que desarrollan, justifican o aclaran apartados específicos de la memoria u otros documentos básicos del proyecto.
- c) Planos: Tienen como misión, junto con la memoria, definir de forma unívoca el objeto del proyecto, y son esenciales para su materialización.
- d) Pliego de condiciones: Su objeto consiste en establecer las condiciones técnicas, económicas, administrativas y legales para que el objeto del proyecto pueda materializarse en las condiciones especificadas, evitando posibles interpretaciones diferentes de las deseadas.
- e) Estado de mediciones: Tiene como misión definir y determinar las unidades de cada partida o unidad de obra que configuran la totalidad del producto, obra, instalación, servicio o software objeto del proyecto.
- f) Presupuesto del Proyecto: Tiene como misión determinar el coste económico de materializar el objeto del proyecto. Se basará en el estado de mediciones y seguirá su misma ordenación.
- g) Estudios con entidad propia: Tienen como misión incluir los documentos requeridos por exigencias legales, si las hubiera.
Especial atención merecerá el apartado de «Planos» donde deberán recogerse todos y cada uno de los algoritmos que implemente la Inteligencia Artificial. En ingeniería informática se utiliza el Lenguaje Unificado de Modelado (UML por sus siglas en inglés). Se trata de un estándar internacional, comprensible para cualquier ingeniero informático independientemente de su país de origen.
Los planos y diagramas en UML facilitan la comprensión de las ideas abstractas que conforman los algoritmos informáticos mediante un lenguaje visual. Una de sus ventajas fundamentales consiste en la posibilidad de explicar cómo funciona un algoritmo de IA o Software a personas no expertas en tecnología, como por ejemplo a un magistrado en un tribunal de justicia. Por ello el perito informático se valdrá de este tipo de esquemas con carácter preferente, nunca del código informático, del todo inabordable para personas ajenas al proyecto y al ámbito de la ingeniería informática.
En concreto, serán del máximo interés los «Diagramas de Actividades», donde se plasman los algoritmos en una primera aproximación. Por tanto, el proyecto técnico informático y los diagramas de actividades constituyen prueba fundamental a la hora de discernir:
- a) Si estamos realmente ante un Sistema de IA
- b) Si existe un error de diseño de la IA que provoca un resultado no contemplado
- c) Si existe una adaptación incontrolada de la propia IA que provoca el resultado no contemplado.
El primer punto resulta fundamental para dirimir el marco legal de aplicación. El segundo punto resultará fundamental en la atribución de posibles responsabilidades, dado que, en caso de error inicial de diseño, es clara la atribución de responsabilidad tanto de los autores del proyecto técnico de la IA como de la propia empresa que la comercializa. En el tercer caso, estamos ante una situación más compleja de cara a la atribución de responsabilidades, con un encendido debate en amplios sectores, nada pacífico.
Ahora bien, existiendo un algoritmo de partida correcto, el perito deberá realizar un examen funcional del Sistema IA, al objeto de comprobar si dados unos datos de partida, la IA responde dentro de unos márgenes de resultado aceptables previamente contemplados. En caso contrario, el error de funcionamiento se puede atribuir a diferentes causas que habrá que examinar por orden eliminatorio:
- 1. El manual de uso del Sistema IA, al objeto de descartar un uso indebido, como error ajeno al propio Sistema IA.
- 2. El código informático original, antes de la puesta en marcha de la instancia individual del Sistema IA, relativo a la implementación efectiva del algoritmo sometido a examen. Se trata de dilucidar si el resultado erróneo se debe a un error de programación de la IA en su estado originario.
- 3. Si la implantación física en la máquina de la instancia individual del Sistema IA, su configuración y su puesta en marcha han cumplido las instrucciones especificadas en el proyecto técnico informático, dado que pueden influir en la capacidad de cómputo, y provocar el error.
- 4. No existiendo error de programación originario ni de despliegue, cabe examinar los algoritmos de aprendizaje del Sistema IA, y más concretamente la calidad de los datos con la que se ha entrenado a ese Sistema IA concreto, lo cual es de gran complejidad técnica. Se trata de dilucidar si se ha producido un defecto de aprendizaje, como causa última del error.
Tal y como se ha argumentado, el proyecto técnico informático del Sistema IA debe analizarse en todo caso, por las razones de peso esgrimidas. El código informático original, deberá analizarse únicamente tras descartar un fallo de diseño original o de uso, y únicamente al objeto de dilucidar si el código informático de partida presentaba algún defecto que condicionará la capacidad de adaptación del Sistema IA en algún sentido.
Se considera que el código informático de una instancia individualizada de IA tras su puesta en marcha es técnicamente innecesario, dado que el código informático presente se puede deber a una auto modificación realizada por la propia IA, fruto de su capacidad de adaptación y aprendizaje, un error de programación, un error de diseño, o todas ellas de forma conjunta. Por tanto, dicho examen, del código informático, de forma aislada, resultaría inútil a efectos probatorios.
Asimismo, cabe señalar que el proyecto técnico informático goza de la misma protección en nuestro sistema legal que el código informático. Así, la Ley de Propiedad Intelectual, en su artículo 96.1 (LA LEY 1722/1996) establece:
«1. A los efectos de la presente Ley se entenderá por programa de ordenador toda secuencia de instrucciones o indicaciones destinadas a ser utilizadas, directa o indirectamente, en un sistema informático para realizar una función o una tarea o para obtener un resultado determinado, cualquiera que fuere su forma de expresión y fijación.
A los mismos efectos, la expresión programas de ordenador comprenderá también su documentación preparatoria. La documentación técnica y los manuales de uso de un programa gozarán de la misma protección que este Título dispensa a los programas de ordenador.»
Por tanto, desde el punto legal y técnico, es del todo oportuno el examen del proyecto técnico informático y de los manuales de uso del Sistema IA como primer paso para poner en contexto la situación controvertida. Asimismo, resulta procesalmente mucho más sencillo el examen de la documentación técnica, que tratar de examinar la instancia individualizada del Sistema IA, la cual puede estar físicamente incluso en otro continente.
Se hace patente que el factor temporal es clave en el análisis de este tipo de casuísticas. Y ello es debido a que, dado que una Inteligencia Artificial tiene capacidad de adaptación, por definición, ésta pudo cometer un error en un momento dado, generando el hecho controvertido, pero posteriormente aprender de su error, no cometiéndolo ya posteriormente, en unas condiciones idénticas. Así pues, los errores de un Sistema IA causados por defectos de aprendizaje presentan una muy elevada dificultad probatoria, rayana con la imposibilidad, transcurrido un cierto tiempo. Asimismo, técnicamente es del todo imposible revertir el estado del Sistema IA a una fecha concreta con el fin de tratar de reproducir la casuística controvertida.
Por último, en Sistemas de IA híbridos, existe una complejidad añadida: ¿se debe el error a la IA, o a la parte no IA del sistema? Este aspecto se torna aún más complejo si el Sistema IA híbrido además es distribuido, esto es, la parte no IA se instala en los equipos informáticos del operador o usuario, que conectan a través de internet con la parte IA del Sistema. ¿Se debe el fallo a una mala comunicación online o a un ciberataque que haya alterado las comunicaciones?
En definitiva, la perspectiva desde el punto de vista pericial informático debiera ser tenida en cuenta por el juzgador, y especialmente por el legislador, dado que ciertas disposiciones de la normativa en materia de IA pudieran ser de cumplimiento imposible, dada la realidad técnica en ingeniería informática.
IV. Jurisprudencia
Partiendo quizás de la jurisprudencia emanada del caso COMPAS en Estados Unidos de Norte América, se hace una mención expresa a como la falta de transparencia algorítmica en los sistemas utilizados en materia de justicia que pueden suponer una afectación a los derechos fundamentales al no poder las resoluciones que descansen sobre información emitida por un sistema IA ser susceptibles de revisión y control en fase de recurso. Por lo que recomiendan que, ante ello, y ante la afectación a multitud de derechos fundamentales, la utilización de la IA en justicia sea limitada a ámbitos concretos por vía legal. Reconociendo que la única solución posible para compatibilizar la tecnología analizada con nuestros sistemas judiciales pasa por «abordar eficazmente los posibles riesgos para los derechos fundamentales. Es necesario estudiar y decidir el establecimiento de requisitos legales obligatorios para el diseño, el desarrollo, la implantación, el uso y la evaluación de los sistemas de inteligencia artificial en el sector de la justicia. Entre estas normas podrían figurar, en particular, la prohibición de una automatización que convertiría en opaca la toma de decisiones judiciales, unos niveles adecuados de transparencia, comprensibilidad, verificabilidad, solidez, exactitud, seguridad y rendición de cuentas, así como unos requisitos para evitar efectos discriminatorios.» Terminando, exigiendo, aunque, con otras palabras, los sistemas IA desarrollados para ser implantados en justicia sean auditados durante su ciclo vital completo desde el desarrollo de los mismos hasta su implementación. Puede apreciarse como el proyecto de reglamento Europeo de IA bebió claramente de estas conclusiones, toda vez que la aplicación de IA a la justicia fue catalogada como de alto riesgo aplicándosele un estándar de seguimiento y control reforzado, desde el desarrollo hasta la aplicación continuada del mismo.
Ya en otras ocasiones hemos visto (11) como se ha abordado esta problemática principalmente en jurisprudencia norteamericana, aunque cada vez más surgen y surgirán casos en nuestro país.
En el caso People v. Superior Court of Los Angeles (12) , se cuestiona el algoritmo del sistema de análisis de ADN de un caso sin resolver donde se tomaron unas muestras de la vagina de la víctima. En septiembre de 2012, Sorenson comparó el perfil de ADN de Chubbs, un afroamericano, con el perfil de ADN principal del esperma y encontró una coincidencia. Se determinó que la frecuencia de aparición del perfil en la población general era de una entre aproximadamente 10.000 para los afroamericanos. Para ello se había utilizado el software TrueAllele para «inferir posibles genotipos contribuyentes de ADN a partir de las muestras», luego comparó los genotipos de evidencia y para calcular la relación de probabilidad del ADN. En enero de 2014, el sospechoso, Chubbs presentó una moción para obligar al descubrimiento que incluía la solicitud de los códigos fuente de Cybergenetics.
La defensa recibió varios elementos de descubrimiento relacionados con Cybergenetics y TrueAllele, incluidos el informe complementario, un paquete de caso de noviembre de 2013 de Cybergenetics, artículos publicados respecto al análisis de ADN y el software TrueAllele, un disco de datos de Sorenson, manuales de TrueAllele de marzo de 2014, un disco de datos de Cybergenetics y una presentación de PowerPoint para ser utilizada. La empresa también estaba dispuesta a reunirse con expertos, con la defensa y explicar cómo funciona el sistema. Sin embargo, la disputa aquí se centra en los códigos fuente de TrueAllele, que no fueron reproducidos ni facilitados por considerarse secreto comercial y la solicitud por considerarse la única forma válida, satisfactoria y recomendada de impugnar sus resultados.
En un primer momento se habría ordenado la comparecencia con los códigos fuentes si bien en una audiencia del 29 de julio de 2014, el tribunal dictaminó que los códigos fuente eran necesarios para confrontar las declaraciones testificales y periciales y que el secreto comercial era susceptible de amparo emitiendo una orden de protección y, en su caso, excluyendo al público del procedimiento. Lo que posteriormente volvió a discutirse en juicio y apelación. Así, en último término el tribunal consideró que es el acusado penal el que necesita demostrar prima facie la relevancia y necesidad del secreto comercial antes de que ocurra la divulgación o incluso para emitir una orden de protección de este. Sin embargo, Chubbs no cumplió con su carga prima facie de divulgación, sino que presumía que la carga de la prueba operaba en sentido contrario y que se trataba de la única prueba de cargo contra el investigado.
El tribunal en definitiva exige que la defensa realice algo más que declaraciones generales y aborde de manera concreta y justificada con su correspondiente prueba de justificar el por qué se necesita el código fuente para revisar la confiabilidad del análisis de TrueAllele, cómo se usaría el código fuente para revisar los resultados de TrueAllele o qué podrían revelar los códigos fuente que serían útiles para la defensa de Chubbs en cuanto a la confiabilidad del análisis.
No basta con que un secreto comercial pueda ser útil para partes, sino que quien busca el descubrimiento debe hacer una prima facie, particularizada que demuestre que la información buscada es relevante y necesaria para la prueba o defensa contra un elemento material de una o más causas de acción presentadas en el caso, y que es razonable concluir que la información buscada es esencial para una resolución justa de la demanda.
En concordancia con esta sentencia, pero esta vez en New Jersey, hay otros casos en los que sí se ha admitido el acceso al código fuente mediante una orden de protección de revisión a puerta cerrada del código fuente y los materiales recibidos. Así, en el caso New Jersey v. Francisco Arteaga (13) se solicita el descubrimiento de la tecnología de reconocimiento facial (FRT) para la identificación del sospechoso en un robo con arma de fuego en una tienda a partir de que supuestamente el gerente de la tienda lo habría reconocido de una visita anterior. Al descubrir que la tecnología FRT tuvo un papel importante en identificación de sospechoso por los testigos, la defensa solicitó su descubrimiento con el código fuente, sus tasas de error, rendimiento, sistema de puntuaciones, lista de parámetros, y otros extremos. Y eso sí, con una declaración de un experto, sus posibles problemas de fiabilidad y la razón de la necesidad del descubrimiento para evaluar sus resultados y rendimiento. De esta manera, se considera que la prueba solicitada está directamente vinculada con la defensa en la posibilidad de sembrar la duda razonable. Además, en el expediente había pocas pruebas sobre el sistema y el experto del acusado ha resultado convincente de la novedad del sistema y de la necesidad de evaluar su fiabilidad.
Esta sentencia sigue la doctrina fijada por el mismo tribunal en State v.Pickett (14) . Se trata de nuevo de una impugnación de un software novedoso HD de genotipificación probabilística para pruebas de ADN. Así, el Tribunal de New Jersey considera que cuando están en juegos las libertades civiles la revisión independiente del código fuente es fundamental para determinar la fiabilidad. Y en caso de una tecnología novedosa el demandado tiene derecho a acceder a la misma a través de una petición de descubrimiento con orden de protección siempre que 1) exista una base racional para la petición apoyada por un experto, 2) se solicite una información específica, 3) se pueda salvaguardar la propiedad intelectual mediante orden de protección y 4) cualquier otro factor relevante.
Asunto TJUE C-634/21 (LA LEY 313981/2023) OQ contra Land Hessen, con intervención de: SCHUFA Holding AG [Petición de decisión prejudicial planteada por el Verwaltungsgericht Wiesbaden (Tribunal de lo Contencioso-Administrativo de Wiesbaden, Alemania)]
El derecho a no estar sujeto a la toma de decisiones automatizadas se está considerando por primera vez ante el Tribunal de Justicia de la Unión Europea en el Asunto C-634/21 (LA LEY 313981/2023) OQ contra Land Hessen, con intervención de: SCHUFA Holding AG [Petición de decisión prejudicial planteada por el Verwaltungsgericht Wiesbaden (Tribunal de lo Contencioso-Administrativo de Wiesbaden, Alemania)]. Es por ello por lo que merece una mención aparte.
El asunto C-634/21 tiene por objeto un litigio entre un ciudadano y el Land Hessen, representado por el Delegado de protección de datos y de libertad de información del estado federado de Hesse («HBDI»), en materia de protección de datos de carácter personal. En el marco de su actividad económica, consistente en proporcionar a sus clientes información acerca de la solvencia de terceros, SCHUFA Holding AG («SCHUFA»), una sociedad de Derecho privado facilitó a una entidad de crédito un score relativo al ciudadano en cuestión que sirvió de base para la denegación del crédito que este había solicitado. El ciudadano pidió entonces a SCHUFA que suprimiera el registro que le concernía y que les diera acceso a los datos correspondientes, pero esta solo le comunicó el score relevante y, de manera general, los principios que subyacían al método de cálculo del score, sin informarlo sobre los datos concretos que se habían tenido en cuenta en ese cálculo ni sobre la pertinencia que se les atribuía en este contexto, alegando que el método de cálculo constituía un secreto comercial.
Dado que el ciudadano afectado alega que la negativa de SCHUFA es contraria al régimen de protección de datos, el Tribunal de lo Contencioso-Administrativo de Wiesbaden ha solicitado al Tribunal de Justicia que se pronuncie sobre las restricciones que el Reglamento General de Protección de Datos (LA LEY 6637/2016) 1 («RGPD») impone a la actividad económica de las agencias de información en el sector financiero, en particular en el ámbito de la gestión de los datos, así como sobre los efectos que deben reconocerse al secreto comercial. Del mismo modo, el Tribunal de Justicia deberá precisar el alcance de las facultades normativas que ciertas disposiciones del RGPD confieren al legislador nacional como excepción al objetivo general de armonización perseguido por este acto jurídico.
El abogado general en su informe considera que se cumplen los requisitos del derecho a no ser objeto de una decisión automatizada en cuanto que:
- — el procedimiento en cuestión supone una «elaboración de perfiles»;
- — la decisión produce efectos jurídicos en el interesado o lo afecta significativamente de modo similar para la concesión del crédito, puesto que los actos atribuibles a una entidad financiera privada también pueden tener consecuencias graves para la independencia y la libertad de actuación del interesado en una economía de mercado, especialmente cuando se debe certificar la solvencia de un solicitante de crédito.
- — cabe considerar que la decisión se basa únicamente en un tratamiento automatizado.
El scoring tiene un papel crucial es el relativo a si el procedimiento de toma de decisiones está concebido de tal manera que predetermina la decisión de la entidad financiera de conceder o denegar el crédito puesto que, si se efectúa sin intervención humana alguna que pueda, en su caso, verificar su resultado y la exactitud de la decisión, constituye la decisión en sí misma. En este sentido, deberá probarse en sede judicial nacional en qué medida la entidad financiera está generalmente vinculada o determinada y en qué medida por el scoring realizado por una agencia de información comercial.
En este sentido, el órgano jurisdiccional remitente considera que «la concesión del crédito puede denegarse a pesar de un valor de scoring en principio suficiente (por otros motivos, como, por ejemplo, la falta de garantías o dudas sobre el éxito de una inversión que ha de financiarse);en cambio, un valor de scoring insuficiente, al menos en el ámbito de los préstamos al consumo, implicará casi siempre la denegación del crédito, aunque una inversión parezca rentable por todo lo demás».
El Abogado General destaca que, con arreglo a otra disposición del RGPD, el interesado no sólo tiene derecho a obtener del responsable del tratamiento confirmación de si se están tratando o no datos personales que le conciernan, sino también otra información, como la existencia de decisiones automatizadas, incluida la elaboración de perfiles, información significativa sobre la lógica aplicada, así como la importancia y las consecuencias previstas de dicho tratamiento para el interesado. Considera que la obligación de proporcionar «información significativa sobre la lógica aplicada» debe entenderse en el sentido de que incluye explicaciones suficientemente detalladas sobre el método utilizado para el cálculo del score y sobre las razones que han conducido a un resultado determinado. En general, el responsable del tratamiento debería proporcionar al interesado información general, en particular sobre los factores que han sido tenidos en cuenta en el proceso de toma de decisiones y sobre su importancia relativa desde el punto de vista agregado, que también le resulte útil para impugnar cualquier «decisión» en el sentido de la disposición del RGPD que consagra el «derecho» a no ser objeto de una decisión basada únicamente en un tratamiento automatizado, incluida la elaboración de perfiles. De ello se deduce que, si bien la protección del secreto comercial o de la propiedad intelectual constituye, en principio, para una agencia de información comercial, un motivo legítimo para negarse a revelar el algoritmo utilizado para calcular el score del interesado, no puede, en cambio, justificar en modo alguno la denegación total de la información, más aún cuando existen medios de comunicación apropiados que facilitan la comprensión, a la vez que garantizan un cierto grado de confidencialidad.
De la misma manera que un prospecto de medicamentos proporciona información sobre usos correctos e indebidos o efectos secundarios, abstrayendo al usuario de las descripciones químicas detalladas, un sistema de machine learning debe ofrecer a sus usuarios información significativa que los haga conscientes de la lógica aplicada, así como la importancia y las consecuencias esperadas del procesamiento y los posibles impactos en su vida diaria.
En sentencia de 7 de diciembre de 2023 el TJUE se ha pronunciado sobre este asunto y lo cierto es que puede decirse que su fallo ha sido un poco una oportunidad perdida. Así, el TJUE considera que en circunstancias como las del litigio principal en las que el valor de probabilidad generado por una agencia de calificación crediticia comunicado al banco desempeña un papel determinante en la concesión del crédito, se trata de una decisión automatizada del Art. 22 RGPD (LA LEY 6637/2016) que produce efectos jurídicos en el sujeto o lo afecta. Debiendo aplicarse lo dispuesto en dicho precepto.
Sin embargo, el Tribunal de Luxemburgo no se pronuncia sobre el alcance del acceso a la información significativa sobre la lógica aplicada, así como la importancia y las consecuencias previstas de dicho tratamiento para el interesado, y si ello supone también el permitir el acceso al código fuente.
Bosco
La FUNDACIÓN CIVIO solicitó al Consejo de Transparencia y Buen Gobierno, cuya petición fue estimada parcialmente y luego en el recurso a dicha decisión ante la Audiencia Nacional del programa BOSCO,
- ○ La especificación técnica de dicha aplicación.
- ○ El resultado de las pruebas realizadas para comprobar que la aplicación implementada cumple la especificación funcional.
- ○ El código fuente de la aplicación actualmente en producción.
- ○ Cualquier otro entregable que permita conocer el funcionamiento de la aplicación
Este programa es utilizado por el Ministerio para la Transición Ecológica, al objeto de reconocer o no el derecho al bono social.
El Consejo de Transparencia y Buen Gobierno, estimó parcialmente la solicitud, si bien denegando el acceso al código fuente al ser de aplicación, únicamente en este extremo, el límite contenido en el artículo 14.1 letra j) de la LTAIBG, relativo a la propiedad intelectual.
Esta decisión fue recurrida, dictándose la sentencia del Juzgado Central De Lo Contencioso-Administrativo N.o 8, Procedimiento Ordinario 0000018/2019, St 143/2021.
Según el juzgado «no puede considerarse que el acto administrativo se dicte por una aplicación informática, sino por un órgano administrativo, y en caso de que el destinatario de dicho acto esté disconforme con el mismo, podrá impugnarlo en vía administrativa»
Y se deniega el acceso al código fuente con base en el Informe técnico Subdirector General de Tecnologías de la Información y de las Comunicaciones del Ministerio de Industria, Comercio y Turismo que argumenta «que la entrega del código fuente haría a la aplicación sensible a ataques por vulnerabilidades "de día cero" o que están aún por descubrir en el momento en que se construye el producto software. Asimismo, añadió que se podrían utilizar dichas vulnerabilidades para acceder a las bases de datos conectadas con la aplicación, que recogen datos especialmente protegidos, como la discapacidad o la condición de víctima de violencia de género del solicitante». En igual sentido, el Centro Criptológico Nacional, emite informe según el cual dicha transparencia del código fuente «aumenta de una manera objetiva la severidad de las vulnerabilidades de cualquier aplicación informática. Si esta además maneja información clasificada o sensible de la administración, el conocimiento del código fuente aumenta el riesgo de que la explotación de las vulnerabilidades pueda afectar a la seguridad nacional, la seguridad pública o la seguridad de los administrados».
Por ello, se desestimó el recurso interpuesto, si bien la sentencia fue apelada y se ha dictado resolución de confirmación en apelación.
SAN. Sala de lo Contencioso (Roj: SAN 2013/2024 - ECLI:ES:AN:2024:2013 (LA LEY 81234/2024); Sección: 7; N.o de Recurso: 51/2022; Fecha de Resolución: 30/04/2024; Ponente: JOSE FELIX MARTIN CORREDERA).
La Audiencia Nacional ratifica la sentencia dictada y llama la atención a los demandantes que el demandante podía haber propuesto contraprueba como le autoriza el artículo 60.2 LJCA (LA LEY 2689/1998) y combatir las apreciaciones técnicas sobre vulnerabilidades expresadas en su informe por el Subdirector General de Tecnologías de la Información y las Comunicaciones del Ministerio de Industria, Comercio y Turismo y por lo tanto la apelante no ha desvirtuado que la entrega del código fuente de la aplicación BOSCO pondría en grave riesgo derechos de terceros y atentaría a bienes jurídicos protegidos.
Se considera por tanto que la ocultación del código fuente de la aplicación supone que no se permita a un potencial atacante estudiar el código para descubrir una vulnerabilidad de día cero. Se asume además la posición del Abogado del Estado de que la aplicación informática no es más que una herramienta que se integra en el seno de un procedimiento administrativo que seguirá produciendo un acto administrativo plenamente sujeto al ordenamiento jurídico, de modo que el control de la legalidad de los actos administrativos sigue estando garantizado.
Como vemos, este caso se asimila bastante a los casos norteamericanos ya vistos People v. Superior Court of Los Angeles, New Jersey v. Francisco Arteaga y State v. Pickett.
A nivel español, también nos gustaría resaltar una sentencia a la que hemos tenido acceso, del Juzgado de lo Contencioso-Administrativo N.o 2 de Mérida, ponente DÑA. Carmen Romero Cervero, con fecha cuatro de septiembre de dos mil veinticuatro, en la que se recurre la resolución dictada por el Director General de Servicio Extremeño de promoción de la autonomía y atención a la dependencia. Así, la aplicación del Baremo de Valoración de los Grados y Niveles de dependencia (BVD) debe fundamentarse en los informes sobre la salud de la persona y sobre su entorno habitual, así como en la información obtenida mediante la observación, la comprobación directa y la entrevista personal de evaluación llevadas a cabo por profesional cualificado y formado específicamente para ello.
Y la realización de la valoración la realiza un programa informático que otorga conforme a un algoritmo una puntuación o scoring. De la valoración de la prueba la juzgadora concluye de acuerdo con las manifestaciones de la funcionaria que no es capaz de determinar por sí misma la puntuación que le corresponde a la discapacitada, llegando a la conclusión de que es un ordenador, con el correspondiente programa informático, el que nos viene a decir la situación de dependencia.
«Obviamente, es razonable pensar que existan programas informáticos para facilitar el trabajo de los técnicos, pero lo que no se puede admitir como prueba es la simple puntuación dada por una máquina para determinar la situación de dependencia de una persona, ello supone deshumanizar por completo una tarea tan sensible cual es la valoración de dependencia. Desde el punto de vista jurídico, existen numerosos supuestos en los que un sistema informático, tras la introducción de determinados datos, viene a ofrecer la puntuación correspondiente; v.gr., la aplicación del baremo de tráfico; hay programas informáticos para el cálculo de las indemnizaciones pero, obviamente, cualquier jurista es capaz —o debería—, sin necesidad de utilizar programas informáticos, determinar la indemnización correspondiente mediante la fórmula de Balthazar; de igual manera que cualquier forense es capaz de dar razón de ciencia de porqué, en aplicación del citado baremo de tráfico, le da a un lesionado una determinada puntuación dentro de las diferentes horquillas que contempla. Y son esas explicaciones las que brillan por su ausencia en el caso de autos.
En nuestro caso, como decimos, no se aporta por la Administración prueba alguna que nos haga entender por qué el resultado de la baremación es de 21 puntos porque, como decimos, esa puntuación la ha dado un sistema informático, del que desconocemos qué parámetros utiliza, que sesgos se le han introducido, sin que se pueda admitir, como un acto de fe, que la puntuación que le corresponde es de 21 puntos».
Es decir, ante la ausencia de explicabilidad y trazabilidad de la lógica aplicada, importancia de los parámetros y consecuencias por el programa informático de la puntuación otorgada se estima la demanda por carecer la valoración del baremo de base probatoria.
V. Conclusiones
En definitiva, con base en criterios jurisprudenciales norteamericanos y criterios periciales informáticos técnicos podríamos decir para aperturar o no el código sería una fase escalonada probatoria en los siguientes términos:
1. Análisis pericial del proyecto técnico informático: con la memoria, anexos, condiciones, mediciones, presupuesto, estudios, etc. Aquí cobra una especial importancia los diagramas UML conforme estándares internacionales para explicar algoritmos de IA de manera visual y comprensible y los denominados diagramas de actividades. Dentro del análisis de esta documental se incluiría el manual de usuario.
En caso de que se trate de una IA de alto riesgo, entraría toda la información documentada obligada que exige el reglamento europeo:
- a) información y documentación: documentación técnica, registro de eventos, instrucciones de uso, y solicitud de registro.
- b) riesgos: documentación de gobernanza de los datos, análisis y evaluación de riesgos, evaluación de derechos fundamentales, copias de seguridad y plan de prevención.
- c) gobernanza: política, propósitos y objetivos, funciones y cometidos del responsable, sistema de gestión de calidad, comunicación y sus canales, toma de conciencia y recursos formativos.
- d) normativo: evaluación de conformidad, código de conducta y código de buenas prácticas.
2. Evaluación por el Tribunal de acceso al código fuente informático. Para lo cual el tribunal según criterios jurisprudenciales recogidos debería analizar:
- — Pertinencia y necesidad del acceso.
- — Fundamentación concreta y específica del acceso sin que sean admisibles argumentos vagos o generales.
- — Afectación a derecho fundamental
- — Pericial informática que justique lo anterior
- — Posibilidad de protección de la propiedad intelectual mediante audiencia reservada.
De igual manera GEMMA GALDÓN (15) , considera que para analizar el funcionamiento del programa y detectar el origen del defecto, se puede recurrir a la llamada «ingeniería inversa» sin necesidad de acudir al código fuente.
Una vez que el tribunal considera superados tales estándares:
3. Pericial de acceso y análisis al código informático para verificar que no haya fallo de diseño.
4. Análisis pericial de implantación del sistema de IA para comprobar que el despliegue es conforme al proyecto técnico.
5. Pericial de posibles fallos de errores de aprendizaje del sistema IA, descartados supuestos anteriores.
Por todo ello considera, por ejemplo, un error querer analizar el código fuente en un primer término y como primer recurso, cuando la primera fase o estadio debe ser el análisis del proyecto técnico informático y los diagramas y documentación, así como el cumplimiento normativo en IAs de alto riesgo, todo ello con una pericial informática. En su caso, el acceso al código informático debería justificarse pericialmente con los criterios antes mencionados antes de su autorización judicial y salvaguardando la propiedad intelectual en todo caso. Y, por último, la prueba pericial de acceso y análisis al código fuente deberá complementarse con los análisis sobre la implantación y posibles errores de aprendizaje del sistema de inteligencia artificial.
VI. Bibliografía
ERCILLA GARCÍA, J. (2023). Transparencia en la Inteligencia Artificial: explorando la necesidad de acceso al código fuente por parte de los Comités de Empresa. Revista Aranzadi Doctrinal (8), ISSN 1889-4380.
PERALTA GUTIÉRREZ, A. (2023). La afectación de la inteligencia artificial a la función jurisdiccional: control judicial de los algoritmos. En El Poder Judicial, garantía del Estado de derecho (Cuadernos Digitales de Formación, N.o volumen 43, pág. 5, 14 y 40 y ss.). CENDOJ. Consejo General del Poder Judicial.
PERALTA GUTIÉRREZ, A. (2024). Diseño, desarrollo e implementación de un modelo de gobernanza y compliance de IA. En A. Abadías Selma & D. González Uriel (Coords.), El impacto de la IA en el aprendizaje y en la práctica del derecho (ISBN 978-84-19905-97-0).
TORRES LÓPEZ, L. S., & PERALTA GUTIÉRREZ, A. (2023). Visión comparada de los principios éticos de la inteligencia artificial y su aplicación a la función jurisdiccional. En El derecho y la inteligencia artificial (Cuadernos Digitales de Formación, N.o 3 .p. 43) CENDOJ. Consejo General del Poder Judicial