Marco de arquitectura para la cartera de proyectos de IA

Contexto

Un grupo empresarial B2B desarrolla en paralelo una cartera de proyectos técnicos que comparten decisiones de infraestructura: identidad, hosting, datos, red, secretos, observabilidad, agentes de IA e infraestructura como código. Para unificarlas se construyó un marco de arquitectura único y prescriptivo, publicado en mayo de 2026. Las revisiones siguientes se contrastaron contra un solo proyecto cada vez, sin verificar si toda la cartera lo cumplía.

Problema

Una auditoría contra toda la cartera —19 proyectos, 17 capas por sujeto, 340 celdas evaluadas— midió 11% de cumplimiento global (27 conformes sobre 241 aplicables), con cuatro capas en 0%: datos, mensajería, agentes de IA y recuperación ante desastres. El hallazgo relevante no fue el porcentaje sino la correlación: el cumplimiento se explicaba por haber pasado una revisión de gobierno técnico, no por la existencia del marco. Se sumó un problema de domicilio: la copia oficial servía una versión desactualizada mientras la vigente vivía dispersa en repositorios de proyecto.

Solución

La auditoría clasificó cada celda no conforme en dos destinos: si rompía una garantía del marco, la celda se clasificaba para corrección del proyecto (75 casos); si el marco no preveía una forma mejor de resolver algo, se corregía el marco (32 casos, trece como patrón canónico). De ahí un axioma nuevo: un control es técnico o no es un control.

• Tabla que traduce cada guardarrail exigido a una implementación verificable —permiso de acceso, archivo de configuración versionado, límite de cuenta—, descartando los que solo existen como texto.
• Gobernanza documental: una única copia escribible, versionado semántico donde una versión mayor invierte una regla vigente, y prohibición de copiar el marco dentro de un proyecto.
• Cada cambio de versión trae una regla de detección ejecutable y abre una tabla de adopción por proyecto, con responsable y fecha; la verificación se integró al escaneo diario de la cartera.

Resultados

• Nueve versiones vigentes en 97 días —de 1.244 a 2.186 líneas, de 97 a 125 subsecciones, de 7 a 8 axiomas—, cada una trazada a su motivo.
• Una versión mayor invirtió un modelo de componentes compartidos acordado poco antes con el área de gobierno técnico; la inversión quedó declarada en el encabezado, no omitida.
• Quedaron verificadas alineaciones puntuales: un proyecto reescribió su pedido de infraestructura, dos desplegaron su entorno de pruebas como código.
• El capítulo de gobernanza quedó operativo con un archivo único que declara la versión vigente y carpetas separadas para el feedback externo.
• El retrofit de la última versión mayor sigue abierto y la cartera no volvió a auditarse con el método inicial: no hay medición de cumplimiento posterior a la reforma.

Arquitectura y decisiones

Cada celda evaluada cruza un sujeto (un proyecto o la capa transversal) con una dimensión de arquitectura, así que el porcentaje de cumplimiento mide algo más específico que “seguir el marco”: mide cuántas de esas combinaciones tienen una implementación verificable. La correlación con haber pasado por una revisión de gobierno técnico, más que con la mera existencia del marco, orientó la reforma hacia hacerlo autoejecutable en vez de autoexplicativo.

La tabla de guardarrails técnicos traduce cada exigencia en una condición comprobable por herramienta —un permiso de acceso, un archivo de configuración presente y versionado, un límite de cuenta activo— y descarta cualquier control que dependa solo de una instrucción escrita sin verificación asociada. El capítulo de gobernanza agregó una regla de adopción: ninguna versión mayor se considera vigente hasta que cada proyecto afectado tiene su fila completa en la tabla de adopción, con responsable y fecha de compromiso. La verificación de cumplimiento se integró al mismo proceso que ya escaneaba la cartera a diario, para no depender de una auditoría manual repetida.