La última milla del dato: ¿por qué el Business Intelligence está pasando del dashboard al diálogo?

Por Axel Bouvier

Hay una escena que se repite en casi todas las empresas con las que trabajo. Alguien en una reunión hace una pregunta que suena simple «¿cuánto crecieron los clientes del segmento X respecto al año pasado?» y la respuesta no está. No porque el dato no exista, sino porque hay que pedirlo, y cuando el reporte vuelve dos o tres días después, la decisión que lo motivó ya pasó. Durante años asumí que ese era el costo natural de trabajar con datos; hoy creo que resolvíamos el problema equivocado.

La última década se fue en tener datos: integrarlos, almacenarlos, ordenarlos. Lo que quedó sin resolver es otra cosa, y es la que de verdad frena a las organizaciones: la distancia entre el dato disponible y la respuesta útil. Ese tramo final, entre que el dato está en un sistema y que quien decide ya tiene su respuesta, es lo que llamo la última milla del dato. Y es, hoy, el verdadero cuello de botella.

Nunca tuvimos tantos datos, y nunca fue tan difícil obtener una respuesta

La paradoja es concreta. Los datos están: en el CRM, en el ERP, en los sistemas de soporte, en los financieros. Nunca sobró materia prima. Lo que falta es el último tramo que la convierte en una respuesta concreta a una pregunta de negocio.

El Business Intelligence nació justamente para cerrar esa brecha: sacar los datos del dominio exclusivo de IT y ponerlos en manos de quienes toman decisiones. Herramientas como Power BI, Tableau o Data Studio cumplieron una parte de esa promesa (democratizaron la visualización), pero no la otra: no democratizaron el acceso.

Y la diferencia es importante. Para que un dashboard exista, alguien tuvo que diseñarlo. Para que una consulta se responda, alguien tuvo que escribirla. Todo funciona bien mientras la pregunta ya esté prevista. El problema aparece cuando no lo está, que es la mayoría de las veces que algo interesante pasa en un negocio. Ahí la cadena se reinicia:

El resultado no es solo lentitud. Es una asimetría estructural: las personas que tienen el contexto del negocio no tienen acceso directo a los datos, y las que tienen acceso a los datos no siempre tienen el contexto del negocio. En el medio queda un traductor, el analista de BI, que hace un trabajo enorme y valioso, pero que tiene un límite físico de horas en el día.

No es un problema de tecnología. Es un problema de interfaz.

Por qué esto importa más de lo que parece

Vale la pena poner un solo número sobre la mesa, porque ordena la conversación: según McKinsey, las organizaciones que realmente toman decisiones basadas en datos son sustancialmente más propensas a captar clientes, retenerlos y ser rentables que el promedio. La orientación a datos no es una moda de gestión: correlaciona con resultados.

Y sin embargo, la mayoría de las empresas todavía no logró un acceso a datos verdaderamente transversal. La conclusión es incómoda pero clara: el problema no está en la parte de arriba de la pirámide (el cómputo, las bases, las herramientas de visualización) sino en la de abajo, en esa capa de traducción entre el lenguaje del negocio y el lenguaje de los datos. Si te interesa cómo se construye una cultura de toma de decisiones basada en datos, escribimos sobre eso en otro artículo; acá me quiero concentrar en qué está cambiando el acceso.

Del dashboard al diálogo

Lo que cambió en los últimos años es el tipo de interfaz posible. Durante décadas, «acceder a los datos» significó dos cosas: mirar un dashboard que alguien armó, o pedirle a alguien que escriba una consulta. Los avances en modelos de lenguaje abrieron una tercera vía: preguntar, en tu idioma, y recibir una respuesta analizada.

Dicho así suena a chatbot, y conviene desactivar esa asociación rápido, porque es la fuente de la mayoría de las decepciones. Un buscador con acceso a datos que «más o menos» acierta no sirve para tomar decisiones: en un contexto de negocio, una cifra inventada es peor que no tener respuesta. Lo interesante de esta nueva camada de sistemas no es que «hablan», sino cómo construyen la respuesta por debajo. Y ahí hay tres ideas que vale la pena entender sin tecnicismos.

1. No inventa: busca antes de responder

El sistema no responde de memoria: antes de decir nada va a la fuente real (tu base de datos, tu documentación), recupera el dato concreto y recién entonces elabora la respuesta. Es la diferencia entre un empleado que contesta lo que cree recordar y uno que primero abre el sistema, mira el dato de hoy y después responde. Técnicamente se llama RAG (recuperación aumentada), pero lo que importa es la consecuencia: cada respuesta queda anclada a un dato verificable, no a una intuición del modelo.

2. Traduce tu pregunta al idioma de la base de datos

Una pregunta en español: «¿cuáles fueron los cinco clientes que más crecieron respecto al año pasado?» se convierte en una consulta técnica, se ejecuta contra los datos reales y vuelve interpretada. Acá quiero ser honesto, porque es donde muchas demos brillan y muchos proyectos fracasan: en una base ordenada funciona casi perfecto, pero en una empresa real (con tablas heredadas, columnas con nombres crípticos y relaciones enredadas entre sistemas) la precisión cae si no hay un trabajo previo de contexto. La solución no es más cómputo, sino explicarle al sistema qué significa cada cosa en términos de negocio, mostrarle vistas ordenadas y validar las consultas antes de ejecutarlas. Esa capa de ingeniería, invisible para el usuario, es lo que separa una demo de un producto.

3. Razona por partes cuando la pregunta es compleja

Una pregunta de negocio interesante casi nunca se responde con una sola consulta: «¿por qué cayó la rentabilidad del producto X este trimestre?» obliga a mirar ventas, costos y quizás reclamos de soporte, todo junto. Los sistemas más maduros dividen esa pregunta grande en preguntas chicas, las buscan en los distintos sistemas (a veces en paralelo) y recién después arman una conclusión integrada. En lugar de que entres a tres sistemas y cruces todo a mano en una planilla, el sistema hace el recorrido y te devuelve la lectura completa: la diferencia entre una herramienta que responde y un asistente que analiza.

Qué cambia, en concreto, en el día a día

Prefiero bajarlo a situaciones antes que a estadísticas, porque es donde se ve el valor real:

• El ciclo de decisión se comprime. Una consulta que antes tardaba entre uno y tres días en volver del backlog pasa a responderse en segundos. Cuando el mercado se mueve rápido, eso deja de ser «eficiencia operativa» y se vuelve ventaja competitiva: ajustas una campaña el mismo día que ves que no rinde, no la semana siguiente.
• El equipo técnico deja de apagar incendios. El backlog crónico de «necesito un reporte de esto» está lleno de preguntas rutinarias que no requieren un experto. Cuando esas se resuelven solas por la interfaz conversacional, el equipo de datos recupera tiempo para lo que sí necesita cabeza humana: modelado, métricas, calidad de datos. No reemplaza al analista, lo libera de la parte que lo satura.
• El que decide deja de depender de un intermediario. Un gerente que quiere entender un número no abre un ticket ni espera a nadie: pregunta y sigue. Ese es el corazón de la democratización real, que la pregunta y la respuesta ocurran en el mismo momento, en manos de quien tiene el contexto para actuar.

Lo que todavía hay que tener en cuenta

Sería deshonesto vender esto como magia. El «enchufar y listo» no existe: en producción hay debajo un trabajo serio de ingeniería (esquemas ordenados, contexto de negocio, validación de consultas). Y la gobernanza no es un detalle, porque abrir el acceso amplía la superficie por la que se llega a los datos y exige control de permisos, auditoría y trazabilidad de cada consulta.

Después de ver varios de estos proyectos de cerca, mi conclusión es que el éxito depende menos de la tecnología que de la claridad sobre qué problema se resuelve y para quién. La pregunta correcta no es «¿qué puede hacer esta tecnología?», sino «¿qué pregunta de negocio tiene hoy un tiempo de respuesta inaceptable en mi organización?».

Conversia: llevar esto a un producto

Todo lo anterior son principios. En GeneXus Consulting los llevamos a un producto concreto, Conversia, precisamente para resolver esa última milla sin pedirle a las empresas que rehagan su infraestructura.

La idea es directa: conectar los sistemas que la organización ya tiene (CRM, ERP, bases operativas, soporte) y exponerlos a través de una interfaz conversacional que devuelve análisis, no datos crudos. Lo que lo distingue de «un chatbot con acceso a datos» es todo lo que pasa por debajo:

• Se conecta directamente a las bases actuales (SQL Server, Oracle, PostgreSQL, MySQL), a bases NoSQL (MongoDB, Cassandra, entre otras) y a data lakes, sin migrar ni replicar datos.
• Las consultas son siempre de solo lectura: no hay riesgo de modificar información por accidente, que es la primera objeción de seguridad que aparece.
• Permite varios asistentes especializados en paralelo (Ventas, Operaciones, Soporte) y comparar sus respuestas en la misma conversación, habilitando el cruce que hoy lleva horas de trabajo manual.
• Incluye un conector para agentes de IA externos (como Claude o Cursor) con la misma gobernanza y auditoría que el acceso humano, para las organizaciones que ya están armando sus pipelines de automatización.
• Ninguna interacción se usa para entrenar modelos. Los datos de negocio no salen de la infraestructura de la organización.

Dicho de otro modo: solo lectura, auditoría completa, autenticación integrada y datos que no se mueven de tu organización. Es la respuesta concreta al problema que vengo describiendo, no una función más.

Si querés, podés conocer más sobre nuestras soluciones de inteligencia artificial aplicadas al negocio.

Una reflexión final

La promesa del Business Intelligence siempre fue que los datos llegaran a quienes toman decisiones. Durante décadas se cumplió a medias: llegaban, sí, pero con retraso, mediados por un intermediario técnico y en formatos que todavía había que interpretar.

Por primera vez tenemos la posibilidad real de cerrar ese último tramo. No reemplazando al analista de datos, que sigue siendo imprescindible para los desafíos complejos, sino sacándole de encima la capa de demanda que hoy lo satura: las preguntas cotidianas que cualquier responsable debería poder contestarse solo, en el momento en que las necesita.

Si estás pensando por dónde empezar en tu organización, mi recomendación es siempre la misma: no arranques por la tecnología, arrancá por el cuello de botella más concreto que tengas. ¿Qué pregunta de negocio tiene hoy un tiempo de respuesta inaceptable? Esa es la conversación que vale la pena tener.