Anthropic tiene razón: la analítica agéntica no es text-to-SQL. Así construimos el stack a su alrededor.

El 3 de junio de 2026, Anthropic publicó uno de los relatos de producción más honestos sobre analítica agéntica que he leído: How Anthropic enables self-service data analytics with Claude. Jose Parreño escribió un desglose excelente, centrado en algo que ojalá más equipos se tatuaran en su hoja de ruta: conectar un LLM a tu base de datos y hacerle preguntas no es una estrategia de analítica.

Parreño llama al resultado de ese atajo «analytics slop»: respuestas seguras, bien formateadas y de aspecto plausible que nadie ha verificado. Las propias cifras de Anthropic explican por qué. Sin el sistema que lo rodea, Claude no pasó del 21 % en sus evaluaciones internas de analítica. Con él, la precisión superó el 95 % en conjunto y rondó el 99 % en algunos ámbitos. El modelo no cambió. Cambió el stack a su alrededor.

Esa distinción nos importa porque es exactamente la apuesta que hicimos al construir InsightNarrator. Somos una plataforma de Voz del Cliente y analítica de CX, lo que significa que nuestro «warehouse» guarda los datos más desordenados que existen: verbatims abiertos de encuestas, reseñas, tickets de soporte, menciones en redes sociales. Texto no estructurado en el que la ambigüedad no es un caso aislado, es la materia prima. Leer el post de Anthropic fue como leer la descripción de la arquitectura a la que ya habíamos llegado desde otra dirección. Este artículo superpone su stack, capa a capa, a lo que hemos construido, con casos concretos de nuestro propio producto.

La tesis de Anthropic en 60 segundos

Anthropic identifica tres modos de fallo que explican la mayoría de las respuestas erróneas:

• Ambigüedad de conceptos y entidades. «Usuarios activos» o «ingresos» pueden corresponder a docenas de campos plausibles. El agente elige uno. A menudo se equivoca, y aun así parece profesional.
• Datos desactualizados. Los esquemas, las definiciones y las reglas de negocio cambian; el procedimiento correcto de ayer se vuelve erróneo sin hacer ruido.
• Fallo de recuperación. La respuesta correcta existe, pero el espacio de búsqueda es tan grande que el agente construye con seguridad sobre un casi acierto.

Su respuesta es un stack de cuatro capas: cimientos de datos (datasets canónicos, metadatos como producto de primera clase), fuentes de verdad (primero la capa semántica, linaje, documentos de referencia curados), skills (playbooks de procedimiento, no solo prompts) y validación (evaluaciones offline, revisión adversarial, pies de procedencia, bucles de corrección). El SQL queda aguas abajo de todo ello.

Y este es el mismo stack, tal y como existe hoy en InsightNarrator.

Capa 1. Cimientos de datos: un dataset canónico, no cuarenta candidatos

El fallo más habitual en Anthropic era que el agente asignaba un concepto a la tabla equivocada entre casi duplicados. Su solución: menos modelos lógicos, gobernados con más rigor.

Nuestro equivalente empieza en la ingesta. Llegue el feedback de una plataforma de encuestas, de un conector de reseñas o de un CSV subido, se normaliza en un único formato de dataset canónico, con estadísticas por columna y un informe automático de calidad de datos (completitud, rangos válidos, anomalías), antes de que ningún agente lo toque. Un agente que pregunta por «comentarios de detractores» no se enfrenta a cuarenta tablas plausibles, sino a un único dataset gobernado con una granularidad documentada: una fila, un feedback de cliente.

Es ingeniería de datos de la vieja escuela, y Anthropic deja claro que sigue vigente. Con texto no estructurado iríamos más lejos: si tu materia prima es el lenguaje, un dataset canónico y con la calidad verificada es lo único que se interpone entre el agente y el garbage in, garbage out a escala.

Capa 2. Fuentes de verdad: el Knowledge Pack y documentos de referencia escritos a la manera de Anthropic

Es la capa en la que el parecido resulta casi inquietante.

Los agentes de Anthropic están obligados por diseño a consultar primero una capa semántica gobernada; el SQL en bruto es el último recurso. También advierten contra dejar que el LLM invente la propia capa semántica: las definiciones de métricas generadas automáticamente «codificaban justo las ambigüedades que intentábamos eliminar». Su recomendación: que Claude redacte la documentación y que la definición sea de las personas.

El Knowledge Pack de InsightNarrator es exactamente ese contrato. Cada workspace lleva una base de conocimiento curada con entradas tipadas:

• metrics: métricas de negocio aprobadas con sus fórmulas SQL exactas
• glossary: qué significan aquí «NPS», «churn» o «cliente activo»
• rules: restricciones que el agente debe cumplir («excluir las respuestas de prueba», «el mes pasado es el último mes natural completo»)
• caveats: trampas de datos documentadas
• example queries: pares de referencia pregunta-SQL
• reference docs: documentación por dataset

Dos mecanismos reflejan directamente las pautas de Anthropic. Primero, cuando un dataset termina de procesarse, un LLM redacta automáticamente su documento de referencia, con una estructura fija de Business Context, Entity Grain, Standard Hygiene Filter, Dimensions, Key Columns, Gotchas. Llegamos a esas secciones por nuestra cuenta; el post de Anthropic usa casi al pie de la letra el mismo esqueleto. Segundo, y es en lo que Anthropic insiste, el borrador queda fuera del contexto del agente hasta que una persona lo aprueba. Las entradas viven en un ciclo draft → approved / needs_review. El modelo escribe la documentación; el significado es de la persona.

Y la defensa frente a la desactualización: cuando cambia el esquema de un dataset, su documento de referencia se regenera y se marca como needs_review. El documento puede desviarse durante un día, pero no puede quedarse mal sin que nadie lo vea; siempre hay un punto de control visible y en manos de una persona.

Capa 3. Skills: tool packs y playbooks, no prompts heroicos

El mayor salto de precisión de Anthropic, del 21 % a más del 95 %, vino de las skills: conocimiento de procedimiento sobre cómo trabajar, no solo sobre qué datos existen.

Nuestro agente, Scoty, sigue el mismo principio. No recibe una conexión en bruto a la base de datos y una plegaria. Recibe tool packs dedicados para las operaciones habituales (exploración de datasets, resultados de análisis, temas y riesgos) que devuelven resultados estructurados y gobernados. El SQL libre existe, pero como último recurso desaconsejado de forma explícita: solo lectura, limitado a una lista de tablas permitidas y usado solo cuando ninguna herramienta dedicada cubre la pregunta. Es el patrón de Anthropic «primero la capa semántica, SQL en bruto como último recurso», impuesto en la descripción de las herramientas y no por convención.

Para el trabajo más profundo hay un pipeline multiagente: nueve agentes especializados (Data, Domain, Sentiment, Themes, Trends, Segments, Risk, Synthesis y un agente final de QA), cada uno con un presupuesto de iteraciones limitado, que se van pasando los hallazgos. Los más de 30 tipos de análisis predefinidos (análisis de drivers, señales de churn, extracción de temas, etc.) son, en el vocabulario de Anthropic, playbooks de analista codificados: el procedimiento de un analista sénior de CX, hecho reproducible.

Capa 4. Validación: revisión adversarial y un pie de procedencia en cada respuesta

La validación online de Anthropic se apoya en dos ideas que hemos implementado con el mismo espíritu.

Revisión adversarial. Antes de entregar una respuesta, una pasada de revisión opcional cuestiona el SQL del borrador y sus supuestos: la misma disciplina de «no autocertificarse» que el subagente obligatorio sql-reviewer de Anthropic, que les dio un +6 % de precisión a un coste real de latencia. Nosotros lo hicimos activable, para que los usuarios elijan en cada pregunta si lo que está en juego justifica la pasada extra. Y el agente de QA al final del pipeline cumple el mismo papel en los análisis largos: los hallazgos se cuestionan antes de guardarse.

Pie de procedencia. Cada respuesta de Scoty lleva un registro de procedencia guardado: de qué nivel de fuente sale (knowledge_pack o raw_exploration), una valoración de confianza derivada de ese nivel, el SQL realmente ejecutado con el número de filas y los tiempos, y lo recientes que son los datos subyacentes. El enfoque de Anthropic es exactamente el correcto: no hace que la respuesta sea más correcta, le dice a quien la lee cuánto puede fiarse de ella. Una respuesta «raw exploration, actualidad desconocida» es una señal para verificarla antes de enviarla a la dirección. En un contexto de CX, donde una cifra errónea puede decidir un presupuesto, ese pie no es decoración.

Tres casos concretos

Caso 1. ABSA sobre verbatims de NPS: significado gobernado para texto no estructurado. Un equipo de CX ejecuta un análisis de sentimiento basado en aspectos sobre 40.000 verbatims de encuestas. El modo de fallo que Anthropic llama ambigüedad de conceptos tiene aquí un primo más traicionero: un LLM sin restricciones inventa categorías de aspectos, plausibles, incoherentes y distintas en cada ejecución, de modo que comparar una oleada con otra deja de tener sentido. Nuestra respuesta es la taxonomía curada: el modelo solo puede asignar categorías y etiquetas que existen en la taxonomía aprobada del workspace, nunca inventadas libremente. La taxonomía es la capa semántica del texto. Las definiciones son de las personas; el modelo encaja el lenguaje desordenado en un significado gobernado. Cuando llega la oleada 2, «Precio» sigue significando «Precio».

Caso 2. C-Risk sobre tickets de soporte: encontrar dónde nace el churn. Una organización de soporte aplica el scoring de Complaint-Risk a las conversaciones de los tickets. Los factores de riesgo salen de la taxonomía gobernada, cruzados con el sentimiento por categoría y subcategoría, así que en lugar de un genérico «sentimiento negativo un 12 % más alto», el equipo ve que Facturación → Retraso en el reembolso es la celda concreta que genera este mes las reclamaciones de riesgo grave, con niveles de gravedad calculados a partir de los datos, no de impresiones. El resultado alimenta los paneles y, como cada resultado de análisis acaba en la Biblioteca compartida, se convierte en una evidencia que el siguiente análisis puede citar, y no en una captura en la presentación de alguien.

Caso 3. Scoty responde a «¿qué está detrás de los detractores este trimestre?». Alguien de negocio le hace a Scoty el tipo de pregunta que suele producir analytics slop. Scoty consulta primero el Knowledge Pack: el documento de referencia aprobado del dataset de NPS, la definición aprobada de «detractor», la regla del workspace sobre qué significa «este trimestre». Solo entonces consulta los datos. La respuesta vuelve marcada como knowledge_pack, con confianza alta, con el SQL exacto y la actualidad de los datos adjuntos. Si la base de conocimiento no cubre la pregunta, recurre a la raw exploration, y el pie de procedencia lo dice; en el fondo le dice a quien lee: verifícame antes de repetirme. Esa honestidad es la clave.

Dónde somos honestos sobre lo que falta

El post de Anthropic es también una lista útil de lo que no hemos terminado. Un harness formal de evaluación offline (pares de pregunta y respuesta anclados a la ground truth, ejecutados en CI frente a los cambios en las skills) está en nuestra hoja de ruta, no en producción. La recogida automática de correcciones (convertir «no, esa es la tabla equivocada» en un parche de la base de conocimiento) es hoy un flujo de trabajo humano, no un agente programado. Preferimos decirlo claramente antes que presumir de un 95 % terminado. La propia historia de deriva de Anthropic, un 95 % que cayó al 65 % en un mes sin mantenimiento, es el mejor argumento de que estos bucles no son opcionales, y está marcando nuestra hoja de ruta igual que marcó la suya.

La conclusión

La frase más útil del post de Anthropic es la más sencilla: el text-to-SQL es una capacidad de ejecución, no el producto. El producto es el sistema que reduce la ambigüedad a un significado gobernado antes de que se escriba la consulta, hace que la respuesta correcta se pueda encontrar y avisa cuando una de las dos se ha quedado desactualizada.

Para los datos de Voz del Cliente, ese sistema no es un extra. Es la diferencia entre una IA que te dice lo que dijeron tus clientes y otra que te cuenta una historia que casualmente suena bien. Construimos InsightNarrator como la primera.

Si llevas VoC o CX y quieres ver cómo es la analítica agéntica gobernada con tus propios datos de feedback, prueba InsightNarrator.

Referencias

• How Anthropic enables self-service data analytics with Claude, Anthropic, 3 de junio de 2026
• Jose Parreño, Anthropic is telling you that Agentic Analytics is not just text-to-SQL, Medium
• Building effective agents, Anthropic

Publicado por primera vez en LinkedIn el 4 de agosto de 2026.