La peritación de un algoritmo en IA y Software resulta crucial para determinar si existe algún tipo de sesgo o fallo informático como origen de daños provocados a terceros, bien por pérdida o filtración de datos personales, bien por una incorrecta toma de decisiones realizada mediante una herramienta informática, ya sea Inteligencia Artificial o un software experto.
A continuación, como perito informático colegiado, trataré de introducir a juristas estos complejos conceptos de ingeniería. No tener presente el papel de los algoritmos en el ámbito de la ingeniería informática provocará enormes errores al tratar de legislar y/o supervisar inteligencias artificiales así como sistemas informáticos para tratamiento masivo de datos, imposibilitando que en la práctica se cumpla y se haga cumplir el marco legislativo.
¿Qué es un algoritmo?
Un algoritmo es 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.
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. Estos dos conceptos, y volveré a ellos.
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 examina para arrojar luz sobre un hecho controvertido. Volveré también sobre esta importante cuestión.
¿Qué partes tiene un algoritmo informático?
Todo algoritmo informático tiene tres partes diferenciadas:
- Datos de partida: Información de la que parte el algoritmo antes de iniciar la tarea. Puede tratarse de instrucciones a través de teclado y ratón, la base de datos de la que se nutre una inteligencia artificial, sensores de temperatura y presión en un motor y un larguísimo etcétera.
- Proceso: Conjunto ordenado y específico de pasos a seguir para, a partir de los datos de partida, para obtener un resultado.
- Resultado: Información o acciones resultantes del proceso aplicado a la entrada de datos.
Así pues, parece claro que para que un perito informático pueda auditar la obtención de un resultado concreto en base a un algoritmo, resulta indispensable estudiar tanto la entrada de datos como el proceso. Fíjese que no hablo en ningún momento de código informático. Volveré a esta cuestión controvertida en el ámbito jurídico.
¿Qué características tiene un algoritmo informático?
Todo algoritmo informático presenta unas características mínimas comunes, que son:
- Precisos: Deben ser precisos y sin ambigüedades. De lo contrario producirán resultados indeseados y potencialmente perjudiciales.
- Ordenados: Presentan una secuencia ordenada de acciones hasta llegar al resultado.
- 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.
- 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 muy temido «efecto avalancha».
- 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 que tenga que revisar así como su impacto en el resto de 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.
¿Qué es un lenguaje de programación?
Un lenguaje de programación es un conjunto de instrucciones gramaticales que posibilita que un ser humano establezca las instrucciones que materializan un algoritmo, pudiendo ser entendidas y ejecutadas por una computadora. Se trata de un paso intermedio entre las instrucciones en lenguaje natural humano y el código binario formado de «1» y «0» que lee un computador informático. Para llegar a estas secuencias los lenguajes de programación tienen «compiladores» de código, que vienen a traducir las instrucciones para que puedan ser entendidas por una computadora.
Las instrucciones de un lenguaje de programación permiten el control de los recursos hardware tanto a nivel lógico como a nivel físico, para que realicen procesos concretos. Con ello se manejan desde ordenadores personales, hasta el sistema de frenos de un coche, el sistema de navegación de un avión o los actuadores de un robot quirúrgico.
En definitiva, se trata del idioma usado por el programador informático para materializar los procesos establecidos en el algoritmo por el ingeniero, y deben corresponderse plenamente con dicho diseño. Este es uno de los aspectos a comprobar por el perito informático con el fin de determinar si existe un fallo de implementación del algoritmo, de diseño, o ambos. Con ello se circunscribirá la responsabilidad al ingeniero que diseño el algoritmo, al programador que lo implementó, o a ambos.
¿Qué es el código fuente de un software informático?
El código fuente es un conjunto de líneas de texto, escritas en un concreto lenguaje de programación al objeto de implementar un algoritmo informático. Como ya se ha indicado se trata de líneas de pseudotexto que el compilador del lenguaje de programación traduce después a código binario interpretable por una computadora.
Utilizando un símil arquitectónico, el código fuente es a la informática lo que ladrillos, argamasa, tuberías y cableado son a una edificación. Así, ante un colapso, tara o defecto, será lo último a examinar en la auditoría a llevar a cabo por un perito informático sobre un algoritmo. Volveré sobre esto un poco más adelante.
El error sobre la importancia relativa del código fuente informático en el ámbito de un proceso judicial viene de la normativa de propiedad intelectual, más concretamente del Real Decreto Legislativo 1/1996, de 12 de abril, por el que se aprueba el texto refundido de la Ley de Propiedad Intelectual, regularizando, aclarando y armonizando las disposiciones legales vigentes sobre la materia.
Así, el Art. 10.1, apartados f) e i) del RDL 1/1996, establece:
«1. Son objeto de propiedad intelectual todas las creaciones originales literarias, artísticas o científicas expresadas por cualquier medio o soporte, tangible o intangible, actualmente conocido o que se invente en el futuro, comprendiéndose entre ellas:»
f) Los proyectos, planos, maquetas y diseños de obras arquitectónicas y de ingeniería
i) Los programas de ordenador
Esta ley es previa a la creación de los respectivos colegios profesionales de ingeniería técnica informática en España. Este proceso se inició con la Ley 2/1998, de 28 de abril, de Creación del Colegio Profesional de Ingenieros Técnicos en Informática de la Región de Murcia. siendo la última hasta la fecha la Ley 12/2018, de 20 de septiembre, de creación del Colegio Profesional de Ingenieros Técnicos en Informática de Aragón. Así mismo, la ingeniería técnica en informática fue reconocida como una especialidad de ingeniería de pleno derecho mediante Real Decreto 1954/1994, de 30 de septiembre, sobre homologación de títulos a los del Catálogo de Títulos Universitarios Oficiales, creado por el Real Decreto 1497/1987, de 27 de noviembre.
Por tanto, hay que desterrar un grave error jurídico de base: un programa de ordenador es el resultado de una labor de ingeniería, y como tal, son exigibles proyectos, planos, maquetas y diseños de ingeniería que justifiquen y ordenen su funcionamiento y despliegue. O dicho brevemente: los algoritmos informáticos son diseños de ingeniería.
Ni tan siquiera las disposiciones legales sobre propiedad intelectual del código de un programa son adecuadas a nivel práctico, puesto que se podría hacer un programa idéntico, en otro lenguaje de programación, y no contravendría la normativa de propiedad intelectual en vigor. Sin embargo, los algoritmos si pueden llegar a protegerse como parte de un proyecto de ingeniería.
¿Cómo se diseñan los algoritmos de IA y Software?
Los algoritmos informáticos son diseños de ingeniería, y como tales quedan recogidos en los correspondientes planos, agrupados en un proyecto técnico informático. Por analogía, constituyen los planos del edificio lógico que conforma la IA o Software en el que se integran, y conllevan importantes procesos de estudio, cálculo y examen de cumplimiento normativo (Compliance informático). Porque sí, al igual que la estructura de un edificio, los algoritmos informáticos deben cumplir con la legislación vigente. Una legislación cada vez más compleja, fragmentada y en aumento, naciendo la necesidad de justificar las soluciones adoptadas por el ingeniero informático a la hora de diseñar el algoritmo con unos determinados parámetros y procesos.
Por tanto, los diseños de los algoritmos informáticos deben quedar recogidos en los correspondientes proyectos, planos y diseños de ingeniería informática.
¿Qué es un proyecto de ingeniería informática?
Un proyecto de ingeniería informática es el conjunto de planos, esquemas, cálculos y textos explicativos que definen un software, hardware o sistema informático, así como las condiciones para su fabricación, montaje, despliegue, configuración y uso posterior.
Por tanto, se trata del documento fundamental a examinar por el perito informático en el caso de controversia jurídica sobre un algoritmo informático en una IA o en un sistema informático, con el fin de examinar:
- Si existe un fallo de diseño en uno o más algoritmos
- Si en su fabricación se han cumplido escrupulosamente con las especificaciones de diseño del algoritmo o existe un error de programación
- Si se ha montado, desplegado o configurado una IA o sistema informático de forma incorrecta, sin atender a las especificaciones de diseño, provocando errores o daños.
- Si se le ha dado un uso a una IA o sistema informático no previsto en los diseños, sin la correspondiente ampliación del proyecto técnico.
Estos son los 4 supuestos de hecho que puede tener que despejar un perito informático en el marco de un proceso judicial y para los que resulta fundamental examinar el contenido del proyecto de ingeniería informática. Como ven, no sólo de prueba digital se trata en el proceso de informática forense.
¿Qué son los planos de una IA o Software?
Los planos de una IA o Software permiten comprender los diseños de los algoritmos, la arquitectura de la infraestructura, tanto hardware como software, y la implementación propuesta para que los programadores puedan codificar la infraestructura diseñada. Para ello 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. Esto resulta vital en proyectos que requieren la colaboración de varias personas tanto dentro del equipo de ingeniería y diseño como en los equipos de desarrollo que deben implementar después el código informático de la IA o software.
Otra de las 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, nunca del código informático, del todo inabordable para personas ajenas al proyecto.
Existen multitud de tipos de planos dentro del esquema UML, clasificados en dos grandes tipos: diagramas de comportamiento y diagramas estructurales
¿Qué tipos de planos informáticos de comportamiento existen?
Diagrama de caso de uso
Los diagramas de casos de uso proporcionan una primera visión gráfica de los algoritmos, estableciendo los actores como fuentes de entrada y salida de datos así como las distintas problemáticas a resolver por la IA o software y la información resultante. En este paso todavía no se entra a definir el proceso de los algoritmos, sólo a establecer la totalidad de algoritmos informáticos a abordar y su relación dentro de la IA o software que se pretende diseñar. Se tratan por tanto de un diagrama de comportamiento fundamental para entender qué hace una IA o software, de forma genérica y gráfica
La primera labor del perito informático consistirá en consultar estos diagramas para poder acotar qué hace y qué no hace una IA o sistema informático.
Diagrama de secuencia
Los diagramas de secuencia muestran cómo los distintos componentes de la IA o sistema informático se relacionan e interactúan entre sí. Estos diagramas ayudan a comprender cómo, por qué y en qué orden se producen estas interacciones en el marco de la ejecución de un algoritmo.
El perito informático examinará estos diagramas para examinar qué componentes intervienen en la ejecución de un algoritmo, acotando el examen a realizar.
Diagrama de actividades
Un diagrama de actividades plasma los procesos que integran un determinado algoritmo, ofreciendo una visión general de alto nivel de los aspectos dinámicos de una IA o software. Así mismo, los procesos descritos pueden también descomponerse en procesos y algoritmos más pequeños, lo que facilita su diseño mediante la descomposición e integración por capas.
El perito informático consultará estos diagramas para conocer de forma exhaustiva el proceso que materializa un determinado algoritmo y si existen fallos de diseño o sesgos en el mismo. Los diagramas de actividades resultan fundamentales en un proceso judicial.
Diagramas de comunicación
Los diagramas de comunicación se centran en los mensajes que se transmiten entre diferentes componentes de la IA o sistema informático, estableciendo un mapa completo y general de las entradas y salidas de información entre los distintos componentes.
El perito informático examinará los diagramas de comunicación para dilucidar si existen disfunciones en la información de partida de un algoritmo y el resultado previsto, lo que puede indicar una circunstancia no prevista en el diseño.
Diagramas de interacción
Los diagramas de interacción representan visualmente el flujo de procesos y la secuencia en la que se desarrolla un algoritmo, modelizando las interacciones externas con la IA o sistema informático, ya sea por parte de operadores humanos o por parte de otros computadores en un sistema informático en nube, por ejemplo.
El perito informático examinará estos diagramas para dilucidar si el fallo o sesgo en el algoritmo de IA o software proviene de una entrada de información no contemplada o bien la emisión de un resultado sesgado o erróneo.
Diagramas de estados
Los diagramas de estados muestran cómo actúan los distintos componentes de la IA o software según el estado del algoritmo que estén procesando en un momento dado.
Los peritos informáticos examinan estos diagramas para comprobar si en un momento y estado dados, existen componentes que causan interferencias no previstas que alteran tanto la ejecución del algoritmo como su resultado.
¿Qué tipos de planos informáticos estructurales existen?
Diagramas de clases
Un diagrama de clases define los proyectos como conjuntos de elementos lógicos agrupados en clases, con una serie de atributos y funciones codificadas en su interior. Con ello muestra las clases de elementos que se pueden encontrar en el sistema informático y los procesos que cada uno puede llevar a cabo de forma genérica. Siguiendo el símil arquitectónico tendríamos la clase «ladrillo», la clase «tubería», la clase «cableado», cada elemento con unas características funcionales y operativas concretas. Se trata de un paso intermedio entre los diagramas de comportamiento y la labor de codificación y programación
El perito informático examina estos diagramas para determinar qué elementos lógicos intervienen en la ejecución de un algoritmo y que características deberán cumplir una vez que sean programados y codificados.
Diagrama de objetos
Los diagramas de objetos muestran las interacciones de elementos concretos de distintas clases para materializar la operativa de la IA o software. Muestran el aspecto lógico de un sistema informático en un momento dado.
El perito informático se sirve de los diagramas de objetos para examinar, a nivel lógico, si la codificación de un algoritmo es potencialmente correcta o incorrecta a tenor de su diseño previo. Aquí se detecta si el ingeniero ha podido cometer algún error al establecer los parámetros que deberá ejecutar posteriormente el programador.
Diagrama de componentes
Un diagrama de componentes establece una comprensión global de los objetos físicos que componen un sistema informático. También muestra la relación estructural entre cada componente físico y los componentes lógicos en un sistema de software complejo.
El perito informático analiza los diagramas de componentes para comprender cómo se organizan y conectan los elementos hardware y software y tratar de descubrir potenciales problemas de configuración y despligue que no se tuvieron en cuenta al diseñar la IA o sistema informático.
Diagrama de despliegue
Un diagrama de despliegue muestra la relación y configuración de los elementos software y hardware de un sistema informático así como la forma en que deben ser dispuestos, configurados y puestos en marcha.
El perito informático examinará los diagramas de despliegue tanto para dilucidar potenciales problemas e incoherencias con el despliegue de los distintos componentes del sistema, así como fallos de configuración y puesta en marcha, bien porque no fueron correctamente diseñados, bien porque el personal encargado del despliegue y puesta en marcha no siguió las instrucciones de diseño.
El error de querer analizar el código informático en un proceso judicial
Es un grave error pretender analizar el código informático que compone una IA o software en el marco de un proceso judicial. En el caso de querer examinar si un edificio presenta fallos estructurales, ¿lo desmotaría ladrillo a ladrillo para dilucidar la controversia? No parece lógico, ¿verdad? Pues la pretensión de analizar el código informático de una IA o software es igual de absurdo.
Este error nace jurídicamente, como se ha señalado, del error jurídico de fondo cometido en el Artículo 10.1 del Real Decreto Legislativo 1/1996, de 12 de abril, por el que se aprueba el texto refundido de la Ley de Propiedad Intelectual, regularizando, aclarando y armonizando las disposiciones legales vigentes sobre la materia. Aunque parezca increíble, hoy día sigue sin considerarse un programa informático como el resultado de un proceso de ingeniería. Así, lo que resulta del todo absurdo para analizar defectos en un edificio, se considera normal al examinar un programa de ordenador, precisamente porque se tiene interiorizado que un edificio es el resultado de un proceso de ingeniería. Frente a ello aún hoy se considera que un programa de ordenador es poco menos que una obra intelectual como una novela o una obra de arte como pueden ser un cuadro o una escultura, y dicho error viene del RDL 1/1996.
Como he explicado anteriormente, queda absolutamente patente que la IA y software informático son resultado de un muy complejo trabajo de ingeniería informática, que debe ser plasmado en el correspondiente proyecto de ingeniería de forma análoga a un edificio, un puente o una línea de producción en una fábrica. El diseño de algoritmos conlleva la realización de multitud de cálculos y la toma en consideración de la normativa legal a la que está sometido el producto de ingeniería resultante.
Volviendo al ámbito jurídico y del Derecho Digital, la solicitud de acceso al código de un programa informática no es ni adecuada, ni proporcional, ni justificada y, por tanto, no resulta admisible que un tribunal de justicia autorice su acceso a un tercero, aún en el marco de un proceso judicial.
Caso Bosco: Sentencia de Audiencia Nacional 2013/2024
Resulta de mucha utilidad examinar la reciente Sentencia de la Audiencia Nacional 2013/2024, de 30 de Abril de 2024, Sala de lo Contencioso (Caso Bosco). Resulta objeto de controversia el recurso contencioso-administrativo 18/2019 interpuesto por la entidad Fundación Ciudadana Civio contra la resolución del CTBG de 18-2-2019, dictada en el procedimiento tramitado con el n.º R/0701/2018, por la que se estimó parcialmente la reclamación presentada en fecha 27-11-2018 contra el MITECO, sobre acceso a la información relativa a la aplicación informática para determinar si se cumplen los requisitos para ser beneficiario del bono social. En primera instancia, el Juzgado de lo Contencioso Administrativo número 8 de Madrid, con fecha 30 de diciembre de 2021, dictó sentencia desestimatoria con expresa imposición de las costas a la demandante con el límite de 1.000,00 euros por todos los conceptos, y para cada una de las partes demandada y codemandada.
El Fundamento Jurídico Primero de la sentencia estableció los hechos relevantes para fundamentar la desestimación del recurso planteado, siendo en su literalidad:
La sentencia apelada desestima el recurso contencioso-administrativo interpuesto por Fundación Ciudadana Civio contra resolución de 18 de febrero de 2019 por la que el CTBG estima parcialmente la reclamación presentada en solicitud de acceso a la información del MITECO que sirve de soporte a la aplicación informática desarrollada y construida para la gestión automatizada de las solicitudes del bono social- sistema de información BOSCO -. Esta aplicación telemática permite al comercializador comprobar que el solicitante del bono social cumple los requisitos para ser considerado consumidor vulnerable.
La solicitud fue estimada en lo relativo a la especificación técnica de la aplicación; el resultado de las pruebas realizadas para comprobar que la aplicación implementada cumple la especificación funcional; y de cualquier otro entregable que permita conocer el funcionamiento de la aplicación.
Pero fue denegada en el extremo en que se solicitaba el código fuente de la aplicación.
La sentencia recurrida mantiene el criterio de la Administración de ser improcedente facilitar el código fuente y cita una pluralidad de razones: la propiedad intelectual, la protección de las personas afectadas y de sus datos personales, la protección ciudadana, la integridad de la información y el control de acceso.
Recuerda la sentencia los límites del derecho de acceso que se extravasarían de facilitarse el código fuente de los señalados en el artículo 14.1 de la Ley 19/2013 , de transparencia, acceso a la información pública y buen gobierno (LTAIBG): d) la seguridad pública; g) las funciones administrativas de vigilancia, inspección y control; i) la política económica y monetaria; j) el secreto profesional y la propiedad intelectual e industrial; y k) la garantía de la confidencialidad o el secreto requerido en procesos de toma de decisión. Y señala especialmente que la entrega del código fuente haría a la aplicación sensible a ataques por vulnerabilidad, pudiendo utilizarse las vulnerabilidades para acceder a bases conectadas a la aplicación como es el caso de la AEAT y de la Seguridad Social.
En garantía de su conclusión, la sentencia hace referencia al informe emitido por el Subdirector General de Tecnologías de la Información y las Comunicaciones del Ministerio de Industria, Comercio y Turismo, el cual fue sometido a contradicción.
Los motivos de la parte recurrente quedan reflejados en el Fundamento Jurídico Segundo, cometiendo clamoroso error en sus motivos primero y segundo:
En su opinión, extensamente desarrollada, el límite del artículo 14.1, apartado j) LTAIBG sólo puede aplicarse cuando se trate de una propiedad intelectual de titularidad ajena al obligado a la transparencia ya que lo que se pretende con tal limitación es la salvaguarda de derechos de terceros.
A continuación, en un segundo motivo, sostiene que la sentencia incurre en error en la apreciación de los hechos del que se deriva una infracción del artículo 9.3 CE . En el desarrollo se alega que del análisis funcional de la aplicación resulta que ninguna persona interviene en la toma de decisión del resultado de modo que para saber si es correcto el funcionamiento del sistema del bono social ha de accederse al código fuente, siendo insuficiente para conocer el funcionamiento el análisis funcional.
Sostener por la parte recurrente que el análisis del proyecto técnico no permite saber el correcto funcionamiento del sistema informático objeto de controversia resulta completamente absurdo, y a lo comentado en este artículo me remito.
El mayor error cometido por la parte recurrente lo refleja la sentencia en su Fundamento Jurídico Tercero, consistente en no haber aportado prueba pericial informática:
Además, el demandante podía haber propuesto contraprueba como le autoriza el artículo 60.2 LJCA 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.
Son también de interés los siguientes extractos del FJ Tercero:
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 por los límites al derecho de acceso a la información pública del artículo 14.1 letras d), g), i) y k) LTAIBG.
En efecto, la revelación del código aumenta de una manera objetiva la severidad de las vulnerabilidades de cualquier aplicación informática, más aún cuando se maneja información clasificada o sensible, no siendo exigible a la Administración que todas las aplicaciones que desarrolle lo sea con fuentes abiertas.
Antes al contrario, un sistema informático ha de ser desarrollado sobre la base de unas garantías de seguridad en función de la sensibilidad de la información a la que da acceso; en el caso examinado existe el compromiso de intereses de terceros y de otros bienes jurídicos, se podrían producir vulnerabilidades para acceder a las bases de datos conectadas con la aplicación que contienen datos especialmente protegidos, como la discapacidad o la condición de víctima de violencia de género del solicitante, los datos tributarios a la AEAT, de la Seguridad Social, etc. y se pondría en riesgo la confidencialidad de la información tributaria, se posibilitaría la suplantación de los usuarios autorizados, la falsificación del consentimiento, etc.
Para alcanzar tal conclusión es concluyente el informe del Subdirector General de Tecnologías de la Información y las Comunicaciones del Ministerio de Industria, Comercio y Turismo, la unidad técnica que gestiona para MITECO el sistema de información BOSCO. El informe se sometió a contradicción con audiencia de las partes, no quedando duda al respecto de que es garantía de protección ante las vulnerabilidades la ocultación del código fuente de la aplicación, de forma que no se permita a un potencial atacante estudiar el código para descubrir una vulnerabilidad de día cero. Según el informe, develar el código fuente podría acarrear las siguientes consecuencias:
– Que el ataque sería muy difícil de detectar por parte de los encargados de la administración técnica de los sistemas de información y del equipo de ciberseguridad del Ministerio, puesto que dicho personal técnico no sería consciente de que sus sistemas de información están siendo atacados.
– El Ministerio no tendría a su disposición, en el momento en que se produce el ataque, de los medios técnicos (antivirus, sondas, parches de seguridad de los productos de Sistema Operativo y Middleware) necesarios para mitigar la vulnerabilidad, puesto que los fabricantes que dan soporte a estos productos tampoco serían conscientes de la vulnerabilidad en sus productos, o de que dicha vulnerabilidad sea detectada y eliminada por los productos específicos de seguridad informática.
– Debido a lo indicado en los anteriores puntos, el atacante dispondría del tiempo suficiente conseguir sus objetivos, entre los que se podrían a modo de ejemplo enumerar las siguientes actuaciones:
* Acceder o modificar, evidentemente con propósitos ilícitos, a los datos de la base de datos de la propia aplicación, que incluye datos personales de especial protección de los interesados en los trámites (niveles de renta de los individuos, situación familiar y laboral, o si existe calificación como víctima de violencia de género o de terrorismo, o si el interesado sufre alguna discapacidad).
* Intento de acceso y/o alteración de los datos almacenados en otras bases de datos, correspondientes a otras tramitaciones administrativas cuya responsabilidad recae en el Ministerio de Industria, Comercio y Turismo.
* Utilizar los medios de la infraestructura de cómputo del Ministerio para otros fines, como por ejemplo la minería de criptomonedas.
* Utilizar la imagen del Ministerio para pertrechar delitos basados en ingeniería social (blackmail o phishing).
También nos vemos obligados aquí a disentir del argumento de la recurrente sobre la infracción del artículo 9.3 CE . El debate se centra en el derecho al acceso al código fuente de la aplicación con la que se gestiona el bono social, quedando fuera del valladar del debate determinar si es conforme a derecho el procedimiento de comprobación para verificar la condición de consumidor vulnerable (Real Decreto 897/2017 por el que se regula la figura del consumidor vulnerable, el bono social y otras medidas de protección para los consumidores domésticos de energía eléctrica y Orden ETU 943/2017, sobre el mecanismo de comprobación de los requisitos para ser consumidor vulnerable).
Como dice el Abogado del Estado 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: la legalidad (o no) del acto administrativo no viene justificada por el uso de la aplicación informática sino por la adecuación al ordenamiento jurídico del acto producido.
La falacia de la opacidad de los algoritmos
Como perito informático quiero dejar bien asentado que es una falacia la insistencia en la opacidad de los algoritmos, basándose en que los tribunales de justicia no conceden acceso al código de los sistemas informáticos de gestión pública. El código informático no define un algoritmo, sino que es la mera materialización del diseño del algoritmo.
Visto el caso Bosco, la sentencia recurrida permitió acceder al proyecto técnico del sistema informático, núcleo de la cuestión litigiosa. ¿Por qué no se requirió el proyecto técnico para que lo analizara un perito informático especializado? En este artículo ha quedado patente que el código fuente no es más que la representación en pseudolenguaje de un programa informático y que un programa informático está constituido por multitud de algoritmos. Como perito informático estoy absolutamente de acuerdo con el razonamiento de base esgrimido por la Sala: es del todo injustificado y desproporcionado acceder a la totalidad del código informático de un sistema sólo para examinar el algoritmo que decide la concesión de una ayuda, no siendo necesario acceder al resto de algoritmos que componen el sistema de información.
En este caso se debió practicar prueba pericial informática para auditar la parte del proyecto técnico definitoria sólo de ese algoritmo y el diseño de los elementos físicos y lógicos encargados de materializar dicho algoritmo. El código informático es del todo irrelevante para examinar la cuestión. QUE QUEDE CLARO.
El error de no haber desvirtuado el informe técnico del Ministerio
En lo referente al informe técnico del Subdirector General de Tecnologías de la Información y las Comunicaciones del Ministerio de Industria, éste es D. Marcos Martínez Díaz, para más señas ingeniero de telecomunicación, sin competencias legales en la materia. Pueden observar las competencias de un ingeniero de telecomunicación en la Orden CIN/355/2009, de 9 de febrero, por la que se establecen los requisitos para la verificación de los títulos universitarios oficiales que habiliten para el ejercicio de la profesión de Ingeniero de Telecomunicación. Carece por completo de competencias en el ámbito de los proyectos de software, los cuales están en el ámbito de competencia de la ingeniería técnica informática en virtud del ANEXO II, Apartado 3 de la Resolución de 8 de junio de 2009, de la Secretaría General de Universidades, por la que se da publicidad al Acuerdo del Consejo de Universidades, por el que se establecen recomendaciones para la propuesta por las universidades de memorias de solicitud de títulos oficiales en los ámbitos de la Ingeniería Informática, Ingeniería Técnica Informática e Ingeniería Química.
A mayor abundamiento, el Tribunal Superior de Justicia de Murcia, en Sentencia nº 1078/2021 de 03/06/2021 ha reconocido como legalmente competentes a los ingenieros técnicos en informática frente a los ingenieros técnicos de telecomunicaciones para realizar la actividad de analista de sistemas, siendo estos últimos incompetentes en la materia.
Y finalmente, los informes técnicos en el ámbito de la informática son un acto propio de la profesión en virtud del Art. 2 de la Ley 12/1986, de 1 de abril, sobre regulación de las atribuciones profesionales de los Arquitectos e Ingenieros técnicos, estando sólo habilitado para realizar informes técnicos en el ámbito de las telecomunicaciones.
Por tanto, el Subdirector General de Tecnologías de la Información y las Comunicaciones del Ministerio de Industria ha emitido un informe técnico en el ámbito de la informática sin estar legalmente habilitado para ello, el cual podría haber sido fácilmente impugnado como prueba. Y no sólo eso, sino que incluso podría haberse llegado a sustentar causa por posibles delitos de estafa procesal e intrusismo profesional.
De haber contado la parte recurrente con un perito informático colegiado, podría haberle dado la vuelta al caso con gran facilidad, desvirtuando fácilmente el informe de contrario, en fondo y forma mediante el análisis de un proyecto técnico a buen seguro erróneo o inexistente y realizado por una persona sin la cualificación legal mínima para ello, en base a lo dispuesto en el Real Decreto 311/2022, de 3 de mayo, por el que se regula el Esquema Nacional de Seguridad.
Entre otras disposiciones, en ENS establece en su artículo 10.6 los requisitos mínimos de una política de seguridad de los sistemas de información públicos:
6. La política de seguridad se establecerá de acuerdo con los principios básicos señalados en el capítulo II y se desarrollará aplicando los siguientes requisitos mínimos:
a) Organización e implantación del proceso de seguridad.
b) Análisis y gestión de los riesgos.
c) Gestión de personal.
d) Profesionalidad.
e) Autorización y control de los accesos.
f) Protección de las instalaciones.
g) Adquisición de productos de seguridad y contratación de servicios de seguridad.
h) Mínimo privilegio.
i) Integridad y actualización del sistema.
j) Protección de la información almacenada y en tránsito.
k) Prevención ante otros sistemas de información interconectados.
l) Registro de la actividad y detección de código dañino.
m) Incidentes de seguridad.
n) Continuidad de la actividad.
ñ) Mejora continua del proceso de seguridad.
Todo ello es imposible de acreditar sin el correspondiente proyecto técnico del sistema de información, que además, debe estar redactado por un profesional cualificado en virtud del principio de profesionalidad definido en el Art. 16 del Esquema Nacional de Seguridad.
El habitual error de no solicitar acceso al proyecto técnico
Constituye un error habitual y constante que los letrados recurrentes no soliciten acceso parcial al proyecto técnico informático del sistema de información público objeto de controversia jurídica. Los motivos para solicitarlo son de mucho peso:
- Los algoritmos están descritos en los distintos diagramas y planos que forman parte del proyecto técnico informático que debe existir para poder justificar la funcionalidad y seguridad del sistema de información pública.
- No existen proyectos técnicos de sistemas de información pública. Aunque le parezca increíble, no existen proyectos técnicos de sistemas de información pública como tales, dado que en la mayoría de casos no hay un sólo ingeniero en informática materializando dicho sistema. Por tanto, si solicita dicha prueba y no existe, por inversión de la carga probatoria, puede ganar el proceso en ese preciso instante, dada la incapacidad de la administración para acreditar en qué consiste el algoritmo objeto de controversia
- En los muy raros casos en los que existe proyecto técnico, el mismo no ha sido suscrito por un ingeniero en informática. Habitualmente se encuentran ingenieros de otras especialidades, sin competencias legales en la materia, como industriales o de telecomunicaciones. Es lo sucedido en el caso Bosco.
- No contar con un perito informático colegiado que le auxilie. Es normal que un letrado no domine el ámbito de ingeniería y menos el de ingeniería informática. Ahora bien, resulta inexcusable que en este tipo de procesos no se cuente con un perito informático colegiado especializado en arquitectura de sistemas.
Algoritmos, ¿opacidad, inexistencia o mala praxis jurídica?
No existe opacidad en los algoritmos informáticos, sino inexistencia. El código informático no describe los algoritmos, sino los correspondientes diagramas, planos y proyecto de ingeniería de la infraestructura informática. Tienen razón los tribunales en no conceder acceso al código informático y ello no implica en modo alguno opacidad u ocultación de los algoritmos. Los tribunales de justicia ya se han pronunciado favorablemente a conceder acceso a los elementos de diseño que definen los algoritmos de una IA o software informático.
Ahora bien, estos elementos, en la mayoría de casos ni tan siquiera existen, precisamente porque prácticamente nunca se solicitan en la práctica jurídica. De hacerlo verán que o bien no existe plano ni definición formal del algoritmo, o está hecho de forma chapucera por alguien sin competencia legal para ello, prescindiendo de los mínimos estándares de diseño y modelado informático.
Si consigue probar la inexistencia del algoritmo en sí o su burdo diseño, habrá ganado su reclamación judicial sin duda alguna. Pero para llegar a buen puerto, necesitará, sí o sí, de un perito informático especializado, que elabore un informe contrapericial informático sometiendo a contraste el proyecto técnico, los planos que definen un algoritmo y la habilitación legalmente exigible a los profesionales encargados del diseño.
¿Necesita peritos especializados en auditoría de algoritmos?
En Indalics somos peritos informáticos profesionales, colegiados y legalmente habilitados. Actuamos ante tribunales de justicia de toda España, tanto presencialmente como mediante declaración telemática.
Nuestros peritos informáticos están especializados en auditoría de algoritmos y proyectos técnicos informáticos.