Arquitectura empresarial: traductora entre negocio, tecnología e IA
Leí una publicación en LinkedIn que afirmaba que el rol del arquitecto cambia a partir del tamaño de la organización en la que trabaja. En startups, gran parte de su trabajo es técnico, es decir, programando, mientras que, en empresas más grandes, este rol pasa a convertirse en el de un estratega generalista, alguien con capacidad de guiar las decisiones mirando el todo.
En este punto es donde entra la visión clásica de la arquitectura empresarial como el puente entre negocio y tecnología, como el punto máximo de esta mirada. Hoy podemos decir que un nuevo actor se sumó a la ecuación. Ya no se trata solo de relacionar negocio con tecnología. Ahora, la propia tecnología se separa entre lo tradicional y la mirada agéntica que trae la última evolución de la inteligencia artificial (IA). Y eso cambia completamente la práctica.
La IA no entiende presentaciones en Power Point. O sí, pero no como tradicionalmente se espera. La IA, como una herramienta para el desarrollo acelerado mediante agentes, no entiende una hoja de ruta en una diapositiva ni el comité de arquitectura ni un organigrama ni tampoco la documentación de arquitectura con suerte poco obsoleta.
Lo que sí comprende es un contexto estructurado, formado por reglas explícitas, restricciones medibles y límites operativos. En pocas palabras, especificaciones claras. Si no se le brinda esto como parte del proceso, improvisa. Y cuando improvisa en producción, el costo es real. Ahí es donde la arquitectura empresarial modernizada y actualizada vuelve a ser crítica.
En la mirada tradicional, un arquitecto interactúa con los actores de negocio, tecnologías de la información (TI), seguridad, infraestructura, producto. Sin embargo, esta visión ya queda corta. Hoy se deben sumar a copilotos de desarrollo, agentes que escriben código, agentes que generan decisiones, flujos de trabajo autónomos. Estos últimos invitados a la fiesta no son herramientas, sino actores activos en la cadena de valor del software. Y si son actores, deben ser tratados como tal.
En un modelo de ingeniería cibernética, en el que el desarrollo se potencia por la integración entre criterio humano y velocidad agéntica, la aceleración es brutal: las especificaciones de producto en el modelo tradicional historias de usuario, pasan a ser especificaciones cocreadas con agentes. Los ciclos de desarrollo pasan de semanas a horas, con calidad y documentación aseguradas, con algunos ejemplos.
Pero si no existe un marco claro de especificaciones estructuradas, reglas versionadas, trazabilidad entre decisiones, validaciones automáticas, lo que estamos acelerando no es valor, sino complejidad.
Solíamos pensar en la arquitectura como una forma de acelerar y alinear la toma de decisiones por parte de personas, por eso el foco estaba en ser claros comunicando a diferentes audiencias. Sin embargo, nuestra nueva audiencia requiere otra forma de comunicar, donde muchas veces ni siquiera hace falta documentación. ¿Hay algo más claro sobre cómo funciona un sistema que su código, si sabemos entenderlo? La IA ya puede hacerlo, y muy bien.
Cambios en la arquitectura empresarial
Hoy, la arquitectura pasa a tener un rol activo en el proceso, y deja de ser una herramienta de soporte a las decisiones, lejos de la ejecución. Ante este escenario, la arquitectura debe convertirse, en primer lugar, en contratos formales — y gobernados, para que agentes hagan lo que se espera que hagan, mediante el diseño de estándares de reglas, habilidades y lógica que estandarice la forma en que los agentes funcionan. "Cursor rules" o "Claude code memory" son buenos ejemplos.
A su vez, lo que esperamos que el sistema haga debe pasar a representarse en especificaciones legibles por modelos, entendible por humanos. Aquí juega mucho métodos como Spec Driven Development una metodología de ingeniería de software, potenciada por IA, que prioriza la redacción de especificaciones técnicas detalladas y estructuradas antes de escribir o generar código
Por último, debe convertirse en una memoria organizacional estructurada, guiada automáticamente desde la fuente de verdad más confiable, el código fuente, la configuración de la infraestructura y los flujos de negocio automatizados. En otras palabras: la arquitectura debe volverse ejecutable, no como código solamente, sino como sistema de gobierno para decisiones tomadas por humanos y por agentes.
Ante esta nueva realidad, surge un interrogante. Si los agentes diseñan, implementan, evalúan y recomiendan, ¿quién gobierna a los agentes? Hoy muchas organizaciones usan copilotos aislados, lo que es una buena noticia de cara a la escala. Pero sin trazabilidad, versionado de reglas, ni control de alineación con estrategia. Eso es riesgo estructural.
Si a esto se le suma trazabilidad entre requerimiento de negocio y decisión generada por IA y evaluación sistemática de impactos y riesgos, se obtiene el nuevo sistema de gobierno de decisiones de arquitectura, sin carga burocrática, sino como arquitectura adaptada a un mundo donde los sistemas también deciden.
Si no rediseñamos la forma en que gobernamos las decisiones y los activos TI en las organizaciones cada equipo tendrá sus propios prompts, cada agente operará con contexto parcial, cada decisión será difícil de auditar y la deuda arquitectónica crecerá exponencialmente. La IA no generará caos, pero amplificará el que ya existe. En este momento ya no debemos preguntarnos si usar o no agentes, sino pensar ¿Tenemos una arquitectura capaz de gobernarlos?
