Reconstruir el stack para la era de la IA: arquitectura componible, cloud y No-Code
Muy pocos CTOs tienen la oportunidad de construir un stack desde cero. La mayoría hereda uno: una colección de decisiones tomadas a lo largo de años, optimizadas para un mundo que ya no existe, con el peso suficiente para que reemplazarlo de golpe sea inviable y la disfunción suficiente para que dejarlo tal cual sea peor.
He pasado la mayor parte de mi carrera operando stacks heredados, no proyectos greenfield. Así que la pregunta en 2025 no es "¿cómo sería el stack ideal de la era de la IA?". Es "¿cómo hago evolucionar el stack que tengo hacia algo capaz de absorber cargas AI-native, integrarse con sistemas autónomos y escalar sin venirse abajo?".
La respuesta pasa por tres cambios estructurales que están convergiendo este año: la arquitectura componible, la rearquitectura del cloud para cargas de IA y el paso de Low-Code a No-Code en casos de uso acotados. Ninguno de estos conceptos es nuevo. Lo nuevo es que el argumento económico para convertirlos en compromisos arquitectónicos centrales — y no en experimentos tácticos — se ha vuelto muy difícil de rebatir.
Así es como yo plantearía la reconstrucción del stack sin engañarse pensando que se puede empezar de cero.
Los síntomas de que tu stack se ha quedado atrás
Antes de decidir qué cambiar, diagnostica qué está roto. Los síntomas de un stack que va por detrás de la era de la IA:
- Cada nueva integración tarda más que la anterior. Lo que antes era un sprint ahora es un trimestre. El código acumula acoplamiento más rápido de lo que tú acumulas capacidad.
- Cada feature de IA exige un pipeline a medida. Cada integración de un LLM reinventa la gestión de prompts, el parseo de salidas, la evaluación y la monitorización, porque la plataforma no ofrece primitivas compartidas.
- Los costes de cloud no escalan en línea con el uso. Los ingresos crecen 2x y el cloud crece 3x. La arquitectura te sirve a ti, pero no sirve a tu margen.
- Cada petición de cumplimiento desata seis semanas de apagar fuegos. Cada nueva regulación obliga a reauditar sistemas que no se diseñaron para ser auditados.
- Los ingenieros junior no pueden entregar features end-to-end. El stack tiene tantas piezas especializadas que cualquier trabajo no trivial requiere tres personas de tres equipos distintos.
Si reconoces más de dos, tu stack está acumulando deuda estructural más rápido de lo que puedes refactorizar. La reconstrucción no es opcional; lo único opcional es el alcance.
Arquitectura componible: la opción por defecto en 2025
El stack monolítico tradicional era coherente pero rígido. La era de los microservicios fue flexible pero operativamente brutal. La arquitectura componible — el verdadero camino intermedio, que por fin está madurando en 2025 — consiste en construir sistemas a partir de componentes bien definidos que se pueden desarrollar, reemplazar o escalar de forma independiente, pero sin la sobrecarga operativa de los microservicios puros.
Las características que definen un stack componible:
- Interfaces primero. Cada componente tiene un contrato bien definido (normalmente API + eventos). La implementación es intercambiable.
- Los datos como plataforma. Los datos son un activo compartido al que se accede mediante patrones consistentes, no un subproducto de servicios individuales.
- Acoplamiento laxo en runtime, estricto en diseño. Los componentes no necesitan conocerse entre sí en ejecución, pero en tiempo de diseño existe un modelo coherente de cómo se componen.
- Sustrato operativo común. Observabilidad, auth, despliegue y configuración son primitivas compartidas, no se reinventan en cada servicio.
El cambio que la mayoría de organizaciones necesita hacer en 2025 es pasar de "tenemos microservicios" a "tenemos primitivas componibles". Lo primero suele significar una maraña de servicios con contratos inconsistentes, patrones de integración ad hoc y heterogeneidad operativa. Lo segundo significa menos bloques de construcción, mejor definidos.
Qué aspecto tiene lo componible en la práctica
Un patrón concreto que funciona para la mayoría de scale-ups:
Capa de plataforma core (con criterios marcados, compartida):
- Gestión de identidad y accesos (fuente única de verdad para auth)
- Bus de eventos y/o cola de mensajes para la comunicación asíncrona
- Stack de observabilidad (logs, métricas, trazas, errores)
- Primitivas de despliegue e infraestructura (módulos IaC, plantillas golden)
- Plataforma de datos (data warehouse, streaming, gobernanza)
Capa de servicios de dominio (acotada, reemplazable):
- Servicios de lógica de negocio, cada uno dueño de sus datos, comunicándose mediante contratos bien definidos
- Servicios de integración que adaptan sistemas externos a los patrones internos
Capa de experiencia (flexible, de ciclo rápido):
- Aplicaciones frontend (web, móvil)
- Servicios backend-for-frontend (BFF) que componen servicios de dominio en APIs específicas de cada experiencia
- Capa de features de IA que integra LLMs, agentes y sistemas de retrieval
Capa de infraestructura de IA (emergente, con propósito):
- Capa de acceso a modelos con routing, fallback y evaluación
- Capa de retrieval y contexto (bases de datos vectoriales, embeddings, grafos de conocimiento)
- Runtime de agentes para orquestar el uso de herramientas
- Pipelines de feedback y evaluación
Esto no es una arquitectura de referencia: es un patrón. Los detalles dependen de tu dominio, tu escala y tu sistema actual. Lo que importa es que cada pieza tenga un rol claro y cada interfaz sea explícita.
Las cargas de IA rompen tu estrategia cloud de 2022
La estrategia cloud de 2025 es fundamentalmente distinta de la de 2022. Los tres cambios que importan:
1. El multi-cloud ya no es teórico
La mayoría de CTOs hablaba de multi-cloud pero operaba en un solo cloud. La economía no justificaba la complejidad. En 2025, el panorama de la IA ha cambiado el cálculo:
- El acceso a modelos condiciona la elección de región y de proveedor. El mejor modelo para tu caso de uso puede estar en un cloud distinto del de tu infraestructura principal.
- La disponibilidad de GPU depende de cada cloud y es volátil. Tener capacidad GPU reservada en AWS no sirve de nada cuando tu carga la atiende mejor un modelo en Azure.
- Las restricciones de soberanía de datos empujan hacia regiones concretas que no están disponibles en todas partes. Cumplimiento europeo, regulaciones sectoriales, requisitos contractuales de clientes.
No necesitas multi-cloud para todo. Lo que probablemente sí necesitas es una capa de IA multi-cloud: una abstracción que te permita enrutar cargas a distintos proveedores sin reescribir el código de aplicación.
2. El patrón «industry cloud» es real
Las plataformas cloud específicas de sector (ICP) están pasando de las diapositivas de los analistas a la adopción en producción. Para CTOs de salud, servicios financieros, sector público, retail o industria, el cálculo de construir-versus-comprar en el trabajo fundacional de plataforma ha cambiado. Los industry clouds de los hyperscalers resuelven cumplimiento, patrones de datos e integraciones que llevaría años construir internamente.
La pregunta no es si usar capacidades cloud específicas de tu sector; es cómo integrarlas sin un lock-in que hipoteque tu flexibilidad futura.
3. La arquitectura de costes es una cuestión de diseño, no de facturación
Las cargas de IA hacen que el coste del cloud deje de ser lineal. Una llamada a la API de un LLM puede costar 1000x más que una consulta a base de datos. La inferencia a escala añade costes que tus prácticas actuales de FinOps no modelan. Las bases de datos vectoriales con índices grandes se encarecen deprisa.
La disciplina de 2025: el coste es una restricción de diseño de primer orden. Cada decisión arquitectónica que involucre cargas de IA debería llevar adjunto un modelo de coste:
- Coste de inferencia por usuario a la escala objetivo
- Curva de crecimiento del coste esperada a medida que escala el uso
- Estrategia de contingencia cuando el coste supere el presupuesto
- Fallback a un modelo más barato donde la calidad lo permita
Los equipos que adoptan esta disciplina pronto se ahorran la conversación trimestral sobre por qué la factura de AWS se ha duplicado.
El No-Code como evolución natural del Low-Code
El No-Code suele despacharse como algo "para usuarios de negocio". Ese encuadre pasa por alto el cambio estructural que está ocurriendo.
La evolución es clara: las plataformas Low-Code democratizaron la construcción de aplicaciones simples. No reemplazaron a la ingeniería: le quitaron de encima una clase de trabajo trivial. El No-Code, con interfaces aumentadas por IA, está haciendo lo mismo con otra capa de trabajo.
Dónde importa el No-Code para un CTO en 2025:
1. Herramientas internas
Toda empresa construye docenas de herramientas internas: paneles de administración, interfaces de corrección de datos, herramientas de workflow para los equipos de operaciones. En 2020 las construían los ingenieros. En 2025 las construyen los propios equipos de operaciones con plataformas No-Code, supervisados por ingenieros que marcan las barreras de seguridad.
El tiempo de ingeniería que se recupera es sustancial. El riesgo es que, sin disciplina, acabes con un paisaje de shadow IT. El patrón que funciona: aprueba una plataforma No-Code concreta, define los patrones de acceso a datos, exige revisión interna para cualquier cosa que toque datos de cliente y deja que los equipos publiquen sus propias herramientas.
2. Automatización de workflows aumentada con IA
Los constructores de agentes No-Code, los orquestadores de flujos y las plataformas de automatización AI-native están madurando rápido. Para workflows que son predecibles en un 70%, con la IA gestionando el 30% que varía, las plataformas No-Code son la herramienta adecuada.
3. Prototipado rápido y validación de mercado
El caso del fundador en solitario: probar una idea de producto, validar un workflow, demostrar que un cliente pagará — todo antes de comprometerse con ingeniería de producción. Las plataformas No-Code son el lugar adecuado para hacerlo, y los CTOs deberían sentirse cómodos con este patrón en lugar de combatirlo.
Dónde no encaja el No-Code
Para ser precisos con los límites:
- Las superficies core del producto. El código que te diferencia de la competencia debería ser tuyo.
- Cualquier cosa con lógica de negocio compleja o requisitos altos de fiabilidad. Las plataformas No-Code tienen límites en ambos frentes.
- Cualquier cosa que vaya a escalar sustancialmente o a integrarse en profundidad con tus sistemas. El coste de migrar de plataforma cuando te quedas pequeño en el No-Code es mayor que el de construirlo bien desde el principio.
El papel del CTO es trazar estos límites de forma explícita, para que los equipos sepan dónde acaba el No-Code y dónde empieza la ingeniería.
El plan pragmático de reconstrucción
No estás construyendo un stack desde cero. Estás haciendo evolucionar uno. Así es como yo lo secuenciaría:
Fase 1: Evaluar (4–6 semanas)
- Inventaría el stack. Cada servicio, cada integración, cada pieza de infraestructura compartida.
- Clasifica cada pieza. Estratégica (nos diferencia), commodity (tiene que funcionar pero no es especial), legacy (con fecha de retirada).
- Mide el dolor. ¿Qué piezas nos frenan? ¿Cuáles cuestan de forma desproporcionada? ¿Cuáles bloquean iniciativas futuras?
- Mapea contra la arquitectura objetivo. ¿Qué pieza pertenece a qué capa componible?
Fase 2: Elegir la primera apuesta (1–2 meses de ejecución)
La primera iniciativa de reconstrucción debería ser:
- Concreta (un componente específico, no "modernizar la plataforma")
- Acotada (se termina en un trimestre, no en un año)
- De alto valor (elimina un dolor significativo)
- De bajo riesgo (si falla, no tumba el negocio)
Una buena primera apuesta puede ser consolidar el stack de observabilidad, construir una capa unificada de acceso a IA o extraer un servicio de dominio con una interfaz limpia.
Fase 3: Establecer el patrón
La primera iniciativa no vale solo por su resultado. Vale por los patrones que establece para el resto del stack: estándares de interfaz, patrones de despliegue, contratos de observabilidad, primitivas de integración de IA.
Si aciertas aquí, las iniciativas siguientes irán más rápido. Si fallas, cada iniciativa posterior volverá a discutir las mismas decisiones.
Fase 4: Escalar la reconstrucción
Ahora la reconstrucción se vuelve sistemática. Iniciativa a iniciativa, vas migrando el stack hacia la arquitectura objetivo — sin hacer nunca una reescritura big-bang. Cada iniciativa tiene valor por sí misma; el efecto acumulado es un stack transformado.
Un ritmo razonable son 2–4 iniciativas arquitectónicas significativas al año. Más rápido suele generar demasiados frentes abiertos a la vez. Más lento significa que el objetivo no deja de moverse.
Las reconstrucciones fracasan como proyecto secundario
Las reconstrucciones de stack compiten con el trabajo de producto por el tiempo de ingeniería. La tensión es real y no tiene solución completa.
El patrón que he visto funcionar: dedicar un equipo de plataforma (2–4 ingenieros más un tech lead) a la reconstrucción arquitectónica, separado de los equipos de features. El equipo de plataforma es dueño de la evolución de las primitivas componibles. Los equipos de features las consumen.
Para organizaciones que no tienen plantilla para un equipo de plataforma dedicado, los squads nearshore dedicados encajan bien en este molde. El trabajo de plataforma tiene entregables claros, un alcance acotado y se beneficia de ingenieros centrados en él a tiempo completo en lugar de saltar de contexto.
Esto no va de ahorrar costes; va de concentrar el esfuerzo. Una reconstrucción de arquitectura sale adelante cuando alguien piensa en ella a tiempo completo, no cuando es el proyecto secundario de tres ingenieros de producto.
El stack que gana en 2025
Los CTOs que irán por delante en 2026 son los que están haciendo apuestas arquitectónicas concretas este año:
- Primitivas componibles, no proliferación de microservicios.
- Una capa de integración de IA que sea un producto, no una colección de llamadas a APIs.
- Multi-cloud donde importa (IA, cumplimiento) y un solo cloud donde no.
- No-Code para los problemas adecuados, ingeniería para los que no lo son.
- Un equipo de plataforma, o capacidad equivalente, liderando la reconstrucción.
Los que se quedan atrás son los que siguen parcheando un stack de la era 2020 con requisitos de 2025: una batalla perdida que se complica cada trimestre.
Si estás dotando de equipo una reconstrucción de plataforma junto a tu equipo in-house, habla con un CTO sobre cómo es en la práctica un squad de plataforma nearshore.
