Analítica conversacional: qué es, cómo funciona y cuánto cuesta

La analítica conversacional es la capacidad de preguntar por los datos de una empresa en español y recibir una respuesta calculada sobre sus bases de datos reales. Un agente traduce la pregunta a SQL, la ejecuta en solo lectura contra el ERP, el CRM o el data warehouse y devuelve la cifra en el chat, sin migrar datos.

Esta guía explica cómo funciona por dentro, qué fuentes puede consultar, qué hace falta antes de implementarla, cuánto cuesta y —tal vez lo más útil— en qué casos no es la herramienta adecuada. Está escrita para quien tiene que decidir si esto le sirve a su empresa, no para quien ya decidió.

¿Qué es la analítica conversacional?

La analítica conversacional es la práctica de consultar los datos de una empresa en lenguaje natural, como se le escribiría a un analista, y recibir una respuesta calculada sobre las fuentes reales de la organización. En inglés se la conoce como conversational analytics.

Las dos mitades de esa definición importan por igual. La primera —preguntar en español— es la que suele llamar la atención. La segunda —calculada sobre las bases de datos reales— es la que separa esta categoría de lo que hace un asistente de propósito general.

Un modelo de lenguaje como los que están detrás de ChatGPT o Claude responde a partir de lo que aprendió durante su entrenamiento y de lo que se le incluya en el mensaje. Si se le pregunta cuánto vendió la compañía el mes pasado, no tiene forma de saberlo, y en el peor de los casos producirá una cifra plausible y falsa. La analítica conversacional invierte el rol del modelo: no le pide que responda, le pide que construya la consulta. La cifra sale de la base de datos; el modelo solo tradujo la pregunta y redactó el resultado.

Esa distinción es la que vuelve utilizable la categoría en una empresa, donde una cifra equivocada no es una curiosidad sino una decisión mal tomada.

¿Cómo funciona la analítica conversacional por dentro?

Entre la pregunta y la respuesta hay cinco etapas, y cada una es un punto donde un proyecto puede salir bien o mal. En orden:

1. Interpretación: qué métrica, sobre qué entidad, en qué período y contra qué comparación.
2. Permisos: qué puede ver la persona que preguntó, antes de tocar un dato.
3. Traducción a SQL: la pregunta interpretada se convierte en una consulta sobre el esquema real.
4. Ejecución: la consulta corre contra la fuente, en modo de solo lectura.
5. Redacción: el resultado vuelve como una respuesta en español, con su tabla o su gráfico.

1. Interpretación de la pregunta

El sistema recibe una frase —«¿cómo viene la cartera vencida del canal mayorista este mes contra el anterior?»— y tiene que determinar qué se está pidiendo. Es menos trivial de lo que parece, porque las preguntas reales son ambiguas. «Este mes» puede significar el mes calendario o los últimos treinta días. «Cartera vencida» puede o no incluir la cartera en gestión judicial. Un sistema que adivina en silencio produce respuestas equivocadas con apariencia de certeza; uno bien construido resuelve la ambigüedad contra las definiciones acordadas de la empresa y, cuando no puede, repregunta.

2. Resolución de permisos

Antes de tocar un dato, el sistema determina qué puede ver la persona que preguntó. No es un filtro posterior sobre el resultado: es una restricción que entra en la construcción de la consulta.

La diferencia es sustancial. Un filtro posterior implica que el sistema sí leyó la información restringida y después decidió no mostrarla. Restringir en la construcción implica que la consulta ejecutada nunca incluyó esos datos. Alguien de compras que pregunte por nómina no recibe una negativa cortés: el sistema nunca leyó esa tabla para esa persona. En Igniten los permisos se combinan en dos capas que se suman: lo que el usuario de base de datos tiene permitido leer, y qué tablas y columnas ve cada rol dentro de la plataforma.

3. Traducción a SQL

Aquí entra el text-to-SQL: la traducción de la pregunta interpretada a una consulta ejecutable sobre el esquema de la empresa. Es el punto donde más proyectos fracasan, y casi nunca por el modelo. Fracasan porque el esquema de un ERP en producción no es autoexplicativo: tablas con nombres heredados, estados codificados como números, tres campos de fecha de los cuales solo uno sirve para el cálculo que interesa.

La solución no es un modelo mejor sino una capa semántica: una descripción explícita de qué significa cada tabla y cada campo, cómo se calcula cada métrica del negocio y qué reglas aplican. Construirla es la parte del trabajo que lleva tiempo, y es también la que queda como activo de la empresa aunque cambie la tecnología. El detalle está en text-to-SQL empresarial: qué resuelve y qué no.

4. Ejecución en modo de solo lectura

La consulta corre contra la fuente —la base transaccional, una réplica de lectura o un data warehouse si existe— con un usuario de solo lectura creado para ese fin. En Igniten, además, cada consulta generada se verifica como de lectura antes de ejecutarse, y tiene un tope de tiempo y de filas para no cargar la base de producción: dos candados, no uno.

No hay migración de por medio. Los datos se consultan donde ya viven, lo que evita el proyecto de integración que suele preceder a la primera respuesta útil. Cuando el volumen de consultas empieza a competir con la operación, se mueve la lectura a una réplica, pero esa es una decisión de rendimiento posterior, no un requisito de arranque. El procedimiento completo está en cómo conectar el ERP a un agente de IA sin exponer datos sensibles.

5. Redacción del resultado

El resultado vuelve como una respuesta en español, con la cifra, la comparación pedida y el contexto mínimo para interpretarla, acompañada de la tabla y el gráfico cuando el análisis lo amerita. El modelo vuelve a intervenir, pero solo para redactar sobre números que ya están calculados.

En la plataforma de Igniten, el recorrido completo tarda entre 10 y 30 segundos, incluidas las preguntas que cruzan varias fuentes, y antes de responder un segundo modelo verifica cada número contra el dato real. La cifra importa menos por la velocidad en sí que por lo que habilita: cuando preguntar cuesta lo que cuesta escribir un mensaje, la gente pregunta cosas que antes no valía la pena averiguar.

¿Qué fuentes de datos puede consultar?

Una plataforma de analítica conversacional puede consultar cualquier fuente a la que tenga acceso de lectura, y la lista práctica se ordena en tres grupos:

• Bases de datos. Es donde vive el ERP de casi cualquier empresa mediana. Igniten se conecta a los principales motores, entre ellos SQL Server, PostgreSQL, Oracle, MySQL y Snowflake.
• CRM. El estado real del embudo comercial, leído en el momento, por ejemplo en HubSpot.
• Herramientas de trabajo diario. Correo, documentos, agenda y planillas de Google Workspace o Microsoft 365.

Los agentes de Igniten no se limitan a las bases de datos: trabajan sobre el ERP y las bases de datos, el CRM, las plataformas de venta como Mercado Libre, Tiendanube o Shopify, los sistemas de gestión y facturación, el correo, el calendario, los chats internos, los documentos y las reuniones. Lo que vuelve útil esa amplitud es el cruce: una misma respuesta puede juntar la venta del ERP con el estado de la cuenta en el CRM y lo que se acordó en la última reunión, algo que ningún tablero junta.

La lista completa, con los permisos exactos que pide cada conexión, está en integraciones. Si la base de datos vive dentro de la red de la empresa, la conexión la abre un conector que el cliente instala y que sale hacia afuera: no hay que abrir puertos en el cortafuegos.

¿Por qué la interfaz es WhatsApp, Teams, Google Chat o Slack?

La interfaz es un chat que la empresa ya usa porque el obstáculo principal de un proyecto de datos no es técnico sino de adopción.

Se construyen tableros, se capacita al equipo y a los tres meses el uso es marginal. No porque el tablero esté mal hecho, sino porque abrirlo requiere una decisión deliberada —entrar a una herramienta que no se usa para otra cosa— y esa fricción, multiplicada por semanas, gana.

Una interfaz conversacional dentro de WhatsApp, Microsoft Teams, Google Chat o Slack no tiene ese costo de entrada: la persona ya está ahí. En Teams y en Google Chat la identidad se resuelve contra el directorio corporativo, así que no hay un segundo padrón de usuarios que mantener. En WhatsApp la conversación corre sobre la WhatsApp Business API, no sobre una cuenta personal, y solo responde a las personas que el administrador habilitó con su teléfono. En cualquiera de los canales se puede preguntar por escrito o con una nota de voz.

En América Latina esta elección pesa más que en otros mercados, porque WhatsApp no es una aplicación de mensajería entre otras: es el canal de trabajo por defecto de buena parte de la operación, desde la bodega hasta la ruta comercial.

¿Qué preguntas responde y cuáles no?

La analítica conversacional responde bien preguntas específicas sobre datos que existen; no reemplaza el seguimiento de métricas fijas ni descubre por sí sola lo que nadie está mirando. La tabla resume el reparto:

Necesidad	Herramienta adecuada	Ejemplo
Métrica fija, mirada a diario por las mismas personas	Tablero de BI	Ventas del día contra meta
Pregunta puntual y no prevista, que alguien necesita ahora	Analítica conversacional	¿Qué clientes se alargaron en el pago los últimos 60 días?
Lo que nadie está mirando y debería	Agentes que analizan sin que se les pregunte	Un margen que se erosiona de a poco durante meses
Una causa, un «por qué»	Análisis humano con datos de apoyo	¿Por qué cayó el margen del canal mayorista?

Frente al Business Intelligence, la analítica conversacional complementa el BI que la empresa ya tiene: el tablero sigue sirviendo para el KPI que se mira todos los días, y la capa conversacional cubre la pregunta que quedó fuera de su diseño. Con el tiempo, muchas empresas terminan eligiéndola como su forma principal de consultar los datos. La comparación completa está en analítica conversacional vs. dashboards de BI.

La tercera fila merece una aclaración. Tanto el tablero como el chat son reactivos: uno muestra lo que alguien decidió mostrar, el otro responde lo que alguien decidió preguntar. Los unknown unknowns —los problemas que nadie sabe que debe buscar— requieren agentic analytics: agentes que recorren los datos de forma continua y escriben por iniciativa propia cuando algo se sale de su rango. En la plataforma de Igniten, esos agentes trabajan sobre todas las fuentes conectadas y avisan en el mismo chat donde ya está el equipo. Además de avisar, esos agentes pueden ejecutar la acción que sigue —agendar una reunión, enviar un correo, crear o actualizar un registro en el CRM o el ERP—, pero solo cuando una persona responde Sí.

¿Qué hace falta antes de implementar analítica conversacional?

Lo que hace falta es, sobre todo, que las métricas del negocio estén definidas de forma consistente; la infraestructura casi nunca es el problema.

En la mayoría de las empresas medianas esa consistencia no existe. Comercial calcula la venta neta de devoluciones; finanzas la calcula bruta. Operaciones cuenta el pedido cuando se despacha; administración cuando se factura. Cada área tiene razón dentro de su propia lógica, y mientras cada una mire su propio informe la inconsistencia permanece invisible.

Una capa conversacional la vuelve visible de inmediato, y no de forma amable: dos personas hacen la misma pregunta con palabras distintas y reciben cifras distintas. La herramienta no falla; expone un problema que ya existía. Pero desde afuera se ve igual, y la confianza en el sistema se pierde en la primera semana.

Por eso, cuando ese es el estado de las cosas, el punto de partida no es la plataforma sino la gobernanza de datos: acordar las definiciones, dejarlas escritas y recién entonces automatizar sobre ellas. La calidad de datos opera igual: automatizar sobre datos malos no genera errores nuevos, genera los mismos de siempre, más rápido y con más autoridad aparente. Un agente conversacional sobre datos gobernados es una capacidad nueva; sobre datos no gobernados es un amplificador de un problema viejo.

La lista de verificación mínima, para el dominio del primer caso de uso y no para toda la empresa:

• Acceso de lectura a las fuentes de ese dominio.
• Definiciones acordadas de sus métricas, con un responsable que pueda decidir.
• Una pregunta de negocio concreta que hoy tarde demasiado en responderse.

No hace falta un data warehouse, ni un equipo de datos, ni haber terminado un proyecto de calidad de datos.

¿Cómo se implementa, paso a paso?

La implementación se hace por dominio, no para toda la empresa a la vez, y cada etapa termina con algo que justifica la inversión de la siguiente:

1. Elegir un dominio y una pregunta. Un área con una pregunta de negocio concreta que hoy tarda días en responderse: cartera, márgenes por línea, cumplimiento de despachos.
2. Acordar las definiciones de ese dominio. Qué es «venta», qué filas se excluyen, qué fecha manda. Es trabajo de semanas, no de meses, cuando el alcance es acotado.
3. Conectar las fuentes con el menor privilegio posible. Un usuario de base de datos exclusivo, de solo lectura, con permiso únicamente sobre las tablas del dominio. La lista de lo que conviene conceder está en cómo darnos el menor privilegio posible.
4. Probar con un grupo chico de usuarios reales. Una prueba de concepto sobre datos reales responde la única pregunta que importa en esta etapa: ¿esto cambia cómo decide esta gente?
5. Ampliar a más dominios y más personas. La capa semántica crece con cada dominio, y conviene tener resuelto de antemano quién es dueño de lo construido. Ese argumento está desarrollado en la optimización de procesos con IA frente al vendor lock-in.

Si la prueba no demuestra valor, la conversación correcta es detenerse. Un proyecto de datos que no puede justificar su siguiente etapa con evidencia es un proyecto que se sostiene por inercia.

¿Cuánto cuesta la analítica conversacional?

El costo tiene dos componentes que conviene separar: la plataforma, que es una suscripción mensual, y el trabajo de gobernanza y definición de métricas, que depende del estado de los datos de cada empresa.

La plataforma de Igniten, hoy en beta privada, publica tres planes con precios de lanzamiento: Inicio (USD 290 por mes, dos fuentes conectadas), Equipo (USD 690, seis fuentes y escritura acotada por rol, siempre con confirmación humana) y Empresa (USD 1.490, fuentes ilimitadas, identidad federada y registro de auditoría de cada consulta y cada acción). Los tres incluyen usuarios ilimitados y todos los canales. El detalle vigente está en precios de la plataforma.

Cuando la empresa prefiere una implementación acompañada —diagnóstico del dominio, definición de métricas y rediseño del proceso alrededor del dato—, el trabajo se contrata como proyecto de consultoría de IA por etapas, con el código y la propiedad intelectual en manos del cliente. La prueba de si un modelo así es real cabe en una pregunta que conviene hacer explícita al contratar: si mañana termina la relación, ¿sigue funcionando lo construido?

Más allá del software, lo que queda como activo es la capa semántica: las definiciones del negocio, escritas, versionadas y ejecutables. Eso sobrevive al proveedor y a la tecnología.

Si está comparando proveedores, los criterios están en cómo elegir una plataforma de analítica conversacional.

¿Es segura la analítica conversacional?

Es segura cuando el acceso está acotado por configuración y no por promesa: solo lectura en las bases de datos, permisos resueltos antes de construir la consulta, y un registro de cada acceso que el cliente puede ver.

En Igniten, además, los datos de cada organización se separan con seguridad a nivel de fila aplicada por el motor de base de datos y con cifrado de sobre con una clave por organización; nadie de Igniten tiene acceso permanente a datos de producción, y toda operación con efecto externo —agendar, enviar un correo, crear o actualizar un registro en el CRM o el ERP— requiere confirmación humana. La conexión a las bases de datos, en cambio, es siempre de solo lectura. El detalle mecánico, escrito para el equipo de IT del comprador, está en la documentación de seguridad.

¿Cuándo no conviene la analítica conversacional?

No conviene en tres situaciones, al menos no todavía:

• Cuando las definiciones del negocio están en disputa. Es la causa número uno de proyectos que se caen después de la primera demostración. Primero, gobernanza de IA.
• Cuando la pregunta que se quiere responder no existe. Si nadie en la organización está esperando datos para decidir algo, el problema no es de acceso a la información. Instalar una herramienta no crea la demanda.
• Cuando el dato no se registra. Si el motivo de una devolución nunca se capturó en un campo, ninguna consulta lo recupera. Detectar ese hueco es un resultado útil, pero no se resuelve con una interfaz.

Si quiere recorrer el tema completo, todos los artículos están en analítica conversacional, y el vocabulario, término por término, en el glosario. El producto funcionando, con la conversación en vivo, está en la plataforma de analítica conversacional de Igniten.