Por qué un LLM no debe tomar decisiones solo

Respuesta corta

Los LLM no deben tomar decisiones de negocio por sí solos porque generan lenguaje probable, no verdad verificada. Pueden resumir, clasificar o traducir una pregunta en una solicitud de análisis, pero una respuesta apta para decidir necesita datos gobernados, cálculos deterministas, reglas explícitas y evidencia trazable.

El objetivo práctico no es pedirle a un LLM que “nunca alucine”. Es diseñar un sistema donde no pueda sustituir silenciosamente hechos inventados por evidencia: si faltan datos, debe decirlo; si se requiere una cifra, un motor determinista debe calcularla.

Por qué un LLM no es un motor de decisiones

Un modelo de lenguaje estima el siguiente token a partir de patrones aprendidos y del contexto que recibe. Por eso sirve para comprender una pregunta como “¿qué región incumplió su meta de margen el trimestre pasado?”. No por eso su respuesta equivale a una consulta de base de datos, un cálculo contable o una decisión de política.

Un flujo basado solo en LLM tiene tres límites críticos:

• No determinismo: la misma solicitud puede producir redacción o rutas de razonamiento distintas. - Sin garantía intrínseca de fuente de verdad: una respuesta fluida puede no corresponder a un registro autorizado y vigente. - Sin prueba integrada: puede afirmar una cifra sin mostrar cálculo reproducible, filtros o filas fuente.

Una narrativa convincente no es evidencia.

La gobernanza define qué puede saber y hacer el sistema

La gobernanza es la capa de control alrededor del modelo. Un flujo de inteligencia de decisiones debe definir, como mínimo:

| Control | Qué evita | |---|---| | Conectores autorizados y de solo lectura | Decidir con datos copiados, obsoletos o no autorizados | | Acceso consciente de rol y permisos | Que un usuario vea métricas o registros indebidos | | Definiciones aprobadas de métricas | Que dos equipos calculen distinto “ingreso”, “margen” o “cliente activo” | | Linaje de datos y trazabilidad | Respuestas que no se pueden rastrear a fuente y periodo | | Aprobación humana en acciones relevantes | Que el modelo ejecute decisiones fuera de un proceso responsable |

La gobernanza no hace infalible al modelo. Hace sus límites explícitos, auditables y aplicables.

El razonamiento determinista cambia el papel del LLM

Para preguntas numéricas o basadas en reglas, el LLM debe orquestar, no calcular ni inventar. Un flujo confiable es:

1. Interpretar la pregunta del usuario. 2. Mapearla a métricas aprobadas, fuentes permitidas y un plan de consulta autorizado. 3. Ejecutar una consulta, cálculo, regla o modelo de optimización determinista. 4. Validar resultado contra esquema, unidades, rangos y reglas de negocio. 5. Entregar la respuesta con supuestos, filtros, fuente y límites de certeza.

La parte determinista puede ser SQL, una capa semántica, un motor de reglas, un modelo de hoja de cálculo o una optimización formalmente especificada. Con las mismas entradas autorizadas y la misma lógica produce el mismo resultado: esa es la propiedad matemática que permite repetibilidad.

Para una afirmación acotada—por ejemplo, un total de ingresos definido por una fórmula aprobada—esta arquitectura evita que el LLM invente la cifra: el valor solo se acepta si proviene del cálculo determinista y supera validaciones. No es una demostración matemática de que toda frase de lenguaje natural sea cierta. Es un control que impide presentar un valor no verificado como resultado calculado.

Qué debe significar “sin alucinaciones” en la práctica

Ningún LLM de propósito general puede garantizar honestamente que jamás generará una frase sin respaldo. Un estándar más defendible es:

• no generar cifras si no vienen de un cálculo aprobado; - citar fuente, periodo, filtros y definición de métrica; - rechazar resultados que fallen validación; - responder “no tengo certeza” o pedir aclaración cuando falte evidencia; y - escalar decisiones ambiguas o de alto impacto a un responsable humano.

Así, la falla pasa de ser una invención segura de sí misma a una excepción explícita y auditable.

Ejemplo: “¿Qué clientes están en riesgo?”

Un chatbot sin gobierno puede producir una lista plausible con contexto incompleto. Un sistema gobernado primero define “en riesgo”: por ejemplo, una combinación aprobada de señales de cancelación, estado de pago, fecha de contrato y reglas de uso. Después calcula la puntuación con datos autorizados y actuales, y presenta la lista con definiciones y evidencia.

El LLM puede explicar el resultado en lenguaje natural. No debe ser la autoridad que crea la puntuación.

Nova Insight: pregunta a tus datos, con controles

Nova Insight permite hacer preguntas de negocio en lenguaje natural sin tratar a un chatbot como fuente de verdad. Se conecta a datos de ERP, CRM y hojas de cálculo en modo solo lectura, conserva los datos en su origen y está diseñado para responder “no tengo certeza” en lugar de inventar una respuesta.

En entornos sensibles o regulados, el enfoque puede incluir despliegue privado y acceso gobernado. Cuando se necesita gobierno de datos y flujos conectados a escala enterprise, Nova Cortex aporta la base de plataforma.

Checklist de adopción

Antes de usar IA en un flujo de decisión, pregunta:

• ¿Cada métrica de negocio está definida y aprobada? - ¿Qué fuentes están autorizadas y vigentes? - ¿Qué preguntas requieren cálculo o reglas deterministas? - ¿El usuario puede inspeccionar fuente, filtros y periodo detrás de una respuesta? - ¿Qué sucede cuando la información es incompleta o ambigua? - ¿Quién aprueba recomendaciones que afectan dinero, clientes, empleados o cumplimiento?

Si estas preguntas no tienen una respuesta clara, la organización tiene un chatbot, no inteligencia de decisiones.

Habla con un experto

FAQ

¿Un LLM puede analizar datos de negocio de forma segura?

Puede ayudar cuando el acceso, la selección de fuentes, los cálculos, la validación y el escalamiento están gobernados. No debe usarse como fuente no verificada de hechos.

¿El cálculo determinista elimina todo riesgo de IA?

No. Hace que cálculos acotados sean repetibles y verificables. La calidad de datos, definiciones, autorización e interpretación aún requieren gobierno.

¿Qué debe ocurrir si el sistema no puede responder?

Debe indicar que la evidencia es insuficiente, identificar la información faltante y evitar construir una respuesta plausible.

¿Un dashboard es más seguro que la analítica conversacional?

Ninguno es automáticamente más seguro. Ambos pueden ser confiables si usan datos controlados, métricas definidas y cálculos trazables.