Nicolás Pavón

Por la plata baila el mono

En el mundo actual, la corrupción es un problema que afecta a todos los países. Por lo tanto, contar con un estándar para almacenar las compras gubernamentales, como el Estándar de Datos de Contrataciones (OCDS, por sus siglas en inglés), desempeña un papel crucial en descubrir actividades fraudulentas y mal uso financiero por parte del gobierno. Afortunadamente, en Uruguay, este estándar se ha utilizado desde 2002 para almacenar una amplia gama de compras gubernamentales, y estos datos están disponibles públicamente de forma gratuita en la página web de Datos Abiertos.

En este estudio de caso, analizaremos estos datos en busca de patrones y características interesantes que, con suerte (o no), revelarán algún mal uso de los fondos gubernamentales.

Inspiración

Al buscar un conjunto de datos interesante para demostrar nuestras habilidades de Machine Learning, nos encontramos con el sitio web Cuentas claras. En ese sitio, los propietarios intentan revelar compras fraudulentas y mal uso de fondos gubernamentales aplicando una "función" que analiza ciertos parámetros y devuelve un valor, en su caso, "red flags". Esta idea de "red flags" no es nueva, y como podemos ver en el sitio web de OCDS, ya ha sido intentada por algunos países, y existen guías para trabajar con los datos de OCDS en busca de estas red flags.

Sitio web de Cuentas Claras

Recomendamos encarecidamente echar un vistazo al sitio web y explorarlo. Como puedes ver en la imagen de arriba, han procesado y clasificado con éxito las compras de muchas organizaciones gubernamentales públicas, marcándolas con las famosas "red flags". Además, hay algunas estadísticas interesantes para explorar.

Lamentablemente, el proyecto "Cuentas claras" no proporciona los datos procesados junto con las "red flags", y después de algunos intentos fallidos de ponerse en contacto con los propietarios, parece estar abandonado o en un estado de espera.

Esta no es una buena noticia. Para entrenar un modelo predictivo, necesitamos datos ya etiquetados. Afortunadamente, las personas en "Cuentas Claras" describieron, de alguna manera, el proceso que llevaron a cabo para marcar las organizaciones en estos documentos. Teniendo esto en cuenta, hay dos posibles caminos para continuar trabajando en esto. Podemos "etiquetar" manualmente los datos procesándolos con una función similar a la utilizada por "Cuentas claras", o podemos intentar aplicar algoritmos de agrupamiento para identificar patrones y grupos, y luego ver si podemos notar algún patrón inusual que pueda indicar actividad sospechosa.
O bien, podemos intentar ambas aproximaciones.

Generando los datos objetivo

Utilizando la guía provista por la organización Open Contracting Partnership sería posible (en teoría) determinar si cierta compra fue "sospechosa", ya que provee una lista con las posibles "banderas rojas", donde se indica que condiciones debe cumplir una compra para generar sospechas.
Luego de una breve investigación llegamos a la conclusión de que determinar eso caso por caso no es buena idea por dos motivos:

• No estamos calificados para analizar las compras y determinar actividades sospechosas, ya que pese a contar con esa guía nunca podríamos saber con presicion si realmente fue una compra fraudulenta, por falta de contexto
• Generar todos esos datos es una tarea muy ardua y lenta

Aplicando clustering

Si bien no era la idea inicial, haciendo uso de los algoritmos de clustering podemos estudiar la informacion de distintas formas, y eventualmente lograr extraer conclusiones interesantes. In cluso tal vez seamos capaz de destacar ciertas compras con patrones interesantes.. outliers.

Standard OCDS

El estandard OCDS procura almacenar la informacion de los prosesos de compra del gobierno de forma clara, concisa y en detalle. Para esto provee una serie de guías disponibles en su sitio web:

• Introducción al estándar
• Guía util para comprender el esquema de datos

Luego de investigar un poco mas el estandar concluimos en que un proceso de compra está compuesto a grandes rasgos por:

• Una etapa de planificación (Planning)
  • Información sobre la fase de planeación del proceso de contratación. Esto incluye información relacionada con el proceso de decidir qué contratar, cuándo y cómo.
• Una etapa de Licitación (Tender)
  • Las actividades llevadas a cabo para celebrar un contrato.
• Una etapa de adjudicación (Awards)
  • Información de la fase adjudicación del proceso de contrataciones. Puede haber más de una adjudicación por proceso de contrataciones; por ejemplo, porque el contrato se divide entre diferentes proveedores, o porque es una oferta permanente.
• Una etapa de Contratación (Contracts)
  • Información de la fase de creación del contrato en el proceso de contratación.

Como se puede observar, esto no es un proceso sencillo. Cuenta de varias etapas en las que no entraremos en profundidad por razones prácticas, pero en un caso ideal podemos concluit que el estandar busca ser verás y completo a la hora de administrar esta información

Selección de datos

Luego de haber estudiado y comprendido el estandard investigamos un poco mas en profundidad las famosas "Banderas rojas", donde encontramos Guía util para comprender el esquema de datos que explica en detalle varios casos posibles de actividades fraudulentas

De esta guía destacamos algunos ejemplos:

• El tiempo disponible para postularse a la licitación es muy poco (menor a 2 dias)
• La licitación no cuenta con un criterio claro para elegir al postulante ni informacion clave como fechas, presupuesto, etc
• La licitación es solo por invitación

Estos son los ejemplos mas claros que podemos observar, pero existen 64 posibles banderas rojas en total 🤯

Teniendo estas red flags en cuenta y los datos disponibles en el standard hacemos una pre selección de los datos que nos interesan. Esta lista se puede ver en detalle en el repositorio del equipo.

¿Que hacemos con las relaciones N-1?

Para estudiar este problema lo mejor será empezar por el camino simple, seleccionando los ejemplos que sean posibles procesar utilizando rapidminer. Teniendo en cuenta que rapidminer trabaja (en un principio) con archivos csv, donde toda la información de una compra se encuentra en una fila, no sería posible procesar compras que contengan relaciones N-1, donde por ejemplo para una compra existen varios postulantes con distintos datos cada uno. Para lidiar con este problema elaboramos un script que itera sobre todas las compras de un archivo con el formato OCDS, resumiendo la información relevante de las compras que sean buenas candidatas para ser procesadas.

Esto no fue una tarea simple, ya que primero hubo que definir qué informacion de una compra es relevante, y luego lidiar con el esquema para extraerla exitosamente resolviendo distintos conflictos como el uso de diferentes monedas para indicar el precio de una licitación, entre otros. Sientete libre de entrar en contacto conmigo para conocer mas detalles al respecto

Datos Uruguayos

Una vez que armamos un script para reducir los datos a un csv con información de interés, procesamos los datos disponibles en el sitio de Uruguay y observamos lo peor.. si bien se almacenan datos en cantidad desde 2002, estos datos están imcompletos, conteniendo solo la indormacion de la cantidad de items que se compraron y su precio unitario..

Datos BsAs

Si bien esto parecía el fin del proyecto, nos acordamos que esto es un estandar internacional y muchos países lo siguen. Luego de hacer una breve investigacion encontramos en su sitio web un mapa con los países adheridos al estandar, donde observamos a argentina. Entramos a la pagina web de datos argentinos, descargamos el set de datos y luego de procesarlo observamos que contiene muchos mas datos que el set uruguayo.

Pero... funciona?

Duración del período de licitacion vs método de adquisición

Conclusión

Futuro del proyecto

Sitios Intereseantes Con Información Del Tema: