Modos de falla de un LLM, cálculos, no determinismo, alucinación y registro de auditoría

Un agente de auditoría de gastos aplica bien la política, pero de vez en cuando suma mal los totales de un informe y marca a la persona equivocada. En otra empresa, una financiera planea responder a los auditores regenerando las explicaciones de sus preselecciones de crédito con temperatura cero, “para que salgan iguales”. Los dos diseños tratan al modelo como algo que no es.

Lo que un LLM no es

Un LLM no es una calculadora, ni una base de datos, ni un sistema determinista. Cada modo de falla (failure mode) conocido tiene su control, y casi nunca ese control es una instrucción más en el prompt:

Modo de falla	Cómo se ve	Control
Aritmética y cálculos exactos	totales, conversiones o fechas mal calculadas	una herramienta de cálculo (calculation tool) o código, y validación del resultado fuera del modelo
No determinismo (non-determinism)	la misma entrada da salidas distintas, aun con temperatura cero	guardar lo que se produjo; nunca reconstruir regenerando
Alucinación	datos, citas o políticas inventadas con tono seguro	anclar en documentos, citas verificables, permiso para decir “no sé”
Fecha de corte de conocimiento (knowledge cutoff)	información desactualizada presentada como vigente	recuperar de fuentes actuales con su fecha
Deriva en contextos largos	reglas que se cumplen menos en conversaciones largas	controles fuera del modelo (lección de guardrails en capas)
Confianza mal calibrada	suena igual de seguro cuando acierta que cuando no	combinar la confianza declarada con señales verificables: validaciones, coincidencia con fuentes, reglas de negocio

La división del trabajo es la idea central: el modelo hace lo que hace bien (interpretar, aplicar un criterio, redactar) y delega lo que tiene que ser exacto. En el agente de gastos, la política se queda en el modelo y los totales los calcula una herramienta, con una verificación en código antes de marcar a nadie.

El registro de auditoría

Si un regulador o un cliente pregunta “¿por qué se decidió esto?”, la respuesta no puede depender de volver a correr el modelo. Además de que la salida puede variar, entre la decisión y la auditoría cambian el prompt, el modelo y los datos externos. El registro de auditoría (audit trail) guarda, para cada decisión:

• las entradas tal como se usaron, incluidos los documentos recuperados y los datos de terceros consultados;
• la versión del prompt, el ID del modelo y los parámetros;
• las llamadas a herramientas y sus resultados;
• la salida completa y lo que hizo después la persona que revisó, si la hubo;
• fecha y hora, con un identificador que conecte todo.

Ese registro se diseña como un requisito más: retención según la norma que aplique, acceso restringido y tratamiento de los datos personales que contiene. Fijar el prompt y el modelo para siempre no lo reemplaza; solo congela el sistema sin garantizar que la regeneración coincida.

Las trampas típicas

• Bajar la temperatura a cero para que “las cuentas den siempre igual”: da el mismo error de forma más consistente.
• Pedirle al modelo que razone cada suma paso a paso o pasar a uno más grande: equivoca menos, pero sigue sin ser exacto.
• Planear la auditoría regenerando salidas, aunque sea con temperatura cero o top_k en uno.
• Guardar solo el texto de la explicación, sin las entradas que la produjeron.
• Usar la confianza que declara el modelo como única puerta para decidir sin revisión.

En el examen

Si el escenario muestra errores de cálculo y el resto del criterio funciona, buscá la opción que delega el cálculo a una herramienta o a código y valida fuera del modelo. Si alguien quiere reconstruir decisiones pasadas regenerándolas, la respuesta es persistir entradas, versiones y salida como registro. Descartá cualquier opción que intente volver exacto o determinista al modelo con parámetros.