Qué es un catálogo de datos y para qué sirve realmente

Qué es un catálogo de datos

Un catálogo de datos es una herramienta centralizada que registra, organiza y hace accesibles los metadatos de todos los activos de datos de una organización: tablas, campos, pipelines, dashboards, APIs, modelos de machine learning y cualquier otro activo de información que la organización use para operar o decidir.

La función del catálogo es responder cuatro preguntas que hoy, sin él, requieren una investigación:

• ¿Qué existe? Inventario de todos los activos de datos disponibles.
• ¿Qué significa? Definición de negocio, contexto y clasificación de cada dato.
• ¿De dónde viene? Linaje: origen, transformaciones aplicadas y recorrido hasta el punto de consumo.
• ¿Quién es responsable y puedo usarlo? Propietario, clasificación de sensibilidad y política de acceso.

Dicho de otra forma: el catálogo de datos es el índice de los activos de información de la empresa. Como el catálogo de una biblioteca: no contiene los libros, pero te dice qué libros hay, dónde están, de qué tratan y si están disponibles.

Catálogo de datos, glosario de negocio y catálogo de metadatos: las diferencias

Estos tres términos se usan a menudo de forma intercambiable, pero no son lo mismo. La confusión entre ellos genera expectativas equivocadas y proyectos que no entregan lo que prometían.

Catálogo de datos

Es la capa técnica: registra los activos de datos físicos —tablas, campos, pipelines, modelos— con sus metadatos técnicos (tipo de dato, nulabilidad, frecuencia de actualización, linaje). En herramientas como OpenMetadata o Collibra, esta capa se puebla automáticamente mediante conectores con las plataformas de datos: Snowflake, Databricks, BigQuery, dbt.

Glosario de negocio

Es la capa de negocio: define qué significa cada concepto para la organización. Qué es un cliente activo. Cómo se calcula el ingreso neto. Qué entiende la empresa por incidente operativo. Esta capa la mantienen los Data Stewards, no los ingenieros, y requiere validación y aprobación por parte de los Data Owners. Sin glosario, el catálogo técnico es un inventario de tablas sin contexto.

Catálogo de metadatos

Es el término más amplio: engloba tanto el catálogo de datos técnico como el glosario de negocio, el linaje, las políticas de calidad y la clasificación de sensibilidad. En la práctica, un catálogo de metadatos maduro es la suma de todas las capas anteriores funcionando de forma integrada. Es lo que las organizaciones construyen cuando la gobernanza de datos alcanza un nivel de madurez real.

Para qué sirve un data catalog realmente

En la teoría, el catálogo sirve para "gestionar los activos de datos de la organización". En la práctica, sirve para resolver cinco problemas concretos que cualquier CDO o Head of Data reconocerá de inmediato:

1. Eliminar el tiempo perdido buscando datos

Los estudios del sector estiman que los equipos de datos dedican entre el 20% y el 35% de su tiempo a buscar datos, entender su significado y verificar su origen. En un equipo de diez personas, eso equivale a entre dos y tres personas a tiempo completo haciendo trabajo que no genera ningún valor. El catálogo convierte esa búsqueda de horas en una consulta de segundos.

2. Establecer una única versión de la verdad

Sin catálogo ni glosario, cada equipo calcula sus métricas con su propia definición. El equipo comercial tiene su "cliente activo", el equipo financiero tiene el suyo y el equipo de producto tiene un tercero. El catálogo fuerza la conversación sobre cuál es la definición canónica y la hace visible y accesible para todos. Una vez acordada y publicada en el catálogo, la discusión desaparece.

3. Acelerar el onboarding de nuevos analistas

Sin catálogo, un analista nuevo tarda entre dos y cuatro semanas en entender qué datos existen, cómo están organizados y a quién preguntar por cada dominio. Con un catálogo bien mantenido, ese tiempo se reduce drásticamente: el analista puede explorar el inventario, leer las definiciones de negocio y entender el linaje antes de escribir la primera consulta. El conocimiento deja de vivir solo en la cabeza de las personas más senior.

4. Habilitar la gobernanza de acceso con contexto

Aprobar o rechazar una solicitud de acceso a un dato requiere saber qué clasificación de sensibilidad tiene ese dato, quién es el Data Owner responsable y qué política aplica. Sin catálogo, esa información está dispersa en documentos, wikis o en la memoria de las personas. Con catálogo, está en un único lugar estructurado y accesible para quien tiene que tomar la decisión.

5. Cumplir el AI Act artículo 10

El artículo 10 del AI Act exige que los sistemas de IA de alto riesgo tengan documentados los datasets de entrenamiento: origen, transformaciones, criterios de selección, análisis de sesgos y métricas de calidad. Un catálogo de datos con linaje automatizado y fichas de dataset actualizadas es la forma más sostenible de mantener esa documentación viva sin que dependa de trabajo manual intensivo. Sin catálogo, el art. 10 se convierte en un documento Word que alguien actualizará una vez y nadie volverá a tocar.

Para profundizar en los requisitos del AI Act sobre datos, consulta el artículo Cómo implementar un Data Governance Framework efectivo en la era del AI Act.

Cómo funciona un data catalog por dentro

Entender cómo funciona técnicamente un catálogo ayuda a tomar mejores decisiones sobre qué herramienta elegir y cómo implementarla. Los componentes principales de cualquier catálogo moderno son:

Conectores e ingesta automática de metadatos

El catálogo se conecta directamente a las plataformas de datos —Snowflake, Databricks, BigQuery, dbt, Airflow, Power BI, Tableau— y extrae automáticamente los metadatos técnicos: esquemas, tipos de datos, frecuencia de actualización, volumen de registros y linaje técnico entre tablas y pipelines. Esta ingesta automática es lo que hace sostenible el catálogo a largo plazo: los metadatos técnicos se actualizan solos, sin trabajo manual.

Motor de búsqueda y descubrimiento

El valor principal del catálogo para el usuario final es poder buscar. Buscar por nombre de tabla, por concepto de negocio, por propietario, por clasificación de sensibilidad o por cualquier combinación. Las herramientas más maduras añaden búsqueda semántica: buscar "ingresos por mercado" y encontrar la tabla correcta aunque no se llame exactamente así.

Linaje de datos

El linaje muestra el recorrido del dato: de dónde viene, qué transformaciones ha sufrido y dónde se consume. En herramientas integradas con dbt, el linaje técnico entre tablas se genera automáticamente a partir del código SQL. El linaje de negocio —qué transformación de negocio representa cada paso— requiere enriquecimiento manual por parte de los Data Stewards, pero una vez documentado se mantiene solo mientras el código no cambie.

Capa de colaboración y enriquecimiento

Sobre los metadatos técnicos automáticos, los Data Stewards y los Data Owners añaden la capa de contexto de negocio: descripciones de campos, definiciones de métricas, clasificación de sensibilidad, propietario responsable y notas de uso. Esta es la capa que convierte un inventario técnico en un activo de gobernanza real.

Integración con el control de acceso

Los catálogos más maduros se integran con el modelo de control de acceso: el catálogo no solo dice quién es el Data Owner de un dato, sino que desencadena o facilita el workflow de solicitud de acceso. Un usuario busca un dato en el catálogo, ve que está clasificado como restringido y puede solicitar acceso directamente desde la ficha del activo, con el Data Owner recibiendo la notificación y aprobando o rechazando con trazabilidad completa.

Herramientas de data catalog en 2026: comparativa honesta

El mercado de herramientas de data catalog ha madurado mucho en los últimos tres años. Hay opciones para todos los tamaños de organización y todos los presupuestos. La clave no es elegir la más potente, sino la que mejor encaja con el stack tecnológico, el nivel de madurez del equipo y los recursos disponibles para mantenerla.

Para la mayoría de organizaciones que empiezan su journey de gobernanza con un stack en cloud, la combinación dbt Docs + OpenMetadata es el punto de entrada más razonable: bajo coste, alta automatización de metadatos técnicos y linaje, y comunidad activa con integraciones bien mantenidas. La transición a una herramienta enterprise tiene sentido cuando el volumen de activos, los requerimientos de workflow de stewardship o las necesidades de compliance superan lo que las opciones open source pueden ofrecer.

Cómo implementar un catálogo de datos que no muera en tres meses

El patrón de fracaso más frecuente en implementaciones de catálogos de datos es siempre el mismo: se instala la herramienta, se hace una carga inicial de metadatos, se presenta en una reunión de dirección y tres meses después nadie lo usa porque nadie tiene tiempo de mantenerlo. Para evitar ese patrón, el orden de implementación importa tanto como la herramienta elegida.

Paso 1: define el alcance inicial y no intentes catalogarlo todo

El error más común es intentar catalogar todos los datos de la organización desde el primer día. El resultado es un proyecto interminable que nunca llega a producción o que llega con metadatos tan superficiales que no aportan valor. Empieza por los tres o cinco dominios más críticos para el negocio —los que generan más preguntas, los que alimentan los informes de dirección, los que sustentan sistemas de IA— y hazlos bien antes de expandir.

Paso 2: automatiza la ingesta de metadatos técnicos desde el primer día

Configura los conectores con tus plataformas de datos antes de escribir una sola línea de descripción manual. Los metadatos técnicos —esquemas, tipos, linaje— deben fluir automáticamente. Si la base del catálogo depende de trabajo manual, está condenada. Con OpenMetadata y Snowflake, esta configuración inicial se puede hacer en menos de una jornada.

Paso 3: asigna Data Stewards con tiempo real antes de lanzar

El catálogo necesita personas responsables de enriquecer y mantener los metadatos de negocio. Esas personas deben tener tiempo asignado —no tiempo residual— y criterios claros de qué se espera de ellas. Sin Data Stewards con mandato, el catálogo es un inventario técnico sin contexto que nadie usa. Para entender cómo estructurar estos roles, consulta el artículo Roles y responsabilidades de un equipo de Data Governance.

Paso 4: integra el catálogo en los flujos de trabajo existentes

Un catálogo que vive en una URL separada que nadie recuerda visitar es un catálogo muerto. El catálogo debe estar donde la gente trabaja: en los datasets de Power BI Service con descripciones visibles, en los modelos de dbt con documentación generada automáticamente en cada deploy, en los tickets de solicitud de acceso con enlace a la ficha del activo. La adopción no viene de campañas de comunicación interna; viene de hacer que el catálogo sea el camino de menor resistencia para encontrar información sobre los datos.

Paso 5: mide la adopción y hazla visible

Define métricas de adopción desde el primer mes: cobertura del catálogo por dominio (porcentaje de activos con descripción de negocio), número de búsquedas semanales, número de activos con propietario asignado, tiempo desde la última actualización de metadatos. Publica estas métricas en un dashboard visible para el equipo y para la dirección. Lo que no se mide no se mantiene.

Lo que funciona en entornos reales

Catálogo federado en un grupo con múltiples aerolíneas

En un entorno con varias aerolíneas operando bajo la misma holding, el reto del catálogo no es técnico: es de coordinación. Cada entidad tiene su propio stack, sus propios Data Stewards y sus propias definiciones de conceptos clave. Intentar un catálogo único y centralizado genera rechazo; intentar catálogos totalmente independientes genera inconsistencias entre dominios compartidos.

El modelo que funciona es un catálogo federado: una instancia central con los dominios maestros compartidos —Clientes, Producto, Operaciones, Finanzas— con definiciones canónicas acordadas y mantenidas por Stewards corporativos, y extensiones locales por entidad donde cada aerolínea puede añadir sus propios activos y adaptaciones sin romper los estándares corporativos. OpenMetadata soporta esta arquitectura de forma nativa con su modelo de equipos y dominios.

dbt Docs como catálogo mínimo viable en equipos de BI comercial

En proyectos de consultoría BI para equipos comerciales, el catálogo de datos no siempre parte de cero ni requiere una inversión en plataforma. En equipos que ya usan dbt, la documentación en dbt Docs —con descripciones de modelos y campos, tests de calidad y linaje automático entre tablas— funciona como un catálogo mínimo viable que resuelve el 70% de los casos de uso más frecuentes: ¿qué es este campo?, ¿de dónde viene esta tabla?, ¿qué tests de calidad tiene este modelo?

El salto a una herramienta de catálogo completa como OpenMetadata tiene sentido cuando el equipo necesita el glosario de negocio vinculado, la gestión de propietarios y clasificaciones, o la integración con plataformas de consumo como Power BI Service. Pero empezar con dbt Docs permite construir el hábito de documentar antes de añadir la complejidad de una plataforma adicional.

Linaje automático en Snowflake como base del artículo 10 del AI Act

En entornos donde Snowflake es la plataforma central de datos, el linaje técnico entre tablas puede capturarse automáticamente mediante los conectores de OpenMetadata o Purview. Esto significa que cualquier dataset de entrenamiento que pase por Snowflake tiene su linaje documentado de forma automática: qué tablas fuente lo alimentan, qué transformaciones se aplicaron y qué modelos o dashboards lo consumen.

Combinado con las fichas de dataset mantenidas por los Data Stewards, esta infraestructura genera de forma casi automática la documentación que el artículo 10 del AI Act exige para sistemas de alto riesgo. El cumplimiento regulatorio deja de ser un proyecto paralelo y se convierte en un subproducto de la gobernanza operativa.

Errores frecuentes en implementaciones de data catalog

• Empezar por la herramienta, no por el caso de uso. Comprar Collibra o activar Purview antes de saber qué problema concreto se quiere resolver garantiza una implementación sin adopción. La herramienta amplifica el proceso; si el proceso no existe, amplifica el vacío.
• Catalogar todo de golpe. El scope infinito mata los proyectos de catálogo. Empezar por todos los dominios a la vez genera un backlog interminable de metadatos por enriquecer que nunca se completa y una herramienta que siempre está "en proceso" y nunca está lista para usar.
• Ingesta manual de metadatos técnicos. Si los metadatos técnicos —esquemas, tipos, linaje— se cargan manualmente, el catálogo está desactualizado desde el primer cambio en el esquema de datos. La ingesta automática no es una funcionalidad opcional; es el requisito mínimo para que el catálogo sea sostenible.
• Sin Data Stewards, sin catálogo real. La herramienta puede poblar los metadatos técnicos automáticamente, pero el contexto de negocio —descripciones, definiciones, clasificaciones— requiere personas con tiempo y mandato para mantenerlo. Sin esa capa humana, el catálogo es un directorio de tablas con nombres técnicos que nadie de negocio entiende.
• No medir la adopción. Un catálogo sin métricas de uso es un catálogo sin argumentos para mantener el presupuesto. Si nadie mide cuántas búsquedas se hacen, cuántos activos tienen descripción actualizada o cuánto ha bajado el tiempo de onboarding de analistas, el catálogo desaparece en la siguiente ronda de recortes.
• Tratar el catálogo como un proyecto de compliance. Si el catálogo se implementa solo para cumplir el AI Act o para superar una auditoría, estará diseñado para superar una inspección, no para ser usado. La diferencia se nota inmediatamente en la calidad de los metadatos y en el nivel de adopción del equipo.

Conclusión: el catálogo de datos no es una herramienta, es una decisión organizativa

Un catálogo de datos bien implementado transforma la forma en que un equipo de datos trabaja: menos tiempo buscando, menos reuniones de validación, más confianza en los datos que sustentan las decisiones. Pero ninguna herramienta logra eso sola. Lo que hace funcionar a un catálogo no es la plataforma elegida; es la combinación de metadatos técnicos automatizados, Data Stewards con tiempo y mandato real, y una integración en los flujos de trabajo diarios que haga que usarlo sea más fácil que no usarlo.

Para las organizaciones que operan sistemas de IA de alto riesgo, el catálogo deja de ser una opción de mejora y se convierte en la infraestructura que hace posible el cumplimiento del AI Act de forma sostenible. Sin él, el artículo 10 es un documento Word que alguien actualizará una vez. Con él, es un artefacto vivo que se mantiene solo.

Checklist: catálogo de datos operativo

• Dominio o dominios iniciales definidos con alcance acotado y realista.
• Conectores de ingesta automática configurados con las plataformas de datos (Snowflake, dbt, Databricks, Power BI).
• Linaje técnico end-to-end visible y actualizado automáticamente.
• Data Stewards asignados por dominio con tiempo dedicado y criterios de mantenimiento claros.
• Glosario de negocio con definiciones validadas por Data Owners para los conceptos críticos.
• Clasificación de sensibilidad aplicada a los activos de datos relevantes.
• Propietario (Data Owner) asignado y visible en cada activo catalogado.
• Integración del catálogo en los flujos de trabajo: Power BI Service, dbt Docs, tickets de acceso.
• Fichas de dataset para sistemas de IA de alto riesgo con linaje y métricas de calidad (art. 10 AI Act).
• Dashboard de adopción con cobertura de metadatos, búsquedas y fecha de última actualización por dominio.
• Proceso de actualización periódica de metadatos de negocio integrado en el sprint o ciclo del equipo.

Preguntas frecuentes sobre catálogo de datos

¿Qué es un catálogo de datos?

Un catálogo de datos es una herramienta centralizada que registra, organiza y hace accesibles los metadatos de todos los activos de datos de una organización: tablas, campos, pipelines, dashboards, APIs y modelos de IA. Su función es que cualquier persona del equipo pueda encontrar un dato, entender qué es, saber de dónde viene, quién es responsable y si puede usarlo, sin tener que preguntar a nadie ni investigar durante horas.

¿Qué diferencia hay entre un catálogo de datos y un glosario de negocio?

El glosario de negocio define qué significa un concepto de negocio: qué es un cliente activo, cómo se calcula el ingreso neto, qué entiende la empresa por incidente. El catálogo de datos registra dónde está ese dato físicamente: en qué tabla, en qué campo, con qué transformaciones y con qué calidad. Un catálogo maduro vincula ambas capas: el dato técnico con su definición de negocio. Sin esa vinculación, el catálogo técnico es un directorio de tablas y el glosario es un documento Word desconectado de la realidad.

¿Qué herramientas de data catalog existen en 2026?

Las opciones más sólidas son: OpenMetadata y Apache Atlas en el segmento open source; Collibra, Alation e IBM Knowledge Catalog en el segmento enterprise; y Microsoft Purview para ecosistemas Microsoft. Para equipos que ya usan dbt, dbt Docs es un punto de partida muy razonable antes de invertir en una plataforma completa. La elección depende del stack tecnológico, el presupuesto y el nivel de madurez de gobernanza existente.

¿Un catálogo de datos es obligatorio para cumplir el AI Act?

No es obligatorio por nombre, pero sí por función. El artículo 10 del AI Act exige que los sistemas de IA de alto riesgo tengan documentados los datasets de entrenamiento: origen, transformaciones, criterios de selección y métricas de calidad. Sin un catálogo que mantenga esa información actualizada y trazable, cumplir el artículo 10 de forma sostenible —no como un documento puntual, sino como evidencia continua— es prácticamente imposible.

¿Por qué fracasan la mayoría de implementaciones de catálogos de datos?

Por tres razones que se repiten sistemáticamente: se implementa la herramienta antes de tener roles con responsabilidad de mantenimiento; los metadatos se cargan manualmente en el arranque y nadie los actualiza después; y el catálogo no está integrado en los flujos de trabajo diarios del equipo de datos. Un catálogo que no está donde la gente trabaja es un catálogo que no se usa. La solución no es comunicación interna ni formación obligatoria: es diseñar la implementación para que usar el catálogo sea más fácil que no usarlo.