Natural language → SQL (self-serve analytics)

Qué hace la automatización

Natural language → SQL — agente de IA que traduce preguntas en lenguaje natural a consultas SQL en el data warehouse. En lugar de un ticket al equipo de analítica y dos días de espera, el empleado obtiene la respuesta en segundos.

Tareas principales

1. Traduce la pregunta a SQL. «¿Cuántos clientes de Alemania compraron más de tres veces en el último trimestre?» se convierte en una consulta SQL válida con JOIN's y agregaciones.
2. Ejecuta la consulta en el almacén. El agente está conectado a Snowflake, BigQuery o Redshift mediante una service account y lee únicamente los esquemas autorizados.
3. Devuelve el resultado en un formato conveniente. Una tabla, un gráfico o un mensaje en Slack con una explicación de qué fue exactamente lo que se calculó.
4. Recuerda el contexto del equipo. El glosario de negocio («cliente activo», «ingresos netos», «cohorte de lanzamiento») se almacena en la capa semántica y se aplica en todas las consultas.
5. Explica el SQL antes de la ejecución. El usuario ve la consulta generada y puede corregirla si algo no se ha entendido correctamente.

Qué NO hace

• No inventa nuevas métricas si el glosario de negocio no está definido.
• No repara la mala calidad de los datos: si el warehouse contiene basura, el agente devolverá la misma basura más rápido.
• No reemplaza al analista en tareas que requieren una hipótesis de múltiples pasos o un procesamiento estadístico complejo.
• No escribe consultas a ciegas sin acceso al esquema — sin onboarding la precisión cae por debajo de lo aceptable.
• No toma decisiones: muestra datos, no recomendaciones de acción.

Configuraciones típicas

Solo / equipo de 1-5 personas. Se conecta una fuente (PostgreSQL o Google BigQuery), un glosario de 10-20 métricas, interfaz mediante un bot de Slack o un chat web. El caso principal es que el fundador hace preguntas de ventas y análisis de cohortes sin molestar al único analista. La configuración tarda 3-5 días hábiles. Es suficiente con un especialista en configuración y acceso a los datos. El efecto aparece de inmediato: 3-5 horas a la semana que antes se destinaban a exportaciones manuales vuelven al trabajo productivo.

SMB / equipo de 6-30 personas. Dos o tres fuentes: CRM (HubSpot o Salesforce), analítica de producto (Amplitude o PostHog), finanzas. Capa semántica con 50-100 métricas, row-level security por roles (el equipo de ventas ve su pipeline, marketing — las campañas, finanzas — los ingresos). Conexión a BI (Metabase, Looker) o una UI independiente. Configuración — 1-2 semanas, incluyendo formación del equipo. Ahorra 20+ horas/mes al equipo de datos y cubre la mayor parte de las solicitudes ad-hoc.

Enterprise / 30+ personas. Warehouse central (Snowflake, BigQuery), integración con la identidad corporativa (SSO, SAML), audit log completo de cada consulta, approval workflow para consultas a campos sensibles. El glosario de métricas es parte del data catalog (Alation, Collibra). Configuración — 4-8 semanas: piloto en un departamento, luego despliegue. Requiere un data engineer dedicado, security review y un plan de trabajo con los stakeholders.

Quién lo necesita

• A fundadores y gerentes cuyas preguntas sobre datos surgen más rápido de lo que los analistas logran resolverlas.
• A equipos donde el conocimiento sobre los datos reside en la cabeza de dos o tres personas y se pierde cuando se van de vacaciones.
• A gerentes de ventas y soporte que necesitan una exportación aquí y ahora para una conversación con el cliente.
• A equipos de producto que prueban hipótesis: una respuesta rápida a «¿y si...?» es más importante que una consulta perfecta.

Cómo funciona

La automatización se construye en tres capas: conexión a datos, capa semántica e interfaz de consultas. El agente de IA basado en un modelo de lenguaje o Snowflake Cortex procesa la pregunta apoyándose en los metadatos del esquema y el glosario.

Stack tecnológico

1. Conexión al almacén. Service account con acceso read-only a los esquemas seleccionados. Se admiten Snowflake, BigQuery, Redshift, Postgres, ClickHouse.
2. Indexación del esquema. El agente lee DDL, comentarios de tablas y columnas, foreign keys. Esto se convierte en un índice vectorial disponible en cada consulta.
3. Capa semántica. YAML o UI donde usted describe las métricas: «MRR = suma de active_subscriptions.monthly_price», «cliente activo = compró en los últimos 30 días». Elimina la ambigüedad.
4. Motor LLM.Modelo de IA para preguntas complejas, Snowflake Cortex para la carga dentro de Snowflake. La elección depende del compliance y el presupuesto.
5. Ejecución de la consulta. El SQL se ejecuta en el warehouse, el resultado se formatea en una tabla, gráfico o explicación en texto.
6. Interfaz. Bot de Slack, chat web, plugin para Metabase/Looker o UI interno.

Escenario paso a paso

1. El empleado escribe una pregunta en Slack: «¿Cuál es la conversión a trial del landing /ai-audit en el último mes?»
2. El agente selecciona las tablas relevantes (pageviews, signups), encuentra la definición de conversión en el glosario.
3. Genera el SQL, lo muestra al usuario junto con la explicación: «Calculo la relación entre los suscritos al trial y los visitantes únicos de la página /ai-audit en 30 días».
4. Tras la confirmación, ejecuta la consulta, devuelve el resultado y el enlace al gráfico.
5. Registra la pregunta, el SQL y el resultado en el audit trail.

Enfoques alternativos

Natural language → SQL no es la única forma de obtener una respuesta a partir de los datos. A continuación, una comparación cualitativa de tres enfoques.

No-code BI sigue siendo una opción sólida para los informes estándar que todos consultan cada día. La automatización de IA gana donde hay muchas preguntas, son no estándar y las formulan personas sin conocimientos de SQL. La consulta manual al analista es necesaria para tareas con un alto coste de error: informes financieros, consultas regulatorias, investigaciones deep-dive.

La práctica muestra que los tres enfoques coexisten. Distribución típica: BI cubre la mayor parte de las preguntas estándar, el agente de IA elimina la carga ad-hoc, los analistas se centran en las tareas complejas y críticas.

Seguridad y compliance

El acceso a los datos es una parte sensible. Grow2.ai configura por defecto varios niveles de protección: service account con permisos read únicamente sobre los esquemas explícitamente listados, row-level security por roles (ventas no ve datos de HR), audit log de cada consulta con user_id, timestamp y texto SQL. Para enterprise se añade un approval workflow para consultas a columnas sensibles y SSO a través del identity provider corporativo.

Para el compliance con GDPR y SOC 2 es importante que el proveedor de LLM no utilice sus consultas para entrenamiento. Snowflake Cortex y LLM a través de AWS Bedrock ofrecen estas garantías en los planes corporativos. Si los datos no pueden enviarse a la nube, existe la opción self-hosted, pero la precisión en consultas complejas disminuye.

Qué se necesita antes del inicio

La automatización funciona mejor cuanto más limpios son los datos y más clara es la lógica de negocio. Sin preparación, el agente generará consultas formalmente válidas pero sin sentido.

Requisitos obligatorios

1. Un único data warehouse o data lake. Si los datos están dispersos entre CRM, hojas de Google Sheets y archivos CSV, primero se necesita un proceso ELT (Fivetran, Airbyte, dbt).
2. Esquema con comentarios. Cada tabla y columna clave debe tener una descripción clara. Sin esto, el agente adivina el significado y comete errores.
3. Glosario de negocio. Documento con definiciones de las métricas clave: MRR, churn, cliente activo, cohorte. 20-50 métricas para SMB, 100+ para enterprise.
4. Acceso e identity. Service account para el agente, roles para los usuarios, row-level security si es necesario.
5. Conjunto piloto de preguntas. 30-50 preguntas típicas de los futuros usuarios. Con ellas se prueba la precisión antes del despliegue a todo el equipo.

Equipo

• Data engineer o analista — configura la capa semántica y el glosario. 10-20 horas en la primera semana, luego soporte bajo demanda.
• Product o department owner — formula las preguntas piloto, valida las respuestas, recoge el feedback del equipo.
• Security / compliance — si el sector está regulado (finanzas, medicina), participa en la revisión de accesos.

Posibles escollos

• Lanzamiento sin capa semántica. Los equipos intentan ahorrar una semana y conectan el warehouse. La precisión cae al 40-50%, la confianza en el sistema se derrumba y el proyecto se cierra. El glosario no es una opción, sino la base.
• Ignorar la calidad de los datos. El agente responderá rápido, pero si la tabla tiene duplicados y vacíos, la respuesta será incorrecta. Primero data quality, luego AI encima.
• Acceso demasiado amplio. Los usuarios ven lo que no deberían: indicadores financieros, datos personales de los clientes. Row-level security debe configurarse antes de la primera consulta, no después de un incidente.
• Ausencia de human review en preguntas críticas. Los ingresos trimestrales para el consejo de administración o los datos para un inversor no deben tomarse de un chat de AI sin revisión. Defina una lista de «zonas rojas» donde el agente ayuda pero no finaliza.
• Sin métricas de éxito. Sin medir la precisión y el ahorro de tiempo, el proyecto no puede justificarse ni mejorarse. Desde el primer día registre preguntas, respuestas, tiempos y la valoración del usuario.