KPIs en lenguaje natural: cómo preguntarle a tu ERP funerario sin recibir una cifra falsa

El comité de dirección es el segundo martes del mes. Están el gerente general, la dirección financiera, la comercial y la de operaciones, y sobre la mesa hay seis sedes, un crematorio, un parque cementerio y dos razones sociales. La primera pregunta siempre es la misma y siempre suena inofensiva: «¿cómo va la cartera?». Alguien contesta con un número. Nadie pregunta de dónde salió.

En el ERP de ese grupo esa pregunta no tiene una respuesta: tiene diecinueve. Lo contamos hoy sobre el código real: de los 338 informes que viven en la instalación, diecinueve llevan la palabra «cartera» en el nombre. Cartera individual, cartera por asesor, cartera esperada por sede, cartera empresarial, cartera de previsión, cartera vencida, cartera de convenios, edad de cartera acumulada por mes, edad de cartera por valor mes a mes… Cada uno responde una pregunta legítima y distinta. Ninguno es «la» cartera, porque «la» cartera no está definida en ninguna parte.

Este es el octavo caso del cluster de IA, agentes y MCP aplicado a la operación funeraria, después de los de atención, análisis conversacional, desempeño comercial, cobranza, gobierno de los agentes, cuadrantes de turnos, cierre contable, compras e inventarios e inventario de espacios de cementerio. Si lo que buscas es qué indicadores debe tener un grupo funerario, ese trabajo ya está hecho en la guía de cuadro de mando e indicadores. Este artículo es lo otro: qué pasa cuando alguien le pregunta esos indicadores a una IA, y cómo se construye para que la respuesta sirva para decidir.

1. El problema de negocio: la pregunta correcta, la cifra equivocada

La dirección de un grupo funerario no sufre por falta de datos. Sufre por latencia y por desconfianza. Latencia porque el indicador que necesita el martes lo tiene el viernes, cuando alguien de sistemas o de contabilidad tuvo tiempo de armarlo. Desconfianza porque, cuando por fin llega, dos sedes discuten el número antes de discutir la decisión.

Ese es el hueco que la promesa de «pregúntale a tus datos» quiere llenar, y por eso es el caso de uso más pedido. También es el peor entendido. Porque el costo de no tenerlo es visible —reuniones que deciden tarde y con información vieja—, pero el costo de tenerlo mal es invisible: una decisión tomada con una cifra que nadie verificó, que nadie puede verificar a un costo razonable, y que se ve exactamente igual que una cifra correcta.

Conviene ponerle números a esa advertencia, porque hay evidencia y casi nadie la cita. Empecemos por el mejor dato disponible sobre lo que de verdad rinde una consulta en lenguaje natural sobre un esquema empresarial privado.

Las fuentes, para que puedas leerlas: BEAVER (arXiv:2409.02038), Spider 2.0 (arXiv:2411.07763, ICLR 2025) y el reporte de ingeniería de LinkedIn (arXiv:2507.14372). Y una nota de método que dice mucho: el leaderboard público de Spider 2.0 muestra hoy cifras superiores al 96 % en su pista de solo lectura, pero son envíos autorreportados por proveedores, optimizados contra un benchmark conocido. Cuando un indicador se convierte en el objetivo, deja de medir. Es la ley de Goodhart aplicada a la evaluación de la propia IA — y volverá a aparecer, esta vez sobre tus KPIs, más abajo.

2. Qué datos del ERP intervienen (y dónde está el hueco)

Un caso de MCP se sostiene o se cae según qué tan delimitado esté el conjunto de datos que toca. Para el cuadro de mando de un grupo funerario, estos son los frentes reales y el estado en el que están hoy dentro del sistema:

Esa última fila merece detenerse. El doctype Velación guarda hora de inicio, hora de fin, sala, sede y estado: con eso, la ocupación de una sala es un cálculo exacto, no una estimación. Y aun así, de los 338 informes de la instalación, ninguno tiene como referencia la sala ni la velación. La pregunta operativa que más se hace un comité funerario —«¿cómo venimos de ocupación?»— no tiene hoy una respuesta rutinaria en el sistema, mientras que la pregunta por la cartera tiene diecinueve.

3. Cómo se arma el caso con MCP, paso a paso

Conviene ser literal con lo que hoy hace el MCP de SFUN, porque el diseño explica el resultado. Son tres caminos distintos para responder una pregunta de indicadores, y no son intercambiables:

Fíjate en el tope de veinte filas del modo SQL. No es una limitación técnica: es una decisión de diseño. Un ERP funerario contiene los datos personales de familias en duelo, y una consulta libre sin techo es una vía de exfiltración con apariencia de analítica. Veinte filas alcanzan de sobra para un indicador agregado y no alcanzan para llevarse una base de datos. Ese es exactamente el reparto correcto.

El cuarto camino es el que convierte una respuesta en un activo: la app de informes a medida, con cinco herramientas propias en el MCP (crear, consultar, obtener la plantilla, revertir a una versión anterior y compartir). Cada versión conserva su propio paquete y revertir solo mueve un puntero, así que nunca se pierde una versión — ni la nueva ni la vieja. Cuando una pregunta del comité se repite tres meses seguidos, deja de ser una consulta y pasa a ser un informe versionado con dueño.

El paso que casi todos se saltan: escribir las definiciones

Aquí está el hallazgo que ordena todo el caso. El error dominante de estos sistemas no es de estructura, es de significado. En el análisis de LinkedIn sobre su propio asistente, «el filtro es incorrecto» explica el 24 % de los errores, mientras que el cruce de tablas mal hecho explica apenas el 4 %. Traducido: el agente entiende cómo se conecta tu ERP; lo que no entiende es qué considera tu compañía un «servicio cerrado», una «cartera vencida a noventa días» o una «sala ocupada».

Y hay evidencia de cuánto rinde cerrar ese hueco. El equipo de ingeniería de Pinterest publicó (abril de 2024) que documentar las tablas y las métricas subió la aceptación al primer intento del 20 % a más del 40 %, y la tasa de acierto al buscar la tabla correcta del 40 % al 90 %. Es el número menos contaminado que existe en esta discusión, por una razón simple: no lo publica quien vende capas semánticas. En la misma dirección, un trabajo de Microsoft con UCSB presentado en CIDR 2024 —sobre un almacén interno de 632 tablas y más de 4.000 columnas— midió que seleccionar a mano las tablas y columnas relevantes suma unos 7 puntos de exactitud. Acotar el contexto pesa más que cambiar de modelo.

4. La ambigüedad: por qué el agente contesta una sola cosa y debería contestar tres

El mismo trabajo de CIDR 2024 midió algo que se cita poco y explica mucho: el 41,1 % de las preguntas de negocio reales fueron marcadas como ambiguas por anotadores humanos, y el acuerdo entre dos personas sobre cómo interpretarlas rondó el 62 %. Es decir: ni siquiera dos analistas de tu equipo entenderían lo mismo. El benchmark AMBROSIA (NeurIPS 2024), construido específicamente para esto, encontró que el mejor modelo recupera el 31 % de las interpretaciones posibles de una pregunta ambigua, y las encuentra todas solo en el 1,9 % de los casos.

Súmale un detalle que a esta región le importa y que casi nadie menciona: en ese mismo estudio, traducir las preguntas del inglés a otros idiomas —el español incluido— baja la exactitud entre 3,5 % y 15 %. Tu comité no pregunta en inglés. La penalización está medida y es real, y es una razón más para que la capa de definiciones esté escrita en el idioma en que se opera.

El comportamiento correcto ante una pregunta ambigua no es acertar: es no elegir en silencio. Un sistema bien diseñado responde «esto se puede leer de tres maneras, aquí están, ¿cuál quieres?» o entrega la cifra diciendo qué definición usó. Y para eso hace falta que el sistema tenga permitido no responder. Un estudio de predicción selectiva sobre consultas generadas a partir de lenguaje natural (arXiv:2607.06799) lo cuantifica sin piedad: la capacidad de detectar automáticamente una respuesta incorrecta llega a un AUROC de 0,72 a 0,78 (0,82 combinando dos proveedores distintos), y si se exige un umbral de bajo riesgo, el sistema solo puede responder cerca del 27 % de las preguntas. Ese 27 % no es un fracaso: es el tamaño honesto de lo que hoy se puede automatizar sin supervisión.

Un gráfico en cero es un dato falso: es indistinguible de uno real. Por eso, cuando un informe compartido públicamente no puede leer los datos, el sistema falla de forma ruidosa en lugar de devolver una lista vacía.— Decisión de diseño documentada en el motor de informes de SFUN

Esa regla, que en nuestro motor de informes aplica a los enlaces públicos, es la misma que debe gobernar al agente: entre callarse y devolver un cero plausible, siempre callarse.

5. Gobierno y límites: lo que la evidencia dice sobre el juicio humano

Aquí es donde este caso de uso se separa de todos los demás del cluster. En cobranza o en compras, un error del agente lo corrige el proceso. En el cuadro de mando, el error entra directamente en una decisión de dirección, y la investigación sobre juicio asistido por máquina es, francamente, incómoda.

• La IA correcta ayuda poco; la incorrecta daña mucho. En un ensayo aleatorizado con 457 médicos hospitalarios publicado en JAMA (doi:10.1001/jama.2023.22295), un modelo estándar mejoró la exactitud en 2,9 puntos, mientras que un modelo sesgado la hundió 11,3 puntos. Asimetría de casi cuatro a uno.
• Mostrar el razonamiento no rescata. En ese mismo ensayo, acompañar la sugerencia sesgada con explicaciones dejó la caída en 9,1 puntos: una mejora no significativa. Enseñar el SQL generado tranquiliza, pero no es por sí solo un control de riesgo.
• La experiencia atenúa el sesgo, no lo elimina. Con 27 radiólogos (doi:10.1148/radiol.222176), los profesionales más experimentados cayeron del 82,3 % al 45,5 % de exactitud ante una sugerencia incorrecta. El argumento «nuestro director lleva veinticinco años, detectará el número raro» no sobrevive al dato.
• Este caso de uso está justo en el peor cuadrante conocido. Una revisión sistemática de 40 estudios (doi:10.1093/jamia/ocw105) encontró que el sesgo de automatización aparece sobre todo en tareas únicas, de diagnóstico y con alta complejidad de verificación. «¿Por qué cayó el margen de la sede norte?» reúne las tres condiciones a la vez.
• Más información puede empeorar la decisión y mejorar la confianza. En cuatro experimentos de psicología del juicio (doi:10.1016/j.obhdp.2007.01.003), dar información adicional bajó la exactitud de 0,66 a 0,63 y subió la confianza de 5,58 a 6,21. El 63,2 % creyó que le había ayudado; solo el 8,5 % consideró que pudo haberlo empeorado. No es autodetectable, así que no se corrige con advertencias en pantalla.

Y una más, porque toca de lleno la función estrella que todo proveedor promete: el «¿por qué cambió este número?». La atribución automática de causas sobre métricas segmentadas funciona bien en el caso fácil y se derrumba en el real. El método clásico del área reporta 95,3 % de acierto, pero entre sus tres primeras respuestas; en primera posición baja al 63 %. Una evaluación independiente con 5.400 fallas (doi:10.1016/j.jss.2023.111748) midió un F1 máximo de 0,68 entre todos los métodos. Sobre métricas de razón —y la ocupación de salas y la tasa de mora son razones, segmentadas por sede— los mejores métodos publicados caen a F1 por debajo de 0,05. Traducción para el comité: la explicación automática de por qué se movió un indicador se vende como resuelta y no lo está.

El motivo de esa última regla también está medido. Un estudio sobre unas 10.000 trayectorias de agentes con herramientas (arXiv:2606.09863) encontró que el «falso éxito» —el agente reporta haber hecho bien algo que hizo mal— explica entre el 45 % y el 48 % de los fallos en dominios de control simple, y que ningún juez automático supera un AUROC de 0,65 detectándolo. Un agente que dice «listo, la ocupación de la sede norte es 78 %» no es evidencia de nada. El informe que la calcula, sí.

6. El bucle de mejora continua: qué se revisa cada semana

Como todos los casos de este cluster, este no se instala: se cultiva. La diferencia es qué se revisa. En el chatbot de atención se revisan conversaciones fallidas; aquí se revisan preguntas mal respondidas y definiciones que faltan.

7. KPIs para medir si funcionó (y la trampa de medirlos)

Un caso de uso que produce indicadores tiene que medirse con indicadores. Estos son los que sirven, con línea base típica y meta realista para un grupo de seis a diez sedes:

Y ahora la advertencia que hace a este artículo distinto de un folleto. Medir cambia lo que se mide. El caso mejor documentado del mundo está en el sistema de salud inglés: los hospitales reportaban al ministerio un cumplimiento del 96 % mientras una encuesta independiente medía 77 %; de 55 entidades auditadas, nueve ajustaron listas «inapropiadamente» y tres directamente falsearon (doi:10.1136/bmj.332.7538.419). En el mismo sistema, el cumplimiento del objetivo de cuatro horas en urgencias subió del 83,9 % al 96,3 % mientras las altas concentradas en los últimos veinte minutos antes del umbral pasaban del 4,7 % al 8,4 % y la estancia real aumentaba 8,6 minutos (doi:10.1016/j.annemergmed.2011.08.017).

Que nadie lea eso como «los objetivos no sirven»: en el mismo sistema, otros dos estudios rigurosos no encontraron esos efectos perversos (doi:10.1093/jopart/mun028, doi:10.1016/j.jpubeco.2010.01.002). El mismo instrumento produjo mejora real y distorsión, según cómo se diseñó. En un contexto puramente comercial el efecto también está medido: los vendedores con incentivo trimestral conceden precios más bajos en el trimestre que les conviene, con un costo del 6 % al 8 % de los ingresos (doi:10.1086/673371). Si tu grupo pone metas trimestrales de margen por sede, ese es exactamente el KPI que se distorsiona — y ahora, además, cada director puede consultarlo cuando quiera.

8. Hoja de ruta de adopción y errores comunes

Los seis errores que se repiten

1. Empezar por la herramienta y no por el glosario. Es el error caro. Sin definiciones escritas, el proyecto se vuelve una discusión sobre cuál número está bien, con la diferencia de que ahora es más rápida.
2. Evaluar por satisfacción. Preguntarle al comité si le gustó siempre da bien. Cuarenta y dos puntos separaron la percepción de la exactitud en el caso mejor documentado del sector.
3. Dar acceso al modo SQL libre «para que sea más potente». Es el camino con menos guardas y el que peor rinde en la evidencia. Existe por una razón acotada y con rol privilegiado, no como modo por defecto.
4. Premiar que el sistema siempre conteste. Una tasa de abstención de cero significa que está adivinando. El sistema debe tener permitido decir «no sé» y ese permiso hay que defenderlo en la primera reunión en que moleste.
5. Creer que el «por qué cambió» está resuelto. No lo está, menos aún sobre razones segmentadas por sede. La atribución es un punto de partida para investigar, no una conclusión.
6. Confundir acceso a datos con capacidad de decidir. La única evidencia experimental limpia sobre productividad y gestión atribuye un +17 % al paquete de prácticas de gestión, no al acceso a la información (doi:10.1093/qje/qjs044). El 5-6 % que citan todos los proveedores viene de un estudio observacional, no causal. La herramienta no sustituye al proceso de decisión.

Preguntas frecuentes

¿De verdad puedo preguntarle a mi ERP funerario en lenguaje natural?

Sí, y hoy funciona bien para una clase concreta de pregunta: agregados sobre un frente ya definido —cuántos contratos por sede y estado, cuánta cartera vencida por asesor, cuántas velaciones por sala en un rango de fechas— y ejecución de informes que ya existen. Funciona mal, en cambio, para preguntas abiertas de diagnóstico sobre un esquema sin documentar. La diferencia no la marca el modelo: la marca si alguien escribió qué significa cada término.

¿Puede un agente ver datos de familias en duelo al consultar indicadores?

Toda lectura pasa por el motor de permisos del ERP, incluidos los permisos a nivel de campo: el agente ve exactamente lo que vería la persona que pregunta, ni un campo más. Sobre eso hay topes duros —20 filas en analítica, 200 en informes— pensados precisamente para que una consulta agregada no se convierta en una extracción. Y la consulta SQL libre exige un rol privilegiado y tiene lista negra explícita. El detalle completo del modelo está en el artículo de gobierno de agentes de IA en el ERP.

¿Necesito una herramienta de BI aparte, tipo Power BI o Looker?

Para el cuadro de mando de operación, no: si el servicio, la cartera, el recaudo y el asiento contable viven en el mismo sistema, el indicador se calcula donde nace el dato y no hay que sincronizar nada. Una herramienta de BI externa se justifica cuando necesitas cruzar el ERP con fuentes de afuera o cuando tu equipo ya vive en ella. Lo que no resuelve ninguna herramienta de BI —ni la mejor— es el problema de este artículo: si «cartera» significa diecinueve cosas, el tablero solo hace que la ambigüedad se vea más bonita.

¿Cómo sé si la cifra que me dio el agente está bien?

Con dos reglas. La primera: toda cifra que va a una decisión debe poder trazarse hasta el informe que la produjo, con su definición y su fecha de corte; si no se puede, no entra al acta. La segunda: verifica contra el estado del ERP, nunca contra lo que el agente dice de sí mismo, porque el falso éxito explica cerca de la mitad de los fallos de este tipo de sistemas y ningún verificador automático lo detecta de forma fiable. La muestra ciega mensual es la versión sistemática de esas dos reglas.

¿Por dónde empiezo si mi grupo tiene ocho sedes y ningún glosario?

Por cinco preguntas y una reunión de dos horas entre finanzas y operaciones para definirlas. No por comprar nada. Si en esa reunión descubres que las sedes calculan distinto la cartera vencida —pasa casi siempre—, acabas de encontrar el problema real, y es un problema que ya tenías antes de la IA: lo único que hace el agente es hacerlo evidente en una tarde. Después, el orden es el de la hoja de ruta de arriba: definir, medir, cerrar el frente ciego, versionar.

La conclusión que cabe en una frase

Un agente de IA no le puede dar sentido a un indicador que tu compañía nunca definió. Puede leer el ERP entero, respetar cada permiso, agregar sin equivocarse una suma y aun así entregar una cifra que responde a otra pregunta, con una seguridad que nadie va a cuestionar en un comité. El trabajo que hace posible este caso de uso no es de inteligencia artificial: es escribir qué es la cartera, qué es una sala ocupada y qué es un servicio cerrado, y dejar esas definiciones dentro del sistema, con dueño y con fecha.

Lo demás —consultar en lenguaje natural, agregar por sede, promover una pregunta repetida a informe versionado, revisar cada semana lo que falló— ya está disponible y funciona. Y las dos brechas que dejamos publicadas aquí, los diecinueve informes de cartera sin un indicador oficial y la ocupación de salas sin un solo informe pese a tener el dato exacto, son trabajo de producto con solución conocida, no misterios. Si quieres ver cómo se ve todo esto cuando el dato nace en el mismo sistema que lo consulta, empieza por el MCP de SFUN, por la guía de cuadro de mando e indicadores y por el módulo de contabilidad.