Analytics embebido con IA para SaaS: qué funciona de verdad en 2026

Nota del autor

Dashrendr es una plataforma de embedded analytics y hoy no ofrecemos funciones de IA. No hay consulta conversacional en nuestro producto, ni interfaz de lenguaje natural, ni generación automática de insights. Estamos observando el espacio y no hemos lanzado nada en él. Ten en cuenta eso al leer lo que viene a continuación.

Lo escribimos igualmente porque el tema sale en casi todas las conversaciones de evaluación que tenemos, y la mayor parte del material disponible lo producen proveedores que venden exactamente la función que describen. Nuestro objetivo es que este artículo te sirva incluso si al terminarlo concluyes que necesitas una herramienta que nosotros no vendemos. Ese desenlace nos parece perfectamente válido, y preferimos que llegues a él rápido antes que despacio.

Haz tu propia evaluación. Plantea las preguntas de este artículo a cualquier proveedor que estés considerando, nosotros incluidos, y fíate más de lo que veas en un sandbox que de lo que leas en un blog.

La respuesta corta

• La IA en embedded analytics son tres productos distintos agrupados bajo una sola palabra. Consulta conversacional para tus clientes finales, detección automática de insights y anomalías, y creación de dashboards asistida por IA para tu propio equipo. Comparten un modelo y poco más.
• Tienen perfiles de riesgo muy diferentes. Una puede devolver los datos de otro tenant. Otra puede equivocarse con total convicción en un correo que tu cliente lee un lunes por la mañana. La tercera puede hacerle perder veinte minutos a un analista interno.
• La conversacional de cara al cliente es con diferencia la más arriesgada en un producto multi-tenant, porque el fallo es visible para tu cliente y, en su peor versión, es una brecha de aislamiento de datos y no un gráfico mal hecho.
• La mayoría de equipos SaaS deberían adoptar la tercera antes que la primera. La creación asistida para tu propio equipo tiene un radio de impacto pequeño, un ciclo de feedback corto y, por defecto, un revisor humano en medio.
• La pregunta decisiva para un proveedor no es la precisión del modelo. Es dónde se aplica el aislamiento entre tenants respecto al punto donde opera el modelo.

Si estás en una fase anterior y todavía decides qué debería hacer tu función de analytics, nuestra guía de embedded analytics para desarrolladores cubre las bases que este artículo da por supuestas.

Las tres cosas que los proveedores llaman IA

Cuando un proveedor dice que su producto de embedded analytics tiene IA, la pregunta honesta de seguimiento es cuál de las tres. La página de marketing suele insinuar las tres. El producto suele hacer bien una.

Capacidad	Quién la usa	Peor fallo realista	Radio de impacto
Consulta conversacional	Tu cliente final	Cifra incorrecta, o filas de otro tenant, dentro de tu producto	Externo, potencialmente una brecha
Insights automáticos	Tu cliente final, a menudo por correo	Una narrativa convincente sobre ruido estadístico	Externo, reputacional
Creación asistida por IA	Tu propio equipo	Un gráfico mal construido que un humano descarta antes de publicarlo	Interno, minutos

Consulta conversacional para tus clientes

Esta es la demo que todo el mundo ha visto. Un campo de texto encima del dashboard, tu cliente escribe "muéstrame los ingresos por región del último trimestre" y un modelo lo convierte en una consulta sobre sus datos. ThoughtSpot construyó una empresa sobre esta interacción, y hoy casi todas las plataformas establecidas ofrecen alguna versión de ella.

El usuario es tu cliente, no tu analista. Ese único hecho lo cambia todo. Tu cliente no puede leer el SQL generado, no puede valorar si el join era razonable y no tiene forma de verificar el resultado más allá de si la cifra le parece plausible. Cuando el modelo se equivoca, se equivoca dentro de tu producto, con tu marca, y la conversación la gestiona tu equipo de soporte. Es la única de las tres en la que el error es visible para tu cliente por defecto, y la única en la que el error puede ser una fuga de datos en lugar de una molestia.

Insights automáticos y detección de anomalías

Aquí el sistema mira los datos sin que nadie se lo pida y cuenta qué ha cambiado. Los registros cayeron un dieciocho por ciento respecto a la semana anterior. El churn se concentra en un plan concreto. Esto aparece en correos resumen, en feeds de notificaciones y como texto narrativo sobre un gráfico.

El problema de precisión es más sutil de lo que parece. La detección de anomalías sobre datos de un tenant con muestras pequeñas produce un flujo constante de hallazgos estadísticamente reales y prácticamente irrelevantes, y un modelo de lenguaje al que le pides que narre esos hallazgos generará una explicación fluida y con apariencia causal de lo que en realidad es ruido. El fallo no es un incidente de seguridad. Es una erosión de la confianza, y ocurre en silencio, durante semanas, hasta que los clientes dejan de abrir los correos.

Creación asistida por IA para tu equipo

La menos comentada y, en nuestra opinión, la más útil de forma inmediata. Tu propio equipo describe un gráfico o un dashboard en lenguaje llano y la herramienta lo redacta. El usuario es alguien que conoce el modelo de datos, el resultado se revisa antes de que lo vea nadie de fuera, y el coste de una mala sugerencia es que alguien la borre y lo intente otra vez.

Aquí las cuentas salen con claridad. Construir dashboards es repetitivo, es un cuello de botella en la mayoría de equipos de producto, y el paso de revisión es gratis porque ya existía. Si vas a adoptar una de las tres este trimestre, adopta esta.

Por qué el text-to-SQL es un problema de seguridad, no de precisión

Casi todos los artículos sobre SQL generado por un LLM lo plantean como una cuestión de corrección. Si el modelo eligió la tabla adecuada, si acertó con el join, si aplicó bien el rango de fechas. Son preguntas legítimas y, en una herramienta de BI interna, son prácticamente las únicas, porque quien lee el resultado suele ser quien puede notar que la cifra no cuadra.

En un producto multi-tenant la pregunta principal es otra, y rara vez es la que se responde en la demo. No es si la consulta generada es correcta. Es si la consulta generada está correctamente acotada al tenant que preguntó.

El modo de fallo, en concreto. Tus datos viven en tablas compartidas con una columna de identificador de tenant. Un cliente hace una pregunta. El modelo recibe una descripción del esquema y unas instrucciones, y escribe SQL. Si el predicado de tenant es algo que el modelo debe incluir, has convertido a un generador probabilístico de texto en la última línea de defensa de tu aislamiento de datos. Da igual que acierte la inmensa mayoría de las veces. Basta con que omita ese predicado una vez, en una consulta cuyo resultado ve un cliente, para que estés escribiendo un informe de incidente y avisando a un cliente de que las filas de otro aparecieron en su dashboard.

La arquitectura correcta aplica el aislamiento por debajo de la capa en la que opera el modelo, de forma que ninguna cadena generada pueda ampliar el alcance de lo que se devuelve:

• Row-level security en la base de datos. Las políticas se asocian a las propias tablas y el motor las aplica en cada sesión. Una consulta que olvide el filtro de tenant no devuelve nada de más, porque ese filtro nunca fue responsabilidad de la consulta.
• Una conexión o credencial por tenant. La conexión sobre la que se ejecuta la consulta generada solo alcanza los datos de ese tenant, ya sea mediante una base de datos separada, un esquema separado o un rol limitado a una vista.
• Una capa de políticas que inyecta el predicado de tenant en tiempo de consulta. El SQL generado se parsea y se reescribe, o el modelo solo puede emitir un objeto de consulta estructurado que un compilador de confianza convierte en SQL con el filtro ya incorporado. La propiedad crítica es que ese predicado inyectado no pueda ser anulado, comentado ni rodeado con un UNION por nada de lo que haya producido el modelo.

Nada de esto es nuevo. Es la misma disciplina que aplica a cualquier dashboard multi-tenant con row-level security, y por eso insistimos en que la IA no creó este problema, solo encareció equivocarse. Añadir una superficie de lenguaje natural sobre una arquitectura donde el aislamiento ya se aplica en la capa de datos es una decisión de producto. Añadirla donde el aislamiento lo aplica código de aplicación que concatena cláusulas WHERE es una reescritura.

Hay un segundo vector que recibe menos atención. El prompt injection es real aquí, y no requiere un usuario malicioso de tu producto. Requiere que texto controlado por el cliente llegue al contexto del modelo, cosa que ocurre constantemente en analytics: nombres de registros, etiquetas de campos personalizados, notas libres, nombres de campañas, títulos de productos. Una fila cuyo campo de nombre contiene instrucciones es una fila que puede intentar dirigir a un modelo al que le has pedido que la resuma. Trata cualquier cadena originada fuera de tu equipo como entrada no confiable al modelo, no como dato.

Una lista breve para plantear a cualquier proveedor sobre este punto concreto:

• Si el modelo emite SQL sin el filtro de tenant, ¿qué devuelve el sistema?
• ¿El predicado de tenant lo inyecta una capa de confianza o se espera del modelo?
• ¿Puede el SQL generado alcanzar alguna tabla fuera del alcance del tenant, en alguna circunstancia?
• ¿Entra texto controlado por el cliente en el contexto del modelo, y qué se hace al respecto?
• ¿Se registra la consulta generada de forma que podamos auditarla tras un incidente?

Un proveedor serio responde a cada una en una frase, porque su arquitectura ya lo decidió. Un proveedor que necesita consultarlo internamente también te ha dicho algo útil.

¿Necesitas un semantic layer?

Pregúntale a un modelo de lenguaje "cuántos ingresos tuvimos el mes pasado" sobre un esquema en bruto y elegirá alegremente una columna, decidirá por su cuenta si usa bruto o neto, aplicará su propio criterio con las devoluciones, escogerá una zona horaria y presentará el resultado con absoluta seguridad. Pregúntaselo mañana con otra formulación y puede tomar decisiones distintas. Dos usuarios de la misma empresa obtienen dos cifras, ambas defendibles, y ahora discuten en una reunión en vez de decidir.

Un semantic layer resuelve esto fijando las definiciones. Los ingresos se definen una vez, como una expresión concreta sobre tablas concretas con filtros concretos, y el trabajo del modelo se reduce de escribir lógica a seleccionar entre métricas y dimensiones gobernadas. Esa superficie es muchísimo más pequeña y más testeable. Además hace legible el fallo: o el modelo eligió la métrica equivocada, lo cual se ve, o eligió la correcta, lo que significa que la cifra es tan correcta como lo sea tu definición.

Queremos ser equilibrados con esto, porque ahora mismo el semantic layer se vende como requisito previo para todo. Es inversión real de ingeniería. Alguien tiene que ser dueño de las definiciones, mantenerlas al día según evoluciona el producto y arbitrar cuando dos equipos no se ponen de acuerdo. Ese trabajo no desaparece, simplemente se vuelve visible.

• Es la decisión correcta si vas a exponer consulta con IA a tus clientes, o si ya tienes varios equipos discutiendo qué significa una cifra clave.
• Probablemente sea excesivo si tienes una docena de métricas bien entendidas, un solo equipo que las comparte y ninguna superficie de consulta con IA.

LookML de Looker es el ejemplo de referencia, y los semantic layers independientes más recientes merecen estudio aunque no adoptes ninguno, porque han pensado el gobierno de métricas más a fondo que la mayoría de nosotros. Si estás comparando plataformas por este criterio, nuestra recopilación de las mejores herramientas de embedded analytics para SaaS en 2026 indica cuáles traen una capa de modelado consigo.

Lo que esto te cuesta y nadie menciona

La página de precios muestra una cuota de plataforma. La estructura real de costes de una función de IA de cara al cliente tiene cuatro partes, y tres no aparecen en esa página.

Inferencia por consulta. Cada pregunta cuesta dinero, y una interfaz conversacional está diseñada explícitamente para invitar a repreguntar. Un cliente que hace catorce preguntas en una tarde está usando bien la función, y tú pagas las catorce. Un dashboard predefinido tiene una curva de coste que puedes predecir a partir del número de tenants. Una función conversacional tiene una curva que depende de lo atractiva que la hayas hecho, lo cual es un incentivo incómodo.

Latencia. Un panel cacheado se pinta en unos cientos de milisegundos. Una pregunta en lenguaje natural implica al menos una ida y vuelta al modelo, planificación de la consulta, ejecución y a menudo una segunda llamada al modelo para narrar el resultado. Los usuarios perdonan esto unos segundos. No lo perdonan cuando querían una cifra cuyo nombre ya conocían y el dashboard la habría tenido en pantalla antes de que terminaran de escribir.

Evaluación. Esta es la que sorprende a los equipos. Un dashboard es determinista: lo construyes, verificas las cifras una vez y sigue siendo correcto hasta que alguien cambia el modelo de datos. Una función conversacional no es determinista, lo que significa que la corrección es una distribución y no un estado. Necesitas un conjunto de evaluación con preguntas reales y respuestas conocidas, necesitas ejecutarlo en cada cambio de prompt y en cada cambio de versión del modelo, y necesitas a alguien responsable del resultado. Un dashboard se prueba una vez. Una función conversacional se prueba para siempre.

Soporte. Cuando un cliente dice que la IA le dio una cifra incorrecta, tienes que poder reconstruir qué pasó. Sin consultas registradas y sin un camino reproducible, ese ticket se convierte en una investigación abierta. Aquí también se desplaza el cálculo de construir frente a comprar: una decisión de comprar que ya era defendible para dashboards lo es más cuando la alternativa es mantener un arnés de evaluación para un modelo que no has entrenado.

Cómo evaluar las afirmaciones de IA de un proveedor

Preguntas concretas con respuestas verificables, en el orden en que las haríamos. Llévalas a la demo y pide el sandbox después.

1. ¿Cómo se aplica el aislamiento entre tenants respecto a la consulta generada? ¿En la base de datos, en una capa de políticas de confianza, o en la cadena que escribió el modelo? Solo hay una familia de respuestas aceptable.
2. ¿Puede el modelo escribir SQL arbitrario o solo seleccionar entre métricas definidas? Si es arbitrario, pregunta qué lo limita. Si está gobernado, pregunta quién mantiene las definiciones y cuánto se tarda.
3. ¿Qué ocurre con los datos de nuestros clientes? Dónde van, cuánto tiempo los retiene el proveedor del modelo y si alguno se usa para entrenar. Pide esto por escrito, no como respuesta en una demo.
4. ¿Cómo se le muestran los fallos al usuario final? ¿La interfaz enseña la pregunta que realmente respondió, la métrica que usó y un camino hasta las filas subyacentes, o presenta una cifra sin procedencia?
5. ¿Cuánto cuesta por consulta a nuestro volumen previsto? Después pregunta qué pasa con diez veces ese volumen y si existe un tope.
6. ¿Podemos desactivarlo por tenant? Lo vas a necesitar para un cliente regulado, para una revisión de seguridad empresarial o para un tenant cuyo modelo de datos esté demasiado desordenado para que funcione bien.
7. ¿Podemos ver los logs de las consultas generadas? Si no puedes auditarlo a posteriori, no puedes darle soporte.

Estas preguntas encajan en la checklist de requisitos de embedded analytics que usamos con los equipos, que cubre la mitad no relacionada con IA de la evaluación, que sigue determinando la mayor parte del resultado.

Cuándo prescindir de la IA por completo

Siendo directos, porque el sector ahora mismo no lo es. Hay buenas razones para no hacer esto, y casi todas son más frecuentes que las razones para hacerlo.

• Tus clientes quieren las mismas cinco cifras cada semana. El uso real del embedded analytics suele ser estrecho y repetitivo. Si el trabajo de fondo es "dime cómo ha ido mi tienda", un dashboard fijo, rápido y bien diseñado lo resuelve mejor que un campo de texto que obliga al cliente a formular la pregunta.
• Trabajas en un vertical regulado. Si no puedes explicarle a un auditor cómo se produjo una cifra, ni reproducirla exactamente un año después, un camino de generación no determinista es un pasivo y no una función.
• No tienes capacidad para evaluar una función no determinista. Si nadie en el equipo va a hacerse cargo de un conjunto de evaluación y ejecutarlo en cada actualización del modelo, no estás lanzando una función de IA, estás lanzando una dependencia sin control.
• Tu función de analytics no se usa lo suficiente para justificarla. Este es, con mucha diferencia, el caso más común. Si el uso de tu dashboard actual es bajo, poner un modelo encima no lo arregla. Hemos escrito sobre por qué los usuarios nunca abren la pestaña de analytics, y la respuesta casi siempre es un problema de diseño y de ubicación, no de inteligencia. Un analytics enterrado tras un ítem de navegación, desconectado del flujo donde se toma la decisión, seguirá sin usarse por listo que se vuelva.

Dónde encaja Dashrendr

Sin rodeos: hoy no ofrecemos IA conversacional, consulta en lenguaje natural ni insights automáticos. No vamos a insinuar lo contrario y no vamos a prometerte una fecha.

Lo que construimos es la capa determinista de debajo. Conectores para Google Analytics, BigQuery, PostgreSQL, MySQL, MongoDB, Google Sheets y Xero, más una API REST para enviar datos pre-agregados. Un constructor visual de arrastrar y soltar, con gráficos renderizados mediante ECharts. Envío programado de dashboards por correo. Row-level security incluido en todos los planes, también en el más barato, porque el aislamiento entre tenants no nos parece una función que deba estar detrás de un upgrade. White-label a partir del plan Grow (Hobby y Starter llevan marca de agua), y un embedding que un desarrollador puede poner en producción en horas y no en sprints. Los planes van desde Hobby por 6 USD al mes hasta Premium por 99 USD al mes, con una prueba gratuita de 14 días y sin tarjeta de crédito.

Si la consulta conversacional de cara a tus clientes es un requisito indispensable ahora mismo, no somos la herramienta, y deberías mirar una plataforma con semantic layer y un camino de consulta con IA gobernado. Preferimos decírtelo la primera semana y no al tercer mes.

Para muchos equipos, sin embargo, la secuencia honesta va al revés. Pon primero delante de tus clientes un dashboard rápido, bien diseñado y correctamente aislado, observa qué hacen realmente con él y decide después si una capa de lenguaje natural responde a una pregunta que de verdad se están haciendo. Una capa de IA sobre un analytics que nadie abre no arregla nada. Solo encarece lo que no se usa.

Conclusión

Esta categoría ha avanzado deprisa, y el marketing ha avanzado bastante más deprisa que la ingeniería. Ese hueco es donde se producen las malas compras, porque una demo sobre datos de ejemplo limpios y con un solo tenant no te dice casi nada sobre el comportamiento con datos de producción desordenados y cientos de tenants.

La pregunta que separa a un proveedor serio de una buena demo no es cuán preciso es el modelo. Es cómo se relaciona el aislamiento entre tenants con la consulta generada, y si la respuesta implica confiar en el modelo para algo de eso. Todo lo demás en una evaluación es negociable. Esto no.

Y si estás decidiendo por dónde empezar, empieza donde el radio de impacto sea pequeño. La creación asistida por IA para tu propio equipo se amortiza rápido y falla sin consecuencias. La consulta conversacional de cara al cliente es un producto con superficie de seguridad, una curva de coste sin techo y una obligación de testeo permanente. Ambas son cosas razonables de construir. No lo son en ese orden invertido.

Si lo que necesitas primero es la base determinista, Dashrendr tiene una prueba gratuita de 14 días sin tarjeta de crédito en app.dashrendr.com/signup. Y si tu conclusión es que necesitas algo que no vendemos, esperamos que la lectura haya valido la pena igualmente.