Diccionario, linaje y clasificación

🌐 También en 28 idiomas

English · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Imagen generada con IA

Traducido con IA. Aún no revisado por la comunidad. Leer en inglés

Módulo 3 de 6 del capítulo Calidad y gobierno de datos, capítulo 5 del curso Data Architect. Cada módulo se sostiene por sí solo. Anterior: Mantener fuera los datos malos · Siguiente: Las leyes de privacidad dan forma al diseño

La pregunta que responde este módulo: ¿Cómo registras qué significan los datos, de dónde vienen y qué tan sensibles son?

Heredaste una organización. La cuenta tiene 900 campos, entre ellos Customer_Type__c, Customer_Class__c, Customer_Category__c, Customer_Status__c, ERP_Status__c y Account_Status__c. ¿Cuál te dice si alguien es realmente cliente? Abres las descripciones. Tres están vacías. Una dice “Customer Type”. Muchas gracias. Una dice que vino del ERP; otra la creó hace seis años alguien que ya no está. Ahora imagina que no eres el arquitecto sino una integración, un equipo de informes o un agente. La organización tiene muchísimos datos. Eso no significa que sepa qué significan.

Ahí es donde los metadatos se convierten en arquitectura, mediante tres preguntas relacionadas pero distintas:

• Diccionario: ¿qué significan estos datos?
• Linaje: ¿de dónde vinieron?
• Clasificación: ¿cómo hay que tratarlos?

Dos tipos de metadatos

Los metadatos son de dos tipos, y necesitas los dos. Los metadatos de negocio son lo que los datos significan para el negocio: la definición, el dueño, las reglas para usarlos, qué tan sensibles son. Los metadatos técnicos son cómo se construyen y cómo se mueven: el objeto y el campo, el tipo y la longitud, el nombre de API, el esquema, la asignación de un sistema a otro, el linaje del origen al destino. El nombre de API y el tipo de un campo le dicen a un desarrollador cómo usarlo; su definición y su dueño les dicen a todos los demás si deben usarlo. Cuando no coinciden, o falta uno, ahí es donde las integraciones y los informes salen mal.

Conocimiento para el examen. Distingue los metadatos de negocio (significado, definiciones, dueño, reglas, sensibilidad: el diccionario de negocio y la clasificación) de los metadatos técnicos (objetos, campos, tipos, nombres de API, esquemas, asignaciones y linaje).

Empieza por el significado

El capítulo 3 fijó la regla: cada campo lleva una descripción. No “Customer Status” para un campo llamado Customer Status, sino algo como “La relación comercial actual del socio con Steve Trucking. La establece el ERP después de la activación. No usar para calificar prospectos”. Ahora sé qué significa, de dónde viene y para qué no hay que usarlo. Ese es el comienzo de un diccionario de negocio: definiciones comunes para los datos que importan. ¿Qué es un cliente? ¿Un cliente activo? ¿Qué significa Entregada? ¿Qué cuenta como a tiempo? Suenan obvias hasta que pones a cinco departamentos en una sala: Finanzas tiene una definición, Ventas otra, Operaciones una tercera, el almacén de datos una cuarta, y alguien construyó un tablero sobre una quinta. El problema no es que nadie hable el idioma. Es que la empresa no se ha puesto de acuerdo sobre el significado.

Un diccionario puede vivir en una hoja de cálculo o en una herramienta de documentación, pero sus definiciones importantes tienen que estar cerca de donde la gente usa los datos. En la plataforma, eso son las descripciones de los campos, el texto de ayuda y los metadatos de clasificación. En la analítica importa todavía más: “ingresos” no puede significar una cosa en el tablero de la dirección y otra en la consulta de un analista. Para eso sirve una capa semántica, y los modelos semánticos de Data 360 guardan definiciones gobernadas como métricas, dimensiones y relaciones por encima de los datos físicos (Create a Semantic Model in Data 360 (opens in a new tab), en inglés). La tecnología cambia; el requisito no: los datos importantes necesitan un significado acordado.

Y empieza por el significado, no por la tecnología. Un diccionario que empieza por objeto, campo, tipo y nombre de API documenta la implementación. Uno que empieza por los términos del negocio documenta la empresa:

Término del negocio	Significado	Dónde se representa
Socio minorista	Un minorista para el que Steve Trucking hace entregas, con contrato	Cuenta de Salesforce; cliente del ERP de finanzas
Entrega	Una entrega a un destinatario, en una dirección, en un día	RouteDesk hoy; una orden de trabajo cuando las entregas pasen a Salesforce
Destinatario	La persona que recibe una entrega	Datos del destinatario en la entrega
Entregada	Completada según la definición operativa acordada	Estado de la entrega
Entrega a tiempo	Completada dentro de la franja de entrega acordada	Métrica derivada

Click to enlarge

Un significado, muchas representaciones técnicas.

Luego pregunta de dónde vino

Una vez que sé qué significa un valor, quiero saber de dónde vino. Eso es el linaje. El nombre legal de un socio en Salesforce: ¿lo escribió un representante, lo envió el ERP, lo transformó una integración, lo unificó Data 360, se calculó, lo generó la IA? Eso afecta cuánto confío en él y qué puedo hacer con él. Recuerda los registros provisionales del módulo 2: dos cuentas pueden decir “Keystone”, una creada ayer por un representante, la otra desde el ERP con un identificador de referencia. El mismo texto, un linaje distinto, un tratamiento distinto.

El linaje no es solo el diagrama de mil tablas de un ingeniero de datos. Para los datos importantes quiero responder preguntas prácticas: ¿dónde empezó, qué sistema es la referencia, qué lo transformó, qué sistemas recibieron copias, qué lo cambió por última vez, y puedo rastrear un valor derivado hasta sus fuentes? El panorama del capítulo 4 dice que los sistemas están conectados. El linaje dice qué les pasó a los datos por el camino.

Algo de linaje viene gratis: el ID del ERP en la cuenta, Creado por y Última modificación por, los logs de integración, los documentos de mapeo. Data 360 agrega a sus objetos de datos campos de linaje que registran la fuente de datos y el objeto de origen de cada registro (Data Lineage Fields (opens in a new tab), en inglés). Pero no supongas que el linaje aparece porque los sistemas están integrados. A veces el linaje más útil es un solo campo: Sistema de origen = Keystone. Y si el origen importa para el gobierno, hazlo mecánicamente confiable, que lo establezca la integración y no que lo escriba una persona.

Los datos derivados son los que más necesitan linaje. Digamos que Steve Trucking calcula un riesgo de entrega tardía a partir de la posición del camión, la franja de entrega y el historial de la ruta, y el despacho lo usa para priorizar. ¿De dónde salió “alto”? Agrega un agente que le dice a un destinatario “tu entrega va con retraso”, y necesitas saber en qué se basó eso, y qué tan actual era. Cuanto más te alejas de los valores guardados hacia los calculados, unificados, predichos y generados, más importa el linaje.

La clasificación responde otra pregunta

Ahora: ¿cómo hay que tratarlos? El nombre del destinatario, la dirección de entrega, el número de teléfono, las notas de entrega, el estado de la entrega, el número de camión, el centro de distribución, el socio minorista, la foto: no son igual de sensibles. “En reparto” no es un número de teléfono, y el código de un centro de distribución no es una foto del interior de la casa de alguien. Salesforce te permite registrar esto en cada campo, estándar o personalizado: Data Owner, Field Usage, Data Sensitivity Level y Compliance Categorization (Data Classification Metadata Fields (opens in a new tab), en inglés). El capítulo 3 los llamó los campos de taxonomía, y explicó por qué importan: marca un campo como PII o GDPR y los procesos pueden encontrarlo, desde las herramientas de enmascaramiento hasta la capa de confianza de IA de Salesforce, que puede impedir que los valores marcados lleguen a un modelo de lenguaje grande. Una advertencia del capítulo 3: Salesforce ahora desactiva ese enmascaramiento para los LLM en los agentes, porque puede quitar el contexto que un agente necesita (Clasifica lo que importa: los campos de taxonomía). Así que la clasificación todavía tiene que impulsar los demás controles.

Mi posición aquí es deliberada: clasifica los campos sensibles, no todos los campos. No quiero que se pasen tres meses clasificando miles de campos para que alguien pueda informar “100 % clasificado” y nadie lo use. El número de teléfono del destinatario: sí. La dirección de su casa: sí. Las notas de entrega que pueden contener códigos de portón y “perro en el patio”: sí. Las fotos que pueden mostrar personas o una casa: por supuesto. ¿Una etiqueta de visualización interna? No es donde debería ir la energía del gobierno. Eso no hace aceptables los campos sin documentar. Son dos trabajos distintos: la documentación es amplia; la clasificación es deliberada. Eso es lo que mantiene el sentido de la clasificación.

Una taxonomía que la gente pueda usar

La clasificación necesita un vocabulario, una taxonomía. Los valores predeterminados de Salesforce son Public, Internal, Confidential, Restricted y MissionCritical; tu organización puede querer sus propias etiquetas. No las estoy prescribiendo. Mantenlas comprensibles: si hay 47 categorías y nadie fuera del equipo de privacidad sabe distinguir la 31 de la 32, no está ayudando. Una buena taxonomía conecta una etiqueta con un comportamiento. Si un campo son datos personales sensibles, ¿quién puede verlo, puede ir a un sandbox, salir de la región, aparecer en la analítica, cuánto tiempo se conserva, puede usarlo un agente? Ahora la clasificación está trabajando.

La clasificación sin cumplimiento es decoración

Marca como sensible el número de teléfono del destinatario y no cambies nada más, y habrás escrito documentación. Útil, pero el gobierno va más allá: la clasificación debería determinar los permisos, el enmascaramiento, el cifrado, la retención, el consentimiento, el movimiento de datos, el uso en sandboxes, la auditoría y el acceso de la IA. Parte de eso es una decisión de diseño del arquitecto; algunas plataformas ya aplican etiquetas y clasificaciones directamente en las políticas, como hace el gobierno de Data 360 (Data Governance in Data 360 (opens in a new tab), en inglés). Y marcar un campo como Restricted no impide que nadie lo lea. La clasificación dice cómo debería tratarse un campo; la seguridad hace que así sea. La secuencia es: identifica los datos, entiéndelos, clasifica lo que importa y luego aplica los controles que pide esa clasificación.

Click to enlarge

Tres preguntas sobre tus datos, y la tercera tiene que impulsar algo.

Los datos de referencia también necesitan metadatos

Códigos de país, estados de entrega, códigos de centro de distribución, identificadores de socios, motivos de cancelación: parecen simples hasta que dos sistemas no coinciden. Uno dice CANCELLED, otro CANCELED, un tercero CNCL, un cuarto 9. Los datos de referencia necesitan definiciones, un dueño, un origen, un ciclo de vida cuando los valores cambian y mapeos cuando los sistemas los representan de forma distinta. Valores pequeños pueden determinar procesos muy grandes. El capítulo 6 va más allá.

Los tres juntos

Toma el número de teléfono del destinatario. Diccionario: el número que se usa para contactar a la persona que recibe una entrega concreta. Linaje: viene del manifiesto del socio minorista. Clasificación: datos personales. Ahora se pueden hacer las preguntas de arquitectura: ¿puede verlo el equipo, y por cuánto tiempo (el planteamiento dice solo para sus propias paradas, solo ese día); puede ir a un sandbox; lo necesita Snowflake; puede usarlo un agente; qué pasa cuando se completa la entrega?

Ahora toma el estado de la entrega. Diccionario: el estado operativo actual de la entrega. Linaje: lo establece el proceso de entrega de Steve Trucking y se devuelve a cada socio a través de su propia integración. Clasificación: operativo, no sensible. Datos distintos, tratamiento distinto. Esa es la idea.

No trato los metadatos como documentación que se produce cuando la arquitectura de verdad ya está hecha. Si no puedo decir qué significa un campo, no entiendo el modelo de datos. Si no sé de dónde vino un valor, no entiendo las integraciones. Si no sé si es sensible, no entiendo la seguridad. Los metadatos describen la arquitectura, y a veces la determinan.

Más allá del examen: lo que cambia la IA. La clasificación se está convirtiendo en el interruptor de lo que un agente puede recuperar o repetir, y el linaje tiene que llegar hasta la respuesta o la acción del agente. Si un agente le dice a un destinatario que la entrega va con retraso, la arquitectura debería poder decir en qué se basó, de dónde vino y si el agente tenía permitido usarlo. “En algún lugar de Salesforce” no es linaje, y “datos de clientes” no es una clasificación.

Lo que decide aquí un arquitecto

• Qué términos del negocio necesitan definiciones gobernadas, para que los sistemas y los equipos no den significados distintos a una misma palabra.
• Cómo conservan los valores importantes el linaje suficiente para mostrar su origen, su autoridad y sus transformaciones.
• Qué campos tienen un significado de confidencialidad o de cumplimiento y por eso reciben una clasificación explícita.
• Qué taxonomía usa la organización, y si la gente puede aplicarla de forma consistente.
• Cómo determina la clasificación controles reales en lugar de quedarse sin usar.

Antes de gobernar los datos, sabe qué tienes: qué significan, de dónde vinieron, cómo hay que tratarlos. Documenta en amplitud, clasifica de forma deliberada, conserva el linaje donde importa. Si no, no gobiernas los datos. Solo los tienes.

Explora

• Ayuda de Salesforce, Data Classification Metadata Fields (opens in a new tab) (en inglés), consultado el 2026-10-14.
• Ayuda de Salesforce, Data 360: Data Lineage Fields (opens in a new tab), Data Governance in Data 360 (opens in a new tab) y Create a Semantic Model in Data 360 (opens in a new tab) (en inglés), consultado el 2026-10-14.