El chatbot responde bien en las demos. El piloto tiene los números verdes. El equipo está contento y el deck para el comité de dirección ya está listo. Todo parece en orden.
Entonces llegas a producción real y empiezan los problemas que nadie puso en el roadmap: latencia que se dispara cuando hay carga concurrente, alucinaciones que en el entorno de pruebas eran marginales y en producción aparecen a diario, costes de inferencia que doblan la estimación inicial, y un equipo de soporte que empieza a recibir tickets sobre "respuestas raras del asistente". El piloto era perfecto. El sistema es otro animal.
Este patrón se repite con una regularidad preocupante. Y la causa casi nunca es técnica en el sentido profundo: no es que el modelo falle, es que el diseño del sistema asumía un contexto que la producción real no respeta. Hay tres vectores de tensión que suelen romperse primero:
- La brecha entre el comportamiento del modelo en evaluación controlada y su comportamiento con usuarios reales, prompts imprevistos y datos sucios.
- La arquitectura de recuperación e integración que funcionaba con un dataset pequeño y empieza a cojear cuando escala.
- La ausencia de un sistema de observabilidad diseñado específicamente para componentes de IA —no basta con los logs de toda la vida.
El Piloto: Por qué el Éxito en Pruebas es una Trampa
Cuando un equipo evalúa un sistema de IA, tiende a hacerlo con preguntas que conoce, datos que controla y usuarios que son o bien ellos mismos o bien un panel reducido de beta testers motivados. Eso no es un entorno de pruebas: es un ensayo de teatro con el guion en la mano.
La producción real introduce tres variables que los pilotos sistemáticamente infravaloran. Primera: la diversidad de la entrada. Los usuarios reales no formulan sus preguntas como las formuló el equipo de producto; escriben mal, cambian de idioma a mitad de frase, preguntan cosas que están fuera del dominio del sistema y esperan igualmente una respuesta útil. Segunda: la concurrencia. Un modelo que responde en 800 ms con un usuario puede responder en cuatro segundos cuando hay cien peticiones simultáneas, y eso, desde la perspectiva del usuario, convierte una app funcional en una app que "va lenta" aunque el modelo técnicamente funcione. Tercera: la deriva del contexto. Los datos sobre los que se construyó el sistema envejecen. La empresa lanza nuevos productos, cambia sus políticas, reorganiza su catálogo —y el modelo sigue respondiendo con la información de hace seis meses.
Un piloto exitoso demuestra que el modelo puede hacer la tarea. No demuestra que el sistema puede sostenerla.
Hemos visto esto en proyectos de sectores muy distintos. Un asistente de atención al cliente que en pruebas resolvía el 87% de consultas sin escalado humano. En producción, tras dos semanas, ese porcentaje bajó al 61% —no porque el modelo hubiera empeorado, sino porque los usuarios reales llegaban con contextos que el piloto no había anticipado, y el sistema no tenía mecanismo para detectar cuándo estaba fuera de su zona de competencia. Sin esa señal, el modelo seguía respondiendo con la misma confianza aparente. Solo que equivocado.
Arquitectura: Dónde se Rompe lo que Parecía Sólido
La arquitectura de recuperación es el componente que más frecuentemente infraestructura un sistema de IA empresarial. No el modelo en sí, sino el andamiaje que lo rodea: cómo se indexan los datos, cómo se construyen los prompts, cómo se gestiona el contexto entre turnos de conversación, cómo se enrutan las consultas cuando el sistema tiene múltiples fuentes de información.
Ya hemos escrito sobre la ilusión de que RAG resuelve sola el problema de la recuperación: elegir entre recuperación densa, dispersa o híbrida no es una decisión técnica neutra, es una decisión que depende del tipo de consulta, del volumen de documentos y de cuánta precisión léxica necesitas. En producción esto se hace evidente porque los casos de uso que el piloto no cubrió —justo los más difíciles— empiezan a llegar con frecuencia.
El problema del contexto que se acumula
En sistemas conversacionales, la gestión del contexto entre turnos es uno de los puntos de fallo más silenciosos. Cada turno de conversación añade tokens al prompt. Con conversaciones largas, los costes por inferencia se disparan y la calidad de las respuestas puede degradarse porque el modelo "pierde el hilo" al saturarse la ventana de contexto. La solución no es aumentar la ventana de contexto indefinidamente —eso es pagar el impuesto de lujo del que ya hemos hablado— sino diseñar un mecanismo de compresión o resumen que preserve la información relevante sin arrastrar todo el histórico.
La trampa de la indexación estática
Muchos sistemas de IA empresarial se despliegan con una indexación estática: los documentos se procesan una vez, se generan los embeddings y se almacenan. Funciona bien en el piloto porque los datos son recientes y el equipo los conoce. En producción, seis meses después, esa base de conocimiento está desactualizada y nadie ha establecido un proceso de reindexación incremental. El modelo sigue recuperando la política de devoluciones antigua, el catálogo de producto del trimestre pasado, la versión del contrato que ya fue sustituida. El modelo no miente: responde con lo que tiene. El problema es lo que tiene.
Observabilidad: el Componente que Siempre Llega Tarde
En sistemas de software tradicionales, la observabilidad está razonablemente madura: logs, métricas de latencia, trazas distribuidas, alertas sobre errores HTTP. Es suficiente para saber si algo se rompe. En sistemas de IA, esas señales te dicen si el sistema está caído, pero no si está funcionando bien.
Un sistema de IA puede estar técnicamente operativo —latencia normal, sin errores 500, tasa de respuesta al 100%— y estar produciendo respuestas incorrectas, parcialmente alucinadas o simplemente inútiles para la consulta planteada. Los logs normales no lo capturan. Necesitas otro nivel de observabilidad.
Esto implica instrumentar el sistema para capturar, como mínimo: el par pregunta-respuesta completo, la fuente o fuentes de las que se recuperó información, una señal de confianza cuando el modelo la produce, y el feedback del usuario cuando está disponible (explícito o implícito vía comportamiento posterior). Sin eso, estás gestionando el sistema a ciegas. Puedes tener la sensación de que funciona porque nadie se queja abiertamente —pero el coste oculto es que los usuarios simplemente dejan de usarlo.
La observabilidad en IA no pregunta si el sistema responde. Pregunta si el sistema acierta.
Existe además un problema organizacional: la observabilidad suele llegar tarde porque en la fase de piloto no se prioriza. El equipo está centrado en hacer funcionar el modelo. La instrumentación se pospone para "cuando estemos en producción". Pero cuando llegas a producción sin esa infraestructura, añadirla es más costoso y tienes semanas o meses de datos de producción que no puedes analizar retroactivamente. Es el mismo error que posponer los tests: siempre parece razonable en el momento y siempre duele después.
Escalado: Los Costes que Nadie Modeló
El modelo de costes de un sistema de IA en producción raramente coincide con la estimación del piloto. No porque los equipos sean descuidados, sino porque las variables que gobiernan el coste real son difíciles de estimar sin datos de producción: el número medio de tokens por consulta, la distribución de la longitud de las conversaciones, la tasa de reintentos, el porcentaje de consultas que requieren múltiples llamadas al modelo por lógica de agente o de reranking.
Una arquitectura que usa un modelo de frontera para cada operación —incluyendo clasificación de intención, reformulación de consulta, recuperación, generación y validación de respuesta— puede estar realizando cinco o seis llamadas por interacción de usuario. Con un modelo grande, eso es un coste por interacción que puede hacer inviable el unit economics del producto a escala.
La solución no es siempre "usar un modelo más pequeño para todo". Es diseñar una arquitectura donde cada operación use el modelo adecuado para esa operación. La clasificación de intención puede hacerla un modelo de 1B o 3B parámetros con precisión más que suficiente. La reformulación de consulta también. La generación final de respuesta puede requerir un modelo más capaz. Este enfoque de orquestación heterogénea —al que también se llama arquitectura de enrutamiento o mixture-of-experts operacional— no es nuevo, pero sigue siendo ignorado por proyectos que arrancan eligiendo un único modelo y lo aplican a todo el pipeline.
Conectar esto con el argumento más amplio sobre la dependencia cognitiva que generan los sistemas de IA cuando se convierten en infraestructura crítica: si el sistema escala mal y el equipo humano ha reducido su capacidad de resolución manual porque "el asistente lo hacía", la caída del sistema tiene un coste operativo muy superior al técnico.
Modelar los costes de producción requiere hacer al menos un ejercicio de simulación de carga antes del lanzamiento. No un benchmark sintético del modelo: una simulación con tráfico realista, distribución de consultas representativa y arquitectura de pipeline completa. Es un trabajo tedioso que la mayoría de proyectos omite. Y es exactamente lo que separa un piloto que se convierte en producto de un piloto que se convierte en deuda técnica.
Cómo Llegar a Producción sin que te Explote en la Cara
No existe una lista de comprobación universal, pero hay decisiones de diseño que reducen drásticamente el riesgo de transición. La primera es diseñar la observabilidad desde el día uno, no desde el día del lanzamiento. Aunque en el piloto solo registres los pares pregunta-respuesta en un fichero plano, eso ya te da datos reales con los que trabajar.
La segunda es definir explícitamente el perímetro de competencia del sistema: qué consultas debe manejar, qué consultas debe rechazar o escalar, y cómo se comporta en los límites. Un sistema que sabe cuándo no sabe es infinitamente más confiable en producción que uno que responde con aparente seguridad a todo.
La tercera es separar el ciclo de vida del modelo del ciclo de vida de los datos. El modelo puede no cambiar en meses. Los datos de los que se nutre el sistema deben tener su propio proceso de actualización, validación y reindexación, con frecuencia que depende del ritmo al que cambia la información del negocio.
Si estás a punto de llevar un sistema de IA a producción o llevas meses con un piloto que no termina de convertirse en producto estable, en Room 714 hacemos auditorías de arquitectura centradas exactamente en estos puntos de fallo. No para rehacer lo que funciona, sino para identificar dónde el sistema va a crujir antes de que cruja delante de tus usuarios.
