En un post anterior hablábamos de la importancia que han cobrado los algoritmos en nuestra vida ordinaria y de la necesidad de someterlos a control.
En este intentaré explicar de forma sencilla, que el común de los mortales (tú o yo) pueda entender:
(i) un procedimiento avanzado y seguro que permite “practicar una auditoría legal” a un algoritmo.
(ii) por qué necesitamos que los algoritmos sean auditables.
Están entre nosotros
Hoy apenas somos conscientes de hasta qué punto, algoritmos (procedimientos de decisión automatizada) deciden cosas triviales como la siguiente canción que te pinchará Spotify, la siguiente película que te propondrá Netflix, o la oferta conjunta que te propondrá comprar Amazon junto con el producto que ya has decidido comprar.
Y cosas no tan triviales como el importe de la prima que te costará tu seguro de vida; si te conceden o no un préstamo personal (y si es que sí, los intereses que tendrás que pagar; o si, de acuerdo con nuestro perfil de inversor, nos "conviene" un producto financiero u otro.
Y está bien, siempre que funcionen bien, que no nos hagamos pupa.
Mañana mismo veremos algoritmos encargándose de aprobar o suspender opositores, decidir cuál de las partes gana un juicio.
Y estará bien siempre que funcionen bien.
Igual que los smartphones hace diez años, estoy convencido de que los algoritmos y sus decisiones automatizadas han venido para quedarse. Y de que pronto, no sabremos cómo demonios vivíamos antes de tenerlos.
Lo mismo que con los coches.
Coches y Cinturones de Seguridad
Creo que viene a cuento algo que me gusta citar hablando de privacidad:
El coche de gasolina se inventó en 1885.
Hasta 1956 no se comercializó (como extra, que había que pagar aparte) el cinturón de seguridad.
El cinturón moderno, el de tres anclajes, se inventó poco después, en 1959. A partir de entonces, se incluyó de serie (por defecto) en todos los automóviles por Volvo.
El avance en términos de seguridad se consideró tan importante que Volvo liberó la patente para que todos los fabricantes la utilizaran y todos los conductores se beneficiaran.
Personalmente me pone los (pocos) pelos de punta pensar que los coches se han venido utilizando sin cinturón de seguridad durante más de la mitad del tiempo de su historia.
Imaginaros lo que eso significa.
En serio, pensemos un momento en la cantidad de muertes y lesiones que se consideraron normales hasta que el uso del cinturón (y el de las medidas de seguridad, en general) se generalizó.
Cinturones de Seguridad para Algoritmos
Creo que no podemos permitirnos el lujo de tardar tanto tiempo en instalar medidas de seguridad eficaces y por defecto sobre “nuestros” algoritmos.
Es preciso determinar el ámbito de responsabilidad de las empresas detrás de cada “robot” (sea un micrófono sofisticado como Alexa, un robot -de verdad- andarín como Atlas, o un algoritmo que automatice la toma de decisiones con efectos para el ciudadano).
Pero también es necesario imponer medidas de seguridad, como por ejemplo, la auditabilidad, sobre los algoritmos.
Y esto no lo digo yo, lo dice el art 22 del Reglamento General de Protección de Datos.
Simplificando: salvo consentimiento o autorización legal específicos, una persona no puede ser objeto de una decisión automatizada que produzca efectos jurídicos o le afecte significativamente de otra forma similar.
Aun en esos casos excepcionales de consentimiento o autorización, deberán tomarse medidas adecuadas para salvaguardar los derechos y libertades e intereses legítimos del interesado.
Además, quien consiente someterse a decisiones automatizadas, tiene un triple derecho:
- A exigir intervención “humana” del responsable de la decisión.
- A hacer alegaciones y, sobre todo,
c.A impugnar dicha decisión
Pero además del propio interesado, el Estado (más bien, la Sociedad) necesita poder verificar que aquellas decisiones (ilícitas por discriminatorias o por cualquier otra causa) que la ley no permite adoptar y aplicar a una persona puedan ser adoptadas y aplicadas por un algoritmo. Por muy inteligente que sea.
Necesitamos que alguien compruebe que los algoritmos funcionan como deben, que respetan la ley en su funcionamiento. Que no discriminan, no incurren en abusos en su funcionamiento.
Pero oiga, ¿Eso se puede hacer?
Vamos por partes.
Conocer el proceso mental que llevó a una persona a tomar una decisión concreta es imposible.
Pero sí es posible conocer o deducir por indicios ese proceso mental. De hecho, los jueces de lo penal lo hacen todos los días. Ese proceso es muy relevante para calificar un delito como voluntario o imprudente.
Ejemplo: un conductor atropella a un peatón. Dependiendo del proceso mental del autor, ese atropello puede ser:
- Un homicidio voluntario, si el conductor utilizó el coche como un arma,
- Imprudente, si el conductor estaba distraído o bajo la influencia del alcohol, o
- Nada en absoluto, si el peatón hizo caso omiso de un semáforo y se echó encima del vehículo.
Vale, pero ¿Cómo planteamos una auditoría de un algoritmo?
Los mejores cerebros del planeta están trabajando en ello. En este sentido, los siete principios de la ASC constituyen un avance relevante para implementar y estandarizar medidas de control sobre algoritmos.
Una cosa es que se pueda hacer, y otras que una persona sin los conocimientos adecuados, entienda cómo se hace.
Pero sigan conmigo: les adelanto que se puede hacer y que lo entenderán.
Nosotros, pobres humanos sometidos a sus decisiones necesitaríamos poder comprobar (o auditar) aspectos como los siguientes:
- La licitud de las premisas o principios básicos que ejecuta el algoritmo (si son lícitas, justas, no discriminatorias, si toman en cuenta o no categorías de datos especialmente protegidas, etc..)
- La regularidad del funcionamiento del sistema: Que la decisión adoptada y que me ha afectado (output), se basó en esas mismas premisas justas, aplicadas precisamente a mis datos (input) y
- La regularidad del funcionamiento y aplicación del algoritmo o sistema: Que ese sistema se aplica igualmente al resto de personas como yo y funcionará exactamente igual que ha funcionado conmigo (o sea que las mismas premisas, sobre el set de datos de otra persona igual o análoga a mí, arrojaría el mismo resultado).
La plena transparencia puede no ser suficiente, ni posible
Como ya anticipamos en el anterior post, la transparencia plena (la publicación completa del código fuente de un algoritmo) no es ni tiene por qué ser suficiente para acreditar la justicia de premisas o la regularidad de funcionamiento del sistema: hay muchos factores relevantes que no son controlables así.
Pero además siempre nos encontraremos con elementos de knowhow que los responsables del algoritmo no estarán dispuestos a mostrar públicamente. Y ello para evitar su copia por terceros, y la pérdida de la ventaja competitiva de su producto. Lo que viene siendo la lógica y necesaria protección de un secreto empresarial.
Es decir, necesitamos un sistema de control que permita a un tercero especialista auditar el funcionamiento de un algoritmo, accediendo a información que acredite de forma sólida su regularidad en un caso determinado (o en todos) pero sin revelar partes esenciales de su codificación, premisas y funcionamiento.
También tendremos que los datos personales de las personas sometidas a los algoritmos, y protegerlos en el proceso de auditoría.
¿Entonces, cómo se hace? Entren conmigo en el mundo de Oz...
No os preocupeis, si la cosa funciona pasablemente con los humanos, algo se podrá hacer con los algoritmos.
Os presento el loco, loco mundo de la criptografía: en el que los ingenieros consiguen complicar las cosas al máximo, para después brindarnos soluciones sorprendentemente simples y sólidas –aunque incomprensibles-.
Estamos esperando a que nos diga cómo demonios funciona la auditoría...
La solución más avanzada que ha encontrado este humilde abogadillo viene de la mano de la criptografía.
(Pido perdón desde ya a los tecnólogos por los errores y generalizaciones que siguen: no perdamos de vista que el objetivo es que otras “amebas” como yo, como nosotros, se enteren de la fiesta).
Este sistema, de forma sencilla y sintética consistiría en diseñar y escribir el algoritmo (de hecho, en escribir el software o sistema) de forma que, durante su funcionamiento, genere algo llamado “pruebas de conocimiento cero”. Unos “commitments” o "testigos" cifrados.
“Pruebas de Conocimiento Cero”. Tres ejemplos en abstracto:
No soy la persona más adecuada para explicar qué es una prueba de conocimiento cero. Eso se lo dejo a los expertos. Lo que sí puedo hacer es enlazarles varios textos que me han ayudado a entender el concepto:
Hayáis visto o no los ejemplos enlazados, si estáis lo suficientemente interesados o aburridos para seguir conmigo, debéis saber que la clave de una "prueba de conocimiento cero" ("zero-knowledge proof" o "ZKP" en su nomenclatura técnica en inglés) es que permite a un Gestor (llamémosle Alicia) acreditar que conoce algo, a un Verificador (llamémosle Roberto), pero sin que Roberto pueda llegar a conocer ni un ápice de ese algo, de la información que Alicia demuestra conocer.
Esto es parecido a lo que andamos buscando, ¿no?
Un ejemplo práctico y cotidiano (creo) en el futuro
Imaginemos que el algoritmo del “Banco Alicia” deniega un crédito personal a Roberto. Roberto es negro, conocido militante de un grupo político de extrema izquierda y bastante paranoico.
Roberto sospecha de la "mano negra algorítmica".
Cree que se le ha denegado el crédito por ser negro o no sé, por ser “rojo”. Probablemente por las dos cosas.
Así que ejercita el derecho que le reconoce el artículo 22.3 del Reglamento Europeo de Protección de Datos: Roberto impugna la decisión adoptada por el Banco Alicia (o lo que viene a ser lo mismo, por su algoritmo).
Será difícil convencer a Roberto: su ignorancia de los algoritmos y la criptografía le permitirá sostener, sea cual sea la explicación recibida, que el crédito se le denegó en realidad por todos esos desahucios que ha impedido. O por esas declaraciones incendiarias contra la banca que tuitea y publica a diario en Facebook y Snapchat.
Pero el Banco Alicia sabe que no basta con ser bueno: tiene también que parecerlo. Conoce el valor añadido de construir el vínculo de confianza con sus clientes. Exigió que el desarrollador del algoritmo le dotara de un mecanismo que permitiera su auditoría para casos como éste. En realidad para muchos otros casos.
Por eso ha tomado sus medidas, y estas medidas son verificables, son auditables.
Su algoritmo está diseñado de modo que, cada vez que recibe un conjunto de datos (un input), y devuelve una respuesta o output, aplicando las premisas que se le han predeterminado, genera tres sobres cerrados y sellados:
- El primero, una copia de las premisas que sirven de base a sus decisiones,
- El segundo, una copia del input o datos que sirven como base, y
- El tercero una copia del output, o la decisión resultante.
El Banco Alicia ha depositado en manos de un tercero de confianza esos tres sobres, sobres que no se pueden abrir sin romper el sello y que no permiten conocer la información contenida en su interior sin abrirlos.
Ante la reclamación de Roberto, el Banco Alicia recupera los tres sobres correspondientes a la decisión sobre Roberto. En los tres sellos figura la fecha de emisión (y de su registro, que corresponde con la transacción de Roberto).
Los entrega al Inspector de Algoritmos para que los abra y compruebe que efectivamente, la decisión sobre el caso de Roberto se ha alcanzado aplicando normas lícitas y tomando en cuenta sus circunstancias objetivas, sin sesgos ilícitos.
Igualmente, este sistema permitiría al inspector solicitar otros kits de sobres relativos a otras decisiones de casos parecidos a Roberto, y así comprobar que el sistema ha funcionado de manera objetiva e igual en todos los casos.
Hasta aquí el ejemplo: ahora es más fácil explicar el funcionamiento real
En la práctica, lo que de verdad genera el algoritmo, cada vez que adopta una decisión, son tres archivos informáticos vinculados entre sí (los sobres del ejemplo).
Estos tres archivos son tres “commitments” o "testigos” criptográficos, más una clave de verificación que permite descifrarlos, y acreditar que cada uno de ellos se corresponde con sus archivos originales (el primero a las premisas, el segundo a los datos de Roberto, el tercero a la decisión adoptada).
Estos commitments o testigos ni siquiera contienen las premisas, los datos introducidos o la decisión adoptada: en realidad son “hashes” o “huellas digitales” de aquellos archivos. Este detalle es relevante, porque los testigos ocupan un espacio mínimo (128 o 256 bytes), mucho menor que los documentos a los que se refieren. Es decir, son relativamente fáciles de gestionar.
Estos tres “testigos” junto con la clave, verificarán correctamente a sus archivos originales y sólo a ellos.
Los archivos originales no se pueden cambiar sin que el “testigo” correspondiente delate la manipulación.
Mediante este sistema el Banco Alicia puede acreditar que (i) aplicó una determinada política a (ii) unos determinados datos de Roberto, resultando (iii) una determinada decisión. Y ello, porque nadie puede modificar los archivos base, una vez generados los testigos, sin que estos testigos delaten la manipulación.
Estos “testigos” en vez de depositados o registrados, pueden ser copiados, publicados o compartidos, sin revelar aspectos sensibles de knowhow de Alicia y sin comprometer la privacidad de los datos de Roberto.
Es decir, son compatibles con un sistema de control unificado, como el registro de la propiedad o bien distribuido, al estilo de la cadena de bloques o blockchain.
De hecho, se trata de la misma relación que media entre el hash que se incorpora a la cadena de bloques o "blockchain" y el archivo a que se refiere: la alteración del archivo original será inmediatamente denunciada por los “mineros” de la cadena.
¿Quién será ese tercero de confianza?
Una opción es que cada kit de “testigos” sea almacenado de forma segura por un tercero de confianza.
Creo que veremos aparecer servicios de almacenamiento institucionales (idea para @notarioalcala: el más evidente sería el Protocolo notarial) y muchos otros privados, análogos o coincidentes con los que utilizan blockchain para acreditar derechos de propiedad intelectual sobre obras, como Stampery.
En caso de necesidad, por reclamación u otras causas, se realiza la prueba de verificación "sólo para los ojos" de la autoridad inspectora de algoritmos (o bien sólo para los del juez competente, apoyada en el perito correspondiente).
La autoridad (administrativa, judicial, una auditora privada) será capaz de determinar, a la vista de la información contenida en estos testigos, la regularidad del funcionamiento del algoritmo y de la decisión adoptada.
Conclusiones
- Los algoritmos deben desarrollarse teniendo en cuenta no sólo su funcionalidad (que desde luego) sino también la licitud de sus premisas, la regularidad de su funcionamiento y la posibilidad de que un tercero pueda auditar todo ello.
- El software debe estar diseñado para satisfacer estas exigencias de transparencia (limitada) y auditabilidad (plena).
- Esta auditabilidad respetará la confidencialidad del knowhow secreto integrado en el sistema y la privacidad de los datos personales de los interesados.
Este sistema es un win-win en términos del Privacy by Design (de los que le gustan a mi admirada Dra. Cavoukian).
Este sistema tiene también debilidades: no sirve para auditar algoritmos “no deterministas” (los que trabajan con un componente esencial de aleatoriedad) ni sistemas de “machine learning”. Para estos hay otras soluciones.
Sea éste u otro el sistema de control sobre algoritmos que se utilice, está claro que necesitamos que alguno se imponga.
Es muy probable que mañana elijamos entre un servicio (algoritmo) u otro, dependiendo de la mayor seguridad o fiabilidad que me ofrezca, como hoy ocurre con los automóviles.
Y lo importante es que esa seguridad o fiabilidad sea acreditable o auditable. El hecho de que no terminemos de comprender cómo funciona la auditoría no parece, hoy por hoy, decisivo.
Lo cierto es que yo no sé exactamente cómo funciona el mecanismo de bloqueo del cinturón de seguridad, ni el del airbag. Pero considero indispensable que mi coche los tenga.
Buena semana
Todo esto, como podéis fácilmente comprender, no se me ha ocurrido a mí solito. La parte tecnológica de este post proviene de este paper: (Kroll, Joshua A. and Huey, Joanna and Barocas, Solon and Felten, Edward W. and Reidenberg, Joel R. and Robinson, David G. and Yu, Harlan, Accountable Algorithms (March 2, 2016). University of Pennsylvania Law Review, Vol. 165, 2017 Forthcoming; Fordham Law Legal Studies Research Paper No. 2765268. Available at SSRN: https://ssrn.com/abstract=2765268 ).
Un agradecimiento especial a Miguel Bote Lorenzo (Doctor en Ingeniería de Telecomunicaciones y en Filosofía, de la Universidad de Valladolid) por guiarme por el loco loco mundo de Oz hasta el camino de baldosas amarillas.
Imagen del robot Elektro, cortesía de The Mannsfield Museum.
