De datos dispersos a una capa consultable por IA

Resumen

El pedido visible era claro: "queremos un chatbot que responda preguntas sobre nuestros datos". El problema real no era el chatbot. Eran datos dispersos entre varios productos, métricas sin una definición única y reglas de negocio que vivían en la cabeza de algunas personas.

Antes de conectar cualquier modelo de IA, había que construir algo más aburrido y más importante: una capa de datos confiable, curada y consultable.

Contexto

El negocio operaba con varios productos distintos, cada uno con su propia forma de generar datos: bases relacionales con transacciones y estados, fuentes documentales con información semiestructurada y algunas APIs externas. Cada producto tenía su propio vocabulario y sus propias reglas implícitas.

La expectativa, impulsada por el ruido del mercado, era saltar directo al chatbot. La realidad era que ni siquiera había una definición compartida de las métricas básicas del negocio.

Por confidencialidad, este caso está escrito de forma sanitizada: sin datos reales, nombres de productos ni cifras internas. El foco está en el enfoque y las decisiones, no en la información del cliente.

Problema Visible

• Fuentes dispersas: cada producto guardaba sus datos en lugares y formatos distintos.
• Métricas sin definir: la misma palabra significaba cosas distintas según el equipo.
• Reglas de negocio escondidas: lógica crítica que nunca se había escrito.
• Datos sensibles sin un control claro de quién accede a qué.
• La idea de un chatbot respondiendo sobre datos en los que nadie confiaba del todo.

El síntoma parecía "nos falta IA". El problema de sistema era más profundo: no había una base de datos confiable sobre la cual una IA pudiera responder.

Hipótesis Iniciales

Enfoque

En lugar de empezar por el chatbot, empecé por las fuentes. La pregunta útil no era "qué modelo usamos", sino "qué tendría que ser verdad en los datos para que cualquier respuesta sea confiable".

• Mapeé cada fuente: qué genera, con qué frecuencia, qué calidad tiene y quién es dueño.
• Construí ETLs para llevar fuentes relacionales, documentales y APIs hacia un modelo común.
• Aterricé los datos en un modelo curado en PostgreSQL, separando lo operacional de lo analítico.
• Definí métricas explícitas, con una sola fuente de verdad por concepto.
• Hice explícitas las reglas de negocio que antes vivían solo en personas.

Arquitectura

Datos Sensibles y Límites

Habilitar consultas asistidas por IA sobre datos internos obliga a tomar en serio el control de acceso. No alcanza con que el modelo responda; importa qué datos puede ver y qué nunca debería exponer.

• Separé datos sensibles de la capa consultable de propósito general.
• Definí qué preguntas tienen respuesta confiable y cuáles quedan fuera de alcance.
• Dejé la capa de IA como consumidora de un modelo curado, no como acceso directo a las fuentes crudas.

Trade-offs

Este enfoque agrega una capa para mantener: pipelines, definiciones de métricas, monitoreo y documentación. Y es más lento que conectar un chatbot a lo que ya existe. Pero evita un problema peor: una IA que responde rápido y con seguridad sobre datos que nadie validó.

Resultado

• Una base de datos confiable y curada, con métricas definidas una sola vez.
• Reglas de negocio escritas y revisables, en vez de conocimiento disperso.
• Una capa lista para dashboards, automatizaciones o consultas asistidas por IA.
• Una IA que, cuando llega, responde sobre datos en los que se puede confiar.

Lecciones Aprendidas

La parte más visible de un proyecto de IA es el chatbot, pero rara vez es donde está el trabajo real. La IA útil empieza antes: en las fuentes, las métricas, las reglas de negocio y el control de los datos sensibles. Si esa base no existe, la IA no resuelve el problema; solo lo hace más difícil de detectar.