Lena Levin, CEO de Octopus AI, publicó esta semana una tesis directa: los LLMs no saben hacer matemáticas, y en finanzas eso no es un bug menor. Su argumento es que en marketing un error pequeño en el copy es perdonable, pero si en finanzas te equivocas por dos dólares, nadie va a volver a confiar en tu sistema. Hay razón para que la frase “cook the books” exista.

Tiene razón en el resultado. Pero la explicación que da es del 2023, y lo que pasó en el último año cambia el porqué y, por lo tanto, la forma de diseñar la solución.

El porqué cambió en septiembre de 2025

El 4 de septiembre de 2025, un equipo de investigadores de OpenAI y Georgia Tech (Adam Tauman Kalai, Edwin Zhang, Ofir Nachum y Santosh Vempala) publicó un paper demostrando algo incómodo: las alucinaciones de los LLMs son matemáticamente inevitables. No es cuestión de datos de entrenamiento ni de tamaño del modelo, y no se arregla con más RLHF, mejores prompts o esperando al siguiente release.

Son tres factores, y cada uno tiene demostración formal:

• Incertidumbre epistémica: cuando un hecho aparece rara vez en los datos de entrenamiento, el modelo aprende a asociarlo con respuestas plausibles, no con la verdad.
• Capacidad representacional: hay tareas que exceden lo que la arquitectura del modelo puede representar internamente, independientemente del tamaño.
• Intratabilidad computacional: incluso un sistema superinteligente no puede resolver problemas computacionalmente duros en tiempo finito.

El paper también señaló algo perverso: nueve de cada diez benchmarks de evaluación penalizan respuestas tipo “no sé” y premian respuestas confiadas, incluso cuando están mal. Es decir, la industria entrenó a los modelos para ser más confiados, no más honestos.

Y por si eso fuera poco, en julio de 2025 Varin y Vishal Sikka (ex-CTO de SAP, ex-CEO de Infosys, fundador de Vianai) publicaron “Hallucination Stations”, un paper que aplica teoría clásica de complejidad (el time-hierarchy theorem) para probar el mismo resultado desde otro ángulo: más allá de cierta complejidad, un LLM no puede ni ejecutar ni verificar correctamente tareas computacionales. La frase de Sikka fue tajante: “There is no way they can be reliable”.

Cuando OpenAI y un ex-CTO de SAP te dicen, desde dos papers distintos y con matemática formal, que tu modelo va a alucinar pase lo que pase, la conversación deja de ser sobre mejores modelos. Pasa a ser sobre arquitectura.

”Pero los modelos modernos llaman a Python”

La primera objeción que vas a escuchar (de hecho, es la primera que aparece en los comentarios del post de Lena) es que los modelos frontera ya no hacen matemáticas “mentalmente”. Llaman a Python, SQL, una calculadora, hojas de cálculo. Delegan la aritmética a sistemas deterministas y solo usan el lenguaje para armar el contexto.

Es cierto. Y es exactamente por eso que el problema se vuelve más sutil, no más simple.

Cuando un modelo llama a una herramienta, alguien tiene que decidir: qué función llamar, qué argumentos pasar, cómo interpretar el resultado y cómo mapearlo de vuelta al contexto del negocio. Todas esas decisiones están en el lenguaje, y el lenguaje sigue siendo donde alucinan los LLMs. Si el modelo elige la columna equivocada de tu plan de cuentas, o pasa un tipo de cambio del mes anterior, o confunde devengado con efectivo, la calculadora va a sumar los números con total precisión. Solo que van a ser los números equivocados.

El problema no desapareció. Se movió de la aritmética a la orquestación. Y la orquestación es un lugar más peligroso para que un error pase desapercibido, porque ya no se ve como un error obvio de suma.

Nombre del patrón: LLM Sandwich

Lena llama a su solución “arquitectura dual”: un motor determinista para matemática y lógica, una capa LLM para contexto, lenguaje y generación de código. Gyde lo llama “LLM Sandwich”: capas deterministas antes y después del LLM, con el modelo de lenguaje como relleno.

Los dos nombres describen el mismo patrón:

1. Capa determinista de entrada: valida permisos, normaliza contexto, enriquece con datos verificados de la fuente autorizada (ERP, plan de cuentas, tipos de cambio oficiales), decide qué puede y qué no puede preguntarse.
2. Capa LLM: hace lo que los LLMs hacen bien (generar texto estructurado, mapear lenguaje natural a operaciones, producir código).
3. Capa determinista de salida: verifica cálculos contra la fuente autorizada, bloquea cualquier número que no tenga trazabilidad, firma digitalmente cada partida con su origen y deja audit trail inmutable.

No es un truco de prompt engineering. Es arquitectura. Y lo que la hace posible no es un modelo más inteligente; es asumir que el modelo va a mentir a veces y construir el sistema para que esa mentira no llegue al reporte.

Es el mismo principio que usamos cuando hablamos de gobernanza para agentes de IA en nómina: el código no confiable se deja trabajar, pero se encierra en primitivas deterministas que validan cada acción antes y después.

Lo que el mercado ya entendió

Si crees que este tipo de escepticismo es cosa de ingenieros paranoicos, mira lo que dicen los CFOs. Un estudio de Wakefield Research reportado por CFO Dive encontró que solo el 14% de los CFOs confía completamente en que la IA entregue datos contables correctos sin supervisión humana. Dos tercios consideran que la supervisión humana sobre agentes de IA en finanzas es extremadamente o muy crítica para garantizar exactitud.

Eso no es miedo al cambio. Es lectura correcta del riesgo.

Y no están solos. En febrero de 2026, Darren Mowry, VP de Google, advirtió que dos modelos de negocio populares (los wrappers de LLM y los agregadores de IA) “tienen prendida la luz del check engine”. Su punto no era que la IA estuviera en crisis. Era que las empresas que solo envuelven un modelo con una interfaz linda y le llaman producto no tienen foso, y cuando el modelo de abajo cambia, se caen. El foso está en las capas que van alrededor del modelo, no en el modelo.

Es exactamente el mismo argumento que hace Lena en su post: “The moat in this space isn’t a pretty UI. It’s data plumbing, semantic mapping to your chart of accounts, and outputs a CFO can actually sign off on”.

Tres voces (una CEO de IA financiera, un VP de Google, un paper de OpenAI) diciendo la misma cosa desde ángulos distintos en menos de seis meses. Cuando pasa eso, deja de ser opinión y se vuelve patrón.

Lo que hacemos en IQ Source

Cuando construimos sistemas de IA para empresas de Costa Rica y Latam que tocan finanzas, nómina, cumplimiento regulatorio o cualquier dato donde un error cuesta dinero o confianza, la arquitectura siempre envuelve al modelo. El LLM nunca es la última palabra: antes pasa por capas que validan permisos y contexto, y después por capas que verifican resultados contra fuentes autorizadas.

No es una preferencia estética. Es la respuesta honesta a lo que OpenAI y los Sikka acaban de probar en papel. Si la alucinación es permanente, tu arquitectura tiene que asumirlo desde el día uno. Es la diferencia entre un sistema que funciona en el demo y uno que sobrevive en producción, que es la misma distinción que hemos estado haciendo sobre riesgos de código no supervisado.

Lo contraintuitivo del asunto es que asumir que los LLMs van a alucinar para siempre no es la posición pesimista. Es la posición madura. El optimista ingenuo cree que el próximo modelo lo va a resolver. El ingeniero serio diseña su sistema para que no le importe.

Si estás construyendo IA encima de tu ERP, tu sistema de facturación o tu flujo financiero y todavía estás esperando que “el próximo modelo sea mejor en matemática”, vale la pena revisar la arquitectura antes de que tu primer error de dos dólares llegue al board. Si te interesa una segunda opinión sobre cómo están envolviendo a tu LLM hoy, escríbenos.