La IA no solo aumentó la velocidad de entrega, sino que rompió la cadencia con la que se valida la arquitectura. La mayoría de las organizaciones siguen revisando la arquitectura a un ritmo diseñado para lanzamientos trimestrales, mientras se despliegan varias veces al día. Ese desajuste estructural, la distancia entre la velocidad de despliegue y la validación arquitectónica, es lo que yo llamo la brecha de revisión de arquitectura. Hoy en día, es la fuente de riesgo no gestionado que más rápido crece en las operaciones en la nube, y es la más amplia entre los equipos que creen que menos necesitan revisiones

Cómo es la diferencia en la práctica

El año pasado, una empresa SaaS de tamaño medio nos pidió que realicáramos una revisión arquitectónica de su entorno AWS. Llevaban tres años funcionando en la nube, contaban con un equipo de ingeniería competente y recientemente habían adoptado herramientas de codificación de IA en todos sus equipos de desarrollo. La velocidad se había duplicado, con despliegues que pasaban de ser semanales a diarios, y el liderazgo de ingeniería estaba encantado.

La revisión duró cuatro días, lo que salió a la luz tardó meses en abordarse. Tres cosas ocurrieron mientras el equipo celebraba la velocidad:

Desviación de seguridad. Una regla de grupo de seguridad de prueba de concepto, creada durante una sesión de depuración ocho meses antes, seguía abierta a internet. Nadie lo había vuelto a visitar porque la sesión de depuración había quedado en el olvido hace tiempo, y los despliegues generados por IA que siguieron nunca cuestionaron la configuración existente.

Fragmentación de datos. Tres equipos distintos habían provisionado sus propias tablas DynamoDB para lo que resultó ser el mismo dominio de datos, cada uno con diferentes modos de capacidad y ninguno con políticas de respaldo. La IA generaba lo que cada equipo pedía; Nadie preguntó si el dominio ya estaba modelado en otro lugar.

Error de configuración de costes a gran escala. La anomalía de costes que desencadenó la revisión en primer lugar, un sobrepaso presupuestario del 40% en un solo trimestre, se remontaba a funciones Lambda generadas por IA desplegadas con asignaciones de memoria predeterminadas y sin configuraciones de tiempo de espera. Docenas de ellos, en múltiples servicios, cada uno razonable individualmente, colectivamente caro.

Nadie había revisado las decisiones de infraestructura porque nadie las había tomado deliberadamente, la IA sí.

El verdadero hallazgo fue la propia brecha: la distancia entre la rapidez con la que el equipo se desplegaba y cuántas veces se paraban a preguntar si lo que estaban desplegando era arquitectónicamente sólido.

La trampa de velocidad

Hay un patrón que sigo encontrando entre los egagements. Un equipo adopta herramientas de codificación por IA, la velocidad aumenta, los despliegues se aceleran, los paneles se vuelven verdes y el liderazgo celebra. Luego, seis o doce meses después, algo se rompe de una manera que revela que la arquitectura nunca fue revisada tras el inicio de la aceleración.

La trampa de velocidad funciona así: la IA elimina la fricción que antes creaba puntos de control naturales de revisión. Cuando la IA genera una plantilla completa de CloudFormation en minutos, desaparece la pausa que la programación humana solía imponer. El equipo aprueba la infraestructura junto con el código de la aplicación y sigue adelante, y para el tercer despliegue del día la revisión de infraestructura es un vistazo, no una evaluación.

Esto se ve incluso en las discusiones públicas sobre ingeniería: un equipo de doce ingenieros que enviaban tres o cuatro veces al día con herramientas de IA habían duplicado su velocidad, pero no podían saber qué versión de su servicio de pago estaba activa. La respuesta de la comunidad fue directa: «En nombre de la IA, todo el mundo se apresura con el trabajo y pierde el hilo de las características e historias.»

El problema es estructural, no disciplinario. La cadencia de revisión fue diseñada para una cadencia de despliegue que ya no existe. Las revisiones trimestrales de arquitectura tenían sentido cuando los equipos se lanzaban trimestralmente. Cuando los equipos se envían a diario, una revisión trimestral significa noventa despliegues entre puntos de control. La brecha en la revisión de arquitectura se amplía con cada despliegue que pasa sin validación, y los equipos acelerados por IA la están ampliando más rápido que nadie.

Lo que ya estaban captando las críticas

Nada de esto es completamente nuevo. Antes de que la IA entrara en escena, las revisiones de arquitectura ya eran la práctica más infravalorada en las operaciones en la nube. En más de veinte proyectos de gobernanza en Clouxter, las revisiones ponen a la luz de forma constante las mismas categorías de hallazgos: suposiciones de costes que se rompen bajo uso real, brechas de resiliencia ocultas por el bajo tráfico, configuraciones de seguridad heredadas de pruebas de concepto que se fueron desvíando con el tiempo y estructuras de múltiples cuentas que ya no coinciden con la realidad organizativa.

Estos hallazgos son el equivalente operativo de intereses compuestos que juegan en tu contra: pequeñas decisiones individualmente razonables que se acumulan en riesgo estructural con el tiempo.

Lo que cambia con la IA es la velocidad a la que se acumulan estos problemas.

Qué cambia la IA sobre qué deben captar las reseñas

La IA acelera la acumulación y añade categorías completamente nuevas de riesgo arquitectónico que las revisiones tradicionales nunca fueron diseñadas para detectar.

La infraestructura generada por IA se solidifica antes de la revisión

En mi publicación anterior sobre la construcción de mafias, describí un modo de fallo que llamo quick-cement: la salida de la IA se solidifica antes de que nadie verifique que es correcta. Ese problema se aplica a infraestructuras, con consecuencias aún mayores que al código de aplicaciones.

Cuando la IA genera una función Lambda con una asignación de memoria de 512MB y un tiempo de espera de 30 segundos, esas son decisiones arquitectónicas. Cuando proporciona una tabla DynamoDB con modo de capacidad bajo demanda, eso es una decisión de coste. Cuando crea un rol IAM con permisos más amplios de los necesarios porque el prompt dice «haz que funcione», eso es una decisión de seguridad. Ninguna de estas decisiones se tomó deliberadamente. La IA las infirió a partir del contexto, las aprobó junto con el código de la aplicación y se desplegó antes de que alguien las evaluara como opciones arquitectónicas.

La revisión tradicional de arquitectura asume que las decisiones de infraestructura las toman personas que pueden explicar su razonamiento. La infraestructura generada por IA no tiene razón para explicarlo. No hay arquitecto que haya elegido la capacidad bajo demanda frente a la aprovisionada tras analizar los patrones de acceso. No hay ningún ingeniero de seguridad que haya evaluado los permisos IAM según el principio del privilegio mínimo. Hay un prompt, una configuración generada y una pipeline de despliegue que lo trató todo como una sola unidad.

Las cargas de trabajo de IA crean nuevas dinámicas de costes

Las cargas de trabajo de GPU representan ahora el 18% del gasto en la nube empresarial, frente al 4% de 2023. Según S&P Global, el 80% de las empresas se queda por encima de las previsiones de costes de infraestructura de IA por más de un 25%. Entre el 30% y el 50% del gasto en GPU se desperdicia en capacidad de reposo.

Los costes de carga de trabajo en IA se comportan de forma diferente a los costes tradicionales de la nube. Son picantes: el entrenamiento de modelos, el ajuste fino y los grandes estallidos de inferencia generan gastos desiguales que los promedios mensuales ocultan. Están distribuidas: la misma organización puede estar ejecutando cargas de trabajo de IA en nubes públicas, plataformas SaaS de IA e infraestructura local, sin una visión unificada de costes. Y se fijan desde el principio: una vez que los modelos están entrenados, las tuberías desplegadas y las incrustaciones se poblan, la estructura de costes es difícil de cambiar. Un equipo realiza ajustes de trabajo durante un fin de semana, olvida cerrarlos y vuelve el lunes con una factura de cinco cifras. El principio de la economía de desplazamiento a la izquierda, que introduce la modelización de costes antes del despliegue en lugar de después, es la práctica definitoria para la gobernanza de costes de la IA en 2026.

Una revisión de arquitectura que no examina los patrones de coste de la carga de trabajo de la IA está revisando la arquitectura equivocada. La factura de 97.000 dólares de Bedrock que surgió en Reddit, acumulada en 48 horas a través de las mismas lagunas de gobernanza (sin MFA, sin políticas de control de servicios, sin alarmas de facturación) que solían permitir el abuso de la minería de criptomonedas, es la nueva normalidad para organizaciones que tratan la infraestructura de IA como una carga de trabajo más en la nube.

La brecha entre el piloto y la producción

Es la misma brecha en la revisión de arquitectura, pero en otra forma.

El setenta y ocho por ciento de las empresas ha desplegado pilotos agentes de IA. Solo el 14% ha alcanzado la escala de producción. Esa brecha de 64 puntos, confirmada por una encuesta de marzo de 2026 a 650 líderes tecnológicos empresariales, se remonta a la arquitectura, no a la calidad del modelo.

Los pilotos se ejecutan en entornos aislados con seguridad relajada, redes simplificadas y una gobernanza sin coste. La arquitectura que soporta un piloto, una sola cuenta, un rol IAM permisivo, una VPC predeterminada, no escala a producción. La revisión que debería realizarse entre el piloto y la producción, la que evalúa la estructura multicuenta, la segmentación de la red, la gestión de identidad, el control de costes y la preparación operativa, es la revisión que la mayoría de las organizaciones se saltan porque el piloto «ya funciona».

Este es el patrón de migración a la nube repitiéndose. Como escribí en Por qué tu migración a la nube tuvo éxito y tus operaciones en la nube no, las organizaciones invierten mucho en llegar a la nube y luego descubren que operar allí requiere músculos completamente diferentes. La misma dinámica se está repitiendo con la IA: las organizaciones invierten en poner en marcha modelos de IA y luego descubren que operar cargas de trabajo de IA a gran escala requiere una gobernanza arquitectónica que nunca construyeron.

Qué cambios de IA sobre cómo deberían funcionar las revisiones

El argumento hasta ahora ha sido sobre la urgencia: la IA hace que las revisiones de arquitectura sean más necesarias. Pero la IA también los hace más poderosos, si las organizaciones están dispuestas a replantearse cómo funcionan las revisiones.

La mayoría de las organizaciones no carecen de herramientas. No tienen un ritmo de revisión acorde con la realidad de su despliegue.

Eso es un problema del modelo operativo, no una brecha tecnológica.

La revisión tradicional de arquitectura es una evaluación puntual. Un equipo de arquitectos dedica unos días a examinar el entorno, elabora un informe y la organización dedica el siguiente trimestre a abordar los hallazgos. Cuando llega la siguiente revisión, el entorno ha vuelto a cambiar. Este modelo fue diseñado para un mundo donde la infraestructura cambiaba lentamente. En un entorno acelerado por IA, es un artefacto de gobernanza de una era anterior.

Lo que los equipos acelerados por IA necesitan es una evaluación arquitectónica continua: revisiones integradas en el ritmo de entrega, no programadas en un calendario. Las herramientas ya existen. AWS lanzó el Acelerador WAFR para automatizar las evaluaciones iniciales según los pilares del Marco Bien Arquitectado. En re:Invent 2025, introdujeron tres nuevas Lentes Bien Arquitectadas específicamente para cargas de trabajo de IA: IA responsable, Aprendizaje Automático e IA Generativa. La Lente de la Industria de Servicios Financieros se actualizó para incluir orientación para sistemas de IA agente.

Microsoft ha realizado una inversión paralela. El Azure Well-Architected Framework incluye ahora un área dedicada al diseño de cargas de trabajo de IA con su propia herramienta de evaluación, y la guía responsable de IA se actualizó en 2025 con salvaguardas específicas para sistemas agentes. Ambos grandes proveedores de nube reconocieron la misma brecha y desarrollaron las herramientas. La brecha persiste porque la práctica no ha alcanzado.

Pero las herramientas sin práctica son productos de estantería. La diferencia entre las organizaciones que utilizan estas herramientas como instrumentos de diagnóstico continuo y aquellas que las ejecutan una vez al año para marcar una casilla de cumplimiento es la misma diferencia que separa a las organizaciones que consideran la monitorización como observabilidad de aquellas que lo tratan como un panel de control. La herramienta es idéntica. El compromiso organizativo de actuar según lo que revela es lo que separa la gobernanza del teatro.

La mentalidad diagnóstica

Las revisiones de arquitectura más valiosas que he facilitado son aquellas en las que el equipo se sorprende con los hallazgos. No porque la revisión revelara fracasos catastróficos, sino porque reveló suposiciones que el equipo no sabía que estaba haciendo.

Un equipo asume que su plan de recuperación ante desastres funciona porque está documentado. La revisión revela que nunca ha sido probado, y la estrategia de respaldo depende de una región que las leyes de soberanía de datos pueden no permitir. Un equipo asume que sus costes están bajo control porque la factura mensual está dentro del presupuesto. La revisión revela que el 40% de su gasto en cálculo se destina a recursos destinados a una prueba de carga hace tres meses que nadie desmanteló. Un equipo asume que su postura de seguridad es sólida porque pasó la última auditoría. La revisión revela que la auditoría evaluó la configuración de la zona de aterrizaje, no los 200 cambios en la política IAM acumulados desde entonces.

La mentalidad diagnóstica trata la revisión como un instrumento que revela lo que el equipo no puede ver desde dentro del sistema. Es el equivalente organizativo de un chequeo médico: el valor está en detectar lo que no sabes, no en confirmar lo que haces.

Para los equipos acelerados por IA, esta mentalidad no es opcional. La velocidad que permite la IA es realmente valiosa, pero solo cuando la arquitectura subyacente puede sostenerla. Un equipo que lanza cuatro veces al día sobre una base que fue revisada por última vez hace seis meses está acumulando riesgos a cuatro veces la tasa anterior, independientemente de lo que diga el panel de velocidad.

Cerrando la brecha

La brecha en la revisión de arquitectura es una desadaptación del modelo operativo. Las herramientas existen: revisiones del Framework Bien Arquitectado, lentes específicas para IA, detección automática de deriva, alertas de anomalías de costes, monitorización continua del cumplimiento. AWS, como plataforma, ofrece más herramientas de gobernanza arquitectónica de las que utilizan la mayoría de las organizaciones.

La brecha reside en la distancia entre saber que las revisiones de arquitectura importan y realizarlas realmente a un ritmo que coincide con la velocidad de despliegue. La velocidad y la solidez arquitectónica son variables independientes, y la evidencia muestra consistentemente que los equipos que construyen más rápido suelen ser los que tienen la mayor diferencia.

Para cerrarla se requieren tres turnos.

Primero, trata las revisiones de arquitectura como una práctica diagnóstica, no como un evento de cumplimiento. Organízalos según la velocidad de despliegue, no los trimestres del calendario. Un equipo que despliega diariamente necesita puntos de control arquitectónicos mensuales, no anuales.

Segundo, ampliar el alcance de la revisión para incluir dimensiones específicas de la IA. Los patrones de costes para cargas de trabajo de IA, las dependencias de la infraestructura de agentes, el riesgo de concentración de API de modelos y la gobernanza de configuraciones de infraestructura generada por IA son todas preocupaciones arquitectónicas que las revisiones tradicionales pasan por alto.

Tercero, haz que la revisión sea una práctica de equipo, no una auditoría externa. Los equipos que más se benefician de las revisiones de arquitectura son aquellos en los que participan los ingenieros que construyen el sistema en su evaluación. Los revisores externos aportan perspectiva; La participación interna fomenta la conciencia arquitectónica que impide que los hallazgos se repitan.

Los equipos que sobreviven a la entrega acelerada por IA no son los que lanzan más rápido. Son ellos quienes saben qué enviaron, por qué lo enviaron y si la arquitectura que hay debajo puede mantener el ritmo.

Las revisiones de arquitectura son la forma de evitar que la velocidad se convierta en riesgo.

Ricardo