Si la estructura documental que vimos en el artículo anterior es el esqueleto del gestor documental, los metadatos son el sistema nervioso. Sin metadatos bien diseñados, los documentos son archivos mudos: se pueden guardar y recuperar, pero no se pueden filtrar, clasificar ni gobernar de manera eficiente. Y en la era de Copilot, esto importa el doble: la calidad de las respuestas de IA que vamos a obtener sobre nuestros repositorios depende directamente de cuán bien etiquetados estén los documentos que esa IA va a encontrar.
En este artículo les cuento cómo diseño el modelo de metadatos para el gestor ECM de esta serie. Empiezo por el Term Store —la taxonomía centralizada— y de ahí bajo hacia las columnas de sitio, los tipos de contenido y, finalmente, los documentos individuales. El hilo conductor sigue siendo el escenario financiero del Artículo 0, pero voy a ir marcando dónde cada concepto aplica de la misma manera en cualquier sector.
¿Qué son los metadatos administrados y por qué importan?
En SharePoint Online hay dos grandes categorías de columnas que podemos usar para describir un documento: columnas simples (texto libre, fecha, número, opción) y columnas de metadatos administrados. La diferencia no es cosmética; es de fondo.
Una columna de texto libre permite que cada operador escriba lo que quiera: «Tarjeta de crédito», «tarjeta credito», «TC», «TDC». Cuatro operadores, cuatro valores distintos para la misma realidad. Cuando alguien filtra por «Tarjeta de crédito» no aparecen los otros tres. Cuando Copilot busca documentos de tarjetas, se pierde todos los que no tienen el valor exacto que espera. Las columnas de metadatos administrados resuelven este problema al conectar la columna con un conjunto de términos predefinidos en el Term Store: el operador no escribe, elige de una lista controlada. Un solo valor, consistente en toda la plataforma.
El Term Store: la taxonomía centralizada del tenant
El Term Store es el repositorio centralizado de vocabularios controlados de SharePoint Online. Vive a nivel de tenant —en el SharePoint Admin Center, bajo Content services → Term store— y todos los sitios del tenant lo comparten. La estructura tiene cuatro niveles:
| Nivel | Descripción | Ejemplo ECM |
|---|---|---|
| Tenant Term Store | Raíz única por tenant; administrada por el SharePoint Admin o el Term Store Admin | (raíz del tenant) |
| Grupo | Agrupa term sets con requisitos de seguridad comunes; define quién puede administrarlos | ECM Documentación |
| Term Set (conjunto de términos) | Lista de valores permitidos para una columna; puede ser abierto o cerrado | Tipo de Producto |
| Term (término) | Valor individual; puede tener sinónimos, traducciones y propiedades personalizadas | «Préstamos Hipotecarios» |
Un term set cerrado solo permite los valores que definen los administradores; los operadores eligen de la lista pero no pueden agregar términos nuevos. Un term set abierto permite que los usuarios propongan términos nuevos, que después el administrador puede aprobar o reorganizar. Para un gestor ECM de producción, los term sets de clasificación documental casi siempre van cerrados: necesitamos control total sobre los valores para que las políticas de retención y las búsquedas funcionen correctamente.
La excepción son las enterprise keywords: etiquetas libres que cualquier usuario puede agregar a cualquier documento. Son útiles para búsqueda informal y para capturar vocabulario emergente que todavía no entró a la taxonomía formal. En el gestor ECM las uso como complemento, no como sistema principal de clasificación.
La Imagen 1 muestra el Term Store que diseño para el escenario financiero de esta serie, con tres term sets cerrados y el área de enterprise keywords.
Columnas de sitio: la unidad reutilizable de metadatos
Una columna de sitio (site column) es una definición de columna que vive a nivel de colección de sitios o de Content Type Hub, y que se puede reutilizar en múltiples bibliotecas y tipos de contenido. Es distinta de una columna de lista o biblioteca, que existe solo en el lugar donde se crea y no se puede compartir.
La regla que sigo en cualquier proyecto ECM es esta: si una columna va a aparecer en más de una biblioteca o en más de un tipo de contenido, tiene que ser una columna de sitio. Nunca una columna local de biblioteca. Las columnas locales parecen más fáciles al principio, pero a la semana siguiente están desincronizadas entre bibliotecas y no hay forma de actualizarlas todas juntas.
Para el gestor ECM financiero, defino estas columnas de sitio en el Content Type Hub, desde donde se propagan a todos los sitios del tenant:
| Columna de sitio | Tipo | Fuente del valor | Descripción |
|---|---|---|---|
| ID_Cliente | Texto (una línea) | Sistema CRM externo | Identificador único del cliente; clave para búsqueda y agrupación |
| Tipo_Producto | Metadatos administrados | Term Set: Tipo de Producto | Producto financiero al que pertenece el documento |
| Tipo_Documento | Metadatos administrados | Term Set: Tipo de Documento | Clase del documento dentro del producto |
| Estado | Metadatos administrados | Term Set: Estado del Documento | Estado del documento en su ciclo de vida |
| Fecha_Vigencia | Fecha y hora | Ingreso manual / flujo | Fecha hasta la cual el documento es vigente |
| Fecha_Vencimiento | Fecha y hora | Ingreso manual / flujo | Fecha de vencimiento del producto o contrato |
| Etiqueta_Retencion | Metadatos administrados | Term Set: Política de Retención | Etiqueta de Purview que controla el ciclo de vida |
| Confidencialidad | Elección | Lista fija: Público / Interno / Confidencial / Restringido | Nivel de confidencialidad del documento |
Tipos de contenido: la herencia que lo conecta todo
El tipo de contenido es donde los metadatos cobran su máximo valor. Un tipo de contenido es una plantilla reutilizable que agrupa columnas de sitio, una plantilla de documento, flujos de trabajo asociados y políticas de retención. Cuando asocio un tipo de contenido a una biblioteca, todas sus columnas aparecen automáticamente en esa biblioteca, listas para usar.
La jerarquía que armo parte de un tipo base publicado desde el Content Type Hub, del que heredan todos los demás:
Documento ECM (tipo base)
Del tipo base heredan las columnas comunes a toda la plataforma: ID_Cliente, Estado, Fecha_Vigencia, Etiqueta_Retencion, Confidencialidad. Todos los tipos de contenido del gestor ECM heredan de este tipo y por lo tanto todos tienen estas columnas sin necesidad de definirlas en cada uno.
Tipos de segundo nivel (por categoría de producto)
Del tipo base heredan los tipos de categoría: Documento de Tarjeta, Documento de Cuenta, Documento de Préstamo, Documento de Hipoteca. Cada uno agrega las columnas específicas de su producto. Por ejemplo, Documento de Hipoteca agrega Número_Escritura y Fecha_Inscripcion_Registro; Documento de Tarjeta agrega Número_Tarjeta_Enmascarado.
Tipos específicos (por clase de documento)
De los tipos de segundo nivel heredan los tipos específicos: Solicitud de Tarjeta, Contrato de Tarjeta, Estado de Cuenta; Contrato de Apertura de Cuenta, Extracto Mensual; Solicitud de Préstamo, Tabla de Amortización, Liquidación de Préstamo. Estos son los tipos que se usan directamente en las bibliotecas.
La Imagen 2 muestra cómo fluye la herencia desde el Term Store hasta el documento final.
Metadatos en la era Copilot: por qué el diseño importa el doble
Microsoft Copilot accede al contenido del tenant a través del Microsoft Graph y del Semantic Index de SharePoint. Cuando un usuario le pregunta a Copilot «mostrame todos los contratos hipotecarios del cliente CLI-00123 que vencen este trimestre», Copilot no abre carpeta por carpeta: consulta el índice semántico, filtra por los metadatos disponibles y devuelve los documentos que coinciden.
Si esos documentos tienen las columnas ID_Cliente = CLI-00123, Tipo_Documento = Contrato, Tipo_Producto = Préstamo Hipotecario y Fecha_Vencimiento dentro del trimestre actual, Copilot responde en segundos con precisión quirúrgica. Si no tienen esos metadatos, Copilot tiene que intentar inferirlos del contenido del texto de cada documento —lo que es más lento, menos exacto y consume más tokens de inferencia—, o directamente no los encuentra.
El impacto es concreto: los metadatos administrados son el lenguaje que Copilot usa para razonar sobre el repositorio documental. Cuanto más consistente y estructurado sea ese lenguaje, más precisas van a ser las respuestas. Estos son los patrones que más impactan:
| Patrón de metadatos | Impacto en Copilot | Ejemplo de consulta habilitada |
|---|---|---|
| Columnas de metadatos administrados con valores controlados del Term Store | Copilot puede filtrar y agrupar con alta precisión | ¿Cuántos préstamos personales tiene el cliente CLI-00456? |
| Fecha_Vigencia y Fecha_Vencimiento en columnas de tipo fecha | Permite consultas temporales precisas | Mostrá los contratos que vencen en los próximos 30 días |
| Estado del documento con valor controlado | Copilot puede ignorar borradores y enfocarse en aprobados | ¿Cuáles son los documentos vigentes para el expediente X? |
| Etiqueta_Retencion asignada al tipo de contenido | Purview gestiona el ciclo de vida automáticamente; Copilot no accede a documentos eliminados | (aplica a gobernabilidad del repositorio) |
| Confidencialidad con etiqueta de sensibilidad de Purview | Copilot respeta los permisos: solo muestra lo que el usuario puede ver | Seguridad en respuestas basadas en el repositorio |
Un detalle que vale la pena aclarar: Copilot respeta los permisos de SharePoint. Si un usuario no tiene acceso a un sitio o a una biblioteca, Copilot no va a mostrarle documentos de ese lugar, aunque los tenga en el índice. El Semantic Index opera dentro del perímetro de identidad del usuario. Esto es buena noticia para la seguridad, pero también significa que la estructura de permisos que diseñamos en el Artículo 2 trabaja en equipo con los metadatos para asegurar que Copilot sea útil y seguro al mismo tiempo.
Metadatos y el SharePoint Knowledge Agent
El SharePoint Knowledge Agent —disponible con licencia Microsoft 365 Copilot— es la capa de búsqueda en lenguaje natural específica del Knowledge Base de SharePoint. A diferencia de la búsqueda clásica por KQL, el Knowledge Agent interpreta preguntas en lenguaje natural, las traduce a consultas sobre el índice y devuelve respuestas con referencias a los documentos fuente.
Para sacarle el máximo partido al Knowledge Agent en un gestor ECM, hay dos cosas que tenemos que tener en orden. Primero, los metadatos de clasificación (Tipo_Producto, Tipo_Documento, Estado) deben estar completos y consistentes, porque el Knowledge Agent los usa como filtros implícitos. Segundo, los documentos deben tener contenido de texto indexable —no solo imágenes o PDFs escaneados sin OCR— para que el Knowledge Agent pueda combinar búsqueda semántica con filtrado por metadatos.
La combinación es poderosa: el Knowledge Agent puede decirme «los tres contratos hipotecarios más recientes del cliente CLI-00123 que están en estado Aprobado» y al instante devuelve los documentos correctos con el texto de justificación. Sin metadatos, esa consulta no es posible. Con metadatos bien diseñados, es trivial.
Diseño práctico: los pasos para implementar el modelo de metadatos
Para cerrar el artículo, les dejo la secuencia de implementación que sigo en proyectos reales:
| Paso | Qué hacer | Herramienta |
|---|---|---|
| 1. Diseñar la taxonomía | Definir los term sets y sus términos antes de tocar SharePoint. Trabajar con los responsables de negocio para validar el vocabulario. | Excel o Miro para el diseño inicial |
| 2. Crear el Term Store | Crear el grupo ECM y los term sets en el SharePoint Admin Center. Importar términos masivamente si son muchos. | SharePoint Admin Center → Term store |
| 3. Crear columnas de sitio en el Content Type Hub | Definir las columnas de sitio conectadas a los term sets. Nombrarlas con guión bajo (sin espacios) para facilitar KQL y Graph. | Content Type Hub → Site settings → Columns |
| 4. Crear tipos de contenido con herencia | Armar la jerarquía de tipos de contenido en el Content Type Hub. Publicarlos al tenant. | Content Type Hub → Content Types |
| 5. Activar en las bibliotecas | Asociar los tipos de contenido a las bibliotecas de cada colección de sitios. Los sitios nuevos heredan la configuración automáticamente. | Configuración de biblioteca → Content Types |
| 6. Validar con una consulta KQL | Comprobar que los metadatos se indexan correctamente buscando con KQL en Microsoft Search. | Microsoft Search → búsqueda avanzada |
Conclusión
En este artículo les presenté el modelo de metadatos que da inteligencia al gestor documental: el Term Store como vocabulario controlado, las columnas de sitio como unidad reutilizable, la herencia desde los tipos de contenido para que todo se propague solo, y el impacto directo que tiene este diseño en la calidad de las respuestas de Copilot y del Knowledge Agent. Los metadatos no son un detalle de configuración tardío; son una decisión de arquitectura que hay que tomar desde el día uno, antes de que los operadores empiecen a cargar documentos. Una taxonomía mal diseñada que después se quiere corregir sobre miles de documentos existentes es uno de los trabajos más costosos y frustrantes que existen en el mundo del ECM. En el próximo artículo vamos a la capa de gobernabilidad y seguridad: cómo gestionar permisos a escala, grupos de Microsoft 365, SharePoint Advanced Management y Data Access Governance.
Fabián Imaz
Office Apps and Services MVP
CEO Siderys | CTO qualitaslearning.com
fabiani@siderys.com.uy | @fabianimaz
Anexo — Serie completa: ECM con Microsoft 365
Serie de 17 artículos. Los links se actualizan a medida que se publican los artículos.
- Gestión Documental Empresarial con Microsoft 365: un caso de uso que aplica a cualquier sector, con foco en el financiero — Arquitectura de referencia: expedientes por cliente, tipos de contenido, ciclo de vida documental y archivado en dos capas con SharePoint Embedded y M365 Archive.
- Licencias para ECM en Microsoft 365: cómo elegir sin gastar de más — Planes Enterprise, Business y Frontline; SharePoint Embedded, M365 Archive, Purview y Copilot. Licencias mixtas por perfil de usuario.
- Estructura Documental — Communication Sites vs. Team Sites, hub sites como concentradores, colecciones de sitios por entidad, bibliotecas por proceso, Document Sets, vínculos a documentos y metadatos en lugar de carpetas.
- Metadatos (este artículo) — Term Store, columnas de sitio, conjuntos de términos, herencia desde el tipo de contenido y su impacto en las respuestas de Copilot.
- Gobernabilidad y Seguridad — Modelos de permisos, grupos de Microsoft 365, SharePoint Advanced Management, Data Access Governance y acceso condicional.
- Procesos y flujos de trabajo — Power Automate, aprobaciones, ciclo de vida documental y Copilot Actions para automatización.
- Cumplimiento y retención con Microsoft Purview — Etiquetas de retención, Records Management y DLP. Reemplazo de las políticas de administración de información deprecadas en abril 2026.
- Catalogación y clasificación — SharePoint Premium / Syntex: clasificación automática, extracción de entidades y etiquetas de sensibilidad.
- Migración a ECM moderno — Auditoría de contenido, estrategia de migración, herramientas (SPMT, Sharegate) y gestión del cambio.
- Almacenamiento — Sitios SharePoint Online — Colecciones de sitios, cuotas, políticas de ciclo de vida y archivado de sitios.
- Almacenamiento — SharePoint Embedded — Contenedores, API vía Microsoft Graph, modelo de costos PAYG y casos de uso de archivado.
- Búsquedas — Microsoft Search, KQL, conectores de Graph y SharePoint Knowledge Agent.
- Integración con APIs y Graph — Microsoft Graph API, SPFx, REST API y webhooks para integración con sistemas externos.
- Azure AI e inteligencia documental — Azure Document Intelligence, OCR, extracción de campos y procesamiento multimodal integrado con ECM.
- Copilot y ECM — Cómo la arquitectura de metadatos y estructura impacta la calidad de las respuestas de Copilot.
- Copilot Studio Agents sobre contenido documental — Agentes autónomos sobre repositorios SharePoint y su integración con Power Platform.
- Formularios y captura inteligente de documentos — Custom upload forms, captura estructurada en el ingreso y validación de metadatos en origen.
Preguntas frecuentes
¿Qué es el Term Store en SharePoint Online?
El Term Store es el repositorio centralizado de vocabularios controlados del tenant, en el SharePoint Admin Center bajo Content services. Tiene cuatro niveles —Term Store, Grupo, Term Set y Term— y todos los sitios del tenant lo comparten, lo que garantiza una taxonomía consistente en toda la plataforma.
¿Cuál es la diferencia entre una columna simple y una de metadatos administrados?
Una columna de texto libre deja que cada operador escriba lo que quiera, lo que genera valores inconsistentes («Tarjeta de crédito», «TC», «TDC»). Una columna de metadatos administrados se conecta a un term set del Term Store, así que el operador elige de una lista controlada y el valor queda único y consistente en toda la plataforma.
¿Por qué importan los metadatos para Microsoft Copilot?
Copilot usa los metadatos del Semantic Index de SharePoint para filtrar y razonar sobre el repositorio. Con metadatos administrados consistentes responde en segundos y con precisión; si faltan, tiene que inferirlos del texto de cada documento —más lento, menos exacto y con más consumo de tokens— o directamente no encuentra los documentos.
¿Qué necesita el SharePoint Knowledge Agent para funcionar bien?
Dos cosas: metadatos de clasificación completos y consistentes (Tipo_Producto, Tipo_Documento, Estado), que el Knowledge Agent usa como filtros implícitos, y documentos con contenido de texto indexable —no solo imágenes o PDFs escaneados sin OCR— para poder combinar búsqueda semántica con filtrado por metadatos.