# Arquitectura de sistemas de IA en producción: lo que rompemos en el mes 3 > Las decisiones de arquitectura que parecían razonables en el mes uno se cobran su precio en el mes tres. Cinco zonas donde casi siempre toca rehacer. **Author:** Pablo de la Vega **Published:** 2026-09-01 **Reading time:** 9 min **Category:** Sistemas **Source:** https://nexau.es/blog/arquitectura-sistemas-ia-produccion --- Hay una consistencia incómoda en los proyectos de IA que llevamos. En el mes uno, todo parece razonable. La arquitectura tiene sentido, los modelos responden bien, los costes son manejables y el cliente está contento. En el mes tres, casi siempre hay que rehacer alguna cosa. No es por mala suerte. Es porque hay decisiones de arquitectura cuya consecuencia solo se ve cuando el sistema lleva un tiempo en producción real, y las hemos visto repetirse las suficientes veces como para listarlas. ## Almacenamiento: lo que parecía suficiente deja de serlo En el mes uno, una sola base de datos vectorial con todos los documentos parece la opción simple. En el mes tres, hay tres problemas a la vez. Los documentos crecen más rápido de lo previsto. Los permisos por usuario o por equipo no se modelaron desde el principio. Y la búsqueda empieza a perder calidad porque el índice mezcla contenidos heterogéneos que deberían estar separados. La solución casi siempre pasa por segmentar. Diferentes índices para diferentes tipos de contenido, con metadata explícita para filtrar antes de buscar, y una capa de permisos que se aplica en la consulta, no después. Es un trabajo que cuesta una semana hacerlo bien al principio y cuesta un mes rehacerlo en el mes tres con datos en producción. Pero rara vez se hace al principio, porque parece prematuro. Y rara vez deja de hacerse en el mes tres, porque es necesario. ## Observabilidad: lo que no se mira no existe En el mes uno, la observabilidad consiste en logs básicos de las llamadas al modelo y un panel rudimentario. En el mes tres, falta de todo. No se sabe qué consultas están fallando, no hay historial reproducible cuando un usuario reporta un problema, no se puede comparar el comportamiento del sistema entre dos versiones de prompts y nadie tiene visibilidad sobre el coste por consulta o por cliente. - Trazabilidad completa: input, contexto recuperado, llamada al modelo, salida, decisión final. - Métricas de calidad: tasa de respuestas que requirieron corrección humana, comparadas en el tiempo. - Métricas de coste: tokens por consulta, coste por usuario, coste por tipo de tarea. - Capacidad de replay: poder volver a ejecutar una consulta pasada con un prompt nuevo y comparar resultados. Estas cuatro capas son trabajo serio si se hacen bien y son imposibles de añadir tarde sin reescribir partes del sistema. La regla práctica es que la observabilidad se diseña al principio o no se tiene. Y sin ella, en el mes seis, las decisiones se toman a ciegas. ## Coste: el primer susto llega con la primera factura En el mes uno, los costes del modelo y la infraestructura parecen razonables. En el mes tres, alguien mira con detalle la factura y descubre tres cosas. Hay un porcentaje de consultas que cuestan diez veces lo que la media, normalmente porque arrastran un contexto enorme que nadie había validado. Hay procesos que llaman al modelo en bucle por error y consumen tokens sin generar valor. Y hay tareas que se podrían resolver con un modelo mucho más barato sin pérdida de calidad y se están resolviendo con el más caro por inercia. El control de coste no es un proyecto separado. Es una parte de la arquitectura desde el primer día. Cap por consulta, cap por usuario, alertas automáticas cuando el patrón cambia y separación clara entre tareas premium y tareas commodity. Sin esa disciplina, los costes pueden multiplicarse por cinco entre el mes uno y el mes seis sin que nadie lo note hasta que llegue la factura. ## Escalado: cuellos de botella donde no se esperaban En el mes uno, el sistema atiende a quince personas. En el mes tres, atiende a ciento cincuenta. Las cosas que se rompen no son las que esperabas. El modelo escala bien. La base vectorial escala bien. Lo que se rompe son las integraciones laterales: el CRM al que el agente escribe, que tiene un rate limit no documentado. El sistema de correo que empieza a marcar como spam los correos generados a volumen. La cola de procesamiento que se construyó como un script y no soporta carga concurrente. Anticipar estos cuellos de botella es muy difícil sin haber pasado por ellos antes. La regla que aplicamos es asumir que el sistema va a multiplicar su uso por diez en seis meses, y diseñar al menos las dependencias críticas para soportarlo. No al principio, pero sí con un plan claro de cómo se hará cuando empiece a hacer falta. ## Multi-tenancy: la decisión que cambia todo Si el sistema sirve a varios clientes o a varios equipos internos con datos separados, hay una decisión que afecta a todo lo demás: ¿se construye multi-tenant desde el principio, con aislamiento real entre datos y permisos, o se construye single-tenant y se replica cuando hace falta? La respuesta correcta depende del modelo de negocio. Pero en el mes uno casi siempre se elige la opción equivocada. Si vas a tener tres o más clientes en seis meses, multi-tenant desde el primer día. Si vas a tener uno o dos, replicar es más simple. Si no se sabe, conviene asumir lo primero. La diferencia de coste al principio es del veinte por ciento. La diferencia de coste cuando hay que migrar después puede ser un proyecto entero de tres meses. ## Una idea para llevarse No hay arquitectura perfecta. Hay arquitectura que sobrevive al mes tres y arquitectura que no. La diferencia rara vez está en elegir la tecnología más reciente o el modelo más nuevo. Está en haber pensado, antes de construir, qué va a romperse cuando el uso real choque con las decisiones del primer día. Las cinco zonas que aparecen aquí, almacenamiento, observabilidad, coste, escalado y multi-tenancy, son las que más se repiten en los proyectos donde entramos a auditar. Quien las anticipa, ahorra meses. Quien las descubre tarde, los paga.