Gerencia
Copiloto de indicadores
Responde preguntas operacionales sobre una capa semántica gobernada, con SQL trazable: cada cifra se puede defender hasta la fila de origen.
En resumen
Una interfaz en lenguaje natural para analítica operacional, anclada en la capa semántica headless. Los usuarios hacen preguntas en lenguaje cotidiano; el agente las resuelve contra definiciones gobernadas de métricas y dimensiones, genera el SQL, lo ejecuta en el data warehouse y devuelve la respuesta junto con el SQL, las filas que obtuvo y las definiciones de métricas que usó. Sin cifras sin respaldo, sin dashboards que se contradicen entre herramientas y sin definiciones paralelas de ingresos.
La mayoría de las organizaciones tiene dashboards de sobra y pocas respuestas confiables. Una misma métrica —ingreso neto, churn, margen bruto— se calcula de tres formas distintas según la herramienta que abra cada persona. El BI de autoservicio amplió la superficie, pero no hizo más defendibles las respuestas.
El copiloto de KPI conecta una interfaz conversacional a una única capa semántica gobernada. Cuando alguien pregunta «¿cuál fue el ingreso neto por segmento el último trimestre?», el agente no inventa la fórmula: resuelve «ingreso neto», «segmento» y «último trimestre» contra las definiciones canónicas, genera el SQL, lo ejecuta en el data warehouse y devuelve la respuesta con el SQL y las definiciones de métricas a la vista.
El agente nunca responde preguntas operacionales desde la memoria del modelo. Cada cifra remite a la definición de métrica que la produjo, al SQL que se ejecutó y a las filas de origen que devolvió. Si la métrica cambia, la respuesta cambia con ella, por diseño.
Qué resuelve este caso
Quien necesita una cifra hoy tiene tres opciones: abrir un dashboard que quizás no tiene el corte correcto, pedírsela al equipo de datos y esperar, o pegar números en ChatGPT y confiar en la suerte. La primera es rígida, la segunda es lenta y la tercera es riesgosa: los chatbots genéricos sobre datos se equivocan con total seguridad, porque no saben cómo define el negocio sus métricas.
Lo que la operación necesita es una interfaz conversacional que *solo* pueda responder a través de la capa semántica gobernada. Las definiciones de métricas viven en un solo lugar, el agente consulta a través de ellas y cada respuesta es reproducible porque el SQL queda a la vista. Los dashboards que lee una persona y las respuestas que entrega un agente salen de la misma fuente: esa es la definición operacional de una única fuente de verdad.
Para quién es
- Equipos de operaciones, finanzas e ingresos que hoy dependen de planillas exportadas desde herramientas de BI
- Organizaciones que están consolidando una única fuente de verdad para sus métricas en dashboards, productos y agentes
- Equipos de empresas medianas y grandes con un data warehouse (Snowflake, BigQuery, Databricks, Postgres) y definiciones de métricas inconsistentes
Cómo funciona
Este patrón de referencia opera en cinco pasos. Cuando el sistema lo permite, las consultas usan la identidad delegada del usuario y su contexto de seguridad a nivel de fila; en caso contrario, se configura una cuenta de servicio de solo lectura con privilegios mínimos para el alcance de datos requerido.
- AgenteResolución de la intención contra la capa semánticaEl agente clasifica la pregunta y resuelve las entidades mencionadas (métricas, dimensiones, granularidad temporal, filtros) contra la capa semántica registrada. Si una resolución es ambigua («¿qué definición de segmento?»), el agente pide una aclaración puntual en vez de adivinar.
- AgenteGeneración y validación del SQLEl agente genera el SQL a través del compilador de la capa semántica, no a mano alzada. Antes de cualquier ejecución, el SQL se valida contra el esquema del data warehouse y el contexto de seguridad a nivel de fila del usuario. Los planes inválidos se rechazan, no se parchan.
- DatosEjecución en el data warehouse y respuesta con procedenciaLa consulta corre en el data warehouse con un rol de solo lectura por cliente. La respuesta incluye el SQL, las definiciones de métricas usadas, la cantidad de filas y el costo de ejecución. El usuario puede bajar a las filas de origen desde cualquier celda.
- PersonaInspección o escalamiento por parte del usuarioCuando una cifra no coincide con un dashboard, se muestra la diferencia: qué definición de métrica usó el dashboard y cuál usó el agente. El camino de escalamiento es corregir la definición de la métrica una sola vez, no parchar una de las superficies.
- AutomatizaciónRegistro de la decisión para auditoría y retroalimentaciónCada pregunta, resolución, SQL, hash del resultado y acción del usuario queda registrada. La señal agregada (qué métricas se consultan más, qué resoluciones requieren aclaración) alimenta la mantención de la capa semántica.
Sistemas que conecta
- Cube / dbt Metrics / MetricFlowCapa semántica headless (definiciones de métricas gobernadas)
- Snowflake · BigQuery · Databricks · PostgresData warehouse (motor de ejecución)
- Slack · Microsoft TeamsPunto de entrada conversacional
- Looker · Tableau · MetabaseDashboards (lectura para contraste)
- Registro de auditoría de XophiaReproducibilidad y gobierno
Metas de referencia
| Indicador | Antes | Meta |
|---|---|---|
| Tasa de respuestas con respaldoControl sobre el registro de auditoría: cada respuesta numérica debe referenciar al menos una definición de métrica y una sentencia SQL ejecutada; la política bloquea las respuestas sin respaldo. | Configuraciones genéricas de LLM sobre data warehouse: ~50 % a 70 % de respuestas respaldadas por SQL trazable | 100 % de las respuestas se despliegan en las definiciones de métricas y el SQL que las produjeron |
| Concordancia entre superficiesProceso diario de comparación sobre un conjunto fijo de métricas canónicas: respuesta del agente frente a la consulta del dashboard y a la verdad de la capa semántica. Toda desviación se marca y se revisa. | Una misma métrica reportada con diferencias de 5 % a 15 % entre dashboards y exportaciones | ≤ 0,5 % de desviación entre las respuestas del agente y el dashboard canónico para el mismo corte |
| Tiempo de respuesta a preguntas operacionales puntualesDesde que se envía la pregunta en Slack o Teams hasta que se muestra la respuesta, medido en la pasarela del agente. | Horas o días cuando pasan por el equipo de datos | ≤ 30 segundos para preguntas cubiertas por la capa semántica; aclaración o escalamiento en los demás casos |
| Cobertura de la capa semánticaPorcentaje de las preguntas que recibe el agente que se pueden responder por completo sin escalamiento. Los escalamientos son el insumo de la hoja de ruta de la capa semántica. | La fracción de preguntas que hoy se puede responder, sea cual sea | Creciente mes a mes, impulsada por la telemetría de escalamientos |
Valores de un escenario ilustrativo, no resultados de clientes.
Traza de ejecución ilustrativa
Un ejemplo sintético de cómo podría quedar registrada una consulta de BI. Nombres, identificadores, cifras, costos y resultados son ficticios; la secuencia es ilustrativa y no corresponde a un resultado de cliente.
Una líder de ingresos pregunta en Slack: «¿Cuál fue el ingreso neto por segmento de clientes el último trimestre, en CLP?». El agente resolvió la pregunta contra la capa semántica, ejecutó una consulta y devolvió la respuesta con su procedencia.
| Herramienta | Entrada | Salida |
|---|---|---|
| agent.classify_intent | question='¿Cuál fue el ingreso neto por segmento de clientes el último trimestre, en CLP?' | intent=metric_query, metrics=['net_revenue'], dimensions=['customer_segment'], grain=quarter, period='last_quarter', currency=CLP |
| semantic.resolve | metrics=['net_revenue'], dimensions=['customer_segment'] | net_revenue → defs.revenue.net_revenue@v3 (gross_revenue − refunds − credit_notes); customer_segment → defs.customer.segment_v2 |
| semantic.compile_sql | metric=net_revenue, dim=customer_segment, period=2026-Q1, currency=CLP, rls_user=USR-117 | Consulta compilada: SELECT customer_segment, SUM(net_revenue) FROM analytics.fct_revenue WHERE quarter='2026-Q1' GROUP BY customer_segment — tipos validados, con RLS aplicada. |
| warehouse.run_query | engine=Snowflake, role=xophia_read_USR-117, query_hash=qh-7c2a | 4 filas devueltas (mid_market: CLP 1.242 MM; enterprise: CLP 893 MM; smb: CLP 318 MM; channel: CLP 96 MM). Costo de ejecución: 0,04 créditos; latencia: 1,8 s. |
| console.render_answer | result=qh-7c2a, definitions=['net_revenue@v3','segment_v2'] | Respuesta mostrada con tabla, panel de definiciones y opción «ver SQL». Bajada a filas de origen habilitada en cada celda. |
Respuesta entregada al usuario en 4,1 s de punta a punta, con un costo del agente de USD 0,012. Fila de auditoría Q-2026-05-06-USR-117-qh-7c2a registrada con la cadena completa (intención, resoluciones, SQL, hash del resultado). Contrastada cada noche con el dashboard canónico, con 0 % de desviación.
¿Te sirve este módulo?
En 20 minutos revisamos cómo se vería sobre tus sistemas.