Nuestro país cuenta en materia de contratación pública con un Servicio que asesora técnicamente a los demás órganos de la Administración y tiene a su cargo la gestión del sistema de información www.mercadopublico.cl. Me refiero a la Dirección ChileCompra.
Como parte de su rol asesor, este organismo suele preparar documentos con recomendaciones y buenas prácticas en distintos temas vinculados con las compras públicas. Ello, con el objeto de favorecer que los órganos compradores actúen dentro de la ley, con transparencia y probidad, con eficiencia de recursos y fomento de la inclusividad.
Una de esas recomendaciones técnicas es la directiva N°27, de diciembre de 2016, mediante la cual la Dirección ChileCompra busca favorecer la generación de datos abiertos en la contratación pública.
Como expliqué en la columna “Datos abiertos: de la transparencia activa a la transparencia útil”, los datos abiertos son aquellos que, en formato digital, se ponen a disposición de cualquier persona y reúnen ciertas características legales y técnicas que permiten su uso, reutilización y distribución en cualquier momento y lugar.
En dicha opinión sostengo que, a mi juicio, ante la baja utilización que tienen hoy los sitios de transparencia activa de los distintos órganos de la Administración, el paso que tenemos que dar es hacia una transparencia útil, basada en la publicación de datos abiertos, ya que permiten una dimensión más participativa del principio de transparencia.
Por ello, me parece interesante explicar los aspectos más relevantes de ese documento de ChileCompra –la directiva N°27-, ya que me tocó participar en su redacción y es una expresión de lo que planteo.
En términos generales, esa directiva tiene lineamientos sobre:
1) la publicación de datos abiertos en los sistemas transaccionales de compra –como el portal mercadopublico.cl- y en los portales de transparencia activa;
2) la utilización de los datos a través de sistemas informáticos; y
3) se pronuncia sobre el límite que encuentran los datos abiertos frente a los datos personales. Veamos cada uno de ellos.
1. Recomendaciones sobre publicación de datos abiertos
En Chile, las compras públicas de bienes muebles y prestaciones de servicio se realizan a través de la plataforma www.mercadopublico.cl que administra ChileCompra. Si bien, cada órgano público es responsable de sus procesos de compra realizados en el portal, los datos de las transacciones quedan registrados en ese sistema de información único.
Por esa razón, tal vez las recomendaciones sobre publicación de estos datos bajo estándares abiertos aplican más directamente a la propia Dirección ChileCompra, ya que se traducen en ajustes a su plataforma. No obstante, como la contratación administrativa es más amplia que solo los contratos regidos por la Ley 19.886, los demás servicios públicos también pueden tomar estos lineamientos y aplicarlos a la publicación por transparencia activa de sus otros contratos.
En términos bien resumidos –ya que sugiero leer la Directiva N°27- destacan las siguientes recomendaciones:
1.1. Publicar información pública de compras en formatos normalizados que permitan su reutilización por parte de la ciudadanía.
Si bien es importante para la publicidad de los procesos de compra el contar con documentos a disposición de la sociedad civil (por ejemplo, bases de licitación, resoluciones de adjudicación, actas de evaluación, contratos, órdenes de compras, entre otras), se trata por lo general de archivos pdf o imágenes que no permiten trabajar con los datos contenidos en ellos.
En este caso, la recomendación es incorporar versiones de esos documentos en formatos más abiertos, como csv, xml, rdf o sparql, por ejemplo.
Si se fijan, no me referí solo a formatos editables como doc, txt, xls, ya que si bien permiten trabajar con los datos, son propietarios. Ese es solo un paso dentro de los estándares internacionales de datos abiertos, ya que es preferible subir a niveles aún más abiertos.
De hecho, la Directiva explica que no todos los formatos normalizados permiten el mismo nivel de reutilización de datos, por lo que se sugiere tomar como referencia la metodología de 5 estrellas de Tim Berners-Lee (el “padre de la web”) e ir subiendo gradualmente.
En términos simples, dicha metodología distingue 5 niveles de madurez en datos abiertos, según su formato, desde los que solo permiten verlos, imprimirlos y guardarlos hasta aquellos que se pueden editar y enlazar.
En mi opinión, los órganos administrativos publican en transparencia activa mayormente en un nivel de 1 y 2 estrellas, a través de archivos pdf y xls. Algunos otros tienen 3 estrellas porque utilizan xml para su almacenamiento y transmisión (según los exigía el hoy derogado decreto 81, de 2004, de SEGPRES, sobre interoperabilidad de documentos electrónicos). En el caso de los datos de compras, según la plataforma en que nos encontremos, podemos ver datos abiertos en los 5 niveles.
1.2. La información pública de compras se puede reutilizar para cualquier finalidad lícita.
Esto significa que los datos abiertos no necesariamente deben ser empleados por la sociedad civil en el mismo contexto en que los utiliza el órgano público.
1.3. Mantener versiones oficiales no editables.
Es importante que la publicación de datos abiertos no olvide otros principios como la seguridad jurídica. Claro, junto con los documentos editables y reutilizables es fundamental que la documentación de un proceso de compras cuente con una versión que garantice la integridad del contenido. Por ejemplo, de los decretos y resoluciones, de las órdenes de compra, de las facturas, de las ofertas, de los contratos, etc.
Es obvio. No podemos caer en la inseguridad de no saber que versión es la correcta, por ejemplo de un acta de evaluación o de una orden de compra. Si cualquiera puede acceder a formatos reutilizables, por supuesto que no faltará quien quiera adulterar datos. Hay que precaver ese riesgo.
1.4. Advertir sobre la fuente de los datos.
La calidad de la información en esencial para los datos abiertos, ya que al ser utilizada por la sociedad civil, es imprescindible la confianza de ésta en la información proporcionada por el órgano público.
Datos de mala calidad terminan por no ser utilizados y, datos abiertos que no se utilizan, no tienen sentido.
En los portales de compras públicas, los datos transaccionales son ingresados por distintas fuentes: los órganos compradores que en Chile son más de 850 organismos y los proveedores con quienes contratan. Por lo tanto, existe el riesgo de ingresar datos con errores, por ejemplo, al equivocarse en las cifras o en las unidades de moneda o de medida, o al no escribir normalizadamente datos de los compradores o los productos.
Ante tales circunstancias, la Directiva N°27 recomienda advertir clara y expresamente a los usuarios de datos abiertos cuando éstos emanan de fuentes distintas al respectivo órgano público, ya que, como no se tiene un control sobre lo publicado por dichas fuentes (compradores o proveedores), pueden existir registros con errores o inconsistencias en los datos.
En este punto, usted podría preguntarse: ¿pero por qué no los corrige quien administra el portal de compras? Simple, porque esos portales de comercio electrónico deben permitir la auditabilidad de los registros, ante posibles responsabilidades de quienes ingresen información intencionadamente falsa. Si el administrador del portal realiza una corrección directa sobre los datos erróneos que advierta, elimina la posibilidad de fiscalización.
Se sugiere, por tanto, implementar soluciones informáticas que estandaricen la carga de los datos –disminuyendo errores en el ingreso-, y correcciones ex post por el mismo usuario que los cargó.
“Datos de mala calidad terminan
por no ser utilizados y,
datos abiertos que no se utilizan,
no tienen sentido”.
2. Recomendaciones para interoperar e innovar con datos abiertos a través de API
Dentro de las características de los datos abiertos está su capacidad de ser leídos por máquinas, gracias a la utilización de formatos estructurados. Acá estamos pensando en la utilización de datos abiertos por usuarios con un poco más de conocimientos técnicos, suficientes como para consumir información a través de herramientas informáticas, normalmente, en grandes volúmenes.
En este punto, las interfaces de programación de aplicaciones (API) son herramientas muy potentes. Para entenderlo en fácil, acá el órgano público que pone a disposición servicios API, abre la puerta para que un tercero ingrese a sus sistemas, a sus bases de datos y consuma directamente de ellas la información. Por eso la necesidad de sistemas informáticos que interoperen, logrando la descarga automática de datos.
Del mismo modo, gracias a los datos que se consumen a través de una API, el usuario se encuentra en posición de realizar desarrollos de aplicaciones, en este caso, enfocadas en las compras públicas. Por ejemplo, programas que alerten mediante Whatsapp sobre las licitaciones que son de mi interés para ofertar o que me muestren gráficamente y con alertas aquéllas que estén próximas al cierre del plazo para presentar ofertas, entre otras.
Todo lo anterior, idealmente para la utilización de la comunidad, ojalá gratuitamente y con código abierto, para ir enriqueciéndolo. Eso sí, también puede ser valioso para realizar negocios a partir de estos programas que tratan los datos abiertos. La finalidad la da el usuario, bastando únicamente que sea lícita.
En cuanto a la directiva N°27, ella recomienda lo siguiente sobre la implementación de una API:
2.1. Documentar y difundir las condiciones técnicas de uso de los datos a que se accede por API.
Como expliqué, la API abre la puerta a las bases de datos del órgano público, por lo que no necesariamente se podrá acceder a todo tipo de información ni de cualquier forma. Ello lo determina el Servicio Público, para evitar que la API se transforme en una vulnerabilidad altamente riesgosa del organismo. Con condiciones claras y explícitas, los usuarios de API pueden dimensionar mejor sus expectativas.
2.2. La API solo debe permitir acceso a información pública.
Esta es una idea esencial en torno a los datos abiertos. Su libre uso se legitima precisamente porque su contenido es público, en cuanto se trata de información de naturaleza pública.
En ese sentido, la información pública es la relacionada con actos administrativos, resoluciones, procedimientos administrativos y documentos que sirven de fundamento a las decisiones que contienen esos actos administrativos. Es decir, no todo documento o dato en poder de un órgano público es información pública y, por ende, no todos deben disponibilizarse como datos abiertos. Por ejemplo, información aún en borrador o sobre la que terceros tienen propiedad intelectual. Igualmente, si son datos personales, como explicaré en breve.
Ahora bien, tratándose del acceso a información pública a través de una API, lo esperado es contar con datos reales y en línea, aunque con los resguardos de seguridad apropiados (ej. ambientes separados para consumir datos de la API, sin afectar la plataforma transaccional).
Del mismo modo, al empezar con una API se sugiere ir incorporando gradualmente más tipos de datos abiertos. Creo que puede ser imprudente dar acceso de inmediato a toda la base de datos, si no se cuenta con experiencia en servicios API. Por lo tanto, en la medida que su funcionamiento sea correcto y esté controlado el posible impacto en otros sistemas del organismo público, se puede ir aumentando la cobertura.
2.3. Restricciones de seguridad
Si bien una de las características de los datos abiertos es su libre uso no discriminatorio, ello no puede significar que se sacrifique la seguridad de la información que tiene el órgano público. Por eso, es importante que éste cuente con restricciones técnicas para el consumo de datos, por ejemplo, cuotas limitadas de peticiones, frecuencia u horarios para la utilización de los servicios de la API, con el fin último de garantizar la integridad de los datos y, sobre todo, la disponibilidad de la información. Por supuesto, tales limitaciones de seguridad deben ser informadas previamente a los usuarios, como parte de las condiciones de uso de la API.
2.4. Considerar el impacto en los usuarios
Finalmente, la Directiva recomienda definir previamente cuáles son las situaciones que habilitan al órgano público para suspender el servicio de una API o modificarlo. Esto es importante para los usuarios quienes, a partir del consumo de datos, crean negocios o desarrollan trabajos de investigación.
Un cambio en las condiciones en que se presta el servicio de una API puede incidir significativamente en la continuidad de esas actividades y proyectos que realizan los usuarios a partir de ella. Por eso, el impacto podría ser perjudicial para ellos, de modo que corresponde que el órgano público transparente la posibilidad de cambiar o suspender el servicio –que, por cierto, debe tenerla-, de manera que las personas puedan tratar ese riesgo.
3. Recomendaciones sobre datos personales y datos abiertos
Las posibilidades que ofrecen los datos abiertos para la sociedad civil son enormes. Mejor información, control, generación de valor agregado a la gestión pública e innovación. Sin embargo, todo lo bueno se degrada cuando cae en excesos. Para eso los límites.
En ese sentido, es muy importante comprender que las ventajas que ofrecen los datos abiertos no se pueden anteponer a los derechos de las personas. En concreto, me refiero a la tentación que puede existir, sea para un órgano público o para la propia sociedad civil, en orden a poner a disposición de la comunidad como datos abiertos (accesibles, usables, reutilizables y distribuibles), los datos personales que se encuentren en registros de un organismo público.
La premisa básica es simple: los datos personales no son información pública. Ergo, los datos personales no deben ser datos abiertos.
De hecho, los datos personales de otros tienen una regulación especial y diferente para acceder a ellos, que no es la Ley de Transparencia, salvo en contadas excepciones, donde prima el interés público. Por el contrario, se requiere seguir las hipótesis de la Ley de Protección de la Vida Privada: autorización del titular del dato o de una ley.
Por tal motivo, la directiva N°27 señala que no hay que incluir automáticamente datos personales en proyectos de datos abiertos. Solo podrían considerarse de forma excepcional, si hay una autorización legal para ello. Sin embargo, sinceramente, en este punto, es muy poco probable encontrar leyes que lo permitan.
Por el contrario, los datos personales deben ser protegidos por defecto, desde el diseño de las iniciativas de datos abiertos. Sobre esto, les sugiero leer mi columna: “Privacidad por diseño: más que una moda”.
Finalmente, se menciona como buena práctica para difundir información vinculada a datos personales, sin infringir los derechos de sus titulares, el disociarlos previamente.
La disociación es un procedimiento dirigido a convertir la información personal en anónima, es decir, en datos estadísticos agregados. Para ello, lo que se hace es quitar información suficiente (sea borrando, tachando o eliminando ciertos datos) o bien, enmascarar o codificar ciertos datos para que no sea posible asociarlos o ligarlos con alguien determinado.
En mi opinión, esa es la única vía legítima para que los datos personales se incluyan en proyectos de datos abiertos, ya que, en realidad, dejan de ser datos personales.
La premisa básica es simple:
los datos personales
no son información pública.
Ergo, los datos personales
no deben ser datos abiertos.
Como ven, los datos abiertos son un tema sobre el que se está trabajando en Chile, quizás aún no con la cobertura que se requiere, pero con ejemplos concretos como el que acabo de presentar, tratándose de compras públicas.