Gobernanza de contenidos en AEM: roles, flujos y multisitio

Un sitio en Adobe Experience Manager (AEM) casi nunca se desordena por la tecnología. Se desordena porque nadie decidió quién crea, quién aprueba y quién retira el contenido. Cada área pidió su propia plantilla, el sitio de Colombia ya no se parece al de México, la aprobación de legal vive en el correo y una promoción de hace dos años sigue publicada. Con tres sitios se aguanta; con quince en cuatro idiomas, cada cambio global se vuelve un proyecto.

En WolfSellers implementamos y operamos Adobe Experience Manager Sites para empresas con varios sitios, marcas y países. Qué es AEM Sites y cuáles son sus modos de arquitectura lo explicamos en nuestra guía de AEM Sites. Esta nota va sobre la gobernanza: roles, aprobaciones, plantillas, multisitio y traducción, contenido estructurado, modelo operativo, capacitación de editores y métricas, en AEM as a Cloud Service. Lo que decimos de funciones de Adobe sale de su documentación en Experience League, revisada en octubre de 2026.

---

Qué es la gobernanza de contenidos en AEM

La gobernanza de contenidos es el conjunto de reglas, roles y controles que deciden quién puede crear, aprobar, publicar, reutilizar y retirar contenido, con qué plantillas y en qué plazos. En AEM esas reglas no se quedan en un documento: se implementan con permisos, workflows, plantillas, políticas de componentes y la configuración de Multi Site Manager (MSM). Es la contraparte, del lado del contenido, del gobierno de datos en Adobe Experience Platform.

Señales de que a tu AEM le falta gobernanza:

1. Plantillas inconsistentes: decenas casi iguales y nadie sabe cuál usar.
2. Páginas sin dueño: nadie responde por ellas cuando hay que actualizarlas o borrarlas.
3. Aprobaciones por correo: la revisión de marca o de legal ocurre fuera de AEM y no deja registro.
4. Sitios por país que divergen: un cambio global no llega a los países, o llega y borra lo local.
5. Contenido obsoleto publicado: promociones vencidas, precios viejos, avisos legales desactualizados.

Roles y permisos en AEM: quién puede hacer qué

En AEM as a Cloud Service el acceso empieza en Adobe Admin Console, con Adobe Identity Management System (IMS). Los servicios de autor y de publicación de cada ambiente (producción, stage o desarrollo) se asignan con perfiles de producto: el de administradores da privilegios de administrador en AEM y el de usuarios, acceso normal. Puedes conectar tu proveedor de identidad compatible con SAML 2 para inicio de sesión único y sincronizar usuarios desde Active Directory con User Sync Tool, en un solo sentido.

Los permisos finos se siguen administrando dentro de AEM: los grupos que llegan de IMS se agregan a grupos locales con los privilegios y las listas de control de acceso (ACL) por ruta. Algunas funciones dependen de grupos específicos: template-authors crea plantillas, experience-fragments-editors escribe Experience Fragments, tag-administrators modifica la taxonomía y los launches piden acceso a /content/launches, como el del grupo content-authors.

Adobe recomienda definir con Repo Init —scripts que viven en el código del proyecto y se despliegan con él— los grupos que son parte de la aplicación, como el grupo al que un workflow le asigna una aprobación, y dejar en tiempo de ejecución los puramente organizacionales. Así quedan en control de versiones, no configurados a mano en cada ambiente. Aplicamos mínimo privilegio: permisos por grupo y por rama del sitio, nunca a personas sueltas; publicar es un permiso explícito, y la lista de administradores se revisa cada trimestre.

Matriz RACI para AEM Sites

R = lo hace, A = responde por el resultado, C = se le consulta, I = se le informa. Es un punto de partida nuestro, no un estándar de Adobe.

Flujos de aprobación y publicación en AEM

Workflows: revisión antes de publicar

Un workflow de AEM automatiza una serie de pasos sobre páginas o activos y avisa a cada participante cuando le toca. El ejemplo de Adobe: el autor aplica el workflow, un editor recibe la tarea de revisar y, al completarla, el administrador del sitio recibe la de publicar. Las tareas llegan a la bandeja de entrada (Inbox) de cada participante. Dos detalles que conviene diseñar desde el principio:

• Publicar sin permiso dispara una solicitud. Si un autor no tiene privilegios para publicar una página, al intentarlo AEM dispara un workflow que notifica a la persona adecuada. Es la forma más simple de que toda publicación pase por un aprobador.
• Quick Publish publica también las referencias que no estuvieran publicadas. Manage Publication, en cambio, deja revisarlas, incluir páginas hijas, elegir destino y programar.

Recomendamos pocos modelos de workflow —uno para correcciones de bajo riesgo y otro con revisión de marca o de legal— en lugar de uno por área.

Publicación programada y Launches

Con Manage Publication puedes publicar o despublicar en una fecha futura (eso arranca un workflow, que se cancela desde la consola de workflows) y, si tienes un servicio de vista previa configurado, publicar ahí antes de producción. Para ocultar temporalmente contenido ya publicado sin despublicarlo, Adobe sugiere On Time y Off Time en las propiedades de la página.

Para cambios grandes con fecha —una temporada, El Buen Fin, un relanzamiento— están los Launches: una copia de las páginas donde preparas la versión futura mientras la actual sigue publicada. Al llegar la fecha, promueves el launch y publicas; si lo marcas como Production Ready y le pones fecha, AEM lo promueve y publica solo. Adobe advierte que un launch del sitio completo puede ser poco práctico con cientos o miles de páginas: hazlo por ramas.

Versiones y registro de auditoría

Una versión es una foto de la página: puedes restaurarla, recuperar páginas borradas, regresar un árbol completo a una fecha y comparar. Solo se versiona el contenido; el código, el CSS y el JavaScript no.

La retención se configura. En AEM as a Cloud Service la purga de versiones y del registro de auditoría (publicaciones, páginas y DAM) hoy no está activa por defecto, pero Adobe avisa que eso cambiará: en los ambientes creados después, el valor por defecto borra versiones de más de 30 días —conservando las cinco más recientes de ese periodo— y bitácoras de más de 7 días. Si tu industria exige bitácoras inalterables, Adobe recomienda integrar un servicio externo especializado. Decide la retención con legal y cumplimiento, no por omisión.

Cómo limitar lo que un editor puede romper: plantillas, políticas y componentes

Al crear una página, el autor elige una plantilla que define su estructura, su contenido inicial y los componentes que puede usar. Con el Template Editor, un autor de plantillas —usuario avanzado del grupo template-authors— las crea y mantiene sin desarrollo, una vez que desarrollo preparó los componentes.

Tres reglas de Adobe que usamos como piso: una plantilla nueva nace como borrador y no está disponible hasta que la habilitas; si editas una ya habilitada, AEM avisa que el cambio puede afectar a las páginas que la usan; y Adobe sugiere quedarse por debajo de 100 plantillas y no recomienda pasar de 1,000.

Los Core Components son 30 componentes estándar de Adobe; sus políticas a nivel plantilla definen qué funciones puede usar el autor, y Adobe declara que cumplen WCAG 2.1, con problemas conocidos documentados. Partir de ellos reduce lo que hay que gobernar; para proyectos nuevos, eso sí, Adobe recomienda Edge Delivery Services (más abajo vemos qué cambia). Y antes de aprobar un componente nuevo, revisamos si basta con un estilo o una política.

Cómo gobernar varios sitios e idiomas con MSM y traducción

Multi Site Manager (MSM) reutiliza el contenido de un sitio en otros mediante live copies, copias que mantienen una relación viva con su fuente (el blueprint). Las rollout configurations definen cuándo y qué se sincroniza; el editor puede suspender la herencia de una página o cancelarla en un componente para personalizarlo, y Detach rompe la relación de forma permanente.

Las buenas prácticas de MSM de Adobe son, en el fondo, de gobernanza: planear estructura y flujos de contenido antes de implementar, personalizar lo menos posible, establecer un modelo de gobernanza desde el inicio y capacitar a los usuarios con base en él, y limitar la autoridad de los productores locales para conectar contenido a otras live copies, porque las herencias encadenadas sin control vuelven la estructura compleja y frágil. Tres comportamientos que todo editor tiene que conocer:

1. Con la configuración estándar, borrar una página en el blueprint la borra en las live copies; moverla no la mueve.
2. En un rollout, un componente se reemplaza completo: lo que un país agregó dentro se pierde, salvo que el componente esté declarado como contenedor.
3. Las páginas que un país crea dentro de su live copy no se sincronizan con la fuente.

Traducción: language copies o live copies

MSM no traduce. Para eso está el Translation Integration Framework, que conecta con proveedores de traducción humana o automática y trabaja con language copies. Adobe recomienda language copies para empezar y deja MSM para sitios grandes y complejos, que exigen gobierno fuerte y automatización para no sobrescribir traducciones. También pide decidir de entrada si el contenido se crea centralmente y se empuja o se jala a los países, qué se desbloquea en cada país y quién gestiona las traducciones. AEM además puede usar un modelo de lenguaje como servicio de traducción —empezando por Azure OpenAI, con tu propia licencia— con reglas por idioma generadas a partir de tus guías de estilo.

Caso típico: México, LATAM y Norteamérica

Adobe recomienda una estructura por idioma, con no más de tres niveles entre la autoría principal y los sitios de país, y una capa de language masters —páginas que no se publican— donde se revisa la traducción antes de pasarla, con MSM, a los países que comparten idioma. Para una marca con sede en México: un maestro de español, del que salen como live copies es-MX, es-CO y es-PE, y uno de inglés traducido de él, del que salen en-US y en-CA. Qué se hereda y qué es local:

Contenido estructurado y taxonomía: fragmentos y etiquetas

Los Content Fragments son contenido editorial independiente de la página, con estructura definida por un modelo, listos para páginas y para entrega headless. Al editar, los autores no pueden cambiar la estructura, y el modelo valida: campos obligatorios, expresiones regulares, valores únicos por raíz de idioma, mínimo y máximo de elementos, y tipo o tamaño de los activos referenciados. Adobe recomienda los modelos necesarios y no más —normalmente bastan unas pocas decenas; demasiados complican la gobernanza—, no anidar más de diez niveles ni pasar de diez variaciones por fragmento.

Los Experience Fragments son un pedazo de página con contenido y diseño que se reutiliza en varias páginas en lugar de copiar y pegar, y funcionan con MSM. Un Content Fragment es contenido sin diseño; un Experience Fragment, contenido ya maquetado.

Las etiquetas se agrupan en namespaces, y sus taxonomías son globales en todo AEM: aplican a páginas y a metadatos de activos. Solo tag-administrators, o quien tenga permisos de modificación sobre /content/cq:tags, cambia la taxonomía. Se publican como las páginas y se pueden fusionar; Adobe aconseja no tener dos etiquetas para la misma idea. Los metadatos de imágenes y documentos los cubrimos en la guía de Adobe DAM.

Cómo cambia la gobernanza con Universal Editor y Edge Delivery Services

El Universal Editor es el editor visual de AEM Sites para experiencias headless o tradicionales, y Adobe dice que pretende reemplazar con el tiempo al Page Editor. Lista entre sus funciones control de acceso, versionado, flujos de aprobación y publicación dentro del editor y herencia de MSM. Lo soportan AEM as a Cloud Service y AEM 6.5, incluida la LTS.

Edge Delivery Services reemplaza la capa de publicación y el Dispatcher de AEM y la construcción con Core Components; el código vive en GitHub. Admite dos formas de autoría, y la gobernanza cambia de lugar según cuál uses:

En la autoría basada en documentos, la documentación de aem.live es explícita: por defecto, los autores no necesitan iniciar sesión para usar AEM desde Sidekick. La autenticación se activa al declarar roles en la configuración del sitio, por persona o por dominio: el rol author previsualiza y el rol publish publica. Si eliges este modelo, es lo primero que configuramos. El impacto en velocidad lo tratamos en cómo optimizar el rendimiento de AEM.

El modelo operativo: consejo editorial, guía de estilo y ciclo de vida

La plataforma hace cumplir las reglas; alguien tiene que escribirlas y revisarlas:

1. Consejo editorial: dueños de contenido por área y país, marca, legal, el administrador de AEM y un líder técnico. Cada mes aprueba plantillas y componentes nuevos, cambios a la taxonomía y excepciones de herencia en MSM.
2. Guía de estilo y de uso de componentes: tono, terminología y qué componente se usa para qué; alimenta también la traducción con IA, si la usas.
3. SLA de publicación: cuánto tarda una aprobación por tipo de contenido; por ejemplo, un día hábil para correcciones y una semana para páginas nuevas con revisión legal. Los plazos los pone tu negocio; lo importante es medirlos.
4. Dueño por sección: cada rama del sitio tiene una persona responsable.
5. Ciclo de vida: solicitud (si la planeación vive en Adobe Workfront, ahí nace el brief, como contamos en Workfront para marketing operations), creación, aprobación, publicación, revisión cada 6 o 12 meses según el tipo de contenido y retiro: despublicar, redirigir la URL si tenía tráfico y archivar. Ocultar con Off Time no es retirar.

Capacitación y adopción de editores en AEM

Adobe incluye la capacitación en sus buenas prácticas de MSM. Nosotros la organizamos por rol:

Partimos de la guía rápida de autoría de Experience League y la convertimos en un manual con capturas de tus plantillas. Nadie recibe permisos de escritura sin el taller, y se repite cuando cambian plantillas o procesos. Para medir la adopción vemos editores activos por mes y cuántas páginas pasan por aprobación frente a las que se publican directo.

Métricas de gobernanza de contenidos

Son recomendaciones nuestras, no cifras de mercado; salen de los workflows, las propiedades de las páginas y un reporte a la medida.

Errores frecuentes en la gobernanza de AEM

1. Dar permisos de administrador para "destrabar" a alguien y nunca quitarlos.
2. Una plantilla por área o por campaña, hasta que nadie sabe cuál usar.
3. Live copies encadenadas sin control y herencias canceladas sin registro.
4. Usar Detach para salir de un conflicto de rollout: no se puede revertir.
5. Aprobaciones fuera de AEM, con el registro en el correo.
6. Tratar la bitácora de AEM como evidencia regulatoria sin definir su retención.
7. Dejar Sidekick sin roles en la autoría basada en documentos.

Cómo lo hacemos en WolfSellers

Empezamos con un diagnóstico de tu AEM: sitios, plantillas, componentes, live copies, permisos, workflows, taxonomía y cómo trabaja hoy cada equipo. Facilitamos el taller de gobernanza y entregamos la matriz de roles, el modelo de herencia y traducción, el catálogo de plantillas y componentes, el SLA de publicación y la guía de estilo. Después lo implementamos —permisos en Repo Init, workflows, políticas, blueprints y traducción—, capacitamos por rol y lo operamos contigo. Somos Adobe Solution Partner nivel Gold, con un equipo de 135 personas en modelo nearshore desde la Ciudad de México.

Nuestros servicios de Adobe Experience Manager Sites, Adobe Experience Manager y AEM Assets cubren del diseño a la operación, y el de soporte y mantenimiento incluye atención 24/7 en los planes Business y Enterprise. Si quieres revisar tu caso, escríbenos.

---

Preguntas frecuentes sobre gobernanza de contenidos en AEM

¿Qué es la gobernanza de contenidos en AEM?

Es el conjunto de reglas, roles y controles que deciden quién crea, aprueba, publica, reutiliza y retira contenido en Adobe Experience Manager. Se implementa con permisos, workflows, plantillas editables, políticas de componentes y Multi Site Manager, y se sostiene con un consejo editorial y capacitación.

¿Qué diferencia hay entre MSM y las language copies?

MSM reutiliza contenido entre sitios con live copies que heredan de una fuente; no traduce. Las language copies son el enfoque del Translation Integration Framework para traducir. Adobe sugiere combinarlos: traducir los language masters y crear los sitios de país como live copies de ellos.

¿Cómo evito que un editor rompa el diseño del sitio?

Con plantillas de estructura bloqueada, políticas que limitan los componentes permitidos y el Style System, para que el editor elija variantes visuales de una lista. Lo que se reutiliza, ponlo en Content Fragments o Experience Fragments.

¿Cómo se configura un flujo de aprobación en AEM?

Se define un modelo de workflow con pasos asignados a grupos —por ejemplo, revisión de marca y luego publicación— y se deja el permiso de publicar solo a quien aprueba. Cuando un autor sin ese permiso intenta publicar, AEM dispara un workflow que notifica a la persona adecuada.

¿Cuánto tiempo guarda AEM las versiones y la bitácora de auditoría?

Depende de la configuración de purga. Hoy no está activa por defecto en AEM as a Cloud Service, pero Adobe anuncia valores por defecto de 30 días para versiones y 7 para bitácoras en los ambientes creados después del cambio. Para requisitos regulatorios, recomienda un servicio externo.

¿Cómo capacitar a los editores de AEM?

Por rol y sobre tus propias plantillas: editores, aprobadores, editores de sitios de país y autores de plantillas necesitan cosas distintas. Nadie recibe permisos de escritura sin el taller, y se repite cuando cambian plantillas o procesos.

¿Edge Delivery Services cambia la gobernanza?

Depende de cómo escribas. Con AEM y Universal Editor conservas los permisos y workflows de AEM. Con autoría basada en documentos, la edición depende de SharePoint o Google Drive y la publicación, de roles que hay que configurar.

Servicios relacionados

Si este tema es relevante para tu negocio, estos servicios de WolfSellers pueden ayudarte a implementarlo:

• Adobe Experience Manager
• Adobe Experience Platform
• IA & Automatización