Magnifica Humanitas, la encíclica del Papa León XIV publicada hace apenas unas semanas, es una reflexión extensa sobre lo que la digitalización, la robótica y la inteligencia artificial les están haciendo a las instituciones humanas. Una observación se me clavó al leerla, y desde entonces no me ha dejado.

Casi al mismo tiempo apareció The People Stack, de Julie Whitten. El libro estudia por qué el cambio organizacional fracasa a pesar de su éxito formal, y ofrece una mirada sobre la transformación anclada en la arquitectura humana que está debajo del trabajo visible. Las dos piezas, aunque radicalmente distintas en su naturaleza, hablan de algo que conecta con mi propio trabajo en cambio organizacional y liderazgo de la transformación.

Ambas lecturas nombran algo en lo que llevo años pensando sin encontrar un lenguaje lo bastante preciso para sostenerlo. La encíclica nombra el patrón a nivel de las naciones, donde la autoridad ha migrado desde los Estados hacia grandes actores económicos y tecnológicos cuyos recursos superan a los de la mayoría de los gobiernos, y cuyas decisiones de diseño fijan las reglas que todos los demás deben obedecer. El libro lo nombra a nivel de la firma, donde otra arquitectura invisible, debajo del trabajo visible, decide si algo se mueve de verdad. Arquitecturas distintas. Escalas distintas. La misma intuición estructural: la capa visible de la acción organizacional cada vez es menos la capa donde se decide.

Lo que sigue es la reflexión que surgió de ellas. El argumento que se desarrolla vuelve a la forma en la que suelo trabajar.

Lo que el organigrama sigue afirmando

La imagen convencional de la autoridad dentro de una gran empresa es la imagen en cascada. El comité ejecutivo se ubica en la cima, con los jefes de función y los líderes de unidades de negocio trabajando debajo, las regiones y oficinas de país más abajo, y los jefes de línea conduciendo el trabajo diario de equipos cuyos colaboradores individuales producen. La autoridad baja a través de derechos de decisión, matrices de delegación, umbrales de aprobación y políticas. La imagen es lo bastante limpia para caber en una sola lámina, y eso explica en parte por qué persiste.

La mayoría de los programas de transformación trata la imagen en cascada como la realidad operativa de la firma. Diseñan nuevos modelos operativos contra ella. Cascadean las comunicaciones de cambio a lo largo de ella. Mapean el sponsorship a ella. La metodología presume que la imagen en cascada es aproximadamente verdadera y que el trabajo consiste en ajustar su forma, afilar sus accountabilities o reasignar derechos de decisión dentro de ella.

La imagen fue cierta alguna vez, o bastante cierta. Describía un mundo donde las decisiones vivían en documentos de política y en el juicio de quienes ejercían autoridad delegada. Los decisores eran personas. Las decisiones ocurrían en deliberación, lentamente, con un razonamiento rastreable. El relato en cascada se sostenía porque la arquitectura de la toma de decisiones era, en la práctica, una red de autoridades humanas trabajando a través de documentos, reuniones y firmas.

Esas condiciones dejaron de ser dominantes. Dentro de la mayoría de las grandes firmas hoy, una segunda arquitectura subyace a la imagen en cascada. No aparece en el organigrama. No figura en el modelo operativo. Ni se asoma al plan de change management. Pero ha absorbido, en silencio y a lo largo de años, una porción significativa de la autoridad que la imagen en cascada todavía reclama.

La imagen en cascada se ha vuelto, cada vez más, una descripción de cómo la firma narra sus decisiones, no de cómo las toma. Los programas que trabajan por encima de la segunda arquitectura sin nombrarla están operando donde la autoridad ya no vive. El primer movimiento hacia la seriedad es reconocer que la segunda arquitectura existe.

Lo que las plataformas decidieron por anticipado

La segunda arquitectura es la capa de plataforma. ERP, CRM, HRIS, sistemas de workflow, herramientas de comunicación, la capa de analítica, y cada vez más el asistente de inteligencia artificial que media entre cualquiera de los anteriores y el humano que en teoría debería usarlos. La mayoría de las grandes firmas corre decenas de estos sistemas.

Cada plataforma codifica decisiones. Qué campos son obligatorios. Qué se mide y cómo se agrega. Quién puede ver qué registros. Qué excepciones son visibles para qué roles. Hacia dónde se rutean las aprobaciones y en qué umbrales. Cómo se ve una condición fuera de política y qué hace el sistema al respecto. Qué comportamientos generan señal y qué comportamientos desaparecen en un log que nadie lee. Nada de esto son funcionalidades. Todo esto son decisiones sobre cómo opera la firma, tomadas en su nombre e incrustadas en la arquitectura sobre la que la firma corre todos los días.

Las decisiones no las tomaron las personas que el organigrama nombra como decisoras. Los proveedores entregaron el producto con sus valores por defecto. Los equipos de implementación eligieron de menús de configuración durante el rollout, muchas veces trabajando bajo presión de plazos y haciendo tradeoffs contra el presupuesto. Los project managers postergaron los casos límite, dejando que el comportamiento por defecto del sistema manejara situaciones que nadie había pensado con cuidado. Consultores externos tomaron decisiones en nombre de la firma con su respaldo tácito. Personas que dejaron la firma hace años tomaron decisiones que todavía moldean cómo se categoriza a los clientes, cómo se puntúa el desempeño y qué conversaciones ocurren dentro de qué reuniones. Las decisiones codificadas sobreviven a cada ejecutivo en la sala, y siguen gobernando la firma mucho después de que el equipo de implementación se haya ido.

Esto no es una crítica a las plataformas. Están haciendo exactamente aquello para lo cual la firma las compró, que es codificar decisiones en software para que la firma no tenga que tomarlas a mano cada vez. Es una eficiencia real, y la firma se beneficia de ella. El argumento es que las decisiones codificadas son decisiones, que la firma las viene cargando desde hace años, y que casi nadie dentro de la firma las trata hoy como decisiones que vale la pena gobernar.

La mayoría de las conversaciones sobre modelo operativo saltan por completo esta capa. Asumen que las plataformas ejecutan decisiones que los ejecutivos han tomado, en lugar de reconocer que las plataformas ya han tomado, en muchos casos, las decisiones que los ejecutivos están a punto de ratificar.

La capa de ficción de la transformación

La consecuencia de la autoridad de la capa de plataforma es que las decisiones aparentes del organigrama son, en muchos casos, posteriores a decisiones que la plataforma ya tomó. El ejecutivo que decide una política está eligiendo entre opciones que la plataforma admite. El gerente intermedio que aprueba una solicitud está operando dentro de un workflow cuya lógica de escalamiento el equipo de implementación fijó durante la configuración hace años, y la aprobación del gerente es un clic de botón en una pantalla que el sistema renderizó usando reglas que el gerente no escribió. El trabajador de primera línea que ejerce su juicio lo hace dentro de una ventana que el sistema talló para la atención humana, con automatización aguas arriba que ya filtró el contexto más amplio y decidió qué contaba como los hechos relevantes.

En una revisión trimestral de negocio rutinaria, el dashboard de analítica ya preseleccionó qué variaciones aparecen al inicio de la discusión, en qué forma visual, con qué categorías sugeridas de causa raíz ya etiquetadas. La herramienta de workflow ya pre-pobló las acciones correctivas disponibles para selección, desde una lista cuyo menú el equipo de implementación construyó hace tres releases del sistema. El ejecutivo llega preparado para decidir. La decisión ya estaba armada antes de que el ejecutivo entrara a la sala. La reunión es el momento en el cual la firma ratifica y narra la decisión que la capa de plataforma ya propuso. Esa es la textura de la toma de decisiones ejecutiva contemporánea en la mayoría de las grandes firmas.

La implicación para el trabajo de transformación es estructural. La mayoría de las transformaciones opera en la capa por encima de esta. Rediseñan procesos que se asientan sobre plataformas cuya codificación de decisiones queda sin tocar. Redibujan modelos operativos que la capa de plataforma, de hecho, no podrá sostener, y luego encargan workarounds costosos cuando el desajuste se hace visible durante el piloto. Cascadean autoridad hacia roles cuya autoridad el sistema ya preasignó, y los titulares de esos roles descubren que la nueva accountability que el programa les asignó viene sin los derechos de decisión que la descripción del rol implica. La transformación cumple sus metas en el papel mientras la realidad operativa deriva en una dirección distinta.

El resultado es el patrón que la mayoría de los líderes senior han vivido más de una vez. El programa cumple las metas de su business case, el equipo de liderazgo declara el éxito en las revisiones de hito, la firma anuncia y despliega el nuevo modelo operativo. Dentro de dos años la brecha entre el modelo declarado y la realidad operativa es más ancha que la que había antes de que el programa comenzara. Las decisiones que el programa pretendía reubicar se quedaron donde la capa de plataforma las colocó hace años. La transformación logró mover el andamiaje visible sin mover nada de la estructura que está debajo.

El diagnóstico estructural es que la mayor parte del trabajo de transformación está ocurriendo por encima de la capa donde la autoridad realmente vive. Los programas que no nombran ni involucran a la capa de plataforma como decisora están desplegando intervenciones en un espacio donde las decisiones ya no ocurren. La energía se va en ajustar la imagen en cascada mientras la sustancia de la firma sigue operando desde la arquitectura que la imagen en cascada ya no describe con exactitud.

La arquitectura de decisión como gobernanza

La disciplina que hace el trabajo real es el análisis de arquitectura de decisión. Trata a la capa de plataforma como coautora de cada decisión que la firma toma. La capa de plataforma participa en esas decisiones, a veces como participante dominante. Una gobernanza que pasa por alto esta participación está incompleta por diseño.

La disciplina tiene cuatro movimientos. El primero es mapear dónde ocurren realmente las decisiones: qué decisiones toma el sistema por sí solo, qué decisiones toma el sistema y ratifica la capa de humanos con acceso a la pantalla, qué decisiones todavía toman los humanos en deliberación. La mayoría de las firmas nunca ha producido este mapa. Cuando lo hacen, la distribución las sorprende.

El segundo es identificar las decisiones codificadas explícitamente, como decisiones. Esto exige recorrer las configuraciones de plataforma, la lógica del dashboard, las reglas de workflow, y los prompts y guardrails de los asistentes automatizados ahora incrustados en esas herramientas, y preguntar, en cada uno, qué elección hizo alguien aquí y sobre qué base. El ejercicio es más incómodo de lo que suena, porque la respuesta es muchas veces que alguien tomó la elección bajo presión de plazos durante la implementación original, en un equipo que desde entonces se dispersó, con un razonamiento que ya nadie puede reconstruir.

El tercer movimiento es preguntar, por cada decisión codificada, si es la decisión que la firma habría tomado de habérsele preguntado. La pregunta separa las decisiones codificadas que todavía calzan con la intención de la firma de las que ya no. Ambas categorías aparecerán. Parte de la codificación heredada será correcta. Otra parte no. La firma ha venido tratando a las dos como igualmente saldadas.

El cuarto movimiento es elegir qué decisiones codificadas acercar al trabajo y cuáles dejar codificadas donde están. Acercarlas significa rediseñar las pantallas, los workflows, la lógica de ruteo y las configuraciones de plataforma para que los derechos de decisión que la firma pretende sean los derechos de decisión que la plataforma admite. Dejarlas codificadas significa aceptar que la firma ha elegido, deliberadamente, dejar que la plataforma decida esa pregunta en su nombre, y aceptar las consecuencias de esa delegación.

Este es trabajo de gobernanza, conducido en la capa donde ahora se decide. Toca configuraciones de plataforma, relaciones con proveedores y estrategia tecnológica sin ser ninguna de ellas.

El ejercicio más útil que un ejecutivo puede hacer este año es recorrer su última gran decisión y preguntar honestamente cuánto de ella ya había decidido la arquitectura circundante antes de que la discusión en la sala comenzara. La respuesta no halagará a nadie. Nombrará las plataformas que moldearon de antemano las opciones, los dashboards que preseleccionaron las variaciones, los workflows que pre-poblaron las acciones correctivas, las elecciones de consultoría tomadas hace años que todavía restringen el menú que el ejecutivo ve hoy. También revelará qué fracción de la decisión el ejecutivo realmente tomó, en la sala, con un juicio que pudo haber ido distinto.

Esa fracción es el piso de la autoridad recuperada. Cualquier transformación que pretenda mover realmente la autoridad hacia donde dice estar moviéndola tiene que hacer crecer primero esa fracción. Los programas que trabajan por encima de la capa de plataforma no pueden hacerlo. Una gobernanza que la trate como coautora sí.

Referencias

León XIV. (15 de mayo de 2026). Magnifica humanitas: Sobre la custodia de la persona humana en el tiempo de la inteligencia artificial [Carta encíclica]. Dicasterio para la Comunicación, Libreria Editrice Vaticana. https://www.vatican.va/content/leo-xiv/es/encyclicals/documents/20260515-magnifica-humanitas.html

Whitten, J. A. (2026). The people stack: Why change fails (and what actually fixes it). Julie Whitten Consulting.