Determinismo antes que LLM: cuándo un diccionario o una función bien escrita vence al modelo

Aduanera del Estrecho es una empresa de gestión aduanera con sede en Algeciras, 42 empleados, factura alrededor de 8 millones al año despachando contenedores en el puerto. En febrero de 2026 el director técnico contrata a una consultora para "meter IA" en el flujo de clasificación arancelaria. La consultora conecta GPT-4o a la entrada del ERP: cada línea de factura de proveedor pasa por el modelo para asignar el código TARIC de 10 dígitos. El sistema procesa unas 18.000 líneas al mes. La factura de OpenAI el primer mes: 1.240 euros. La tasa de error: 11%. Un despachador sénior corrige a mano cada línea porque un TARIC mal asignado son entre 300 y 2.000 euros de arancel mal liquidado.

Cuando entro a revisar el flujo, la pregunta no es cómo mejorar el prompt. La pregunta es por qué hay un LLM ahí. El TARIC es un catálogo cerrado. Está publicado por la Comisión Europea, se descarga en XML, cambia dos veces al año. Reemplazamos el LLM por una función de matching contra el catálogo oficial más una tabla de sinónimos que mantiene el despachador sénior. Coste mensual: 0 euros de API. Tasa de error: 0,7%, todos casos ambiguos que el propio catálogo marca como tales.

El modelo no fallaba por malo. Fallaba porque no debía estar ahí.

Este es el error caro que veo repetido en el 90% de las arquitecturas heredadas con IA. El modelo aplicado a una tarea que se resuelve con código o con un catálogo bien mantenido.

Ya aplica.

Las cinco familias de tareas que no necesitan modelo

Antes de meter un LLM, hay que descartar cinco tipos de tarea donde el modelo siempre pierde por coste, por precisión o por trazabilidad. Si tu problema encaja en alguna de estas cinco familias, el LLM sobra.

• Clasificación contra catálogo cerrado. Códigos TARIC, CNAE, CPV, IBAN por país, códigos postales, provincia por prefijo. El conjunto de respuestas válidas es finito y está publicado por un organismo oficial. La respuesta correcta o está en la tabla o no existe.
• Validación de formato con reglas conocidas. DNI, NIE, IBAN, CIF, matrículas, número de la Seguridad Social, referencia catastral. Cada uno tiene un algoritmo de dígito de control documentado. Una función de 20 líneas devuelve verdadero o falso sin ambigüedad.
• Transformación determinista de un dato a otro. Fecha ISO a DD/MM/AAAA, mayúsculas a minúsculas, quitar tildes para búsqueda, calcular edad desde fecha de nacimiento, convertir moneda con tipo de cambio del BCE del día. Uno a uno, sin criterio.
• Ruteo basado en reglas explícitas. Si el importe supera 3.000 euros, aprobación del director financiero. Si el proveedor está en la lista negra, bloquear. Si el país no está en la lista blanca, escalar. Un árbol de decisiones lo hace en un milisegundo con logs perfectos.
• Búsqueda exacta o casi-exacta en una base propia. Encontrar un cliente por email, un producto por SKU, un contrato por número de expediente. Un índice de base de datos resuelve en microsegundos con precisión del 100%.

Estas cinco familias cubren buena parte del volumen de tareas de un flujo empresarial medio. Meter un LLM en cualquiera de ellas es pagar más por hacer peor lo que ya sabías hacer bien.

Regla: si puedes escribir el criterio de decisión en una frase que empiece por "si el valor está en esta lista" o "si cumple este patrón", el LLM sobra.

Cuánto cuesta usar un modelo donde no toca

El coste de meter un LLM en una tarea determinista no es solo la factura de API. Es la suma de cuatro capas que casi nadie cuenta cuando compra la propuesta del consultor.

Los números que siguen son de un ejercicio de comparación que hice sobre el flujo real de Aduanera del Estrecho durante el primer trimestre de 2026, con las tarifas públicas de OpenAI y Anthropic vigentes en marzo de 2026 (GPT-4o a 2,50 dólares por millón de tokens de entrada, Claude Sonnet 4.5 a 3 dólares por millón). Sirve como orden de magnitud, no como benchmark universal.

Coste comparado por 10.000 líneas de clasificación TARIC:

• LLM sin catálogo. 68 euros de API, 11% error, 6 horas semanales de un despachador revisando y corrigiendo. Coste total con hora de despachador a 32 euros brutos: 260 euros por 10.000 líneas.
• LLM con catálogo cargado en el prompt. 214 euros de API porque el catálogo TARIC ocupa muchos tokens, 3% error, 2 horas de revisión. Coste total: 278 euros. Peor que sin catálogo, porque los tokens de contexto dispararon la factura.
• LLM con RAG contra el catálogo. 41 euros de API, 2,5% error, 1,5 horas de revisión. Coste total: 89 euros. Mejor, pero con infra adicional (base vectorial, pipeline de ingesta, monitorización).
• Función determinista contra catálogo oficial. 0 euros de API, 0,7% error, 20 minutos semanales de revisión de casos que el propio catálogo marca como ambiguos. Coste total: 11 euros.

La función determinista es 24 veces más barata que el LLM sin catálogo y 8 veces más barata que el LLM con RAG. Y la precisión es superior en las tres comparaciones.

Traducción: cuando la tarea es determinista, cada euro que gastas en el LLM es un euro que pagas por peor resultado.

Hay una capa más que rara vez se contabiliza: la trazabilidad. Cuando el despachador tiene que justificar ante inspección de Aduanas por qué asignó un TARIC concreto, con la función determinista muestra la línea del catálogo que hizo match. Con el LLM muestra un prompt y una respuesta que el modelo podría generar distinta la próxima vez. Ese es un coste que no aparece en la factura hasta que llega la inspección.

Por qué el modelo se inventa respuestas cuando el criterio ya existe

Aquí está la parte que a mucha gente le cuesta aceptar. Un LLM no es un sistema de recuperación de información. Es un sistema de generación probabilística. Cuando le pides que asigne un código TARIC y el modelo no ha visto ese producto exacto en el entrenamiento, no dice "no lo sé". Genera el código que estadísticamente es más probable dado el contexto.

Y la respuesta más probable no es la respuesta correcta.

Un caso real del flujo de Aduanera del Estrecho: un proveedor chino describe un producto como "aluminium foil roll, food grade, 30 micron". El TARIC correcto es 7607111990, papel de aluminio de espesor inferior a 0,021 mm, uso alimentario, sin soporte. GPT-4o devuelve consistentemente 7607192090, que es aluminio con soporte. La diferencia arancelaria son 4,2 puntos porcentuales sobre el valor CIF del contenedor. En un contenedor de 24.000 euros, son 1.008 euros mal liquidados. Multiplicado por los aproximadamente 40 contenedores mensuales de este proveedor, 40.000 euros al mes que Aduanas reclama en la próxima inspección.

El modelo no está roto. Está haciendo exactamente lo que se le pidió: generar la respuesta más probable. El problema es que la respuesta más probable no coincide con la respuesta correcta cuando el criterio de decisión ya está codificado en un documento oficial.

El LLM no consulta la Comisión Europea. Consulta su memoria estadística de haber visto muchos textos que hablaban de aluminio.

Esto se agrava en tres escenarios donde nunca deberías dejar decidir a un modelo generativo:

• Cuando la respuesta tiene consecuencias legales o fiscales. TARIC, IVA por categoría, retenciones IRPF, códigos de la Seguridad Social. El regulador espera trazabilidad. El modelo no la tiene.
• Cuando el catálogo cambia y el modelo no lo sabe. El TARIC se actualiza dos veces al año. Un modelo entrenado en enero de 2025 no conoce los códigos añadidos en julio. Preguntarle es garantizarte respuestas obsoletas.
• Cuando el mismo input debe producir el mismo output siempre. Un LLM con temperatura mayor que cero puede dar respuestas distintas a la misma pregunta. Un catálogo no. Si el auditor te pide reproducir el resultado de una clasificación de hace tres meses, la función determinista te lo da. El LLM no.

Síntoma: el modelo devuelve respuestas plausibles pero inconsistentes entre ejecuciones. Solución: sacarlo del flujo y sustituirlo por lookup contra la fuente oficial.

El patrón catálogo vivo mantenido por el negocio

Cuando reemplazo un LLM por una función determinista, no basta con hardcodear una tabla en el código. Eso es lo que quema al equipo técnico en tres meses cuando el catálogo cambia y nadie sabe cómo actualizarlo. El patrón que funciona es lo que llamo catálogo vivo, y tiene cuatro capas.

La primera capa es la fuente autoritativa. TARIC lo publica la Comisión Europea. CNAE lo publica el INE. Códigos postales los publica Correos. IBAN por país los publica SWIFT. Cada catálogo tiene un dueño externo que decide qué códigos existen. Descarga el catálogo original en su formato oficial (XML, CSV, JSON) y guárdalo intacto en un directorio versionado. Nunca edites este archivo.

La segunda capa es el catálogo derivado. Es una versión de la fuente autoritativa transformada al formato que tu sistema necesita: una tabla en Postgres, un JSON en el bucket S3, un archivo pickle en memoria. Este catálogo se regenera automáticamente cada vez que llega una nueva versión del catálogo oficial. Cero intervención manual.

La tercera capa es la tabla de sinónimos y overrides. Aquí es donde el negocio manda. En Aduanera del Estrecho, el despachador sénior mantiene una hoja de cálculo con tres columnas: descripción libre del proveedor, código TARIC oficial que aplica, notas. Cuando un proveedor chino escribe "aluminium foil roll, food grade, 30 micron", la tabla tiene una línea que dice "aluminium foil food grade < 40 micron -> 7607111990". La función de matching consulta primero la tabla de sinónimos, y solo si no hay match cae al catálogo oficial. Esta tabla la mantiene la persona del negocio que conoce el dominio, no el ingeniero.

La cuarta capa es el registro de casos no resueltos. Cuando la función no encuentra match ni en sinónimos ni en el catálogo oficial, el caso se guarda en una cola de revisión. El despachador sénior la revisa una vez a la semana, decide qué código aplica y añade la línea correspondiente a la tabla de sinónimos. El sistema aprende, pero el aprendizaje lo dirige una persona con criterio, no un modelo.

Este patrón tiene tres ventajas que ningún LLM da:

• Auditable. Cada decisión de clasificación deja un rastro: qué línea del catálogo o de sinónimos hizo match, cuándo se añadió, quién la añadió. Inspección tributaria lo agradece.
• Determinista. El mismo input produce siempre el mismo output. Si algo cambia es porque alguien lo cambió a propósito, y queda registrado.
• Barato. Cero API. Un servidor pequeño resuelve millones de consultas al día. La infraestructura la mantiene la misma persona que ya mantenía el ERP.

En Aduanera del Estrecho la tabla de sinónimos creció de 0 a 340 líneas en los primeros dos meses. A partir del cuarto mes el ritmo de crecimiento cayó a 3-4 líneas nuevas por semana. El sistema se estabilizó porque los proveedores repiten productos.

Un LLM nunca se estabiliza. Cada mes te cobra igual porque no aprende de tus correcciones si no montas un fine-tuning, y montar fine-tuning para clasificar TARIC es exactamente el tipo de arquitectura que necesitas evitar.

Cuándo el diccionario deja de ser suficiente

No estoy diciendo que el LLM no sirva. Estoy diciendo que sirve para tareas concretas donde la variabilidad del input no cabe en ningún catálogo por grande que sea. Hay una línea clara que marca cuándo el diccionario se queda corto y hay que subir de nivel.

Hay que subir de nivel cuando aparece cualquiera de estas cuatro señales:

• El input es texto libre con estructura semántica variable. Una queja de cliente escrita en un email, una descripción de síntomas médicos, una respuesta abierta a una encuesta. No hay catálogo de "quejas posibles". El modelo aporta valor porque genera comprensión.
• La respuesta requiere combinar múltiples fuentes de conocimiento. Redactar un resumen ejecutivo a partir de tres informes distintos, sintetizar una respuesta legal que combine jurisprudencia y regulación, generar un guion de llamada que use histórico del cliente. Aquí el modelo compone.
• La tarea es intrínsecamente subjetiva. Redactar un email en tono profesional, sugerir un titular llamativo para un blog, traducir manteniendo registro cultural. No hay respuesta correcta única. El modelo genera variantes plausibles.
• El coste de un error es bajo o hay revisión humana obligatoria antes de publicar. Draft de respuesta a un cliente que un humano revisa, sugerencia de código que un programador acepta o rechaza, resumen de reunión que se comparte para validación. El modelo asiste, no decide.

Cuando ninguna de estas señales aparece, el LLM está de más. Cuando alguna aparece, el LLM puede aportar valor. Aun así, la pregunta siguiente es qué parte del flujo puede seguir siendo determinista.

Un ejemplo concreto. Consultoría Administrativo, una asesoría de Sevilla con 18 empleados, quiere clasificar y responder tickets entrantes de clientes. Análisis del flujo:

• Clasificar el ticket por área (fiscal, laboral, contable, mercantil): tarea determinista. Se hace con una lista de palabras clave que la propia asesoría mantiene. 92% de acierto sin LLM.
• Detectar urgencia: tarea determinista. Si el ticket menciona "requerimiento", "notificación", "plazo", "hoy", "mañana", se marca urgente. Regex simple.
• Enrutar al gestor responsable: tarea determinista. Tabla cliente-gestor mantenida en el CRM.
• Redactar borrador de respuesta con tono asesoría: aquí sí, LLM. El input es texto libre y el output es texto libre con matiz profesional.

El flujo pasa de "LLM en toda la cadena" a "LLM solo en la última milla". Coste de API baja un 78%. Latencia baja un 60%. Precisión del enrutado sube del 71% al 94%. El LLM sigue siendo útil, pero solo en el paso donde aporta.

Regla: el LLM entra en el flujo donde el criterio no puede escribirse. Si puede escribirse, escribe el criterio.

Cómo detectar código heredado con LLM mal ubicado

Cuando reviso una arquitectura heredada, tengo seis preguntas rápidas que me dicen en 20 minutos si el LLM está bien puesto o mal puesto. Son las mismas preguntas que puedes hacer tú antes de contratar a nadie.

• ¿Cuál es el conjunto de respuestas posibles? Si es finito y publicable como lista, no necesitas modelo generativo. Un catálogo basta.
• ¿La respuesta correcta cambia con el tiempo por motivos técnicos o regulatorios? Si sí, el LLM entrenado en fecha fija te dará respuestas obsoletas. Necesitas fuente autoritativa consultable en tiempo real, con o sin modelo por encima.
• ¿El mismo input debe producir el mismo output siempre? Si sí, el LLM con temperatura mayor que cero está descartado. Si estás dispuesto a fijar temperatura a 0 y aun así aceptas variabilidad entre versiones del modelo, revisa si la tarea es determinista.
• ¿Un humano puede escribir en una frase el criterio para decidir? Si sí, ese criterio es código. Un if, un lookup, una regex. El LLM está de más.
• ¿Hay una fuente de datos oficial descargable que ya contiene la respuesta? TARIC, CNAE, BOE, DOUE, catálogo de medicamentos AEMPS, códigos postales de Correos. Si la respuesta está en un archivo público, consultar el archivo es más barato y más preciso que preguntar al modelo.
• ¿El coste de un error es alto? Si sí, el LLM sin trazabilidad es un pasivo. O metes una capa determinista de validación posterior o quitas el modelo del flujo crítico.

Si respondes "sí, catálogo cerrado" o "sí, hay fuente oficial" en cualquiera de estas seis preguntas, tienes un LLM mal ubicado en el flujo.

Errores frecuentes al rediseñar un flujo con determinismo

Cuando se hace bien, un rediseño de este tipo se completa en dos o tres semanas. Cuando se hace mal, se tarda meses y se queda a medias. Estos son los cinco errores que veo repetidos.

• Error 1: Sustituir sin medir el estado inicial. Síntoma: quitas el LLM y no puedes demostrar cuánto mejoró la precisión. Solución: antes de tocar nada, ejecuta 500 casos manuales, mide precisión y coste, guarda el resultado. Sin baseline no hay mejora demostrable.
• Error 2: Hardcodear el catálogo en el código. Síntoma: seis meses después nadie sabe cómo actualizar los códigos TARIC porque están en un array dentro de un archivo .py que solo el ingeniero original entendía. Solución: el catálogo vive en una tabla o en un archivo separado del código, con un proceso documentado de actualización desde la fuente oficial.
• Error 3: No dar propiedad de la tabla de sinónimos al negocio. Síntoma: la persona del dominio tiene que abrir un ticket al equipo técnico cada vez que quiere añadir una línea. En dos meses la tabla está desactualizada. Solución: la tabla de sinónimos vive en una hoja de cálculo o en un panel de admin editable por la persona del dominio, sin intervención técnica.
• Error 4: Dejar el LLM como plan B sin criterio de salida. Síntoma: cuando el catálogo no da match, el flujo llama al LLM como respaldo. Sin registro de esos casos, el LLM vuelve a decidir por su cuenta y la trazabilidad se pierde otra vez. Solución: cuando el catálogo no da match, el caso va a una cola de revisión humana. El LLM solo se usa si el humano lo autoriza explícitamente para ese tipo de caso.
• Error 5: No versionar el catálogo. Síntoma: en enero clasificaste 12.000 productos con un TARIC. En abril un cliente reclama y pides reproducir la clasificación de enero. No puedes porque el catálogo se actualizó en marzo y no guardaste la versión anterior. Solución: cada versión del catálogo oficial se guarda con fecha. La función de clasificación puede recibir un parámetro de fecha para consultar la versión vigente ese día.

Ninguno de estos errores es técnico. Los cinco son de proceso. Por eso el rediseño lo tiene que dirigir alguien que entienda de datos, de negocio y de arquitectura al mismo tiempo. Un backend puro se queda en "hice la función". Un consultor puro se queda en "definí el proceso". Falta el puente.

Preguntas frecuentes

¿Cuándo no se debe usar un LLM en un flujo empresarial?

Cuando la tarea encaja en una de estas cinco familias: clasificación contra catálogo cerrado, validación de formato con reglas conocidas, transformación determinista de un dato a otro, ruteo basado en reglas explícitas, o búsqueda exacta en una base propia. En todos estos casos el LLM es más caro, menos preciso y menos auditable que una función determinista. La regla rápida: si puedes escribir el criterio de decisión en una frase que empiece por "si el valor está en esta lista" o "si cumple este patrón", el LLM sobra.

¿Qué tareas se resuelven mejor con código o con un diccionario que con IA?

Todas las que tienen respuesta única y verificable. Asignar un CNAE a una empresa a partir de su actividad principal (5.000 códigos posibles publicados por el INE), validar un IBAN español (algoritmo de dígito de control conocido), calcular el IVA aplicable a un producto según su código de familia (tabla mantenida por el departamento fiscal), enrutar un email al departamento correcto según remitente (tabla de cuentas mantenida por RRHH), convertir divisas al tipo de cambio del BCE del día (endpoint público del Banco Central Europeo). Ninguna de estas tareas mejora con LLM.

¿Cómo saber si una tarea necesita modelo generativo o basta con determinismo?

Hazte cuatro preguntas. Uno: ¿el conjunto de respuestas posibles es finito y publicable como lista? Si sí, no necesitas modelo. Dos: ¿el mismo input debe producir siempre el mismo output? Si sí, no necesitas modelo con variabilidad. Tres: ¿un humano del dominio puede escribir el criterio de decisión en una frase? Si sí, ese criterio es código. Cuatro: ¿existe una fuente oficial descargable con la respuesta? Si sí, consultar la fuente es más barato y más preciso. Si respondes "no" a las cuatro y la tarea implica texto libre con estructura semántica variable, entonces sí, el modelo aporta. En caso contrario, determinismo.

¿Por qué un catálogo de códigos puede ser mejor que preguntar a ChatGPT?

Por tres razones que la factura no muestra. Primero, precisión: el catálogo oficial es la fuente autoritativa, el modelo es una aproximación estadística que puede alucinar códigos plausibles pero incorrectos. Segundo, trazabilidad: el catálogo devuelve la línea exacta que hizo match, auditable ante inspección; el modelo devuelve una respuesta que puede variar entre ejecuciones. Tercero, coste marginal: cada consulta al catálogo es prácticamente gratis, cada consulta al modelo tiene un precio por token que se multiplica por volumen. En tareas de clasificación arancelaria, contable o regulatoria, el catálogo gana en las tres dimensiones.

¿Qué hago si mi flujo actual ya tiene un LLM mal puesto?

Sigue este orden. Uno: mide el estado actual con 500 casos manuales. Precisión, coste por 1.000 casos, latencia. Sin baseline no hay negociación con el proveedor ni con la dirección. Dos: identifica en qué paso del flujo aparece el modelo y aplícale las seis preguntas de detección de la sección anterior. Tres: si el LLM está mal ubicado, diseña la sustitución en cuatro capas (fuente oficial, catálogo derivado, tabla de sinónimos, cola de revisión). Cuatro: ejecuta la sustitución en paralelo al sistema actual durante dos semanas, comparando resultados caso por caso. Cinco: cuando la función determinista supera al LLM en precisión y coste, apagas el LLM. Todo el proceso rara vez pasa de tres semanas si tienes acceso al código y a la persona del dominio.

¿El determinismo aplica también a agentes autónomos?

Sí, y ahí importa más. Un agente autónomo que ejecuta acciones (envía emails, mueve dinero, actualiza registros) sin humano en el bucle multiplica el coste de cada decisión mal tomada. La arquitectura correcta es agente para razonar sobre input variable, código determinista para ejecutar cualquier acción con efecto lateral. El agente propone, la función determinista dispone. Si el agente decide asignar un TARIC y ejecutar el despacho sin pasar por la capa de catálogo, no tienes agente autónomo, tienes agente sin control.

Cierre

El error caro no es el modelo mal elegido. Es el modelo puesto donde no toca.

Cada mes que tu flujo pasa 200 euros a OpenAI para clasificar códigos que están publicados en un XML gratuito de la Comisión Europea, es un mes que estás pagando por peor resultado. Cada trimestre que el despachador sénior corrige a mano las respuestas del LLM en lugar de mantener una tabla de sinónimos, es un trimestre de sueldo consumido en resolver un problema que no debía existir. Cada auditoría que llega y no puedes reproducir la clasificación de hace seis meses porque el modelo ya no está disponible en esa versión, es un pasivo latente en tu arquitectura.

Determinismo primero. El modelo va donde el determinismo no llega, no antes.

Si tienes un flujo con LLM que sospechas mal ubicado y quieres revisar en qué pasos el determinismo gana, reserva una cita de 30 minutos para hacer juntos el diagnóstico de los seis criterios y salir con una lista concreta de qué pasos del flujo pueden pasar a código y cuáles justifican mantener el modelo. Si prefieres explorar antes qué modelo aplica a cada tipo de tarea, en la página modelos de IA por tarea tienes el mapa completo.

Lecturas relacionadas

• Escala semántica: cuándo escalar del diccionario al embedding al LLM
• Coste real de una arquitectura con LLM: la factura que nadie te enseña
• Auditoría de flujos heredados con IA en seis criterios

Fuentes

• Comisión Europea, base de datos TARIC oficial: ec.europa.eu/taxation_customs/dds2/taric
• INE, clasificación CNAE 2025: ine.es/dyngs/INEbase/es/operacion.htm?c=Estadistica_C&cid=1254736177032
• OpenAI, tarifas de API vigentes en marzo de 2026: openai.com/api/pricing
• Anthropic, tarifas de API vigentes en marzo de 2026: anthropic.com/pricing