Amazon presenta una arquitectura de analítica agéntica basada en SageMaker, Athena y Quick

AWS ha presentado una arquitectura en la que el asistente agéntico Amazon Quick convierte la analítica sobre un lakehouse en self-service para los equipos de negocio. El esquema combina S3, SageMaker, AWS Glue y Athena para que el usuario pueda hacer preguntas a los datos en lenguaje natural y no mediante SQL.

Cómo funciona el esquema

En su demostración, AWS utiliza el conjunto TPC-H y construye sobre él un lakehouse de varias capas. Los datos se almacenan en Amazon S3, los metadatos se gestionan con AWS Glue y Amazon Athena actúa como capa SQL única para consultar distintos formatos de almacenamiento. El ejemplo emplea a la vez tablas CSV externas convencionales, tablas Iceberg en Parquet y S3 Tables gestionadas.

Este enfoque no busca la elegancia arquitectónica: la compañía muestra que una misma pregunta de negocio puede dirigirse a fuentes heterogéneas sin montar a mano data marts para cada escenario.

Sobre esto, Amazon Quick construye la capa de usuario:

• datasets en SPICE para respuestas y dashboards rápidos
• Topic como capa semántica para términos de negocio
• un dashboard con consultas en lenguaje natural
• una Knowledge Base basada en documentación y especificaciones
• Quick Space y un chat agent como interfaz única

Qué hace el agente

La pieza clave no es solo un chat sobre tablas, sino la combinación de Topic, Space y Knowledge Base. Topic funciona como capa semántica: vincula formulaciones habituales como ingresos, segmento de clientes o el trimestre pasado con campos, fechas y filtros concretos del dataset.

Dentro de Quick, los datos se cargan primero en SPICE, por lo que los dashboards y las respuestas a preguntas típicas deberían funcionar con rapidez incluso cuando crezca el lakehouse de origen. Para conjuntos grandes, AWS aconseja unir previamente las tablas en Athena mediante Custom SQL y solo después pasar el resultado plano a Quick.

Para que el agente responda con algo más que cifras, AWS añade contexto no estructurado a las tablas estructuradas. En la Knowledge Base se carga mediante un web crawler la especificación de TPC-H en PDF, y en un Quick Space se reúnen el Topic, la base de conocimiento y un dashboard listo. Después, el chat agent dispone de un único entorno de conocimiento gestionado: puede responder preguntas sobre ingresos y estados de pedidos, y además extraer de la documentación definiciones de campos, la lógica de negocio de las consultas y el significado de las consultas de benchmark. La idea es sencilla: una interfaz en lugar de un conjunto de pantallas de BI y páginas wiki dispersas.

Dónde está el efecto

Para el negocio, la principal ventaja es que la analítica deja de ser una cola de espera para los especialistas en SQL y el equipo de BI. El usuario puede preguntar en lenguaje corriente por los ingresos por segmento, la dinámica de pedidos, los descuentos o los productos, y obtener una respuesta vinculada a datos y visualizaciones.

AWS subraya por separado que este modelo no está pensado solo para el modo demo: el acceso se limita por roles y los límites de visibilidad se heredan de IAM y Lake Formation. Es decir, el empleado ve únicamente las tablas, columnas y fuentes para las que ya tiene permisos.

Pero la publicación también muestra el precio de esta comodidad. Antes del lanzamiento hay que configurar el catálogo de Glue, los permisos en Lake Formation, la conexión con Athena, la carga en SPICE, el Topic, el Space, el dashboard y un agente aparte. Es decir, AWS no promete magia lista para usar: la analítica agéntica aparece donde ya existen un lakehouse, modelos de acceso y una semántica de datos cuidada. A cambio, la compañía obtiene un camino más corto de la pregunta a la respuesta y menos trabajo manual para los analistas.

Qué significa

AWS impulsa en la práctica la siguiente etapa del BI: no un nuevo dashboard, sino una capa de interfaz agéntica sobre un lakehouse existente. Si el enfoque se consolida, los usuarios de negocio recurrirán cada vez más a los datos mediante el diálogo, y los equipos de datos se centrarán no en extracciones puntuales, sino en la calidad de los modelos, los permisos y el contexto.