Por qué los agentes de IA alucinan en operaciones (y cómo una arquitectura determinista lo evita)

Cuando un modelo de lenguaje se conecta directamente a una base de datos empresarial para responder preguntas de negocio, el riesgo más peligroso no es que lance un error 500 o diga que no sabe. El riesgo mortal es que entregue un número completamente incorrecto con total seguridad y elocuencia ejecutiva, sin que ninguna excepción técnica alerte al equipo.

En el mundo de la ingeniería de software a esto se le conoce como alucinación silenciosa (silent mathematical hallucination). En marketing o redacción creativa, una imprecisión lingüística es inofensiva; en finanzas corporativas, tesorería o conciliación tributaria en SAP, un número mal sumado puede costar millones de dólares o derivar en contingencias legales con el SII.

"Un LLM es un motor probabilístico de predicción de tokens, no una calculadora financiera. Pedirle a GPT-4 o Claude que ejecute SQL crudo sobre tu contabilidad es el equivalente a confiar el balance general a un poeta."

La anatomía del desastre: El temido "Fan-Out" en Joins 1-a-N

Para entender por qué falla la IA generativa en datos relacionales, analicemos el caso más frecuente en cualquier empresa con ERP: la relación entre Órdenes de Venta y Líneas de Pago.

Supongamos que un Gerente General le pregunta a un asistente de IA: "¿Cuál fue el total pagado por el cliente Acme Corp este trimestre?".

El modelo de lenguaje, en su afán de ser servicial, escribe una consulta SQL uniendo la tabla orders con order_items y payments:

SELECT SUM(p.amount) 
FROM orders o
JOIN order_items i ON o.id = i.order_id
JOIN payments p ON o.id = p.order_id
WHERE o.customer = 'Acme Corp';

¿Qué ocurrió aquí? Si la orden tenía 4 productos (ítems), el JOIN multiplicó cada registro de pago por 4. La base de datos ejecutó la consulta en 8 milisegundos, retornó $48.000.000 CLP en lugar de los $12.000.000 CLP reales, y la IA redactó: "El total pagado por Acme Corp fue de $48M, evidenciando un crecimiento sostenido del 300%".

El ejecutivo recibe un reporte impecable, perfectamente formateado y completamente falso. Nadie sospecha hasta la auditoría de fin de año.

Cómo David resuelve el problema: El Compilador AST en 4 Pasos

En Guren AI diseñamos a David (nuestro trabajador digital arquitecto de datos) bajo un principio no negociable: los modelos de lenguaje nunca tocan la base de datos SQL directamente.

La arquitectura funciona mediante una máquina de estados determinista dividida en cuatro capas herméticas:

Paso 1: Extracción de Intención a Árbol Semántico (AST)

Cuando el usuario pregunta por ventas o balances, David no genera SQL. Genera un objeto estructurado que declara dimensiones, métricas y filtros en base a un esquema estricto de GraphQL/JSON Schema.

Paso 2: Validación de Tipos y Guardrails de Esquema

El compilador analiza si las dimensiones solicitadas son matemáticamente compatibles. Si un usuario intenta sumar una métrica que no es aditiva (como márgenes porcentuales ponderados) o realizar un join 1-a-N no certificado, el AST es rechazado en memoria en 0.2 milisegundos con una explicación técnica clara.

Paso 3: Ensamblado Determinista de la Consulta

La consulta final que se envía a SAP HANA, PostgreSQL o BigQuery es ensamblada por código determinista compilado y auditado, utilizando únicamente vistas materializadas y consultas paramétricas probadas.

Paso 4: Trazabilidad Criptográfica Inmutable

Cada cifra entregada viene acompañada de su Certificate of Provenance: el hash de la consulta ejecutada, el usuario autorizante, el snapshot temporal de la base de datos y la fórmula exacta empleada.

Benchmark Comparativo: Resultados sobre 100.000 Transacciones

Sometimos esta arquitectura a una prueba de fuego contra 50 consultas analíticas complejas en un ambiente simulado con 100.000 transacciones comerciales de una cadena de retail en Chile:

5 Preguntas que debes hacerle a cualquier proveedor de "IA para Finanzas"

Si estás evaluando asistentes inteligentes para conectar a tus sistemas contables, haz estas preguntas directas antes de firmar cualquier contrato:

• ¿Cómo previenen la duplicación de datos en órdenes con cuotas o múltiples pagos? Si responden que "el modelo aprende la relación leyendo el schema", están usando text-to-SQL probabilístico y van a alucinar.
• ¿Qué capa intermedia valida la consulta antes de que toque el motor SQL? Debe existir un validador estricto independiente del LLM.
• ¿El sistema puede decir "esta consulta viola la política semántica" en lugar de inventar un cálculo aproximado?
• ¿Cómo garantizan que un Gerente de Ventas no acceda al balance de nóminas de Recursos Humanos mediante prompt injection?
• ¿Existe un registro auditable e inmutable de cada cálculo para presentar al auditor externo?

El Futuro de las Finanzas Autónomas

La inteligencia artificial generativa transformará las operaciones y la toma de decisiones empresariales, pero solo aquellas compañías que construyan sobre cimientos deterministas podrán disfrutar de sus beneficios sin arriesgar la integridad de sus balances financieros.