El costo oculto de la nube

Capítulo 5 — El costo oculto de la nube

La narrativa dominante de los últimos cinco años dice que la nube es económica, escalable y sencilla. Para muchas cargas de trabajo es perfectamente cierto. Para los RAG empresariales, cada vez con más frecuencia, no lo es. Y el momento en que te das cuenta suele ser a finales del primer trimestre, cuando llega la factura.

Tomemos el caso más infravalorado de la cuenta: las API de los modelos de visión. Cuando una empresa ingiere su archivo fotográfico en un RAG moderno, cada foto debe ser "descrita" por un modelo multimodal que extrae su contenido, objetos, contexto, cualquier texto superpuesto, estado de ánimo, composición. Un gran proveedor europeo de modelos —aún sin nombre— ofrecía, en 2025, un excelente modelo de la familia Qwen de 32 mil millones de parámetros, a un precio por imagen interesante. El problema, descubierto solo sobre el terreno y después de meses de producción: bajo carga, el proveedor truncaba las respuestas. No siempre, no de forma predecible, no cuando estaba el equipo de pruebas presente: aleatoriamente. Una foto de cada diez, a veces una de cada cinco, regresaba con un JSON cortado a la mitad, analizado incorrectamente, con metadatos parciales o nulos. Los tiempos se disparaban de diez segundos a doscientos segundos por imagen, sin patrón. La factura del reintento —porque los reintentos se pagan, cada llamada, incluso la que el servidor trunca— era más alta de lo previsto. La base de datos era heterogénea: algunas fotos riquísimas en metadatos, otras truncadas. Y el equipo no lograba reproducir el problema en entornos de prueba, porque en las pruebas la carga era baja y todo funcionaba.

La solución llegó en tres partes: un prompt más compacto (las respuestas más cortas se truncan menos), una lógica de reintento inteligente (si la respuesta tarda más de cincuenta segundos y vuelve vacía, vuelve a intentarlo inmediatamente) y —cuando el volumen lo justifica— la posibilidad de saltarse por completo la nube y ejecutar el modelo de visión en una GPU local, más lenta pero determinista. La arquitectura correcta, según esta experiencia, no es "nube siempre" ni "local siempre". Es "elige para cada llamada, según lo que se necesite en ese momento".

Luego está el capítulo de las consultas. Cada búsqueda de usuario, en un RAG nativo de la nube clásico, desencadena una cascada de llamadas a la API de pago. Una para la incrustación de la pregunta. Una para la clasificación intencional (¿de qué tipo es la pregunta?). Una para el reordenamiento de los documentos. Una para la generación de la respuesta final. Cada una cuesta una fracción de céntimo. Para un servicio interno con cincuenta usuarios y diez mil consultas al día —que no son pocas, pero tampoco un número enorme para una empresa mediana— la factura mensual llega a cifras que harían fruncir el ceño incluso a un CFO indulgente. Y el crecimiento es lineal: duplicas los usuarios, duplicas la factura. No hay economías de escala en los tokens consumidos, no para ti.

También existe un problema que en 2025 era latente y que en 2026 se convirtió en central: cada consulta individual envía fragmentos de documentos empresariales —a veces confidenciales, a veces cubiertos por acuerdos de confidencialidad, a veces sujetos a normativas sectoriales— a los servidores de un proveedor externo, en jurisdicciones que no siempre coinciden con la suya, con políticas de conservación de registros no siempre transparentes. Más de una empresa europea, en los últimos dieciocho meses, ha descubierto solo durante una auditoría —normalmente provocada por un cliente preocupado o por una verificación ISO— que sus contratos, listas de precios y especificaciones técnicas habían sido procesados (y potencialmente registrados para fines de "mejora del servicio") por infraestructuras fuera de la UE. La sorpresa, por lo general, ha costado más que el ahorro en hardware local que se había querido evitar.

La alternativa no es el dogma opuesto. "Nube no, local sí" es tan incorrecto como "nube sí siempre". La alternativa es una arquitectura que te permita elegir, para cada pieza individual del pipeline — embedding, clasificación, reranking, visión, generación final — si usar un modelo en la nube o uno local, y cambiar de opinión en un día, no en un trimestre. Esto requiere un diseño en el que los proveedores sean intercambiables, donde ninguna pieza esté fijada al nombre de una empresa específica, donde el paso de Regolo a Ollama (o viceversa) sea una línea de configuración, no una reescritura. Y esto, hasta hace poco, era raro. Los frameworks populares, a pesar de la fachada de "proveedor-agnóstico", en realidad estaban muy comprometidos con alguien.