LLMs en la empresa: de cero a producción sin quemar el presupuesto

Hay una brecha enorme entre hacer un demo impresionante con ChatGPT y desplegar un sistema de IA que funcione de forma confiable en producción. En Epitech hemos recorrido ese camino con varios clientes, y en este artículo compartimos lo que realmente importa.

El problema con los proyectos de IA que fallan

La mayoría de los proyectos de IA empresarial no fracasan por falta de datos ni por limitaciones del modelo. Fracasan por tres razones predecibles:

Falta de un caso de uso acotado. Querer “hacer IA” sin definir qué decisión o proceso concreto se va a mejorar.
Ignorar la capa de integración. El modelo es el 20% del trabajo; el 80% restante es conectarlo de forma confiable con los sistemas existentes.
No medir lo correcto. Evaluar demos en vez de métricas de negocio: tasa de resolución, tiempo de proceso, costo por transacción.

La pregunta correcta no es “¿qué puede hacer un LLM?” sino “¿qué decisión de negocio queremos automatizar y cómo medimos el éxito?”

Arquitectura de referencia para producción

Para aplicaciones empresariales con LLMs, usamos consistentemente una arquitectura de cuatro capas:

1. Capa de orquestación

El modelo de lenguaje no debería hablar directamente con tus sistemas. Necesitas un orquestador que gestione el estado de la conversación, enrute las peticiones y maneje errores.

# Ejemplo simplificado con LangGraph
from langgraph.graph import StateGraph, END

def router(state):
    intent = classify_intent(state["message"])
    if intent == "consulta_factura":
        return "billing_agent"
    elif intent == "soporte_tecnico":
        return "support_agent"
    return "general_agent"

graph = StateGraph(AgentState)
graph.add_node("router", router)
graph.add_node("billing_agent", billing_agent)
graph.add_node("support_agent", support_agent)
graph.set_entry_point("router")

2. Capa RAG (Retrieval-Augmented Generation)

Para que el modelo responda con información de tu empresa —y no alucine— necesitas una base de conocimiento vectorial actualizada.

La arquitectura que recomendamos:

Chunking semántico del contenido corporativo (manuales, políticas, FAQs)
Embedding con modelos como text-embedding-3-small de OpenAI o nomic-embed-text (open source)
Vector store con pgvector (si ya usas PostgreSQL) o Qdrant para escala
Re-ranking antes de pasar contexto al LLM para mejorar la relevancia

3. Capa de herramientas (Tool Use)

Los LLMs modernos pueden ejecutar acciones reales: consultar una API, crear un ticket, actualizar un registro. Esto es lo que transforma un chatbot informativo en un agente que resuelve problemas.

{
  "tools": [
    {
      "name": "get_order_status",
      "description": "Consulta el estado de un pedido por número de orden",
      "parameters": {
        "order_id": { "type": "string", "required": true }
      }
    },
    {
      "name": "create_support_ticket",
      "description": "Crea un ticket en el sistema de soporte",
      "parameters": {
        "title": { "type": "string" },
        "priority": { "type": "string", "enum": ["low", "medium", "high"] }
      }
    }
  ]
}

4. Capa de observabilidad

Sin logs estructurados y métricas, no sabes qué está fallando. Instrumentamos cada llamada al LLM con:

Latencia por etapa (retrieval, inference, tool call)
Tasa de fallback (cuántas veces el agente no pudo resolver)
Costo por conversación (tokens consumidos × tarifa del modelo)
Evaluación automática de respuestas con un segundo modelo juez

Elección del modelo: no siempre el más grande es el mejor

Para procesos de negocio repetitivos y bien definidos, modelos como gpt-4o-mini, claude-haiku o llama-3.1-8b (self-hosted) ofrecen una relación costo/rendimiento que los modelos flagship no pueden igualar.

Caso de uso	Modelo recomendado	Costo aprox.
Clasificación y enrutamiento	gpt-4o-mini / llama-3.1-8b	< $0.01 / 1K req
Extracción de datos estructurados	gpt-4o-mini	< $0.05 / 1K req
Generación de documentos complejos	claude-sonnet / gpt-4o	$0.50–$2 / 1K req
Razonamiento y análisis profundo	claude-opus / gpt-4o	$5–$15 / 1K req

La clave es no usar un modelo de $15/1K tokens para clasificar correos cuando uno de $0.01 lo hace igual de bien.

El error más costoso: el “prompt monolítico”

Vemos frecuentemente sistemas con un prompt de sistema de 4,000 palabras que intenta cubrir todos los escenarios posibles. El resultado es un agente que se confunde, contradice sus propias instrucciones y se vuelve imposible de mantener.

La alternativa es la descomposición de agentes:

Un agente especializado por dominio (facturación, soporte, ventas)
Prompts cortos, específicos y evaluables
Routing basado en intención antes de asignar el agente

Esto también facilita la evaluación: puedes testear cada agente en aislado con casos conocidos antes de integrar el sistema completo.

Evaluación continua: el paso que todos saltan

Antes de lanzar a producción, necesitas un conjunto de evaluación —mínimo 50–100 casos representativos— que cubra:

Casos normales bien resueltos ✅
Casos límite donde el agente debe escalar a humano ⚠️
Casos de ataque o jailbreak que deben ser rechazados 🚫

Y luego, en producción, evaluación continua con muestreo automático. Un LLM como juez evaluando el 10% de las conversaciones reales es suficiente para detectar degradación antes de que lo reporten los usuarios.

Conclusión

Implementar LLMs en producción es un problema de ingeniería, no de magia. Los equipos que tienen éxito son los que tratan a los agentes de IA como cualquier otro sistema de software: con arquitectura clara, testing, observabilidad y mejora continua.

Si estás evaluando dónde empezar, nuestro consejo es siempre el mismo: elige un proceso de alto volumen, alta repetición y bajo riesgo. Automatiza ese primero, mide los resultados durante 30 días y luego expande.

¿Quieres revisar si tu caso de uso es el adecuado para empezar con LLMs? Conversemos.