Cómo construí un sistema autónomo que recaba información oficial para un despacho profesional

Necesité comprender mejor el flujo de trabajo actual de la empresa, para averiguar cómo mejorar su proceso. Para ello, algunas de las preguntas que necesité responder son las siguientes:

1. ¿Cuál era el flujo de trabajo actual y sus condicionantes? Para responderlo, entrevisté al trabajador más veterano en esta labor, ya que la metodología era la misma entre los 3.
2. ¿Qué fuentes contienen la información necesaria y en qué formatos? Necesitaba saber si las fuentes ofrecían la información por API, o en formato CSV, XML, PDF... Necesitaba saber si podría extraerlo de forma sencilla, de manera programática, o si por el contrario necesitaría recurrir al scrapeo o soluciones similares.
3. ¿Qué frecuencia de actualización tienen y cómo de estables son las fuentes? Necesitaba saber si las URLs serían previsibles; si cambiaban a menudo; si podrían surgir problemas por los que necesitaríamos establecer fallbacks, etc.
4. ¿En qué software y de qué manera guardan la información de sus clientes? Era importante saber si el ERP y/o CRM de la empresa era comercial o privado, y si disponía de una API que pudiera utilizar para cruzar los datos.
5. ¿Existen limitaciones en cuanto a protección de datos? Supuse que en el caso de Autónomos (personas físicas) tendríamos ciertas limitaciones en cuanto a la toma o almacenamiento de datos. Quería confirmarlo.

Algunos de los hallazgos más importantes en mi investigación fueron los siguientes:

• Alguna de las fuentes disponía de API, pero la mayoría disponía únicamente de un archivo XML o PDF.
• En el caso de PDFs antiguos, incluso se trataban folios impresos; por lo que para disponer de histórico, debía integrar una mezcla de métodos para procesar estos datos.
• Las fuentes de información no disponen de datos normalizados. De hecho, son bastante inconsistentes. Y en varios casos existen erratas y errores ortográficos desde la toma de datos que dificultan su normalización.
• Utilizaban un ERP comercial, por lo que la integración de la información parseada y normalizada podía realizarla a través de su API.
• Efectivamente, existían limitaciones en cuanto a protección de datos en el caso de los autónomos.

El producto resultante se podría resumir de la siguiente manera:

Un sistema autónomo, que aglutina diferentes fuentes de información oficiales de manera modular y escalable, y reconcilia cada nueva noticia en el perfil del respectivo cliente en el ERP de la asesoría.

Construí un prototipo inicial para testear la calidad de la información, la fiabilidad de la reconciliación entre la información que provenía de diferentes fuentes; y para determinar la probabilidad de fallo y encontrar casos extremos que debiéramos solventar.

Opté por un patrón de diseño denominado "Medallion", para organizar los datos de forma lógica en un Data Lakehouse. Con el objetivo de mejorar la calidad, estructura y fiabilidad de los datos de manera progresiva a medida que fluyen a través de tres capas distintas: Bronze, Silver y Gold.\

Capa Bronze (Datos Crudos)

Es el punto de entrada de toda la información. Los datos se almacenan exactamente igual que en su origen (en formato raw o crudo), sin aplicar filtros ni transformaciones.

• Propósito: Mantener un historial completo e inalterable. Permite reprocesar datos si hay fallos o realizar auditorías en cualquier momento.
• Tipo de datos: JSON, archivos planos (CSV, Excel), o flujos continuos (streaming) de APIs, bases de datos, etc.

Capa Silver (Datos Depurados)

Aquí es donde los datos de la capa Bronze se filtran, limpian y transforman. Se integran y estandarizan distintas fuentes de información en un modelo coherente.

• Propósito: Crear una fuente única y confiable de datos con calidad empresarial.
• Operaciones clave: Se eliminan duplicados, se corrigen errores, se resuelven problemas de formatos y se valida la integridad de los datos.

Capa Gold (Datos Agregados)

Representa la capa de presentación y consumo final. Los datos ya refinados se modelan en esquemas orientados al negocio (tablas de hechos y dimensiones).

• Propósito: Optimizar los datos para informes, Dashboards, LLM, API...
• Tipo de datos: Información lista para ser consumida en este caso por la API que alojará la información en cada respectiva empresa del ERP de la asesoría.

Algunos de los edge cases más importantes fueron:

• ¿Qué ocurre si los datos parten de un dato escaso, erróneo o con diferencias ortográficas? Para estos casos, creé un sistema de triple-check. Primero se intenta resolver de manera determinista. Si no se reconcilia, pasa a un fallback de IA. Si el sistema de IA no lo reconcilia, un sistema manual. Técnicamente es un sistema que puntúa similitudes y establece posibles matches de información que, en caso de no ser reconciliada automáticamente, se presenta en un dashboard de validación manual. Tras diversas pruebas con cientos de datos, aproximadamente un 4% de la información caía en este fallback manual inevitable, por motivo de las propias fuentes de datos.
• ¿Qué ocurre cuando se incorpora una nueva empresa como cliente de la asesoría y se necesita cierto histórico sobre ella? Como gracias al sistema Medallion, almacenamos la información en crudo: Para estos casos, creé un simple formulario en el que introducir un rango de fechas y, al pulsar un botón de acción, el sistema pasa por los archivos de las fechas indicadas y recaba la información histórica sobre ella en las diferentes fuentes.
• ¿Qué ocurre si una fuente de datos deja de actualizarse por rotura o cambio de URL, o cualquier otro motivo? El sistema conoce la periodicidad de actualización de cada fuente, y en caso de no recibir datos tras 12 horas más de lo esperado, el sistema envía una notificación a la asesoría y al equipo técnico, que en este caso soy yo.
• ¿Qué ocurre si la API del ERP cambia? Implementé una solución similar a la del punto anterior, que en este caso en la notificación devolvía el changelog de la API dentro de un breve rango de fechas en las que el sistema se vio interrumpido.