Artículo · 2 min
Llevar los LLM más allá del demo
Llamar a una API de IA es fácil. Convertirla en una funcionalidad de producción confiable es el verdadero trabajo — y es ingeniería de software ordinaria, aplicada sin excepciones.
Hay una categoría de software que funciona de maravilla en un demo y se desmorona silenciosamente en producción, y ahora mismo las “funcionalidades de IA” la dominan. La brecha no es el modelo. La brecha es todo lo que rodea al modelo.
En House Edge trabajé llevando capacidades LLM — la Claude API y el Model Context Protocol — a aplicaciones de producción. Mi propiedad era la integración en la capa de aplicación y la ingeniería de software de producción a su alrededor; los especialistas en IA eran dueños de las estrategias de prompting y del comportamiento del modelo. Ese límite resultó clarificador, porque hizo visible el verdadero problema de ingeniería.
Un LLM es una dependencia con carácter
Trata al modelo como lo que es: una dependencia externa que es no determinística, puede fallar o expirar, cuesta dinero por petición, y está en el camino de datos reales de usuarios. Escribe esa frase sobre cualquier otra dependencia y los requisitos de ingeniería caen por su propio peso. Por alguna razón, cuando la dependencia es un LLM, los equipos olvidan aplicarlos.
El trabajo de integración que importa:
- Manejo de errores y fallbacks. La llamada va a fallar. La funcionalidad tiene que degradarse en algo sensato, no en un spinner o un stack trace.
- Validación a ambos lados. Entradas antes de la llamada, salidas después. Una dependencia no determinística significa que la forma de la respuesta es una esperanza, no una garantía, hasta que la validas.
- Logging y observabilidad. Cuando la funcionalidad se comporte raro en producción — y lo hará — necesitas poder ver qué pasó.
- Testing que contempla la variabilidad. No puedes salir del no determinismo con snapshot tests; el enfoque de testing tiene que estar construido para ello.
- Mantenibilidad. Los modelos y los requisitos cambian. Una integración construida como pieza frágil de un solo uso se reconstruye; una construida como servicio limpio de capa de aplicación evoluciona.
Los mismos estándares, sin excepciones
El principio con el que salí: la IA tiene que integrarse como una capacidad del producto, no atornillarse como una novedad. Observabilidad, manejo de errores, seguridad, mantenibilidad y UX aplican a una funcionalidad de IA exactamente igual que a cualquier otra cosa. En el momento en que un equipo baja el listón “porque es IA”, está construyendo el demo, no el producto.
Este no fue mi primer contacto con la IA — había trabajado en proyectos de chatbots con IA años antes, cuando esto era mucho menos moda. Pero el trabajo con LLM en producción es donde la lección cristalizó: la parte difícil y valiosa es la ingeniería alrededor del modelo, no la llamada al modelo.