Nota de anonimización #

Este caso fue reescrito para reducir riesgo de reidentificación. Se omiten o generalizan sector, tipo exacto de análisis, nombres de módulos, fuentes, stack específico, roadmap exacto, detalles comerciales y cualquier combinación de señales que pueda asociarse con una organización concreta.

Resumen ejecutivo #

El proyecto partía de un activo técnico valioso: un motor analítico construido durante varias iteraciones, capaz de transformar datos heterogéneos en indicadores, comparaciones, rankings y reportes usados para decisiones de negocio.

El problema no era “hacer ciencia de datos desde cero”. El problema era más común en productos de datos que nacen desde conocimiento experto: el valor ya existe, pero vive repartido entre scripts, archivos, reglas implícitas, modelos, procesos manuales, supuestos metodológicos y personas clave.

La pregunta central fue:

¿Cómo convertimos un análisis experto en una plataforma reproducible, auditable y operable sin reescribir todo?

La recomendación fue evolucionar de forma incremental hacia una arquitectura con dominios claros, contratos de datos, trazabilidad por corrida, quality gates, operación observable, seguridad práctica y un camino de producto sin perder compatibilidad con lo que ya funcionaba.

El problema: el valor existía, pero era difícil de operar #

Muchas plataformas de datos nacen como una combinación de análisis experto y ejecución artesanal. Primero funcionan como scripts o notebooks. Después aparecen reportes, extractos, archivos intermedios, reglas de scoring, parámetros por caso, procesos de limpieza y pasos que sólo algunas personas conocen bien.

Eso puede ser suficiente mientras el volumen es bajo y el equipo conserva todo el contexto. Pero cuando el producto empieza a crecer, aparecen preguntas incómodas:

  • ¿Podemos repetir exactamente un resultado de hace meses?
  • ¿Sabemos qué datos, código, parámetros y reglas produjeron un indicador?
  • ¿Qué pasa si falla una fuente externa?
  • ¿Qué pasos siguen siendo manuales?
  • ¿El resultado es defendible ante un cliente, comité o auditoría?
  • ¿Qué tanto depende el proceso de una persona específica?
  • ¿Podemos operar esto como producto sin volverlo frágil?

El diagnóstico mostró un patrón claro: había valor analítico real, pero la operación todavía no tenía suficiente estandarización, trazabilidad, observabilidad ni gobierno.

El enfoque: diagnosticar el producto antes que la tecnología #

Una decisión importante fue no empezar por la nube, el framework o la herramienta de moda. Primero había que entender qué entregaba el producto y qué partes no podían fallar.

El principio fue:

El output manda.

Si el resultado final es un reporte, ranking, score, comparación o recomendación que habilita una decisión importante, entonces el pipeline debe diseñarse alrededor de ese resultado, no alrededor de una herramienta.

El diagnóstico cubrió cinco frentes:

Qué decisiones habilita el análisis, quién consume los outputs y qué nivel de explicación necesita.

  1. Producto y decisiones

Qué fuentes son críticas, cuáles son frágiles, cuáles requieren validación y cuáles tienen restricciones legales u operativas.

  1. Fuentes de datos

Cómo se ingesta, limpia, transforma, une, calcula y entrega información; qué pasos son manuales y dónde se rompe el proceso.

  1. Proceso end-to-end

Qué reglas alimentan los resultados, qué parámetros cambian por caso y cómo se validan regresiones entre versiones.

  1. Modelos, reglas e indicadores

Quién accede a qué datos, cómo se auditan corridas, cómo se monitorean fallas y qué debe construirse primero.

  1. Operación, seguridad y roadmap

Hallazgos principales #

El sistema ya tenía elementos de producto, no sólo experimentos. Existían pipelines funcionales, salidas útiles para negocio y una base metodológica valiosa.

También había brechas típicas de una transición desde investigación aplicada hacia operación:

  • pasos manuales difíciles de repetir;
  • convenciones de carpetas y salidas mezcladas;
  • contratos de datos no aplicados en runtime;
  • adopción parcial de identificadores de corrida;
  • dependencias no gobernadas;
  • configuración local o hardcodeada;
  • pruebas insuficientes;
  • observabilidad limitada;
  • hot spots de performance;
  • reglas de scoring sin versionado formal;
  • documentación dispersa;
  • criterios de promoción entre capas poco explícitos.

El riesgo no era sólo técnico. Esas brechas podían afectar confianza, velocidad de entrega, onboarding, soporte, auditoría y capacidad de defender resultados.

Arquitectura objetivo: industrializar sin reescribir #

La recomendación no fue tirar todo y empezar de nuevo. Eso habría sido costoso y riesgoso. La ruta correcta era industrializar lo que ya tenía valor.

La arquitectura objetivo se planteó con estos principios:

  • Separación por dominios: cada parte del proceso con responsabilidades, owners y contratos claros.
  • Datos como producto: datasets versionados, documentados, validados y promovidos por reglas explícitas.
  • Trazabilidad por corrida: cada resultado debe poder explicar de dónde vino y con qué método se generó.
  • Quality gates: reglas mínimas antes de promover datos o publicar resultados.
  • Observabilidad por defecto: duración, errores, volumen, calidad y estado de cada corrida.
  • Seguridad práctica: secretos fuera del código, accesos mínimos, cifrado, backups y auditoría.
  • Evolución incremental: mantener compatibilidad con el core existente mientras se encapsula y profesionaliza.

La cadena lógica quedó expresada de forma conceptual:

fuentes -> evidencia inicial -> normalización -> entidades limpias -> indicadores -> outputs

Lo importante no era el nombre de cada capa, sino la capacidad de responder:

  • qué entró;
  • qué cambió;
  • qué reglas se aplicaron;
  • qué calidad tuvo;
  • qué versión del método corrió;
  • qué resultado se entregó.

Contratos de datos y trazabilidad #

Una pieza central fue pasar de “archivos que funcionan” a contratos explícitos.

Cada dataset relevante debía tener:

  • schema esperado;
  • llaves canónicas;
  • versión de método;
  • identificador de corrida;
  • timestamps de ingesta y procesamiento;
  • fuente lógica;
  • estado de calidad;
  • linaje;
  • reglas de promoción.

Esto permite que un resultado no sea una caja negra. Con trazabilidad suficiente, el equipo puede investigar diferencias, repetir corridas, comparar versiones y explicar cambios sin depender de memoria humana.

Operación y seguridad #

El trabajo también aterrizó una matriz de controles mínimos para operar con disciplina sin burocratizar al equipo.

Los controles prioritarios fueron:

  • catálogo de servicios de datos;
  • ownership por dominio;
  • política de cambios;
  • versionado de método y schema;
  • configuración externa por ambiente;
  • pruebas unitarias e integración;
  • validaciones de calidad;
  • gestión de secretos;
  • cifrado y backups;
  • monitoreo de corridas fallidas;
  • runbooks básicos;
  • postmortems ligeros;
  • scorecard operativo.

La intención era proteger el producto y al equipo. Cuando un análisis se usa para decisiones relevantes, la disciplina operativa se vuelve parte del valor.

Roadmap seguro #

El roadmap se formuló por capacidades, no por fechas públicas ni compromisos específicos.

Fase 1: estabilizar #

  • unificar rutas y convenciones;
  • retirar wrappers obsoletos;
  • cerrar dependencias faltantes;
  • separar configuración de código;
  • asegurar que los flujos críticos corran en un entorno limpio.

Fase 2: gobernar datos #

  • activar trazabilidad end-to-end;
  • formalizar contratos de datos;
  • agregar quality gates;
  • documentar datasets y owners;
  • definir criterios de promoción.

Fase 3: operar #

  • orquestar corridas;
  • medir duración, fallas y calidad;
  • agregar alertas;
  • crear runbooks;
  • registrar cambios relevantes.

Fase 4: productizar #

  • versionar reglas e indicadores;
  • validar regresiones;
  • separar core analítico de capa de entrega;
  • preparar acceso multiusuario o APIs sólo cuando existan controles suficientes.

Lecciones aprendidas #

1. Un producto de datos no se vuelve plataforma sólo por correr en cloud #

La nube puede ayudar, pero no reemplaza contratos, trazabilidad, calidad, seguridad y operación.

2. La reproducibilidad es una característica de negocio #

Si un resultado no puede repetirse o explicarse, su valor comercial se debilita.

3. No todo debe reescribirse #

Cuando el core analítico ya funciona, conviene encapsular, ordenar y profesionalizar antes de intentar una reescritura grande.

4. El scoring necesita gobierno #

Un indicador compuesto debe tener versionado, explicación, validación y criterios de cambio.

5. La operación también es producto #

Alertas, runbooks, calidad de datos, auditoría y trazabilidad no son detalles internos. Son lo que permite vender o sostener confianza.

Conclusión #

El aprendizaje principal fue que modernizar un producto de datos no empieza comprando una plataforma ni migrando todo a otro stack.

Empieza haciendo visible el proceso:

conocimiento experto -> reglas explícitas
scripts dispersos -> flujos operables
archivos sueltos -> datasets gobernados
resultados manuales -> corridas trazables
modelo implícito -> método versionado
entrega artesanal -> producto confiable

La meta no era borrar el pasado técnico. Era conservar el valor y darle forma operativa.