Pipeline de IA en producción: las lecciones que nadie te enseña antes de lanzar
Hay una diferencia enorme entre hacer un demo de IA que impresiona en una reunión y tener esa misma IA corriendo en producción con datos reales, usuarios reales y dinero real en juego. Fouzi Oukacha, desarrollador de Rangewell, una FinTech de préstamos comerciales del Reino Unido, lo vivió en carne propia durante el primer semestre de 2026. Y tuvo la honestidad de documentar no solo lo que funcionó, sino todo lo que salió mal.
El caso es especialmente relevante porque Rangewell no es una startup de laboratorio. Es una plataforma SaaS B2B donde los brokers gestionan el ciclo completo de préstamos comerciales: llamadas, correos, documentos financieros, estructuras corporativas, verificaciones KYC y propiedades. Antes de la IA, cada paso era manual. Un solo deal podía acumular más de 100 correos antes de que el archivo estuviera completo. El objetivo era claro: automatizar todo lo que no requiere juicio humano para que los brokers puedan enfocarse en lo que sí lo requiere.
Lo que sigue son las tres lecciones técnicas más importantes que emergieron de ese proyecto, y por qué cada una de ellas aplica directamente a cualquier empresa en Perú o Latinoamérica que esté pensando en integrar IA a sus operaciones.
Lección 1: La IA lenta necesita arquitectura asíncrona desde el día uno
El primer obstáculo que encontró el equipo no fue el modelo de IA en sí, sino el tiempo que tarda en responder. Analizar una llamada de 30 a 90 minutos con contexto completo del deal, incluyendo información del CRM, datos del prestatario, lenders y partes involucradas, puede tomar entre 30 y 90 segundos de procesamiento.
Una llamada HTTP sincrónica con ese tiempo de espera simplemente no es viable en producción. El navegador hace timeout, el servidor se bloquea y la experiencia del usuario colapsa. La solución fue diseñar un patrón asíncrono que se convirtió en el estándar para todos los endpoints de IA del proyecto:
- El cliente hace un POST y recibe inmediatamente un 202 Accepted
- El servidor lanza un job en background que procesa la solicitud
- Cuando el análisis termina, se emite un evento por WebSocket
- El frontend actualiza el estado vía Redux dispatch
Lo valioso de este enfoque es que se definió bien una sola vez y se aplicó a todos los endpoints posteriores. En cualquier sistema de automatización con IA, esta decisión de arquitectura debe tomarse antes de escribir la primera línea de código de integración, no después de que los usuarios reporten timeouts en producción.
Lección 2: El schema de respuesta es un contrato, no una sugerencia
Los modelos de lenguaje como Gemini devuelven texto libre por defecto. Para obtener JSON estructurado que pueda usarse como respuesta de una API, hay que forzarlo explícitamente con un MIME type y un schema de respuesta. Hasta ahí, todo razonable.
El problema aparece cuando ese schema no está bien definido. Si un campo de texto no tiene longitud máxima, el modelo puede repetir contenido indefinidamente hasta agotar todos los tokens disponibles, corrompiendo la respuesta completa. El análisis termina con un error, pero sin contexto suficiente para saber qué ocurrió.
La corrección fue doble: primero, agregar límites de longitud a todos los campos de texto en el schema. Segundo, y esto es quizás lo más importante del proyecto entero, guardar siempre el resultado aunque sea un error. El motivo del fallo, el contexto del prompt, el modelo utilizado, el tiempo de respuesta y el consumo de tokens. Sin esa información, depurar un pipeline de IA es como intentar arreglar un motor con los ojos vendados.
Hay otro punto que vale la pena destacar: el schema de respuesta cuenta contra el límite de tokens de entrada del modelo. Schemas muy grandes o prompts con mucho contexto pueden empujar la solicitud más allá del límite antes de que el modelo procese el contenido real. Esto obliga a ser estratégico con qué información se incluye en el contexto y cómo se estructura.
Lección 3: El límite de tokens no es un solo problema, son dos
Cuando los brokers empezaron a seleccionar diez llamadas y varios correos a la vez para un análisis combinado, el sistema empezó a fallar con errores de límite. La trampa es que "error de límite" puede significar dos cosas completamente distintas, y confundirlas lleva a diagnósticos incorrectos y soluciones que no resuelven nada.
El primer tipo es el límite de entrada o contexto: cada transcripción, cada cuerpo de correo y cada archivo adjunto se tokeniza y cuenta contra la ventana de contexto del modelo. Demasiadas fuentes en una sola solicitud superan ese límite. Adicionalmente, los archivos adjuntos que se enviaban codificados en base64 aumentan su tamaño en aproximadamente un 33%, y la API de Vertex tiene un límite de tamaño de request que puede alcanzarse antes incluso de llegar al límite de contexto.
El segundo tipo es el límite de salida: el modelo trunca su respuesta porque el parámetro maxOutputTokens estaba configurado demasiado bajo. El resultado parece el mismo desde afuera, un análisis incompleto, pero la causa y la solución son completamente diferentes.
Distinguir entre ambos errores requiere exactamente la observabilidad que se mencionó antes: guardar métricas de cada request. Sin datos, un error de salida puede reportarse incorrectamente como un error de entrada, y el equipo pasa días ajustando el contexto cuando el problema real era otro.
¿Cómo aplica esto en empresas de Perú y Latinoamérica?
El caso de Rangewell no es exclusivo de las FinTech británicas. En Perú y Latinoamérica estamos viendo exactamente el mismo patrón en empresas que intentan integrar IA a sus operaciones: un piloto funciona bien en condiciones controladas, llega a producción y empieza a fallar de maneras que nadie anticipó.
Las empresas que están considerando integrar IA a sus flujos de trabajo, ya sea en un ERP como Odoo, en un sistema de gestión de clientes o en procesos de análisis de documentos, deben tener en cuenta tres cosas concretas antes de lanzar:
- Diseñar para la latencia desde el inicio. Si el proceso de IA toma más de 5 segundos, la arquitectura asíncrona no es opcional. Es la única forma de mantener una experiencia de usuario aceptable.
- Tratar los schemas de respuesta como contratos de API. Cada campo debe tener validación, límites y manejo de valores nulos. Un campo sin límite de longitud es una bomba de tiempo en producción.
- Instrumentar todo desde el día uno. Guardar el contexto del prompt, el modelo, la duración y el resultado de cada llamada a la IA no es un lujo, es la única manera de depurar cuando algo falla en producción.
La IA en producción no es un problema de prompt engineering. Es un problema de ingeniería de software con todas sus letras: arquitectura, contratos, observabilidad y manejo de errores. Las empresas que lo entiendan así van a tener una ventaja real sobre las que están tratando la IA como una feature que se agrega al final.
Conclusión
El proyecto de Rangewell es un recordatorio honesto de que integrar IA a un producto real es significativamente más complejo que los demos de cinco minutos que circulan en redes sociales. Las lecciones de Fouzi, ganadas con errores reales en producción, son exactamente el tipo de conocimiento que separa un piloto fallido de una integración que agrega valor de verdad.
En Consultoría-Ti trabajamos con empresas en Perú y Latinoamérica que están en ese momento crítico: quieren integrar IA a sus operaciones pero no quieren aprender estas lecciones de la manera difícil. Si estás evaluando cómo hacerlo bien desde el inicio, conversemos.
📩 Escríbenos a través de nuestra web o contáctanos directamente. Estamos listos para ayudarte a diseñar una integración de IA que funcione en producción, no solo en el demo.
Fuentes y Referencias
✨ Contenido generado con ContentFlow — Consultoría-Ti