La empresa como territorio habitado

El entorno digital de una empresa mediana o grande puede leerse como un territorio habitado, con fronteras, zonas, infraestructura compartida, rutas, un subsuelo de datos y una población de personas, sistemas y agentes de IA que trabajan bajo reglas comunes. Esa es la propuesta de la Urbanización del Mundo Digital (DWU), un marco conceptual que desarrollé, y parte de un límite de la arquitectura empresarial tal como suele practicarse, donde el inventario de aplicaciones enumera los activos sin explicar cómo se gobiernan juntos.

Lo que un inventario sabe

El inventario de Northstar Consumer Group muestra ese límite. Northstar es un caso ficticio que uso en toda la serie, un fabricante y minorista regional con cinco entidades legales en cinco países, y su inventario de aplicaciones está al día. Tiene filas para el ERP, para las plataformas de clientes y de fuerza laboral, para cada aplicación de país y para la plataforma de datos en la nube, más de cuarenta filas de productos analíticos y doce de agentes inteligentes experimentales, cada una con un dueño anotado y su costo.

Cuando el área de Cadena de suministro pide llevar a producción el agente de compras, el que prepara órdenes de compra, el inventario tiene una fila para ese agente y ninguna respuesta. No dice con las reglas de cuál entidad debe operar, ni quién responde si prepara una orden equivocada, ni con qué identidad actúa (hoy usa credenciales heredadas de un desarrollador), ni por qué ruta llega la orden al ERP, ni de qué maestro de proveedores lee.

Un inventario de aplicaciones es una lista de activos, y como lista es útil para renovar licencias, explicar costos y saber a quién llamar cuando algo se cae. Lo que una lista no puede guardar es la relación entre sus elementos, es decir, qué reglas comparten dos aplicaciones, qué servicio común usan, por dónde viaja un dato de una a otra y quién tiene autoridad sobre ese viaje.

La arquitectura empresarial tiene herramientas más ricas. Zachman (1987) organizó las descripciones de la empresa según las perspectivas de sus interesados, y TOGAF (The Open Group, 2022) formalizó métodos, gobierno y contenido reutilizable. Ambos siguen siendo necesarios, pero suelen practicarse con modelos estáticos, puertas de proyecto y documentos de estado objetivo, y a ese estilo le cuesta seguir el desarrollo repartido por producto, las plataformas que evolucionan sin pausa y, ahora, los actores de software que actúan por su cuenta.

En Northstar hay tres implementaciones de notificaciones, una en el e-commerce, otra en la plataforma de fuerza laboral y otra en la aplicación de uno de los países. El margen se calcula de tres maneras según lo mire Finanzas en el cierre, el dashboard comercial o esa aplicación de país, que además lee tablas del ERP directamente, igual que la herramienta de BI. Varias integraciones comparten la cuenta de servicio svc-integracion. Ningún problema de esa lista pertenece a una fila del inventario, y por eso ningún dueño de aplicación lo tiene entre sus pendientes.

Durante tres años apliqué estas ideas en arquitectura de plataformas empresariales y vi repetirse ese patrón, problemas que nadie negaba y que quedaban sin dueño entre dos responsabilidades bien definidas. En arquitectura cloud AWS e IA para empresas conté por qué diseño empezando por el diagnóstico; DWU intenta darle a ese diagnóstico una unidad de análisis que abarque el conjunto.

El mundo digital como territorio de siete sistemas

Esa unidad es el mundo digital empresarial, el entorno sociotécnico acotado, aunque permeable, a través del cual una organización ejecuta capacidades, coordina actores, procesa información y crea valor. DWU deja de mirar la aplicación o el portafolio y mira ese entorno completo.

Ese mundo se acumula sin un plano único, por proyectos, adquisiciones, exigencias regulatorias, hojas de cálculo, servicios en la nube y, cada vez más, agentes. Cada pieza puede ser útil donde está y el conjunto, aun así, producir fragmentación, capacidades duplicadas, identidades inconsistentes y flujos de datos opacos.

La afirmación central del marco es que un entorno así no debería gobernarse únicamente como portafolio. Puede analizarse como un territorio sociotécnico en evolución, habitado por personas, aplicaciones, servicios, productos de datos, modelos y agentes. «Territorio» porque tiene fronteras, jurisdicciones y reglas que aplican en unas zonas y en otras no. «Habitado» porque la empresa no puede desalojarse para rediseñarse; como una ciudad viva, se renueva mientras sigue en uso, y entre quienes la usan ya hay agentes que invocan herramientas y producen efectos operativos.

DWU organiza ese territorio en siete sistemas. Cada nombre urbano corresponde a algo que la empresa ya tiene, aunque rara vez lo gobierne como una sola cosa.

La separación entre edificios e infraestructura pública es la que mejor explica las tres notificaciones de Northstar. Un edificio pertenece a un distrito, tiene dueño y puede reemplazarse. La infraestructura pública agrupa los servicios cuya duplicación genera ineficiencia o riesgo para todos, y lo que exige es acceso estandarizado a capacidades confiables, esté o no centralizado. Northstar tiene tres edificios haciendo el trabajo de un servicio público, y ninguno de sus dueños está equivocado desde su propio distrito.

El territorio es la capa constitucional, la que define dónde aplica cada autoridad (entidad, país, regulación, apetito de riesgo); sin ella, las plataformas dan acceso global o repiten la lógica de cada país a su manera.

En el subsuelo el marco ubica las fallas que aparecen lejos de su origen. Un margen que difiere entre el cierre de Finanzas y el dashboard comercial se ve en dos edificios, pero nace en una definición que ninguno de los dos posee.

Cómo se relacionan los sistemas

La lógica que une a los siete es relacional. Los territorios contienen distritos, los distritos alojan edificios, los edificios dependen de la infraestructura pública y de la movilidad, el subsuelo provee datos y conocimiento, y los habitantes actúan dentro de reglas que cubren todo el entorno. Son sistemas distintos para el análisis e interdependientes en la operación, y el agente de compras de Northstar lo muestra bien.

Desde el inventario, llevar ese agente a producción es cambiar el estado de una fila de «experimental» a «productivo». Desde el territorio, el mismo cambio obliga a decidir en seis sistemas.

Bajo qué reglas y en nombre de quién

Empieza por el territorio y el distrito. Las cinco entidades comparten plataformas pero tienen fronteras regulatorias y apetitos de riesgo distintos, así que el agente tiene que saber bajo las reglas de qué entidad prepara cada orden, y alguien tuvo que escribirlas antes. El agente pertenece a Cadena de suministro, lo cual parece obvio hasta preguntar quién responde hoy por él.

Responde, por omisión, el desarrollador que lo construyó.

La identidad es el punto más delicado. Con credenciales heredadas de ese desarrollador, cualquier registro de auditoría atribuye las acciones del agente a una persona que no las ejecutó. Necesita una identidad propia, y debería emitirla un servicio de identidad compartido. En Northstar ese servicio todavía no existe como infraestructura pública, porque la autenticación se reconstruye en varias aplicaciones, y resolver la del agente con otro mecanismo a la medida repetiría el patrón de las tres notificaciones con algo mucho más sensible.

La ruta y el maestro de proveedores

La orden puede llegar al ERP por una API con contrato, observable y versionada, o por escritura directa en tablas, que es técnicamente posible y se parece a lo que BI y la aplicación de país ya hacen para leer. El marco llama a esas conexiones no reguladas caminos improvisados que cruzan propiedad privada, porque resuelven lo inmediato y dejan dependencias ocultas. En las integraciones punto a punto son carreteras improvisadas sigo una de ellas hasta el día en que se rompe.

Debajo de la ruta está el maestro de proveedores. Si arrastra los mismos problemas de definición que el cliente y el margen, el agente los propagará a un volumen que ninguna persona que revise órdenes podría seguir.

El agente como habitante

DWU pide que todo agente tenga un perfil cívico, con identidad verificable, patrocinador, distrito, rutas y datos permitidos, límites y revocación de emergencia, entre otros campos. También distingue residentes de visitantes. El agente de compras, persistente y con tareas recurrentes, es un residente potencial, y pide más control de ciclo de vida que un visitante como el asistente analítico temporal de cobranza. La idea es que el perfil sea ejecutable por máquina donde se pueda, y un fragmento como este, validado en el despliegue, sería una forma de intentarlo.

# Ilustrativo: ficha de cambio del agente de compras de Northstar.
# No es un esquema definido por DWU ni un estándar.
agente: agente-compras
tipo_habitante: residente              # persistente, con tareas recurrentes
territorio:
  jurisdicciones: [entidad-a]          # arranca en una entidad, no en las cinco
  reglas_de_compra: politica-compras-entidad-a
distrito:
  dueno: cadena-de-suministro
  patrocinador: responsable-de-compras # persona que responde por el agente
infraestructura_publica:
  identidad: propia                    # emitida por el servicio compartido, sustituye las credenciales heredadas
  auditoria: registro-central
movilidad:
  crear_orden: api-ordenes-de-compra   # contrato versionado, sin escritura en tablas del ERP
subsuelo:
  lee: productos-de-datos/maestro-proveedores
habitante:
  autonomia: prepara-y-propone         # una persona aprueba antes de emitir
  limite_financiero: definido-por-finanzas
  revocacion: inmediata-por-el-patrocinador

Cada bloque de esa ficha tiene un dueño distinto. La entidad fija sus reglas de compra, Cadena de suministro patrocina, el equipo de plataforma emite la identidad, el de integración publica la API, el de datos responde por el maestro de proveedores y Finanzas pone el límite. En el inventario, todo eso cabía en una columna llamada «dueño».

La ficha también deja a la vista un costo, porque una aprobación humana en cada orden le quita al agente parte de la autonomía útil que lo justificaba.

Una analogía con disciplina

DWU no afirma que las empresas sean ciudades. Usa la ciudad como analogía disciplinada para construir teoría, y su utilidad depende de dos cosas que se pueden examinar, el poder explicativo de sus constructos y la posibilidad de operacionalizarlos. El parecido visual entre un diagrama de arquitectura y un plano urbano no cuenta como argumento.

Por eso los nombres urbanos pasaron por un filtro. Un constructo urbano solo se retuvo si cumplía un papel analítico propio y explicaba algo que ningún otro capturaba. También es deliberado el nivel de análisis. El mundo digital empresarial es un nivel meso, por encima de la arquitectura de una aplicación y por debajo de la digitalización de la sociedad.

La idea tiene antecedentes en la tradición francófona de la urbanisation du système d’information, que ya dividía el sistema de información en zonas, barrios y bloques, y que reviso en la tradición olvidada de urbanizar sistemas de información. Esa escuela es en general anterior a las plataformas cloud-native, los productos de datos distribuidos y los agentes. DWU intenta extenderla hasta ahí, y en ese mismo texto lo comparo con los enfoques vecinos (TOGAF, data mesh, zero trust, los marcos de riesgo de IA), que el marco quiere ubicar en un mismo territorio sin reemplazar a ninguno.

Rodas López (2026) es un preprint conceptual, sin revisión por pares. Sus seis proposiciones son hipótesis, y ni ellas ni la selección de los siete sistemas tienen todavía validación empírica. La práctica que conté al principio motivó los constructos, pero no fue un estudio diseñado y trae un riesgo claro de sesgo de confirmación. Cuando esta serie diga que algo reduce la duplicación o acelera el cambio, debe leerse como lo que esperaría observar si el marco acierta.

De los tres años de esa práctica, la parte documentada en repositorios empieza en agosto de 2025 con Portal Diveco, el portal corporativo interno de Grupo Diveco, que reúne en un registro único las herramientas de operaciones, finanzas, ventas, reportes y capital humano. Primero existió la plataforma, y el marco se abstrajo de construirla. Internamente el portal se llama «Ciudad Diveco». Desde el 26 de agosto de 2025, todo usuario recibe por defecto el rol «Ciudadano DIVECO», y REDI, la fuente maestra de colaboradores, es su registro civil. Los módulos comparten identidad, auditoría, notificaciones y filtrado por fila, leen de un data lake con semántica común y conviven con agentes de IA y bots de RPA.

Ese vocabulario de ciudad pertenece a la marca. En la documentación del portal no aparecen las palabras distrito, habitante ni edificio, y lo urbano vive en los nombres y en una maqueta 3D que publicamos en septiembre de 2026. La maqueta dibuja la plataforma como ciudad, con un edificio por herramienta, manzanas para los sectores del portal y distritos para Capital Humano, RPA, Ingeniería de Datos e IA. Es un mapa de comunicación, y su parecido con una ciudad es del tipo que no cuenta como argumento. Su territorio, un valle acotado con garitas, es solo visual. La jurisdicción real está en el filtrado por fila, que deriva del registro de cada colaborador en REDI el país cuyos datos puede ver y deja sin acceso a quien figura como inactivo.

Lo que falta es igual de concreto. El país es hoy un filtro de filas, y las entidades legales, la residencia de datos y el apetito de riesgo por jurisdicción que el marco ubica en el territorio no están modelados. El perfil cívico que el marco propone para los agentes todavía no existe como una pieza formal. La maqueta es configuración estática copiada a mano del registro, y sus edificios no enlazan a la herramienta que representan. Diveco muestra que los constructos se pueden operacionalizar en una organización real. No mide ninguno de los efectos que el marco les atribuye.

Dónde puede fallar el marco

El riesgo más serio de DWU es la sobreextensión, que la analogía urbana termine tapando fenómenos que otra imagen explicaría mejor, o que a los siete sistemas les sobre o les falte alguno. Hay formas concretas de detectarlo. Si analistas independientes discrepan de forma persistente sobre si el maestro de proveedores de Northstar es subsuelo o un edificio del distrito de Cadena de suministro, el vocabulario carece de la estabilidad que hace falta para acumular conocimiento.

La metáfora tiene que ganarse su lugar explicando algo que el inventario, el mapa de capacidades o el checklist de riesgo de IA dejaban repartido, y ese es el criterio con que pido que se juzgue lo que sigue. Esa prueba y las otras dos que propone el marco, con las observaciones que me obligarían a estrechar, revisar o abandonar partes de él, están en cómo sabría que esta teoría está equivocada.

Hay también un límite de autoridad. El marco supone que la organización puede fijar reglas comunes, una autoridad que nadie tiene en solitario sobre un marketplace o una infraestructura compartida entre varias organizaciones. Esos casos piden constructos institucionales y económicos que DWU no ofrece.

El otro límite es de tamaño. DWU está pensado para organizaciones medianas y grandes, empresas con varios negocios, instituciones reguladas y entornos ricos en plataformas, legado y automatización. En una organización pequeña con un paquete contable y una tienda en línea que no se hablan, con fronteras estables y casi nada compartido, el marco sirve poco. Ahí los siete sistemas agregan vocabulario sin agregar decisiones, y un inventario bien llevado alcanza.

Para saber de qué lado cae una organización hay un ejercicio que casi no cuesta, siempre que nadie lo tome por una medición. Se elige el último cambio relevante y se cuenta en cuántos de los siete sistemas hubo que decidir algo. Si fueron uno o dos, el marco probablemente sobra ahí. Si fueron cinco o seis, como con el agente de compras de Northstar, la pregunta siguiente es quién tomó cada una de esas decisiones y si alguno sabía que las otras existían.

Cómo leer la serie

Tras el repaso de la tradición que precede al marco, el orden baja, a grandes rasgos, por el corte transversal de arriba, empezando por zonificar la empresa por capacidades de negocio, porque sin distritos claros no hay a quién asignarle las rutas ni los datos. El agente de compras regresa en gobierno de agentes de IA, donde el perfil cívico se desarrolla completo, y el canvas de urbanización digital reúne todo en diez preguntas de diagnóstico.

Quien prefiera empezar por las objeciones puede leer primero el último post.

Este artículo es parte de la serie Urbanización digital, basada en el preprint Toward a Theory of Digital-World Urbanization (Rodas López, 2026), un marco conceptual cuyas ideas apliqué y refiné en la plataforma corporativa de Grupo Diveco, aunque sus seis proposiciones todavía no tienen validación empírica. Siguiente: La tradición olvidada de urbanizar sistemas de información.