Nota técnica. Dirigida a quien ya está construyendo APIs y se plantea cuándo meter un LLM en producción. No hablamos de chatbots: hablamos de reemplazar lógica de negocio procedimental por un modelo, cuando tiene sentido hacerlo. Spoiler: a veces sí, a veces no, y el criterio no es "cuánta IA queremos usar".

El patrón clásico: la API que crece a base de if anidados

Pongamos una API real del día a día. Un endpoint /classify-request que recibe un mensaje entrante (email, formulario, ticket) y tiene que clasificarlo en una categoría. Al principio, son tres categorías y diez reglas. Lo resuelves con un switch o un diccionario y a correr.

Seis meses después, la función tiene esta pinta:

function classify(string $text, array $metadata): string {
    if (str_contains($text, "factura")) {
        if (str_contains($text, "pendiente") || str_contains($text, "impago")) {
            return "ADMIN_COBROS";
        }
        if ($metadata["sender_domain"] === "partner.com") {
            return "ADMIN_PARTNERS";
        }
        return "ADMIN";
    }
    if (preg_match("/devoluci[oó]n|reembolso/i", $text)) {
        // ...55 líneas más aquí...
    }
    // ...otras 150 líneas de casos...
}

Y no funciona bien. Los usuarios siguen viendo tickets mal clasificados. Cada vez que añades una regla para un caso nuevo, se rompe otro que antes iba bien. El test de regresión se convierte en un monstruo.

Este patrón es señal clara de que estás resolviendo mal un problema que no es procedimental: es de interpretación del lenguaje. Y para eso los LLMs son mejores que las reglas, por mucho.

Cuándo un LLM gana: interpretación, no cálculo

La regla general que aplicamos nosotras:

Si lo que tienes que hacer es interpretar un texto o un contexto matizado y decidir algo cualitativo, y eso hoy lo resuelves con un tejido de reglas que no termina nunca, un LLM casi siempre es mejor solución.

Ejemplos concretos donde hemos sustituido reglas por un LLM en producción:

• Clasificación de mensajes entrantes en sistemas de soporte, comerciales o administrativos.
• Extracción de datos estructurados de textos libres: pedidos por email, formularios con campos rellenados "como se le ocurrió al usuario", documentos escaneados.
• Normalización de nombres y direcciones con variantes múltiples (MercadoLibre entre todas sus formas de escribirlo, ciudades con acentos ausentes, etc.).
• Moderación de contenido contextual: distinguir una crítica legítima de un insulto.
• Enrutamiento inteligente de solicitudes complejas a la persona o departamento correcto.

Cuándo un LLM pierde: determinismo, cálculo y volumen

Por contrapartida, no usaríamos un LLM para:

• Cálculos financieros. Un descuento de 13.25% no se le pregunta a un modelo: es precio * 0.1325.
• Validaciones estrictas (formato de email, NIF, IBAN). Un regex es gratis, rápido y siempre acierta igual.
• Decisiones que tienen que ser 100% reproducibles: el mismo input → exactamente el mismo output cada vez. Los LLMs pueden dar respuestas distintas aunque se fije temperature=0 en casos límite.
• Operaciones de altísimo volumen y baja complejidad. Si pasan 10 millones de solicitudes al día y cada una es trivial, el coste y la latencia de llamar a un LLM no compensan.
• Cuando hay suficientes datos etiquetados para entrenar un modelo clásico dedicado más barato y más rápido.

Arquitectura que usamos cuando sí metemos un LLM

Cuando decidimos que la lógica vive en un modelo, el LLM no es el endpoint. Está dentro de un servicio controlado, rodeado de código tradicional que hace que sea fiable en producción.

1. Prompt versionado

El prompt es parte del código. Vive en un archivo (prompts/classify_request.v3.txt), con número de versión, y los cambios pasan por revisión como cualquier commit. No vive dentro de una cadena hardcodeada en medio de un controlador.

2. Respuesta estructurada y validada

Nunca dejamos que el modelo devuelva texto libre y hagamos parsing a ojo. Le pedimos JSON con un esquema, validamos la respuesta y rechazamos (con fallback o reintento) si no cumple. Claude y OpenAI ya soportan structured outputs directamente.

3. Caché agresiva

Si el input es exactamente el mismo que ya se procesó, devolvemos la respuesta anterior. Un hash del input y una tabla Redis bastan. En clasificación real, el hit rate de caché puede subir del 30%.

4. Fallback a código clásico para casos conocidos

Antes de llamar al LLM, pasamos por reglas rápidas para casos "obvios". Si el mensaje es "OUT OF OFFICE AUTO-REPLY", no hace falta un LLM para saber que es ruido. Esto reduce llamadas caras.

5. Logs con trazabilidad

Guardamos input, output, modelo, versión de prompt, y si pasó el validator. Esto es clave para debugging, compliance y mejora continua del prompt.

6. Métricas y alertas de calidad

Monitorizamos el porcentaje de respuestas rechazadas por el validator, la latencia, el coste por petición. Si algo cambia fuera de rango, alerta.

7. Feedback humano opcional

Si el resultado es crítico, una persona revisa un porcentaje antes de que se use. Ese feedback vuelve como dataset para ajustar el prompt o detectar regresiones.

Ejemplo concreto: endpoint con LLM

Así se ve, simplificado, un endpoint /classify-request real:

POST /api/v1/classify-request
{ "text": "...", "metadata": {...} }

→  1. Normalizar input (quitar firmas, HTML, espacios).
→  2. Regla rápida: ¿es auto-reply? ¿es spam conocido? → devolver sin LLM.
→  3. Cache lookup por hash del input normalizado.
→  4. Si no hay caché: llamar al LLM con prompt v3 + esquema JSON.
→  5. Validar respuesta contra el esquema. Si no valida: reintentar 1 vez o fallback.
→  6. Guardar en caché y en logs.
→  7. Devolver respuesta estructurada al cliente.

El endpoint del cliente ve exactamente lo mismo que veía con el switch anterior. La diferencia está en que ahora acierta más y el código es mucho más simple.

¿Cuánto cuesta esto en producción?

Con los precios actuales (finales de 2025-inicio 2026) de Claude Haiku y GPT-4o-mini, una clasificación de texto corto cuesta del orden de fracciones de céntimo por petición. Con caché al 30-40% y fallbacks para casos fáciles, casi cualquier caso de uso corporativo cabe en un presupuesto razonable.

La parte importante no es el coste por token: es que el mantenimiento de ese código baja drásticamente. Donde antes había 300 líneas de reglas que nadie quería tocar, queda un prompt claro de medio folio y la infraestructura alrededor.