Visualización de datos con IA 2025: De dashboards pasivos a agentes autónomos que deciden

En 2018, cuando publicamos la primera versión de este artículo, el reto era elegir la herramienta correcta para pintar gráficos sin saber programar. Datawrapper, Tableau Public, Raw, Infogram: el abanico era amplio, la curva de aprendizaje suave y el objetivo, legítimo, era «democratizar la visualización».

Siete años después, el problema ha mutado. Las empresas no necesitan más gráficos; necesitan menos ruido y más decisiones. Según Gartner 2025, el 78% de los dashboards corporativos se consultan menos de una vez al mes. El coste no está en licenciar Tableau o Power BI —que siguen siendo estándares—, sino en el tiempo de analistas senior limpiando datos, eligiendo el chart adecuado y redactando conclusiones que nadie lee.

El cambio de paradigma: de BI pasiva a Analytics Agentic

La irrupción de modelos multimodales (GPT-4o, Claude 4 Sonnet/Opus) y frameworks de agentes autónomos (LangGraph, CrewAI, AutoGen, MCP) ha desplazado el foco:

1. Generación de código de visualización on-demand: Un analista pide en lenguaje natural «muéreme la evolución del churn por cohorte y segmento en los últimos 18 meses con intervalos de confianza» y el agente escribe el Python (Plotly, Altair, Observable) o SQL + Jinja para Superset/Metabase, lo ejecuta y devuelve el gráfico interactivo.
2. Auto-insight & narrative generation: El agente no solo pinta; detecta anomalías (rupturas de tendencia, outliers multivariantes), cuantifica el impacto económico y redacta el resumen ejecutivo en el tono de la organización.
3. Closed-loop actuation: Vía MCP (Model Context Protocol), el agente puede disparar acciones: crear ticket en Jira, alertar en Slack/Teams, lanzar re-entrenamiento de modelo en Vertex AI o disparar un workflow en n8n/Temporal.

En BAOSS hemos pasado de implementar dashboards a diseñar sistemas de analytics agentic que reducen el time-to-insight de semanas a minutos.

Caso real anonimizado: Retail omnicanal — 1.200 tiendas, 14 TB/día

Problema 2024: El equipo de datos (12 personas) dedicaba el 68% de su sprint a mantener 340 dashboards Power BI. Los directivos de zona recibían PDFs estáticos cada lunes; para el miércoles ya eran obsoletos. Decisiones de reposición y promociones se tomaban con 5-7 días de latencia.

Solución BAOSS (Q1 2025):

• Arquitectura RAG híbrida sobre Snowflake + Pinecone: catálogo de métricas gobernado (dbt + Data Contracts), embeddings de definiciones de negocio y linaje columnar.
• Agente LangGraph multi-paso (planner → sql_generator → validator → chart_coder → narrator) orquestado con MCP servers para GitLab (versionado de código de viz), Slack (human-in-the-loop) y ServiceNow (ticketing).
• UI conversacional en Teams (Bot Framework + Adaptive Cards) + portal web React/Observable para drill-down.
• Modelos: Claude 4 Opus para planning y narrativa; GPT-4o para SQL/Plotly coding; Llama-3.1-70B-Instruct (vLLM/Ollama on-prem) para clasificación de intención y PII masking.

Métricas a 6 meses (producción real):

El secreto no fue «comprar Copilot», sino gobernar el contexto: catálogo de métricas versionado, tests de regresión sobre SQL generado (SQLMesh + dbt unit tests) y bucles de feedback humano (RLHF interno) para alinear narrativa y criterio de negocio.

Stack 2025-2026: Qué tecnologías usan los equipos que ganan

Capa de orquestación y agentes

• LangGraph (producción): grafos de estado cíclicos, checkpointing, human-in-the-loop nativo. Ideal para pipelines multi-paso con ramificación condicional.
• CrewAI (prototipado rápido): roles/agents/tasks declarativos, buen soporte para herramientas (tools) y memoria compartida.
• AutoGen 0.4+ (colaboración multi-agente): patrones GroupChat, SelectorGroupChat, código ejecutable en contenedores sandbox.
• MCP (Model Context Protocol): estándar emergente (Anthropic, Microsoft, JetBrains) para exponer herramientas, recursos y prompts a cualquier cliente LLM. En BAOSS montamos MCP servers internos para: catálogo dbt, GitLab, Jira, Confluence, feature store, feature flags.

Capa de modelos: nube + on-prem híbrido

• GPT-4o / GPT-4o-mini (Azure OpenAI): coding, function calling, visión para chart QA.
• Claude 4 Opus / Sonnet (AWS Bedrock / Anthropic API): reasoning largo, narrativa, planificación.
• Llama 3.1 / 3.2 / Nemotron 3 Ultra (vLLM / Ollama / TGI) en GPU propia (H100/A100): clasificación, embedding, PII masking, SQL generation fine-tuned (Text-to-SQL Spider benchmark 89% EX).
• Embeddings: BGE-M3, NV-Embed-v2, text-embedding-3-large según latencia/coste/calidad.

Capa de visualización y front-end

• Observable Framework / Plot / Plotly.js / Altair: gráficos reactivos, versionables en Git, servidos estáticos (CDN) o embebidos.
• Apache Superset / Preset / Metabase / Evidence.dev: BI headless para dashboards gobernados (core KPIs).
• Streamlit / Gradio / Chainlit / CopilotKit: interfaces conversacionales rápidas para agentes.

Patrones de arquitectura que funcionan (y los que no)

✅ Pattern: Semantic Layer + RAG + Agentic Loop

El agente nunca escribe SQL crudo contra tablas físicas. Consulta el catálogo semántico (dbt metrics, Cube, AtScale, o capa propia), recupera definiciones vía RAG (chunking semántico de YAML + documentación), genera SQL validado contra contracts, ejecuta en read-replica, renderiza chart, narra. Cada paso tiene test automático y auditoría.

✅ Pattern: Human-in-the-loop como feature, no bug

El agente propone, el analista valida/edita en lenguaje natural («cambia el eje Y a log-scale y añade la media móvil de 4 semanas»), el agente regenera código y aprende (preference tuning / DPO sobre traces). Latencia percibida: < 8 segundos.

❌ Anti-pattern: «Text-to-SQL directo a producción»

Sin catálogo gobernado, sin tests, sin linaje. Alucinaciones de join, métricas inconsistentes, filtros de seguridad omitidos. Lo hemos visto fallar en 3 clientes antes de llegar a BAOSS. Coste medio de limpieza: 4-6 sprints.

❌ Anti-pattern: Un modelo para todo

Usar GPT-4o para clasificar intención, generar SQL, pintar chart y narrar. Coste/latencia innecesarios. Routing inteligente (pequeño classifier → modelo especializado) ahorra 60-75% en tokens y reduce latencia P95 de 14s a 3,2s.

Seguridad, gobernanza y coste: la letra pequeña que decide el go/no-go

• PII / Data residency: Clasificador ligero (Llama-3.2-3B fine-tuned, 40 ms en CPU) en edge antes de salir a cloud. Datos sensibles → modelo on-prem (vLLM/Ollama).
• RBAC a nivel de métrica: El catálogo semántico lleva políticas (OPA/Rego) que el agente respeta al generar SQL. El director de zona solo ve sus tiendas.
• Observabilidad LLM (Langfuse / Helicone / Arize / Phoenix): Traces completos, evaluaciones automáticas (faithfulness, answer_relevance, sql_correctness), alertas de deriva.
• FinOps: Presupuesto mensual por agente/usuario. Router corta a modelo barato si supera umbral. En el caso retail: 0,18 €/consulta media (blended), 4.200 consultas/mes → 756 €/mes vs 18.000 €/mes de licencias Power BI Premium + 2 FTEs liberados.

Cómo empezar mañana (hoja de ruta 90 días)

1. Semana 1-2: Auditoría de dashboards (uso real, linaje, dueños). Identificar top 20 preguntas de negocio recurrentes no resueltas por dashboards actuales.
2. Semana 3-4: Construir catálogo semántico mínimo (dbt metrics + YAML docs) para esos 20 temas. Versionar en Git. CI con dbt test + SQLMesh.
3. Semana 5-6: Prototipo agente (LangGraph + Claude 4 Sonnet) sobre read-replica. Tools: sql_generator (con catálogo), chart_coder (Plotly), narrator. Eval set: 50 preguntas reales + expected SQL/chart.
4. Semana 7-8: Human-in-the-loop en Teams/Slack. Feedback loop (thumbs up/down + corrección NL). Métricas: faithfulness > 0,92, sql_ex_accuracy > 0,8