Diseñando una Landing Zone enterprise en 2026: el framework de decisiones estructurales para clientes con legacy y ambición de IA

En varios kickoffs de Landing Zone enterprise en LATAM, se repite un patrón común: inventarios que incluyen unos 40 servidores físicos poco deseados, un cluster VMware con muchas VMs, aplicaciones en Windows Server 2016 al borde del fin de soporte extendido, y un roadmap que promete adoptar IA generativa sin detalles sobre arquitectura, modelo o gobierno.

El requerimiento habitual es iniciar sin deuda técnica desde el diseño. Sin embargo, tratar el diseño como un proyecto de migración a AWS no es apropiado, ya que es el diseño de la plataforma sobre la que el cliente operará durante cinco a siete años, con cargas y modelos de IA que aún no están anunciados, y con requisitos regulatorios que pueden cambiar en ese período.

La Ley 21.719 en Chile, que entra en vigor en diciembre de 2026, ya ha obligado a revisar controles de datos en varios proyectos activos este año.

El framework de decisiones estructurales para clientes con legacy y ambición de IA se presenta aquí. Este framework se crea antes de escribir la primera línea de Terraform, no es un tutorial de Control Tower, sino una secuencia que define si la Landing Zone sigue siendo la plataforma correcta en el año tres. El blueprint de Landing Zone de 2022 ya no es suficiente como referencia única, ya que ahora se deben considerar asunciones adicionales.

En este framework, se establecen seis decisiones estructurales clave:

1. Modelo de OU con horizonte de plataforma, no de proyecto de migración: el modelo de OU se debe diseñar en función de la plataforma, no como una estructura para proyectos de migración. Las cuentas del legacy deben ser ciudadanos permanentes, no visitantes. El modelo incluye una OU de AI separada para agentes con patrones de consumo, de red y de identidad distintos de las aplicaciones clásicas.

2. AWS Transform como parte del diseño, no como herramienta paralela: AWS Transform integra el assessment al diseño, procesando datos de VMware vCenter, Hyper-V y otras fuentes para identificar servidores, dependencias y agrupaciones de aplicaciones. Luego, genera escenarios de assessment, TCO y configuraciones de red para topologías hub-and-spoke o isolated, con soporte de migración desde varios proveedores de seguridad.

AWS Transform también genera configuraciones de control de acceso y permite alineación de la Landing Zone con el wave planning.

3. Identity Center desde el primer día: se debe implementar Identity Center desde el principio para gobernar identidades no-humanas como agentes autónomos, flujos MCP y cargas de Bedrock. Esto es necesario desde el diseño, no como retrofit.

4. Seguridad y guardrails: se deben establecer guardrails para mantener la seguridad y controlar el acceso a los recursos, basados en los requisitos de cada carga y la naturaleza de cada OU.

5. Planificación de waves de migración: se deben definir waves de migración basadas en la clasificación de aplicaciones y servidores, determinando qué cargas se rehostan puro, cuáles requieren refactor y cuáles no se mueven. Cada wave debe asignar cuentas destino y OUs correspondientes.

6. Modelos de IA y requisitos regulatorios: se deben diseñar modelos de IA y estrategias de cumplimiento regulatorio desde el principio. Esto incluye la creación de OUs separadas para AI y el desarrollo de guardrails específicos para controlar y gestionar estos modelos dentro de la Landing Zone.