AI in Production -- Parte 1
La Brecha de la que Nadie Habla: De la Demo de IA a la IA en Producción
El Problema
La demo siempre funciona.
Ves a alguien en un escenario construir un chatbot en 20 minutos. Llamada a la API, stream de la respuesta, listo. Responde preguntas. Suena inteligente. El público aplaude. Vuelves a tu escritorio y piensas: “Yo puedo hacer esto.”
Y puedes. Lo construyes en una tarde. Funciona genial — en tu portátil, con tus datos de prueba, una petición a la vez, cuando ya sabes lo que vas a preguntar.
Entonces pasa algo. Se lo enseñas a tu equipo. Alguien pega un PDF de 10 páginas en el chat. La latencia se dispara a 40 segundos. El modelo devuelve algo que es factualmente incorrecto pero suena completamente seguro. Un compañero le pregunta algo que tus datos de prueba nunca cubrieron y se inventa una respuesta. Lo dejas funcionando una semana y la factura de la API es tres veces lo que esperabas.
Todavía no lo has desplegado en producción. Y ya se está rompiendo.
Esta es la brecha. Y no es una brecha pequeña — es la razón por la que la mayoría de los proyectos de IA empresarial mueren entre “prueba de concepto aprobada” y “funcionando en producción para usuarios reales.”
El problema no es la IA. El modelo hace lo que hace. El problema es que las demos esconden las decisiones que todavía no has tomado. Todo sistema de IA que funciona de forma fiable en producción tiene respuestas a preguntas como: ¿qué pasa cuando la API se cae? ¿Cómo sabes si la respuesta fue buena o mala? ¿Cuánto cuesta esto a 10x el volumen actual? ¿Qué datos van al modelo, y es eso legal? ¿Puede el sistema existente siquiera integrarse con esto?
Nadie cubre esto. Hay miles de tutoriales de “construye un chatbot en 10 minutos.” Casi no hay artículos que pregunten “¿qué pasa cuando un usuario real lo rompe a las 2 de la mañana un sábado?”
Esta serie trata sobre esa brecha.
Las Diferencias Reales
Voy a ser específico. Así es como se ve una demo frente a lo que se ve en producción:
| Demo | Producción | |
|---|---|---|
| Input | Controlado, probado | Cualquier cosa. En serio, cualquier cosa. |
| Escala | 1 usuario (tú) | Cientos o miles, concurrentes |
| Latencia | Te da igual | SLA. Alguien está esperando. |
| Coste | ”No pasa nada, solo estoy probando” | Presupuesto. Por petición. |
| Fallos | Reintentas manualmente | Los usuarios ven mensajes de error. O respuestas incorrectas. |
| Datos | Falsos o tuyos | Datos reales de usuarios. GDPR. Legal. |
| Cambios de modelo | Ni te enteras | El proveedor actualiza el modelo, el comportamiento cambia |
| Monitorización | Ninguna | ¿Cómo sabes que funciona? |
Cada fila de esa tabla es una decisión que todavía no has tomado cuando construyes la demo. Producción te obliga a tomarlas todas a la vez.
Dónde Se Rompen las Cosas
He trabajado en sistemas enterprise el tiempo suficiente como para ver los patrones. Estas son las cosas que realmente salen mal:
Sin fallback. La API de IA se cae — pasa, todos los grandes proveedores tienen incidencias — y toda la funcionalidad se cae con ella. A veces toda la aplicación. No hay degradación elegante, ni respuesta cacheada, ni “lo intentamos de nuevo en un momento.” Solo una experiencia de usuario rota.
Sin control de costes. Alguien envía un documento muy largo. O muchos usuarios entran a la vez. O una nueva funcionalidad genera más tokens de los esperados. La factura a final de mes es una sorpresa. Finanzas hace preguntas. Alguien tiene que explicarlo.
Datos yendo donde no deberían. Un desarrollador integra la funcionalidad de IA sin darse cuenta de que los datos de usuario — a veces datos personales, a veces datos confidenciales de negocio — se están enviando a una API de terceros. Legal se entera. Compliance hace preguntas. Es un problema.
Sin forma de saber si funciona. La monitorización tradicional te dice si la API devolvió un 200. No te dice si la respuesta de la IA fue correcta, útil o segura. No tienes visibilidad sobre la calidad. Solo te enteras de que algo va mal cuando un usuario se queja.
Prompt injection. Los usuarios reales no se comportan como tus datos de prueba. Algunos de ellos, intencionadamente o no, meterán cosas en el input que cambian el comportamiento del modelo. “Ignora las instrucciones anteriores y…” es el ejemplo clásico. En una demo nunca ves esto. En producción lo ves el primer día.
Integración con sistemas existentes. La demo funciona de forma aislada. El sistema real necesita integrarse con la base de datos, el sistema de autenticación, el bus de eventos, la capa de API existente. Esa integración es donde está la mayor parte del trabajo real de ingeniería — y es invisible en la demo.
En Qué Piensan los Arquitectos
Los desarrolladores que construyen demos piensan en la IA. Qué modelo, qué prompt, qué formato de respuesta.
Los arquitectos que construyen sistemas en producción piensan en el sistema alrededor de la IA. El componente de IA es solo una pieza — y normalmente no la más difícil. Las partes difíciles son:
- ¿Cómo se comporta el resto del sistema cuando la IA falla?
- ¿Cómo observas lo que realmente está pasando?
- ¿Cómo mantienes los costes predecibles?
- ¿Cómo integras sin romper lo que ya funciona?
- ¿Cómo cumples con la normativa?
Estas no son preguntas de IA. Son preguntas de arquitectura. Y tienen respuestas de arquitectura — patrones, prácticas y decisiones que la gente lleva aplicando a sistemas distribuidos durante años, ahora aplicados a un nuevo tipo de componente.
Eso es lo que cubre esta serie.
Qué Hay en Esta Serie
Ocho artículos. Cada uno es una decisión específica que necesitas tomar antes de poder ejecutar IA de forma fiable en producción.
- La Brecha — Este artículo. El problema y la mentalidad.
- Diseñar para el Fallo — Fallbacks, circuit breakers, modo degradado. Qué pasa cuando la IA no funciona.
- Observabilidad — Cómo medir lo que no puedes ver. Calidad, latencia, drift, coste — en tiempo real.
- El Problema del Coste — Tokens, caching, batching. Cómo hacer que el coste sea predecible.
- Gobernanza y Compliance — Lo que Legal va a preguntar antes de que esto salga a producción. Cómo diseñar para ello desde el principio.
- Integración en Sistemas Existentes — Patrones para añadir IA a arquitecturas que ya existen.
- Testing de Funcionalidades de IA — Tests fiables para un componente no determinista. Capas de unit, integración y evaluación.
- Preparación para Producción — La checklist completa antes de que tu funcionalidad de IA salga a producción.
Nada de tutoriales para construir chatbots. Nada de hype sobre lo que la IA puede hacer. Solo las decisiones de arquitectura que determinan si tu proyecto de IA sobrevive al contacto con usuarios reales.
Una vez que termines esta serie y quieras ir más allá — no solo cómo ejecutar IA en producción, sino cómo usar IA como herramienta de desarrollo estructurado en tu propio flujo de trabajo — estoy trabajando en una nueva serie llamada ATLAS + GOTCHA que continúa desde aquí. Cubrirá la parte metodológica: prompting estructurado, desarrollo asistido por IA, mantener el output de la IA consistente y verificable. Un paso natural después de esta serie. (Actualización: la serie ATLAS + GOTCHA ya está publicada.)
Antes del Siguiente Artículo
Antes de leer el artículo 2, piensa en un proyecto que conozcas — uno donde se consideró o ya se intentó usar IA. Elige una cosa de la sección “Dónde Se Rompen las Cosas” de arriba.
¿Cuál pasó? ¿O cuál pasaría si lo desplegases hoy?
Esa es la pregunta que guía el resto de esta serie.
Si esta serie te resulta útil, puedes invitarme a un café.
Este es el artículo 1 de la serie AI in Production. Siguiente: Diseñar para el Fallo — qué pasa cuando la IA no está disponible, es lenta o se equivoca, y cómo construir un sistema que lo gestione.
Loading comments...