*Por Víctor Práxedes Saavedra
La narrativa casi mítica de las iniciativas relacionadas con tecnologías digitales, unida a su complejidad y rápida evolución, pueden llevar a confundir la confianza con la fe. Ya habíamos hablado de transparencia e invitamos a la confianza crítica, no ciega. La importancia de la confianza y su fragilidad en las relaciones con los gobernantes es crítica, tal como recordaba Mauricio García Villegas aprovechando el día sin IVA.
Veamos un ejemplo. El 16 de junio tuvo lugar el debate de control político sobre CoronApp en la Comisión Primera, Constitucional, de la Cámara de Representantes. Antes de la sesión, diversas autoridades enviaron por escrito sus respuestas. En este contexto, a la pregunta sobre el código fuente de la aplicación, que no es más que las líneas de lenguaje de programación que dicen cómo una aplicación debe ser ejecutada (las instrucciones), el Alto Consejero para la Economía y la Transformación Digital del Gobierno señaló que no se publicaría por “el nivel de sensibilidad y reserva de la información que se maneja en la aplicación”, para evitar un proceso de “ingeniería inversa, y que con ello potenciales hackers entiendan cómo funciona el algoritmo”. Agregó, además, que la publicación generaría un “detrimento de la seguridad nacional, la vulneración de la confidencialidad de la información gubernamental o que se comprometa la razón de su creación al compartirlo”.
Traigamos a la tierra el mito comenzando por los adversarios. Repetido como mantra, la palabra “hacker” nos transmite el riesgo sin decirnos nada. Sin embargo, los “hackers” son personas que aprovechan el conocimiento, creatividad e ingenio para usar sistemas (digitales o no) de una manera diferente a la prevista y que frecuentemente descubren problemas de seguridad para mejorarlos o atacarlos. En todo caso, no hay duda de que su contribución en el avance de la seguridad digital es imponderable. La cuestión de la ingeniería inversa va por el mismo camino. La ingeniería inversa es un proceso que busca ir hacia atrás a partir de un producto final para conocer sus componentes, sin más. De hecho, aquellos realmente interesados tienen métodos para realizarla directamente desde los teléfonos celulares. La ingeniería inversa puede servir para fines ilegítimos, como suele ocurrir en los casos bélicos, o legítimos, para contribuir a la mejora de productos, como es más habitual.
¿Y qué ocurre con la amenaza? El acceso al código fuente se pide para conocer cómo funciona la aplicación. El problema está en presentar como perjudicial un simple ejercicio de transparencia. Se busca acceso al código porque, dada la diversidad de funciones, los muchos cambios realizados en la aplicación, el rol que se le imputa en una situación tan delicada como esta pandemia y el sacrificio que se pide a todos en la entrega de sus datos personales, se quiere saber si efectivamente el programa cumple con las funciones que dice que hace, y si lo hace de forma segura y con el mayor respeto posible a la privacidad. Lo paradójico de esto es que, a pesar de la aparente oposición, el objetivo del Gobierno y de quienes piden el código es el mismo: contribuir a una aplicación lo más efectiva, segura y acorde a derecho posible. Esta participación de diversidad de actores es uno de los valores de la filosofía del código abierto. Es más, la apertura de código está siendo una constante en las aplicaciones de rastreo de contactos contra el coronavirus. Un ejemplo es la aplicación alemana, presentada en estas últimas semanas como referente.
La razón para negar la publicación del código fuente se autoderrota, y por ende, pierde la posibilidad de cumplir su función explicativa de una decisión pública. La ingeniería inversa, los hackers, menciones que no dicen nada por sí mismas. El “conocimiento del algoritmo” es positivo salvo prueba en contrario, no confundamos regla y excepción. La seguridad nacional, ¿cómo se vería afectada?, ¿llevamos en nuestros bolsillos información que puede comprometerla fácilmente? La razón de su creación, ¿cómo se vería comprometida? El nivel de sensibilidad de la información que maneja la aplicación, ¿qué tiene que ver? Las buenas prácticas técnicas señalan que en ningún caso el código debe incluir la información personal que permite manejar. El código en un lugar, la información en otra (y cifrada en transmisión y guardado). Juntar ambas puede comprometer la seguridad.
El problema de la explicación mitológica es que busca la fe, no la confianza. Su función es más efectista que descriptiva, adormece el espíritu crítico ciudadano y la responsabilidad que todos tenemos de evaluar la acción de nuestros gobernantes. En su lugar, el mito contribuye a un estado de cosas narrativo, de “tecnosolucionismo” y “tecnodeterminismo”, que presenta las tecnologías digitales como capaces de solucionar de modo efectivo cualquier problema y nos invita a alienarnos respecto de los procesos sociopolíticos. Ya un computador se encargará. No existen límites. Y esto despierta suspicacias para quienes creen que no es suficiente con mantras. Las tecnologías digitales suponen riesgos como toda herramienta; dejar de mencionarlos no los hace desaparecer.
Devolver las tecnologías al debate público, con transparencia y sin miedo, es un imperativo. De no hacerlo, se escaparán de la órbita de los debates democráticos. Más información y más comprensible como presupuesto de la construcción de confianza. Frente a los despliegues tecnológicos en el sector público exigimos palabras con contenido, palabras humildes que reconozcan el límite en lo tecnológico, el error en lo humano, el valor en la crítica y la posibilidad de mejora en la sociedad. Confianza, sí; ciega, nunca. A Dios lo que es de Dios, al algoritmo lo que es del algoritmo y a la ciudadanía, todo.
*Fellow de la Línea de Investigación en Tecnología, Derechos Humanos y Transparencia de Dejusticia