Qué pueden hacer realmente los agentes de datos, qué revelan los benchmarks actuales y qué arquitectura necesita Agentic Analytics para funcionar en producción.

La demo siempre es la misma. Alguien abre un chat, escribe «investiga por qué han caído las ventas en el norte», y un agente consulta el warehouse, cruza tres tablas, detecta una anomalía en un canal concreto y devuelve un informe redactado. Impecable. El problema es que esa demo se parece muy poco al trabajo real de un equipo de datos, donde el punto de partida no suele ser un dashboard limpio con una anomalía interesante, sino un dashboard roto y un jefe preguntando por Slack qué ha pasado.

La analítica agéntica —agentes autónomos que planifican y ejecutan flujos analíticos de varios pasos sin que un humano dirija cada clic— es una categoría real y con recorrido. Pero es también, ahora mismo, una de las etiquetas más infladas del sector. Este artículo intenta separar las dos cosas usando lo único que permite hacerlo con honestidad: los benchmarks públicos y los datos de adopción.

Agentic Analytics en pocas palabras

• Qué es: el uso de agentes de IA capaces de planificar y ejecutar análisis de datos de varios pasos de forma autónoma.
• Qué lo diferencia de un chatbot: el agente no se limita a responder; utiliza herramientas, consulta datos, comprueba resultados y modifica su estrategia.
• Principal limitación actual: los benchmarks muestran que las tareas analíticas complejas siguen siendo difíciles para los agentes.
• Qué determina su fiabilidad: no solo el modelo de IA, sino también el contexto, la capa semántica, las herramientas disponibles y la gobernanza.
• Cómo empezar: con tareas acotadas, verificables, permisos mínimos y métricas claras de precisión y coste.

1. ¿Qué es Agentic Analytics y cómo funciona?

La diferencia con un chatbot o un copiloto no es de grado, sino de estructura. Un chatbot responde una pregunta y espera la siguiente, sin memoria de por qué preguntaste. Un agente recibe un objetivo y ejecuta un bucle: planifica los pasos, invoca herramientas reales contra infraestructura real, observa el resultado, detecta si algo no cuadra y vuelve a intentarlo. Ese bucle —y la capacidad de comprobar su propio trabajo antes de responder— es lo que hace que algo sea agéntico.

La distinción importa porque el mercado la está borrando activamente. Gartner identificó una práctica extendida a la que llamó «agent washing»: el rebranding de productos ya existentes —asistentes, automatización robótica de procesos, chatbots— sin capacidades agénticas sustanciales. Su estimación es contundente: de los miles de proveedores que dicen ofrecer IA agéntica, solo alrededor de 130 son reales. Eso obliga a leer la cifra de cancelaciones con matiz: parte de ese 40 % nunca fueron programas agénticos, sino automatización corriente vestida con lenguaje nuevo, que se canceló cuando la etiqueta no sobrevivió al contacto con una carga de trabajo real.

2. Agentic Analytics benchmarks: ¿qué rendimiento tienen realmente los agentes?

Aquí está el material que casi nunca aparece en los artículos sobre este tema. Hay al menos tres evaluaciones públicas sobre tareas de datos realistas, y sus resultados son mucho más sobrios que cualquier demo.

El primero es DABstep, construido por Adyen y Hugging Face a partir de más de 450 tareas reales de una plataforma de analítica financiera. Exigen combinar procesamiento de datos con código y razonamiento contextual sobre documentación heterogénea, y están diseñadas para resistir la generación de código en un solo disparo. El resultado: los mejores agentes alcanzan alrededor de un 16 % de precisión en las tareas difíciles —o4-mini marcó un 14,55 %, Claude 3.7 Sonnet un 13,76 %— frente a un 70-80 % en las fáciles. Y las difíciles son el 84 % del benchmark.

El segundo es DAB, centrado en consultas realistas sobre múltiples bases de datos. Incluso el mejor modelo frontera logra solo un 38 % de pass@1, y el análisis de errores apunta a algo revelador: los fallos dominantes no están en escribir SQL, sino en formular planes correctos e implementarlos bien. El cuello de botella es la planificación, no la sintaxis.

El tercero es el más relevante para quien trabaja con dbt: ADE-bench, creado por Benn Stancil en colaboración con dbt Labs. Su virtud es el realismo deliberado: proyectos dbt completos con modelos, macros y configuración, bases DuckDB con datos de verdad —a veces rotos, con tipos que no casan— y tareas tan vagas como «está roto», que es literalmente lo que un directivo escribe en Slack. El agente trabaja en un contenedor aislado y su solución se valida con tests de dbt.

En ADE-bench, el agente Codex con GPT-5.1 pasó el 56 % de los tests con un coste aproximado de 14,90 dólares por ejecución, y Claude Sonnet 4.5 rindió casi idéntico. Pero conviene subrayar la advertencia del propio autor: no considera significativa esa cifra absoluta, sino su utilidad como línea base para comparar configuraciones entre sí. Ese es exactamente el espíritu con el que hay que leer todos estos números.

Y es en las comparaciones relativas donde aparece la lección práctica para un data engineer. Añadir el servidor MCP a dbt Core subió la tasa de acierto del 50 % al 54 %. Cambiar a un motor con mejor comprensión de SQL produjo la mayor subida de acierto, mientras que MCP aportó la mayor ganancia de eficiencia. Y un modelo antiguo como Claude Haiku 3 resolvió apenas el 10 % de las tareas. Traducido: el contexto y las herramientas que le das al agente pesan tanto como el modelo que elijas. Es la misma conclusión a la que llegamos al hablar de analítica conversacional, y no es casualidad.

3. Arquitectura de Agentic Analytics: qué necesita un agente para ser viable

Si los agentes fallan sobre todo planificando, y si el contexto pesa tanto como el modelo, la conclusión de diseño es clara: el trabajo no consiste en darle al agente más autonomía, sino en acotar el espacio donde puede equivocarse. Cuatro capas hacen ese trabajo.

• La capa semántica como frontera. Los agentes deben operar contra definiciones gobernadas, no contra tablas en crudo. Eso impide que infieran sus propias definiciones de métricas o que devuelvan respuestas que contradigan lo que dice el resto de la organización.
• Guardarraíles en la infraestructura. Los controles que impiden ejecutar consultas destructivas o salirse del flujo aprobado tienen que vivir a nivel de infraestructura, y no depender del comportamiento del agente. Un permiso mal concedido no se arregla con un prompt mejor escrito.
• Herramientas estrechas. Permisos mínimos por herramienta y un alcance acotado por agente. Un agente especializado que hace bien una cosa es más fiable —y muchísimo más fácil de depurar— que uno genérico con acceso a todo.
• Traza de auditoría. Cada acción debe dejar registro de qué la disparó, qué datos usó, bajo qué permisos y contra qué versión del modelo semántico. Sin eso es imposible responder a la única pregunta que importa cuando algo sale mal: «¿por qué hizo eso el agente?»

Nada de esto es opcional ni se puede añadir después. La precondición para una analítica agéntica segura es una infraestructura gobernada y definida como código sobre la que el agente se apoya, no un acceso directo a conexiones de base de datos. En un entorno multi-cliente el riesgo deja de ser de experiencia de usuario y pasa a ser de seguridad: un agente que se salta el aislamiento entre inquilinos puede exponer los datos de un cliente en la consulta de otro.

En la práctica, y aterrizando en un stack Snowflake y dbt, esto se parece bastante a lo que ya sabes hacer. El agente recibe herramientas explícitas y un rol de solo lectura, en lugar de credenciales amplias:

La idea de fondo es que el agente hereda tu gobernanza en lugar de esquivarla. Si una métrica está mal definida, el agente la usará mal con total confianza; si el rol tiene más permisos de los necesarios, tarde o temprano los usará.

4. Supervisión y observabilidad de agentes de datos

«Human in the loop» es la respuesta estándar a cualquier pregunta incómoda sobre autonomía, y funciona bien mientras el volumen es bajo. El problema aparece con la escala, y se expresa muy bien así: la supervisión humana se vuelve insuficiente cuando el umbral de aprobación está fijado en una cantidad concreta y el agente toma quinientas decisiones por hora. Nadie revisa quinientas decisiones. Se aprueban en bloque, que es otra forma de no supervisar.

Esto conecta directamente con la fatiga de alertas de la que hablábamos al tratar la observabilidad de datos: la supervisión que no se puede sostener acaba siendo teatro. La salida no es más revisión manual, sino supervisión por diseño: reservar la aprobación humana para las acciones irreversibles o de alto impacto, y sustituirla en el resto por verificación automática —tests que el propio agente debe pasar antes de que su resultado se considere válido— y por muestreo auditado en lugar de revisión total.

De ahí que la observabilidad de agentes se haya convertido en una disciplina propia, con trazas de extremo a extremo sobre herramientas, subagentes y llamadas al modelo, apoyadas en OpenTelemetry como estándar de facto. Y con una consecuencia de gestión que conviene anticipar: hay que vigilar el coste por tarea, no solo la precisión. Un agente que resuelve el 56 % de los casos a quince dólares la ejecución tiene una economía muy distinta de uno que resuelve el 50 % a dos.

5. Cómo implementar Agentic Analytics en una empresa

Los tres motivos de cancelación que señaló Gartner —costes crecientes, valor poco claro y controles insuficientes— son sorprendentemente fáciles de prevenir si se abordan al principio en lugar de tratarlos como algo que se añade luego. Un orden que funciona:

• Elige una tarea repetitiva y verificable, no una espectacular. Clasificar tickets, documentar modelos sin descripción, proponer un primer diagnóstico cuando falla un test de dbt. Si el resultado no se puede comprobar automáticamente, no es un buen primer caso.
• Pon un techo de gasto desde el día uno. Warehouse propio, límites explícitos y medición del coste por tarea resuelta. Los costes crecientes son la primera causa de muerte, y siempre se detectan tarde.
• Define el criterio de éxito antes de escribir el primer prompt. Qué porcentaje de acierto lo hace útil, medido contra qué conjunto de casos. Sin esa cifra, la discusión sobre si el piloto funciona será interminable y subjetiva.
• Construye tu propio ADE-bench en pequeño. Veinte o treinta tareas reales de tu equipo, con su solución conocida, que puedas volver a ejecutar cada vez que cambies de modelo o de configuración. Es la única forma de saber si una novedad te ayuda o solo suena bien.
• Empieza en modo propuesta, no en modo ejecución. Que el agente abra un pull request en lugar de escribir en producción. La revisión humana llega gratis a través de un proceso que tu equipo ya tiene.

Y una advertencia sobre la elección de casos: muchos usos que hoy se presentan como agénticos no requieren una implementación agéntica. Si el problema se resuelve con una consulta programada y una alerta, resuélvelo así. La autonomía tiene un coste de complejidad y de gobernanza que solo se justifica cuando la tarea exige de verdad planificar y adaptarse.

Conclusión: qué podemos esperar de Agentic Analytics

Agentic Analytics no consiste simplemente en incorporar un modelo de IA más potente al stack de datos. Los benchmarks disponibles apuntan a que la fiabilidad depende tanto del contexto, las herramientas, la capa semántica y la gobernanza como de las capacidades del propio modelo. Para los equipos de datos, el reto no es maximizar la autonomía desde el primer día, sino construir una arquitectura en la que los agentes puedan actuar dentro de límites definidos, verificables y auditables.

La analítica agéntica está en un momento incómodo pero sano: la capacidad es real y demostrable, la etiqueta está inflada, y los benchmarks sitúan el rendimiento en tareas difíciles muy por debajo de lo que sugieren las demos. Nada de eso significa que haya que esperar sentados. Significa que el trabajo útil hoy no consiste en dar más autonomía a los agentes, sino en construir el suelo sobre el que puedan pisar: definiciones gobernadas, herramientas acotadas, permisos mínimos y trazas que permitan reconstruir cada decisión.

Para un data engineer, ese es un mensaje curiosamente tranquilizador. Los datos de ADE-bench muestran que las herramientas y el contexto mueven la aguja tanto como el modelo, y ese es precisamente el terreno donde un equipo de datos puede actuar. Los proyectos que sobrevivan a 2027 no serán los que tengan el agente más capaz, sino los que trataran el valor y el control como condiciones de partida y no como algo que se resuelve más adelante.

Nota: las cifras de los tres benchmarks proceden de estudios independientes con metodologías y conjuntos de tareas distintos, por lo que no son comparables entre sí ni extrapolables a otros entornos; los resultados por modelo corresponden a las versiones evaluadas en cada estudio y quedan desactualizados con rapidez. La predicción de cancelaciones de Gartner se publicó en junio de 2025 y su ventana temporal llega a finales de 2027.

Preguntas frecuentes de Agentic Analytics

¿Qué es Agentic Analytics?
Agentic Analytics es un enfoque de análisis de datos en el que agentes de IA pueden planificar y ejecutar de forma autónoma tareas analíticas de varios pasos. Estos agentes pueden consultar datos, utilizar herramientas, evaluar resultados y modificar su estrategia sin que una persona tenga que dirigir cada acción.

¿En qué se diferencia Agentic Analytics de la analítica conversacional?
La analítica conversacional permite consultar datos mediante lenguaje natural, pero normalmente el usuario sigue dirigiendo la interacción. En Agentic Analytics, el agente recibe un objetivo y decide qué acciones, consultas y herramientas necesita utilizar para alcanzarlo.

¿Es fiable actualmente Agentic Analytics?
Depende del tipo de tarea y de la arquitectura que rodea al agente. Los benchmarks muestran resultados elevados en algunas tareas sencillas, pero una caída considerable en problemas complejos. Por eso son esenciales la capa semántica, los permisos limitados, los tests y la trazabilidad.

¿Cuál es la diferencia entre Agentic Analytics y un chatbot?

La diferencia principal está en la autonomía y en el uso de herramientas. Un chatbot recibe una pregunta y genera una respuesta. Un sistema de Agentic Analytics recibe un objetivo, decide qué pasos necesita realizar, consulta fuentes de datos y herramientas, evalúa los resultados y puede corregir su estrategia antes de entregar una respuesta.

Por tanto, añadir una interfaz conversacional a una herramienta de BI no la convierte automáticamente en un sistema agéntico.

¿Qué papel tienen dbt y la capa semántica en Agentic Analytics?
La capa semántica proporciona al agente definiciones gobernadas de métricas y conceptos de negocio. En entornos dbt, además, los agentes pueden trabajar sobre modelos, documentación y tests existentes, reduciendo el espacio en el que tienen que inferir por sí mismos qué significa cada dato.

¿Cómo empezar a implementar Agentic Analytics?
Es recomendable empezar con una tarea repetitiva, acotada y cuyo resultado pueda verificarse automáticamente. Después se deben establecer permisos mínimos, límites de coste y métricas de éxito antes de aumentar progresivamente la autonomía del agente.