Cómo llevar una funcionalidad LLM real a producción (no solo una demo)

Cada founder con el que hablo tiene 3-5 “funcionalidades de IA” en su roadmap. Un chatbot aquí, un botón “resume mis datos” allá, un agente que “simplemente gestiona” la atención al cliente. Cerca del 80% de esas funcionalidades no sobrevivirían a producción. No porque los LLMs no sean lo bastante capaces — lo son. Es porque la distancia entre una demo LLM que funciona y una funcionalidad LLM que vive en producción es mayor que la distancia entre la mayoría de productos y sus MVPs.

Una demo se ejecuta una vez, con entradas seleccionadas a mano, con el founder al teclado. Una funcionalidad en producción se ejecuta 50.000 veces al día, sobre entradas que nadie anticipó, facturadas a una suscripción de Stripe, en una UI que tiene que sentirse rápida incluso cuando la API upstream está rate-limited a las 3 de la mañana de un domingo. Son problemas de ingeniería distintos.

Este post es el checklist operativo que realmente reviso antes de decirle a un founder “sí, esto lo podemos lanzar.” Es el mismo checklist que usé construyendo Dealko — el primer asistente de IA para el mercado de telecomunicaciones esloveno — y CrewPress, un plugin de WordPress con 7 agentes especializados enrutados entre Claude, GPT-4o, Gemini y DALL-E 3.

Decisión 1: ¿De verdad necesitas un LLM?

Esta es la comprobación anti-hype, y mata más “funcionalidades de IA” en mis revisiones de roadmap que cualquier otra pregunta. Muchas funcionalidades que los founders enmarcan como “IA” se resuelven mejor con lógica determinista y un buen UX. Un dropdown gana a un chatbot en el 90% de los problemas de selección. Un formulario bien estructurado gana casi siempre a un textarea de “describe tus necesidades en lenguaje natural.”

Las preguntas que me hago, en orden:

• ¿La entrada o la salida es genuinamente texto? No “podría ser texto” — realmente texto, donde los usuarios prefieren escribir en formato libre a elegir.
• ¿La variabilidad requiere de verdad comprensión de lenguaje natural? ¿O es un conjunto finito de intenciones que podrías enumerar?
• ¿El modo de fallo es sobrevivible? Si una respuesta incorrecta dispara un reembolso, una demanda o el borrado de datos de alguien, el LLM tiene que ir envuelto en guardrails tan pesados que apenas es ya un LLM.

Si alguna respuesta es no, probablemente no necesitas un LLM. Necesitas una funcionalidad que respete la intención del usuario y que se entregue en dos semanas en vez de en dos trimestres. Gasta el presupuesto LLM donde la variabilidad sea real — normalmente en una parte pequeña y contenida del producto, no como puerta principal.

Decisión 2: Qué modelo, y por qué importa

La elección de modelo es la decisión más barata del stack — puedes cambiar de proveedor en una tarde si tu abstracción es sensata — y es la que más founders sufren equivocadamente. Leen tablas de benchmarks y eligen el que lideró MMLU el mes pasado. Ese es el instinto equivocado.

Mis defaults, con el matiz de que no soy religioso con esto:

• Claude (Anthropic) para generación de código, razonamiento con contexto largo, cualquier cosa donde el tool use y seguir instrucciones limpiamente importe más que la fluidez conversacional pura.
• GPT-4o o GPT-5 (OpenAI) para funcionalidades conversacionales, escritura creativa, donde el modelo necesita sentirse cálido e improvisador.
• Gemini (Google) para trabajo masivo sensible al coste, especialmente cuando importa la cobertura de idiomas — lenguas europeas pequeñas, incluido el esloveno, donde el dataset de entrenamiento de Gemini es más amplio de lo que la gente supone.

Elige por funcionalidad, basándote en benchmarks para tu workload, no en puntuaciones MMLU promedio de la industria. El líder de MMLU puede seguir estando equivocado sobre tu dominio. En CrewPress, los 7 agentes están enrutados entre Claude, GPT-4o, Gemini y DALL-E 3 según el ajuste a la tarea — generación de contenido, optimización SEO, asistencia de código y generación de imágenes son cada uno una forma distinta de problema con un modelo óptimo distinto. Tratar “la IA” como un único proveedor es un error de categoría.

Las 5 cosas que matan funcionalidades LLM en producción

Una vez decidido lanzar, estos son los modos de fallo que veo matar funcionalidades después del lanzamiento. Ninguno aparece en la demo. Todos aparecen en la tercera semana.

1. Hallucination en rutas críticas. Si los usuarios confían en la salida como verdad — precios, textos legales, orientación médica, cualquier cosa donde equivocarse tenga un coste — necesitas guardrails, citas, o human-in-the-loop. El peor patrón es esconder la incertidumbre del modelo detrás de una UI segura. Muestra la fuente. Muestra la confianza. Deja que los usuarios vean cuándo el modelo está adivinando. El producto que admite “no estoy seguro, esto lo saqué de aquí” gana confianza más rápido que el que finge certeza y a veces se equivoca.

2. Coste fuera de control. Cada token cuesta dinero, y una funcionalidad ingenua que llama al prompt en cada petición puede multiplicar por 10 tu factura de AWS o de API el día que un tweet viral te trae 100.000 usuarios. Pon cuotas por usuario y por tier antes del lanzamiento, no después. Cachea agresivamente donde el espacio de entrada esté acotado. Conoce tu economía unitaria al céntimo-por-usuario-activo-al-día antes de lanzar a clientes que pagan.

3. Latency. Los LLMs en producción son más lentos de lo que los usuarios esperan viniendo de software no-IA. Una respuesta de 4 segundos se siente rota en una UI acostumbrada a 200ms. Streaming de respuestas más UX de progreso percibido — skeleton states, revelación progresiva, renderizado optimista — es la diferencia entre “esto se siente mágico” y “la funcionalidad de IA está rota.” El presupuesto de latency es una restricción de diseño, no un problema de backend.

4. Prompt drift. Tu prompt que funcionaba perfectamente en desarrollo se rompe seis meses después porque el modelo subyacente se actualizó. Los proveedores reentrenan, deprecan, y silenciosamente cambian comportamiento. Pinea versiones de modelo explícitamente. Construye una pequeña eval suite — incluso 30 pares fijos de entrada/salida — y ejecútala en cada upgrade de modelo antes de pulsar el interruptor. Sin evals vuelas a ciegas cada vez que el proveedor publica un nuevo checkpoint.

5. El problema “context window lleno”. Las conversaciones reales son largas. Los documentos reales son largos. La ventana es finita. Retrieval-augmented generation (RAG) o pipelines de summarisation son no-opcionales en el momento en que una funcionalidad coge tracción. Planéalo desde el día uno — añadir RAG a posteriori a una funcionalidad que no fue arquitecturada para ello cuesta más que construirlo desde el principio.

Cómo se ven las funcionalidades LLM reales en producción

Dos ejemplos que he entregado, los dos siguen corriendo, los dos facturan a usuarios reales:

Dealko es el primer asistente de IA para el mercado de telecomunicaciones esloveno. Los usuarios preguntan, en esloveno, cosas como “necesito un plan con al menos 20GB y roaming EU por menos de 25 €.” El LLM parsea la intención, la cruza con un catálogo real de operadores y muestra opciones reales sobre las que el usuario puede actuar. Cuando la confianza del modelo baja — consulta ambigua, datos faltantes, caso límite — entrega elegantemente a un camino de venta humano en vez de inventar una respuesta. El LLM es un componente, no el producto entero. Ver Dealko para el caso completo.

CrewPress es un plugin de automatización para WordPress con 7 agentes. Content Generator, SEO Optimizer, Developer Assistant, Image Creator y tres más — cada agente tiene responsabilidad acotada, su propia plantilla de prompt, y su propia elección de modelo. Las cuotas de uso se aplican por tier de suscripción Stripe, de manera que un power user en el plan más barato no puede quemar accidentalmente el presupuesto API mensual en una tarde. Ver CrewPress para la arquitectura.

Los dos están entregados a usuarios reales. Los dos tienen modos de fallo incorporados al UX, no escondidos. Los dos facturan costes limpiamente a la suscripción que los paga.

El checklist de funcionalidad LLM lista para producción

Una compuerta pre-lanzamiento que repaso con founders antes de acordar que la funcionalidad está lista:

• ¿Resuelve un problema que la lógica determinista no puede?
• ¿La elección de modelo está fundamentada en tu workload, no en benchmarks?
• ¿La hallucination está o protegida o mostrada honestamente?
• ¿Los costes están capados por usuario y por tier?
• ¿La latency está enmascarada por UX — streaming, skeleton states, revelación progresiva?
• ¿La versión del modelo está pineada y existe una eval suite?
• ¿La estrategia de gestión de contexto está decidida — RAG, summarisation o solo ventana?
• ¿Degrada elegantemente cuando el LLM está caído o rate-limited?

Si no puedes marcar las ocho, la funcionalidad no está lista. Sigue siendo una demo.

Una funcionalidad LLM que se lanza es 20% prompt y 80% higiene de ingeniería. El prompt es la parte sobre la que los founders se obsesionan. El otro 80% es lo que decide si la funcionalidad sigue viva dentro de un año.

Si tienes una funcionalidad de IA en tu roadmap y quieres una revisión sensata, reserva una llamada gratuita de 30 minutos o mira la página de integración IA para ver cómo se ve un engagement.