Saltar al contenido

¿Por qué la IA no debe calcular tus números?

Un argumento a favor de separar redactar de calcular, con una definición real de métrica y la ruta para auditarla hasta Odoo.

Por Equipo SixaraPublicado 17 de octubre de 2026 Actualizado 17 de octubre de 20267 min de lectura
Respuesta corta

Porque un modelo de lenguaje predice texto verosímil, no ejecuta aritmética: puede entregar una cifra falsa con total seguridad. Las cifras de una empresa deben salir de consultas SQL fijas y revisables, y la IA debe limitarse a elegir qué métrica consultar y a redactar el resultado.

¿Por qué la IA no debe calcular los números de tu empresa? Porque un modelo de lenguaje fue entrenado para producir texto plausible, no para ejecutar aritmética exacta sobre tus registros. Este artículo es para quien dirige una empresa o un área y está decidiendo cuánta confianza darle a una IA que "responde sobre los datos". Nuestra respuesta es una postura: ninguna, mientras la cifra salga de la IA.

¿Qué pasa cuando un modelo de lenguaje suma?

Un modelo de lenguaje genera la siguiente palabra más probable dado lo anterior. Cuando le pides sumar una lista de facturas, no abre una calculadora: produce un número que se parece a la respuesta correcta. Con listas cortas y números redondos suele coincidir. Con cien facturas, decimales, notas de crédito y monedas mezcladas, la probabilidad de coincidir baja, y el modelo no avisa cuándo.

Eso es lo peligroso. Una calculadora que falla da un error o un resultado absurdo. Un modelo que falla da un resultado creíble, con buena redacción, acompañado de una explicación convincente. Nadie lo cuestiona, porque tiene el mismo aspecto que cuando acierta.

Hay tres fuentes de error que se combinan:

  • Aritmética aproximada. Sumar, promediar o calcular porcentajes sobre muchos datos no es lo que el modelo hace de forma nativa.
  • Definiciones implícitas. "Deuda vencida" puede incluir o no las facturas en borrador, las notas de crédito, los clientes del grupo. Si el modelo elige en cada respuesta, la cifra cambia sin que nadie lo decida.
  • Contexto incompleto. Si le pasas un extracto de los datos, calcula sobre el extracto y lo presenta como el total.

No hace falta una estadística para ver el problema. Basta con imaginar un informe de gerencia en que una cifra está mal por unos puntos. Nadie lo nota, se decide un descuento o una compra con ella, y cuando se descubre ya no hay manera de saber qué otras cifras del mismo informe estaban bien.

¿Qué es una cifra determinista?

Es una cifra que, con los mismos datos y los mismos parámetros, produce siempre el mismo resultado, porque la genera una consulta fija y no un modelo. Se puede repetir mañana, que dé lo mismo. Se puede explicar línea por línea. Y se puede discutir: si no estás de acuerdo con cómo se define, cambias la definición en un solo lugar y cambia para todos.

Esta es una definición real del catálogo de Sixara. La métrica es deuda vencida, del módulo de cobranza:

select sum(f.saldo)
from core.facturas f
  left join core.contactos c on c.id = f.contacto_id
  left join core.empresas e on e.id = f.empresa_id
where f.tipo = 'cliente'
  and f.estado = 'posted'
  and f.saldo > 0
  and f.vencimiento < current_date

Se lee sin ser programador: suma el saldo de las facturas de clientes que están publicadas (posted), tienen saldo pendiente y cuyo vencimiento ya pasó. No incluye facturas en borrador ni de proveedores. Si tu empresa entiende "vencido" de otra manera, la discusión es sobre estas cuatro condiciones, no sobre qué respondió el asistente un martes.

El catálogo actual tiene 128 métricas, cada una con definición, unidad, dimensiones posibles (por cliente, vendedor, segmento, zona, mes, según corresponda), tablas que usa y su SQL exacto. Otras métricas que suelen importar a una pyme están descritas en nuestra guía de indicadores para pymes con Odoo.

¿Cómo se separa redactar de calcular?

Dividiendo el trabajo en tres pasos, cada uno a cargo de quien lo hace bien:

  1. Entender la pregunta (IA). Alguien escribe "¿cuánto nos debe cada cliente de la zona norte?". El modelo traduce eso a una elección dentro del catálogo.
  2. Calcular (núcleo). El sistema toma esa elección, compone una consulta parametrizada y la ejecuta. Devuelve un valor.
  3. Redactar (IA). El modelo recibe el valor ya calculado y lo explica en palabras: qué cliente concentra más, qué cambió respecto al período anterior.

La elección del paso 1 se parece a esto:

{"metrica": "deuda_vencida",
 "dimension": "cliente",
 "filtros": {"zona": "Norte"},
 "limite": 10}

Para una métrica con período, como el margen bruto, la elección incluye uno de los períodos permitidos (por ejemplo mes_pasado o ultimos_12_meses):

{"metrica": "margen_bruto",
 "dimension": "categoria",
 "periodo": "mes_pasado"}

El modelo no puede salirse de esa forma. Si pide una métrica que no existe, una dimensión que la métrica no tiene o un período inválido, el núcleo rechaza la consulta y le explica qué opciones hay. El valor de cada filtro viaja como parámetro de la consulta, no pegado al texto del SQL. Y los permisos de la persona se aplican en la misma consulta: un vendedor con cartera propia solo ve su cartera, sin importar qué pregunte.

El resultado de este diseño es que el modelo no tiene dónde equivocarse con la aritmética. Se puede equivocar eligiendo mal la métrica, y esa equivocación es visible: el chat muestra las etapas de la consulta y cita la fuente. Un error de elección se detecta en segundos. Un error de suma escondido en una frase bien escrita, no.

Hay un segundo control sobre el texto. Cuando la IA redacta el informe, el sistema compara cada cifra del texto con las cifras oficiales de ese turno. Si aparece un valor que no coincide con ninguna, se descarta la redacción y se entrega una versión simple con los datos calculados. Es un control conservador y limitado: verifica números, no interpretaciones, así que no reemplaza tu lectura. Más sobre cómo se protege el resto del sistema en seguridad.

¿Cómo se audita una cifra hasta su registro en Odoo?

Una cifra confiable es una cifra que se puede rastrear hacia atrás. En Sixara el camino es el siguiente:

  1. De la cifra a su definición. Cada métrica muestra su SQL, como el de arriba.
  2. De la definición a las tablas. Esa consulta usa tablas normalizadas de Sixara (core.facturas, core.contactos, core.empresas), que son una copia ordenada de los datos de tu ERP.
  3. De las tablas a Odoo. El catálogo declara el origen de cada métrica. Para deuda vencida: account.move (facturas), res.partner (clientes) y res.company (empresas).
  4. De ahí al registro. Con esos tres modelos puedes abrir en Odoo las facturas que componen el total y revisarlas una a una.

Hay además una verificación contra Odoo. Para las ventas del mes, la plataforma compara el total de sus tablas con el total que informa Odoo para el mismo período. Si hay una diferencia mayor a la tolerancia, la métrica se bloquea hasta resolverla, en vez de publicar una cifra que no cuadra. Hoy esa conciliación cubre las ventas; no la presentamos como si cubriera todo el catálogo.

Otro punto de auditoría es el registro: el chat cita la fuente de lo que responde, y las llamadas a la IA, las acciones y las aprobaciones quedan registradas. Si alguien pregunta "¿por qué dijo esto el martes?", hay con qué responder.

¿Qué pierde una empresa con un número convincente pero falso?

Pierde en cuatro frentes, casi siempre sin saberlo:

  • Decisiones mal calibradas. Se presiona la cobranza donde no hacía falta, o se compra stock que no se necesitaba, sobre una cifra que parecía firme.
  • Confianza interna. La primera vez que alguien descubre una cifra falsa en un informe, deja de creerle al resto. Recuperarla cuesta mucho más que haberla cuidado.
  • Tiempo. Cuando no se confía en el informe, cada reunión empieza con una auditoría manual en planillas, que es justo lo que la automatización debía evitar.
  • Responsabilidad. Si un banco, un socio o un auditor pregunta de dónde sale una cifra y la respuesta es "lo dijo el asistente", no hay respuesta.

Ante esto, nuestra recomendación para cualquier empresa que evalúe un asistente de IA sobre sus datos es una prueba simple: pídele que te muestre la definición y los registros detrás de una cifra. Si no puede, no es una cifra, es una opinión. Y si te dice que la IA "calcula bien casi siempre", pregúntale cuál es el "casi" en tu informe de cierre de mes.

Nada de esto significa desconfiar de la IA. Significa usarla donde aporta: entender preguntas en español, explicar resultados, clasificar mensajes de clientes, redactar un borrador de cobranza. Para lo demás están la aritmética y las bases de datos, que llevan décadas haciéndolo bien. Una visión más amplia de qué le corresponde a cada parte está en qué puede hacer la IA conectada a Odoo y qué no.

¿Cuál es el siguiente paso?

Puedes ver en el producto cómo se ve una cifra con su definición y su fuente, o recorrerlo en el demo con datos de ejemplo. Si quieres probarlo con tu propio Odoo, el Diagnóstico de US$349 dura 4 semanas y se descuenta si contratas en los 30 días siguientes. Una buena primera revisión es elegir tres cifras que hoy te cuesta verificar y recorrer juntos su camino hasta Odoo.

Equipo Sixara

Escribimos sobre cómo leer un negocio con sus propios datos. Cada cifra de nuestros ejemplos es ficticia y está marcada como tal.

Tu empresa ya sabe.
Escúchala.

Agenda una demo con tus propios datos. Si no te sorprende, no seguimos.