El dashboard ha muerto como destino final: ahora el dato quiere ejecutar acciones

Hay una frase que probablemente suene exagerada, pero creo que resume bastante bien hacia dónde vamos:

El dashboard ha muerto como destino final.

No porque los dashboards vayan a desaparecer. No porque Power BI, Tableau, Looker, Streamlit o cualquier otra herramienta de visualización dejen de tener sentido. Al contrario: seguirán siendo necesarios durante mucho tiempo.

Pero sí creo que cada vez tiene menos sentido pensar que el viaje del dato termina en una pantalla con gráficos.

Durante años hemos construido productos de datos como si el objetivo final fuera “ver la información”. Y eso ha tenido sentido en muchos contextos: cuando no había visibilidad, cuando cada área tenía su Excel, cuando las métricas estaban dispersas, cuando para responder a una pregunta había que pedirle a alguien una extracción manual.

En ese escenario, un dashboard era un salto enorme. El problema es que muchas empresas se han quedado ahí.

Y ahora el negocio ya no necesita solamente ver datos. Necesita que esos datos le ayuden a decidir, a priorizar, a detectar problemas, a entender qué está pasando y, cada vez más, a ejecutar acciones.

Ahí está el cambio importante.

No es “poner IA”. No es “hacer un chatbot”. No es “crear un agente porque todo el mundo habla de agentes”.

Es entender que el dato está dejando de ser solo una capa de reporting para convertirse en una capa de operación.

Y eso cambia por completo cómo deberíamos diseñar los sistemas.

El dashboard fue una solución enorme… hasta que empezó a quedarse corto

Durante muchos años, cuando una empresa tenía un problema de información, la respuesta casi automática era construir un dashboard.

Necesitamos ver las ventas.
Necesitamos controlar pedidos.
Necesitamos seguimiento de incidencias.
Necesitamos saber cómo va el área.
Necesitamos un cuadro de mando.

Y muchas veces era verdad. Hacía falta. Porque no había nada mejor. O porque el dato estaba oculto en sistemas dispersos. O porque dependías de que alguien preparara un Excel cada semana. O porque cada reunión empezaba discutiendo qué número era el correcto.

En ese contexto, construir un dashboard no era poca cosa. Era ordenar datos, definir métricas, crear una capa común, dar acceso, reducir dependencia manual y permitir que varias personas miraran la misma realidad.

Pero una cosa es que el dashboard sea útil y otra muy distinta es tratarlo siempre como el producto final.

Porque llega un punto en el que el usuario no quiere más gráficos. Quiere respuestas. O, mejor dicho, quiere saber qué hacer con lo que está viendo.

Si las ventas bajan, quiere saber por qué.
Si un pedido está bloqueado, quiere saber quién tiene que actuar.
Si una métrica se desvía, quiere saber si es ruido o si requiere atención.
Si hay demasiadas incidencias, quiere saber cuáles son prioritarias.
Si un cliente está en riesgo, quiere saber qué acción conviene lanzar.

Ese es el punto donde el dashboard empieza a quedarse corto. No porque sea malo, sino porque solo cubre una parte del trabajo.

Muestra -> Pero no siempre explica.
Informa -> Pero no siempre ayuda a decidir.
Centraliza -> Pero no siempre activa nada.

Y aquí es donde creo que estamos entrando en otra etapa.

La pregunta ya no es “dónde veo el dato”, sino “qué hago con esto”

Esto parece un matiz, pero cambia mucho.

Cuando la pregunta es “dónde veo el dato”, el objetivo es construir una buena capa de visualización. Necesitas fuentes, modelo, métricas, permisos, diseño, filtros y una experiencia razonable para el usuario.

Pero cuando la pregunta pasa a ser “qué hago con esto”, ya no basta con pintar una gráfica. Necesitas contexto, reglas de negocio, saber qué acciones existen, saber quién puede ejecutarlas, distinguir entre una anomalía y una variación normal, definir umbrales, etc.

Es decir: de repente ya no estás construyendo solo reporting. Estás construyendo operación.

Y esto es justo lo que mucha gente no está viendo cuando habla de agentes de IA o de copilotos sobre datos.

La parte llamativa es la interfaz: preguntar en lenguaje natural, recibir una explicación, pedir un resumen, generar una recomendación.

Pero la parte importante está debajo. Si debajo no hay un sistema bien construido, el agente no aporta inteligencia. Aporta una capa más bonita encima del mismo desorden.

El riesgo de saltar directamente al agente

Ahora mismo todo el mundo habla de agentes. Es normal. Snowflake está empujando claramente hacia la empresa “agentic”, con anuncios recientes alrededor de CoWork, CoCo, Cortex, Snowflake Intelligence y Horizon Catalog. Microsoft también está moviendo Fabric, Power BI y Copilot hacia experiencias donde los agentes pueden trabajar sobre datos gobernados, modelos semánticos e informes. Incluso la documentación reciente de Microsoft insiste en algo bastante importante: la calidad de las respuestas de IA depende muchísimo de cómo prepares las fuentes de datos y los modelos semánticos.

Es decir, el mercado va hacia ahí. Eso no lo discuto. Lo que discuto es la interpretación fácil. Porque muchas empresas van a leer todo esto y van a decir: “tenemos que hacer un agente”.

Y quizá sí. Pero quizá no todavía. O quizá el agente debería ser la última pieza, no la primera.

Porque si una organización no tiene claros sus datos, sus procesos, sus reglas, sus permisos y sus responsabilidades, el agente no va a solucionar eso. Al contrario: va a hacerlo más evidente.

Un agente conectado a una base confusa no convierte esa base en fiable.
Un agente conectado a definiciones ambiguas no crea una verdad común.
Un agente conectado a procesos mal diseñados no genera automáticamente eficiencia.

Y un agente con acceso a herramientas internas sin límites claros no es innovación. Es riesgo con interfaz moderna.

Esto hay que decirlo así, sin demasiadas vueltas: muchas empresas no necesitan empezar por un agente de IA. Necesitan construir un sistema técnico que, llegado el momento, pueda ser operado por uno.

Una respuesta bonita puede ser peor que una tabla fea

Hay algo que me preocupa especialmente con la IA aplicada a datos: la confianza que genera el lenguaje natural.

Cuando un dashboard está mal hecho, muchas veces se nota. Ves un número raro, una gráfica que no cuadra, un filtro extraño, una tabla incoherente. Puede que el usuario no sepa explicar técnicamente el problema, pero sospecha.

Con un agente es diferente. Un agente puede responder muy bien redactado. Puede sonar seguro. Puede darte una explicación aparentemente razonable. Puede incluso estructurar la respuesta de forma impecable.

Y aun así estar apoyándose en datos mal definidos… ese es el peligro.

Imagina una pregunta muy simple: “¿cómo van las ventas esta semana?” Parece una pregunta inocente. Pero cualquiera que haya trabajado con datos sabe que no lo es.

¿Qué significa “venta”? ¿Pedido creado? ¿Pedido pagado? ¿Pedido enviado? ¿Venta neta? ¿Venta bruta? ¿Incluye devoluciones? ¿Incluye cancelaciones? ¿Se mezclan canales online y offline? ¿Hay centros que deben excluirse? ¿La fecha correcta es la de pedido, la de pago, la de envío o la contable? ¿Todos los usuarios pueden ver margen? ¿Todos pueden ver detalle por cliente?

Si esas preguntas no están resueltas, el agente no está contestando realmente a “cómo van las ventas”. Está interpretando algo como puede.

Y eso en un dashboard ya era un problema.

Pero en una interfaz conversacional puede ser peor, porque la respuesta llega envuelta en seguridad, lenguaje fluido y aparente criterio.

Por eso la capa semántica deja de ser un detalle técnico. Se convierte en una condición de posibilidad.

La semántica no es documentación bonita

En muchas empresas, las definiciones de negocio viven repartidas entre documentación incompleta, código SQL, Excels, conversaciones, costumbre y memoria de algunas personas concretas.

Eso ya era frágil antes; ahora es directamente insuficiente si queremos poner IA encima.

Si cada área entiende algo distinto por “cliente activo”, “venta válida”, “pedido completado”, “margen”, “riesgo”, “incidencia” o “conversión”, el problema no es que falte un agente. El problema es que falta una definición común.

Y esto no se arregla solo con tecnología.

Se arregla hablando con negocio, entendiendo procesos, modelando bien, documentando reglas, haciendo explícitas las excepciones y construyendo una capa técnica que no dependa de interpretaciones informales.

La IA puede ayudar, claro. Puede revisar documentación, detectar inconsistencias, explicar reglas, generar borradores, asistir en consultas y facilitar el acceso al conocimiento.

Pero no puede decidir por la empresa qué significan sus conceptos clave. Eso tiene que estar gobernado y, si no lo está, el agente va a trabajar sobre arena.

De visualizar a actuar hay un salto enorme

En cuanto pasamos de visualización a acción, aparecen preguntas que antes podían quedar escondidas. Quién puede hacer qué. Qué acciones requieren confirmación. Qué pasa si algo falla. Cómo se registra. Cómo se audita. Cómo se revierte. Qué coste tiene. Qué límites debe respetar el sistema.

Mostrar que hay pedidos bloqueados es una cosa. Decidir cuáles son prioritarios, asignarlos, notificar a alguien y registrar la acción es otra.

Mostrar que una métrica cae es una cosa. Explicar la causa probable, distinguir si es una anomalía real y preparar una acción correctiva es otra.

Mostrar clientes en riesgo es una cosa. Crear tareas comerciales, sugerir argumentos y medir si se recuperan es otra.

Y aquí es donde se ve que el salto no es simplemente “añadir IA al dashboard”. Es rediseñar el producto de datos como un sistema operativo, no solo informativo.

No todo necesita IA, y esto conviene repetirlo

Creo que también hay que bajar un poco el entusiasmo. Ni todo necesita IA, ni agentes ni un copiloto.

A veces lo que hace falta es una tabla bien modelada. O una vista. O una alerta. O una aplicación interna sencilla. O una automatización. O un formulario con estados. O una capa de validación. O un dashboard mejor pensado. O simplemente eliminar un Excel que se ha convertido en sistema crítico sin que nadie lo reconozca.

El problema es que muchas veces la tecnología de moda se come el diagnóstico.

Antes todo era “necesitamos un dashboard”. Ahora empieza a ser “necesitamos un agente”.

Y en ambos casos la primera pregunta debería ser la misma: ¿para qué problema concreto? Si no hay problema concreto, no hay producto. Hay experimento (con suerte).

Y experimentar está bien. Pero no es lo mismo experimentar que transformar un proceso.

El nuevo producto interno será híbrido

Creo que aquí está una de las claves de lo que viene. Las soluciones internas de datos no van a ser solo dashboards, ni solo aplicaciones, ni solo automatizaciones, ni solo agentes. Cada vez más serán una mezcla.

Una aplicación interna que muestra datos, valida reglas y permite ejecutar acciones.
Un dashboard que no solo enseña KPIs, sino que explica cambios relevantes.
Un asistente que no responde desde cualquier sitio, sino desde documentación y modelos gobernados.
Un flujo de trabajo donde la IA clasifica, resume o prioriza, pero una persona confirma las acciones importantes.
Un sistema que avisa, registra, mide y deja evidencia.

Eso, para mí, es mucho más interesante que hacer “un chatbot”. Porque ahí es donde la IA deja de ser una demo y empieza a formar parte de un producto técnico real.

Pero también exige más criterio. Hay que entender datos, desarrollo, procesos, permisos, experiencia de usuario, automatización, operación, costes y mantenimiento.

El Data Engineer no desaparece: cambia de responsabilidad

Hay una idea que aparece cada cierto tiempo: que con la IA el perfil técnico va a perder importancia porque las herramientas serán más fáciles de usar.

Puede que la interfaz sea más fácil. Puede que un usuario pueda preguntar en lenguaje natural. Puede que ciertas tareas se aceleren muchísimo. Puede que algunas consultas, explicaciones o prototipos se generen de forma más rápida.

Pero eso no elimina la arquitectura. La hace más importante.

Porque alguien tiene que decidir qué datos son válidos. Alguien tiene que modelar. Alguien tiene que definir métricas. Alguien tiene que controlar permisos. Alguien tiene que versionar reglas. Alguien tiene que registrar acciones. Alguien tiene que medir calidad. Alguien tiene que observar costes. Alguien tiene que diseñar qué partes se automatizan y cuáles no.

El perfil técnico de datos deja de ser solo alguien que mueve datos de un sitio a otro.

Cada vez más, se convierte en alguien que diseña sistemas donde los datos pueden ser usados por personas, aplicaciones y capas inteligentes de forma segura.

Eso es bastante más estratégico, y también más difícil.

Antes de crear un agente, yo miraría estas cosas

No lo plantearía como una checklist enorme ni como un documento de consultoría eterno. Pero sí haría algunas preguntas muy básicas antes de lanzarme.

Qué proceso queremos mejorar. Qué decisión queremos acelerar. Qué acción queremos preparar. Qué datos necesita el sistema. Quién es responsable de esos datos. Qué definiciones están claras y cuáles no. Qué usuarios pueden ver qué información. Qué acciones requieren confirmación humana. Qué debe quedar registrado. Qué pasa si el sistema se equivoca. Cómo medimos si realmente aporta valor.

Si no podemos responder a eso, probablemente no estamos construyendo un producto agentic. Estamos haciendo un prototipo.

Y repito: un prototipo puede ser útil, pero hay que saber que es un prototipo. Lo peligroso es vender una demo como si fuera una solución productiva.

La parte visible será más sencilla, pero la parte invisible será más seria

Es curioso, porque para el usuario final todo esto puede parecer más simple.

En vez de navegar por diez informes, preguntará.
En vez de abrir varias pantallas, pedirá un resumen.
En vez de revisar manualmente una lista, recibirá una priorización.
En vez de montar una consulta, pedirá una explicación.

Pero por debajo la complejidad no desaparece. Se desplaza. Debajo habrá identidad, permisos, modelos semánticos, SQL, APIs, documentación, reglas de negocio, validaciones, logs, observabilidad, control de costes y auditoría.

La experiencia se simplifica: la ingeniería, no.

Y quizá esta sea una de las ideas más importantes: cuanto más sencilla parece una herramienta para el usuario, más serio tiene que ser el sistema que la sostiene.

Fuentes y referencias

Para este artículo he usado como contexto los anuncios recientes de Snowflake sobre CoWork, CoCo, Horizon Catalog y Snowflake Summit 2026; las novedades de Microsoft Build 2026 sobre Fabric, Power BI, modelos semánticos y aplicaciones agentic; y el paper “Agentic AI in Industry: Adoption Level and Deployment Barriers”, publicado en mayo de 2026, sobre barreras reales de adopción industrial de agentic AI.