Qué es un LLM y qué no debe hacer en tu empresa

Un LLM (large language model, modelo de lenguaje de gran tamaño) es un sistema de IA entrenado con enormes cantidades de texto para entender y producir lenguaje. En una empresa debe resolver las tareas de lenguaje: leer un correo, clasificar una petición, resumir un contrato o redactar una respuesta. Las tareas que consisten en calcular, consultar, validar o registrar exigen una operativa determinista, que da siempre el mismo resultado ante los mismos datos. Las mejores soluciones combinan ambas: el lenguaje en la frontera y la exactitud en el núcleo.

El conversador y el contable

La irrupción de la IA generativa ha sembrado una confusión comprensible pero costosa: la idea de que cualquier problema de software es, en el fondo, un problema de IA. No lo es. Distinguir qué tareas debe resolver un modelo de lenguaje y cuáles exigen una operativa determinista es hoy una de las decisiones de criterio más rentables que puede tomar una organización.

El viejo dicho lo resume bien: cuando la única herramienta que se tiene es un martillo, todos los problemas acaban pareciendo un clavo. Es la ley del instrumento que popularizó Abraham Maslow (se abre en una pestaña nueva), y describe el momento que atraviesan muchas organizaciones desde que los grandes modelos de lenguaje llegaron al gran público. La pregunta «¿y esto no lo podría hacer la IA?» se cuela a menudo en proyectos que no tienen nada que ver con comprender o generar lenguaje.

La honestidad técnica obliga a responder que a veces podría, pero no debería. Un modelo de lenguaje puede intentar casi cualquier cosa que se le pida con palabras, pero otra cosa es que el resultado sea fiable, sostenible o siquiera económico. Cuando se elige la herramienta antes de diagnosticar el problema, el diagnóstico acaba adaptándose a la herramienta.

Las empresas de tecnología también tenemos parte de responsabilidad. Muchas tareas de negocio podían resolverse desde hace años con software a medida, pero la conversación sobre automatizarlas no ha llegado hasta la aparición de los LLM.

En este artículo proponemos un criterio sencillo para sostener esa conversación con rigor: qué hace bien un LLM, qué hace mejor un sistema determinista, cómo reconocer cuál hace falta en cada caso y cómo se combinan cuando una tarea tiene las dos naturalezas a la vez.

Qué es un LLM y qué hace realmente, y qué no

Un LLM es un intérprete extraordinariamente competente del lenguaje humano. Su mecanismo interno consiste en predecir, fragmento a fragmento, la continuación más plausible de un texto, y de esa capacidad aparentemente modesta emergen habilidades como resumir documentos densos, clasificar mensajes según su intención, redactar borradores con el tono adecuado, extraer datos de un contrato, traducir, reformular o conversar. Ante una frase ambigua, un informe farragoso o un correo desordenado, hace lo que ningún software clásico sabe hacer: entender lo que hay debajo de la letra.

Ese talento lo convierte en un conversador brillante, pero no en un buen contable. No calcula con garantías: puede sumar bien una lista, equivocarse en la siguiente operación y presentar ambos resultados con idéntica seguridad. Es lo que se conoce como alucinaciones (se abre en una pestaña nueva): respuestas falsas pero verosímiles. No conoce los datos de la empresa por sí mismo: no sabe qué pedidos siguen pendientes ni qué condiciones pactó cada cliente, salvo que se le conecte a los sistemas donde está esa información. Y no garantiza la repetibilidad: ante la misma pregunta puede devolver dos respuestas distintas e igual de razonables. Incluso con la configuración más conservadora, un experimento de Thinking Machines (se abre en una pestaña nueva) obtuvo 80 respuestas distintas en 1.000 peticiones idénticas al mismo modelo.

Para una tarea de lenguaje, esa variabilidad es irrelevante o incluso deseable. Dos buenos resúmenes del mismo contrato son igual de útiles, y nadie exige que una carta se redacte siempre con las mismas palabras. Para una tarea operativa, en cambio, es inaceptable: la empresa no puede tener «dos totales plausibles» para una misma cartera de facturas. Necesita el total, el mismo hoy que mañana, verificable por cualquiera que lo consulte. Si un dato alimenta una decisión (un importe, un stock, un plazo, un estado), la fuente tiene que ser un cálculo determinista, no una generación plausible.

Los modelos mejoran en cada generación, pero estas limitaciones nacen de su naturaleza, no de un defecto de fabricación. Un sistema construido para navegar la ambigüedad del lenguaje no puede garantizar a la vez la exactitud de una calculadora, y confundir las dos naturalezas está detrás de buena parte de las decepciones con proyectos de IA. La variabilidad puede acotarse con configuración, y las respuestas de un modelo pueden someterse a verificación automática, pero acotar no es eliminar, y la verificación, para ser fiable, tiene que ser a su vez determinista.

El sistema determinista: el contable de confianza

Frente al conversador, la operativa determinista es el contable de la empresa: exacta y fiable. Una calculadora, una hoja de cálculo, un flujo de trabajo bien diseñado o una consulta a una base de datos comparten una propiedad definitoria: ante la misma entrada, producen siempre la misma salida. Aplican reglas; no improvisan ni interpretan. Nadie quiere que la calculadora opine sobre los números que recibe.

Esa familia de sistemas resuelve la inmensa mayoría de la operativa de cualquier organización: consultar el estado de un pedido, calcular una tarifa según las condiciones pactadas, validar que un formulario esté completo, trasladar datos entre dos sistemas sin perder nada, mantener la lista de expedientes pendientes o aplicar un descuento conforme a la política comercial. Cada operación se ejecuta en milisegundos, con un coste marginal prácticamente nulo y con una propiedad valiosísima cuando algo sale mal: se puede reconstruir exactamente qué pasó, qué se ejecutó, con qué datos y en qué momento, porque cada operación quedó registrada y puede repetirse con exactitud.

Exactitud, repetibilidad, trazabilidad y bajo coste sostienen desde hace décadas la facturación, la contabilidad, la logística o las nóminas, y el desarrollo de software sigue mejorándolos. Cuando una tarea pertenece a este ámbito, la discusión tecnológica ya está resuelta: llevarla al terreno de la IA generativa solo añade una capa de interpretación probabilística a una operación que necesita precisamente lo contrario.

IA generativa o automatización: en qué se diferencian

La IA generativa interpreta y produce lenguaje, y su resultado puede variar de una vez a otra. La automatización clásica ejecuta reglas fijas sobre datos conocidos y da siempre el mismo resultado. No compiten: la primera sirve para entender lo que llega en lenguaje libre, y la segunda para operar con exactitud sobre lo que ya está en los sistemas de la empresa.

El coste de confundir las dos naturalezas

La confusión funciona en los dos sentidos, y cada uno tiene su precio.

El primer error, y hoy el más frecuente, es tratar tareas de cálculo y consulta como problemas de lenguaje. Si la información ya está en un sistema de la empresa (qué expedientes esperan firma, qué facturas siguen impagadas, qué stock queda de un artículo), la solución natural es mostrarla con una vista filtrada, un listado o un informe. Pedir a un modelo de lenguaje que la reconstruya a partir de texto es peor en todo lo que importa a la operativa: más lento, más caro por consulta y sin garantía de que la cifra sea exacta. La IA no añade exactitud a un dato; añade una interpretación donde no hace falta ninguna.

El segundo es el caso inverso: forzar tareas de lenguaje a reglas rígidas. Por ejemplo, clasificar los correos entrantes con listas de palabras clave: si contiene «factura», a facturación; si contiene «baja», a cancelaciones. Pero el lenguaje humano es demasiado abierto para esa jaula. El cliente que quiere cancelar puede escribir «no me interesa seguir», «canceladme lo que tengo» o «quiero que esto se acabe ya», y ninguna lista cubre esos matices sin falsos positivos. El resultado es un listado inmenso de excepciones que exige revisión constante y nunca abarca todos los casos. Aquí el LLM hace con soltura lo que las reglas no pueden: leer la intención más allá de la letra.

En ambos casos el error es de diagnóstico: elegir la herramienta antes de preguntarse qué naturaleza tiene la tarea. El resultado son proyectos caros que resuelven mal un problema trivial, o automatizaciones rígidas que se rompen con el primer caso imprevisto.

El LLM en la frontera, las reglas en el núcleo

Las organizaciones pueden poner a trabajar al conversador y al contable a la vez, cada uno en su sitio. El LLM trabaja en la frontera, donde el mundo habla en lenguaje natural. El sistema determinista trabaja en el núcleo, donde se consulta, se calcula, se valida y se registra.

Un ejemplo de atención al cliente lo muestra de punta a punta. Un cliente escribe: «Creo que me cobraron mal la factura de marzo». El LLM lee esa frase libre, entiende que es una reclamación de facturación y la traduce a una operación estructurada que el sistema clásico sabe procesar, con datos como área, tipo de incidencia y periodo. A partir de ahí, el sistema determinista consulta los datos reales de ese cliente, aplica la política de la empresa y devuelve la información exacta. Con esos datos verificados delante, el LLM puede redactar la respuesta en un tono cordial, o el sistema puede escalar el caso a una persona si es delicado.

La pieza técnica que hace posible este reparto son las salidas estructuradas. Los modelos actuales pueden obligarse a responder con datos en un formato estricto, definido por un esquema, que un sistema clásico puede validar y ejecutar, como documentan OpenAI (se abre en una pestaña nueva) y Anthropic (se abre en una pestaña nueva). El mismo mecanismo permite al modelo llamar a herramientas (se abre en una pestaña nueva): en lugar de calcular, pide al sistema que calcule y trabaja con el resultado. La IA traduce, el software ejecuta, y todo lo que toca la operación queda registrado y auditable, como siempre.

En un proceso determinista, el rastro que permite explicar y reconstruir cada decisión ante un tercero (qué regla se aplicó, con qué datos y en qué momento) surge del propio mecanismo que construyó la respuesta, porque cada paso es una operación registrada y reproducible.

Una respuesta generada por un LLM, en cambio, es por sí sola un rastro pobre: no explica qué regla siguió ni permite reproducir el resultado, porque ese resultado no es un cálculo. Por eso, en procesos sensibles, el modelo debe situarse donde su salida pueda verificarse contra datos reales antes de que toque la operación. Cuando cada afirmación del modelo viene acompañada de un dato verificado por el sistema, la fiabilidad del conjunto la pone esa verificación. La trazabilidad la conserva el núcleo, y conviene no cedérsela a ningún componente que no pueda justificar sus pasos.

Siete preguntas antes de elegir

Aplicado a una tarea concreta, el criterio cabe en una lista de preguntas. Si la respuesta es sí, apunta al tipo de solución indicado. Cuando una tarea responde sí a preguntas de los dos tipos, conviene descomponerla en subtareas.

1. ¿La misma entrada debe producir siempre exactamente la misma salida? Operativa determinista.
2. ¿La tarea consiste en entender, resumir o redactar lenguaje natural? LLM.
3. ¿El resultado incluye cifras, importes o estados que deben ser exactos? Núcleo determinista; el LLM, como mucho, de interfaz.
4. ¿El proceso debe poder auditarse paso a paso ante un tercero? Núcleo determinista.
5. ¿La respuesta correcta depende de datos internos que cambian a diario? Sistema determinista, con el LLM como capa de acceso.
6. ¿Se acepta cierta variabilidad si el resultado es correcto en lo esencial? LLM.
7. ¿La petición llega en lenguaje libre y ambiguo? LLM en la frontera, reglas en el núcleo.

La tabla se lee tarea a tarea, no proceso a proceso. Un mismo flujo (recibir una consulta, entenderla, buscar el dato, calcular la respuesta, redactarla y registrarla) puede repartirse entre ambos mundos sin perder exactitud por el camino. Si estás eligiendo por dónde empezar, en cómo elegir tu primer proyecto de automatización aplicamos este mismo criterio a un caso completo.

La pregunta correcta

Por eso «¿dónde podemos meter la IA?» es la pregunta equivocada. La pregunta correcta va a la raíz: ¿qué naturaleza tiene la tarea que queremos automatizar? Si consiste en comprender o producir lenguaje, el LLM es hoy la mejor herramienta disponible, y renunciar a él sería dejar valor sobre la mesa. Si consiste en calcular, consultar, validar o registrar, la operativa determinista sigue siendo la respuesta exacta, económica y auditable que ya era antes de la IA generativa, y lo seguirá siendo después.

Las mejores soluciones aprovechan las fortalezas de ambos sistemas: el lenguaje pertenece a la frontera y la exactitud al núcleo. Saber distinguirlos marca la diferencia entre construir soluciones robustas y añadir complejidad donde no hace falta.

No todos los problemas son de IA, ni todas las automatizaciones necesitan un modelo de lenguaje. En nuestro servicio de IA y automatización analizamos cada proceso para determinar qué parte debe comprender lenguaje, cuál debe ejecutar reglas de negocio y cómo integrar ambas de forma fiable, auditable y rentable.