7.1 Estrategia y gobernanza de datos

Presentación y motivación

La estrategia de datos es tu plan deliberado para tratar los datos como un activo: cómo se producen, describen, poseen, protegen, comparten y consumen para crear valor. La gobernanza de datos es el sistema operativo que hace real la estrategia: los roles, políticas, estándares y controles que mantienen los datos confiables y conformes con el tiempo. En equipos pequeños estas preocupaciones suelen ser implícitas, cargadas en las cabezas de unos pocos ingenieros. A la escala de las grandes organizaciones de desarrollo, las empresas y las agencias gubernamentales, esa informalidad se desmorona. Cientos de equipos producen miles de tablas. Docenas de sistemas afirman tener el registro «real» del cliente. Y nadie puede decir con confianza qué número es correcto en una presentación para la junta o en un informe público.

Para los equipos grandes, el costo de una mala gobernanza de datos no es abstracto. Los reguladores esperan un linaje demostrable y control sobre los datos personales, financieros y de salud bajo regímenes como el RGPD (el Reglamento General de Protección de Datos de la UE), la HIPAA (la Ley de Portabilidad y Responsabilidad del Seguro Médico de EE. UU.), y normas específicas del sector. Las empresas enfrentan una exposición financiera directa por métricas mal reportadas, auditorías fallidas y plataformas de datos duplicadas. Las agencias gubernamentales cargan obligaciones adicionales en torno a la retención de registros, el acceso por libertad de información, la rendición de cuentas pública y el trato equitativo de la ciudadanía. En cada uno de estos entornos, un dato en el que no puedes confiar es peor que ningún dato, porque impulsa decisiones confiadas pero equivocadas.

La idea que impulsa el progreso a escala es simple: trata los datos como un producto. En lugar de que los datos sean un subproducto residual de las aplicaciones, cada conjunto de datos importante tiene un dueño, una interfaz documentada, garantías de calidad, y consumidores tratados como clientes. Este capítulo cubre esa mentalidad de producto junto con las disciplinas de gobernanza clásicas: administración, catalogación, gestión de datos maestros, y calidad. También cubre las elecciones organizacionales que determinan qué modelo se ajusta a tu equipo: una malla de datos (datos descentralizados, propiedad de dominio, publicados como productos), un lakehouse de datos (gestión y gobernanza al estilo de un almacén superpuestas sobre un lago de datos flexible), y un almacén de datos (un almacén central gobernado de datos modelados y listos para consultar).

Véase también: el capítulo 4.5 (privacidad y protección de datos), el capítulo 7.2 (ingeniería de datos), y el capítulo 4.6 (cumplimiento y gobernanza).

Principios fundamentales

Los datos son un activo duradero con dueños, no un subproducto desechable de las aplicaciones.
Cada conjunto de datos importante tiene un dueño responsable nombrado y un contrato documentado.
La gobernanza habilita el uso confiable; no es una puerta burocrática que solo dice que no.
Debería existir una fuente autorizada única para cada entidad de negocio crítica.
La calidad, la privacidad y el linaje se diseñan desde el principio, no se inspeccionan después.
Los consumidores de datos son clientes cuyas necesidades moldean el producto.
Las políticas se codifican y aplican automáticamente siempre que es posible, no se dejan a la buena voluntad.
La propiedad federada escala mejor que un único equipo central a medida que la organización crece.

Recomendaciones

Trata los datos como un producto

Da a cada conjunto de datos significativo un dueño de producto responsable de su idoneidad para el uso. Un producto de datos tiene un nombre, un esquema documentado, una descripción de su significado y procedencia, una cadencia de actualización definida, y expectativas de calidad publicadas. Tus consumidores deberían poder descubrirlo, comprenderlo y depender de él sin hacer una sola pregunta al equipo productor. Aplica la misma disciplina que aplicas a las API de software: versionado, avisos de obsolescencia, registros de cambios y compatibilidad hacia atrás.

Establece contratos de datos y acuerdos de nivel de servicio

Un contrato de datos es un acuerdo explícito y verificable por máquina entre un productor y sus consumidores. Cubre el esquema, la semántica, la frescura, el volumen y los cambios permitidos. Haz cumplir los contratos en el canal para que un cambio disruptivo aguas arriba falle rápido en la fuente, en lugar de corromper silenciosamente informes posteriores semanas después. Combina los contratos con acuerdos y objetivos de nivel de servicio. Por ejemplo, «dimensión de cliente actualizada antes de las 06:00 diariamente, el 99.5% de los días, con menos del 0.1% de claves de negocio nulas». Publica esto, y alerta ante incumplimientos.

Construye administración y un modelo operativo de gobernanza

Mantén la responsabilidad separada de la ejecución. Los dueños de datos (a menudo líderes de negocio) son responsables de un dominio. Los administradores de datos (expertos en la materia) mantienen definiciones, resuelven problemas de calidad y aprueban el acceso. Un consejo de gobernanza de datos ligero fija estándares transversales y resuelve disputas. Mantén el modelo federado: un equipo central de habilitación proporciona herramientas, estándares y acompañamiento, mientras los equipos de dominio son dueños de sus datos. Esto evita tanto el cuello de botella de la centralización total como el caos de ninguna gobernanza en absoluto.

Invierte en un catálogo de datos y linaje

Un catálogo con capacidad de búsqueda es la puerta de entrada a tu patrimonio de datos. Debería contener glosarios de negocio, esquemas técnicos, propiedad, clasificaciones de sensibilidad, puntuaciones de calidad, y linaje de extremo a extremo desde el sistema fuente a través de las transformaciones hasta los tableros. Automatiza la recolección de metadatos en lugar de depender de la documentación manual, que se pudre rápidamente. El linaje es esencial para el análisis de impacto, la respuesta a incidentes, la auditoría, y las solicitudes regulatorias como el acceso y la eliminación de datos de un titular.

Gestión de datos maestros y una única fuente de verdad

Para entidades centrales (cliente, ciudadano, producto, proveedor, empleado), usa la gestión de datos maestros para reconciliar duplicados y registros en conflicto en un único registro dorado. Elige una arquitectura (registro, consolidación, coexistencia, o centralizada) según cuán autoritativo necesite ser el centro. Define explícitamente las reglas de emparejamiento y supervivencia, y hazlas auditables. Una fuente única de verdad previene el fallo clásico donde finanzas, ventas y operaciones reportan cada uno ingresos distintos.

Mide la calidad de los datos en varias dimensiones

Gestiona la calidad a lo largo de dimensiones nombradas: exactitud, completitud, consistencia, oportunidad, validez y unicidad. Instrumenta los canales con pruebas automatizadas y observabilidad continua de datos (frescura, volumen, deriva de esquema, y comprobaciones de distribución), para que detectes anomalías antes de que se vean afectados los consumidores. Trata los incidentes de datos como interrupciones de producción, con detección, triaje, análisis de causa raíz, y postmortems.

Clasifica, protege y controla el acceso

Clasifica los datos por sensibilidad, y aplica controles en proporción: cifrado, enmascaramiento, tokenización, seguridad a nivel de fila y columna, y acceso de mínimo privilegio revisado regularmente. Mantén un calendario de retención y eliminación que satisfaga tanto los requisitos de minimización como la ley de retención de registros. En contextos gubernamentales, reconcilia las obligaciones de transparencia con las protecciones de privacidad deliberadamente, en lugar de caso por caso.

Ventajas y desventajas

Enfoque	Ventajas	Desventajas	Mejor ajuste
Equipo de gobernanza centralizado	Estándares consistentes, responsabilidad clara	Cuello de botella, desconectado de los dominios	Organizaciones pequeñas o muy reguladas
Gobernanza federada	Escala, experiencia de dominio, propiedad	Requiere herramientas y cultura sólidas	Grandes empresas multidominio
Almacén de datos	SQL maduro, gobernado, de alto rendimiento	Rígido, costoso para datos no estructurados	Cargas de trabajo de BI estables e intensivas
Lakehouse de datos	Flexible, unificado, maneja todo tipo de datos	Herramientas más jóvenes, esfuerzo de gobernanza	Analítica mixta y aprendizaje automático
Malla de datos	Propiedad de dominio, escala organizacionalmente	Alto umbral de madurez, costo de coordinación	Organizaciones muy grandes y descentralizadas

La gobernanza siempre intercambia velocidad por confianza. Una gobernanza ligera permite a los equipos moverse rápido, hasta que una auditoría, una brecha, o un informe erróneo vergonzoso fuerza un ajuste de cuentas costoso. Una gobernanza pesada protege la confianza pero puede asfixiar la experimentación y empujar a los equipos hacia sistemas en la sombra. La respuesta duradera es codificar la gobernanza como barandillas automatizadas de autoservicio, para que el camino conforme sea también el camino fácil. Arquitectónicamente, los almacenes favorecen la simplicidad gobernada, la malla favorece la escala organizacional, y los lakehouses dividen la diferencia. La elección correcta sigue la estructura de tu organización mucho más que cualquier referencia técnica.

Preguntas para discutir con tu equipo

¿Qué arquitectura de datos (almacén, lakehouse o malla) realmente se ajusta a cómo está estructurada tu organización, y eres honesto sobre el umbral de madurez que cada una exige? La tabla de ventajas y desventajas plantea que esta elección sigue la estructura organizacional, no las referencias: un almacén premia las cargas de trabajo de BI estables e intensivas, un lakehouse maneja analítica mixta y aprendizaje automático, y una malla escala a través de muchos dominios autónomos pero exige alta madurez y herramientas sólidas. Para una gran empresa o agencia gubernamental con docenas de dominios, saltar a una malla antes de tener plataformas de autoservicio y una cultura de gobernanza produce caos disfrazado de descentralización. Trae señales concretas: cuántos dominios producen datos, si los equipos centrales ya son un cuello de botella, y si los equipos de dominio tienen la habilidad y el incentivo para ser dueños de productos. Si careces de herramientas federadas hoy, la respuesta honesta puede ser un almacén o lakehouse gobernado ahora y una malla después. Elige el modelo que tu gente realmente puede operar, luego invierte en la madurez que el siguiente modelo necesita.
¿Puedes honrar una solicitud de eliminación de extremo a extremo hoy, y tu linaje demuestra a dónde fue cada copia de un registro personal? Bajo el RGPD y regímenes similares, una solicitud de eliminación o acceso de un titular de datos es una obligación legal con plazos estrictos, y copiar datos ampliamente sin linaje hace imposible satisfacerla. Los equipos grandes rutinariamente dispersan los datos en data marts, extractos, cachés y hojas de cálculo, así que la pregunta real es si puedes rastrear y alcanzar cada copia, no si puedes eliminar el original. Trae evidencia: elige un cliente o ciudadano real e intenta enumerar cada lugar donde viven sus datos. Si no puedes, esa brecha es tanto un riesgo de cumplimiento como un problema de radio de impacto de una brecha. La respuesta debería impulsar la inversión en linaje automatizado y controles más estrictos sobre la copia no controlada, porque el camino conforme tiene que construirse antes de que llegue la solicitud.
¿Tu gobernanza es el camino fácil o una puerta que la gente rodea, y dónde están los sistemas en la sombra que lo demuestran? La respuesta duradera del capítulo es codificar la gobernanza como barandillas automatizadas de autoservicio para que el camino conforme sea también el camino más rápido, porque la gobernanza manual pesada empuja a los equipos hacia hojas de cálculo en la sombra y copias sin gobernar. Para las empresas y agencias, los sistemas en la sombra son donde nacen las brechas, los números erróneos y las auditorías fallidas, precisamente porque nadie los vigila. Trae un inventario concreto: qué equipos mantienen sus propias copias, qué informes evitan el catálogo, y dónde la gente dice que el proceso oficial es demasiado lento. Cada sistema en la sombra es una señal de que el camino gobernado cuesta más que la solución alternativa. Arregla la fricción en lugar de emitir otra política, para que usar datos certificados y contratos sea genuinamente más fácil que rodearlos.
¿Qué entidad de negocio crítica necesita más urgentemente una fuente autorizada única, y quién, por nombre, es responsable de su registro dorado hoy? La gestión de datos maestros existe para evitar que finanzas, ventas y operaciones reporten cada uno un cliente distinto o una cifra de ingresos distinta, y a escala, la ausencia de una fuente autorizada única convierte cada número entre dominios en una discusión. Las consideraciones en competencia son cuán autoritativo debe ser el centro (registro, consolidación, coexistencia, o totalmente centralizado) y cuánta lógica de emparejamiento y supervivencia estás dispuesto a construir y auditar, ya que un centro más pesado cuesta más pero resuelve más conflictos. Trae las entidades que aparecen en más informes (cliente, ciudadano, producto, proveedor, empleado), un conteo de cuántos sistemas afirman tener el registro real de cada una, y las reglas de emparejamiento que usas hoy, si las hay. Para un banco o una agencia nacional, nombra al dueño responsable y las reglas de supervivencia explícitamente, porque un regulador que rastrea una cifra desde un informe público hasta la fuente preguntará quién decidió qué duplicado ganó, y «nadie» no es una respuesta que sobreviva a una auditoría.
¿Cómo sabes que un conjunto de datos crítico es apto para el uso antes de que un consumidor descubra que está roto? En patrimonios de datos inmaduros, la calidad la descubre el analista cuyo tablero se rompe o el ejecutivo cuya cifra de la junta está mal, que es el punto de detección más costoso posible. La tensión es entre el costo de instrumentar la calidad (pruebas, comprobaciones de frescura y volumen, monitoreo de distribución y deriva de esquema a través de dimensiones nombradas como exactitud, completitud y validez) y el costo de los incidentes que previenes, y los equipos rutinariamente subinvierten porque los fallos permanecen invisibles hasta que se vuelven catastróficos. Trae los últimos tres incidentes de datos, cómo se detectaron, y cuánto tiempo corrieron antes de que alguien se diera cuenta, más los acuerdos de nivel de servicio de calidad que realmente publicas y sobre los que alertas hoy. Para el reporte empresarial y gubernamental, vincula cada producto de datos crítico a umbrales de calidad explícitos y trata un incumplimiento como una interrupción de producción con triaje y un postmortem, porque una cifra incorrecta en una presentación regulatoria o una estadística pública conlleva un costo legal y reputacional que empequeñece la factura de monitoreo.
¿Tu gobernanza está genuinamente federada con propiedad de dominio, o es un equipo central responsable de datos que no comprende? El capítulo argumenta que la propiedad federada con habilitación central escala donde la centralización pura genera cuellos de botella y la descentralización pura desciende al caos, sin embargo muchas organizaciones afirman tener federación mientras un pequeño equipo central sigue siendo nominalmente responsable de miles de tablas de las que no tiene conocimiento de dominio. La tensión en competencia es real: los equipos centrales dan consistencia y un único cuello que estrangular, mientras que la propiedad de dominio da experiencia y responsabilidad pero exige que los dueños de negocio acepten una responsabilidad que quizás no quieran. Trae un mapa honesto de quién es responsable frente a quién realmente mantiene las definiciones y resuelve los problemas de calidad para tus principales dominios, y si los administradores tienen la autoridad y el tiempo que el rol requiere. En una gran empresa o agencia, comprueba que la propiedad recaiga en personas que tienen tanto el conocimiento de dominio como el mandato de decir que no, porque la gobernanza asignada a un equipo central sin autoridad produce políticas que nadie sigue y un consejo que no resuelve nada.

Perspectiva sectorial

Startup. La velocidad y la supervivencia superan al proceso. Nombra un dueño para cada conjunto de datos central y haz que un almacén sea la fuente única de verdad para entidades como «cliente activo», y salta por completo los catálogos, consejos y mallas. Un contrato de una página para tu puñado de tablas críticas (esquema, hora de actualización, una única expectativa de calidad) termina la discusión de «quién tiene el número correcto» en una tarde. Apóyate en la gobernanza ya incorporada en tu almacén en lugar de dotar de personal a una función que no puedes costear.

Pequeña empresa. Sin un especialista de datos dedicado y con un presupuesto ajustado, trata la gobernanza como higiene de datos en lugar de un proyecto de plataforma: sabe qué datos personales tienes, dónde viven, y quién tiene permiso para tocarlos. Prefiere un almacén gestionado o una herramienta de BI que proporcione linaje, control de acceso y retención de fábrica, así compras gobernanza incorporada en herramientas que ya operas en lugar de construirla. Reserva cualquier canal personalizado para el único conjunto de datos que genuinamente impulsa el negocio.

Empresa. A escala a través de muchos equipos, el trabajo es propiedad federada con habilitación central: un catálogo compartido con linaje automatizado, contratos de datos aplicados, datos maestros para entidades centrales, y acuerdos de nivel de servicio de calidad medidos contra líneas base. Codifica la gobernanza como barandillas de autoservicio para que el camino conforme sea también el camino rápido, y gestiona los datos como una cartera de productos con dueños nombrados. De esa manera los auditores pueden rastrear cualquier cifra desde el informe hasta la fuente, y los grupos dejan de reinventar los mismos canales y definiciones.

Gobierno. Las reglas de contratación pública, la transparencia y la rendición de cuentas pública moldean cada elección. Trata los indicadores publicados como productos de datos con metodología documentada, lanzamientos versionados y puertas de calidad, y reconcilia las obligaciones de libertad de información y datos abiertos con la privacidad y la minimización deliberadamente en lugar de caso por caso. Exige portabilidad de datos y divulgación de linaje en los contratos con proveedores para evitar la dependencia de un proveedor único, mantén un calendario de retención y eliminación defendible, y deja que un consejo de administración mantenga definiciones compartidas para que «hogar» o «desempleo» signifiquen lo mismo en todos los departamentos.

Ejemplos

Startup. Una empresa SaaS en etapa semilla descubrió que su hoja de cálculo de facturación, su herramienta de ventas y su base de datos de producto reportaban cada una un conteo de clientes distinto, y nadie podía decir cuál era correcto para la actualización a los inversores. El equipo de cuatro personas nombró un dueño para cada conjunto de datos central, hizo que el almacén fuera la fuente única para «cliente activo», y escribió un contrato de una página que describía el esquema y la hora de actualización diaria. Tomó una tarde, y terminó la discusión semanal sobre en qué número confiar.

Empresa. Un banco multinacional consolidó docenas de registros de clientes en conflicto a través de sus divisiones minorista, de préstamos y de patrimonio en un centro de gestión de datos maestros con reglas de supervivencia y un registro dorado. Cada dominio publicó productos de datos con contratos y acuerdos de nivel de servicio de frescura, expuestos en un catálogo central con linaje. El tiempo de reporte regulatorio cayó drásticamente, porque los auditores ahora podían rastrear cualquier cifra desde el informe hasta la fuente. El banco también retiró varias plataformas de reporte redundantes.

Gobierno. Una agencia nacional de estadísticas trata sus indicadores publicados como productos de datos, con metodología documentada, lanzamientos versionados y puertas de calidad estrictas. Un consejo de administración reconcilia definiciones entre departamentos, para que «desempleo» u «hogar» signifiquen lo mismo en todas partes. La clasificación y el acceso controlado protegen la confidencialidad de los encuestados, mientras un catálogo público apoya la transparencia y las obligaciones de libertad de información.

Caso de negocio: motivaciones, ROI y TCO

La motivación para la gobernanza de datos es la reducción de riesgo y la creación de valor en aproximadamente igual medida. En el lado del riesgo, los costos evitados incluyen multas regulatorias, responsabilidad por brechas, auditorías fallidas, y el daño reputacional de publicar números erróneos. En el lado del valor, los datos confiables y descubribles aceleran cada esfuerzo posterior de analítica y aprendizaje automático, reducen los canales duplicados, y acortan el tiempo desde la pregunta hasta la respuesta.

El costo de adopción es real: herramientas de catálogo y calidad, tiempo de administradores y dueños, y el cambio organizacional para que la propiedad se mantenga. Pesa el TCO (costo total de propiedad) contra el costo de no adoptar, que usualmente es mayor, solo que oculto. Sin medir, ese costo se manifiesta como analistas que pasan la mayor parte de su tiempo encontrando y limpiando datos, equipos reconstruyendo los mismos canales, y ejecutivos tomando decisiones sobre cifras que nadie puede defender. Presenta el caso al liderazgo en su idioma: la gobernanza convierte los datos de un pasivo con desventaja ilimitada en un activo con retornos compuestos, y es un prerrequisito para la IA confiable. Empieza donde el dolor y la exposición regulatoria son más altos, para que puedas mostrar valor rápidamente.

Antipatrones y trampas

Gobernanza por comité sin automatización, produciendo políticas que nadie sigue.
Catalogar todo a la vez en lugar de los conjuntos de datos que realmente importan.
Proyectos de datos maestros que abarcan demasiado y nunca entregan un registro dorado.
Tratar la calidad de datos como una limpieza única en lugar de observabilidad continua.
Propiedad asignada a un equipo central que carece de conocimiento de dominio o autoridad.
Contratos documentados en wikis pero no aplicados en los canales.
Copiar datos ampliamente sin linaje, haciendo imposible honrar las solicitudes de eliminación.
Comprar una herramienta y llamarla estrategia; las herramientas sin modelo operativo fallan.

Modelo de madurez

Iniciar: Los datos no están documentados ni tienen dueño, se manejan de forma ad hoc y reactiva. Las definiciones entran en conflicto entre equipos. La calidad la descubren los consumidores cuando los informes se rompen. No existe catálogo ni linaje.
Desarrollar: Aparecen prácticas básicas pero son inconsistentes entre equipos. Algunos conjuntos de datos tienen dueños y documentación, y existe un catálogo parcial. Las comprobaciones de calidad son manuales y reactivas. Se escribe una política de gobernanza pero se aplica débil y desigualmente.
Estandarizar: La propiedad, los contratos y los acuerdos de nivel de servicio están documentados y se aplican en toda la organización. Los productos de datos críticos tienen dueños nombrados; un catálogo con linaje automatizado cubre los dominios clave; existen datos maestros para las entidades centrales; la gobernanza es federada con habilitación central y se aplica de forma consistente en lugar de equipo por equipo.
Gestionar: El patrimonio se mide y controla contra líneas base. Las dimensiones de calidad (exactitud, completitud, oportunidad, validez, unicidad) se rastrean contra objetivos de acuerdo de nivel de servicio publicados; las tasas de incumplimiento de contratos, la cobertura de linaje y catálogo, la frescura, y el tiempo para honrar una solicitud de eliminación se reportan en tableros; la observabilidad alerta sobre la deriva de esquema y las anomalías de volumen; los incidentes reciben triaje, análisis de causa raíz y postmortems; las decisiones de acceso y de continuar o no descansan en métricas contra líneas base, no en opinión.
Orquestar: La gobernanza se mejora continuamente y se integra en toda la organización. Los datos como producto son la norma en todos los dominios; los contratos se aplican automáticamente y los cambios disruptivos fallan rápido; las barandillas de autoservicio codifican la política; la calidad y el linaje alimentan la gestión proactiva de riesgos; las definiciones son confiables en toda la empresa y apoyan el reporte regulado y la IA. La organización rutinariamente reequilibra la propiedad, retira plataformas redundantes, y adapta la gobernanza a medida que cambian el negocio y la regulación.

Ideas para el debate

¿Cuál de tus entidades de negocio necesita más urgentemente una fuente única de verdad, y por qué está fragmentada hoy?
¿Dónde habrían prevenido un incidente reciente los contratos de datos aplicados?
¿Tu organización está estructurada para la propiedad federada, o la centralización se ajustaría mejor ahora mismo?
¿Cómo reconcilias las obligaciones de transparencia del gobierno con la privacidad y la minimización?
¿Qué porcentaje del tiempo de tus analistas se gasta encontrando y limpiando datos, y cuánto valdría reducirlo a la mitad?
¿Quién es responsable, por nombre, de tu conjunto de datos más importante, y lo sabe?

Puntos clave

Trata los datos como un producto con dueños, contratos y acuerdos de nivel de servicio, no como residuo de aplicaciones.
La gobernanza federada con habilitación central escala mejor que la centralización pura.
Un catálogo con linaje automatizado es la puerta de entrada a un patrimonio de datos confiable.
Establece una fuente única de verdad para entidades centrales mediante la gestión de datos maestros.
Gestiona la calidad continuamente a través de dimensiones nombradas con observabilidad y respuesta a incidentes.
Codifica la gobernanza como barandillas automatizadas para que el camino conforme sea el camino fácil.
Elige almacén, lakehouse o malla para ajustarte a tu organización, no a la moda.

Referencias y lecturas adicionales

DAMA International, «DAMA-DMBOK: Data Management Body of Knowledge».
Zhamak Dehghani, «Data Mesh: Delivering Data-Driven Value at Scale».
Ralph Kimball y Margy Ross, «The Data Warehouse Toolkit».
Piethein Strengholt, «Data Management at Scale».
David Loshin, «Master Data Management».
Chad Sanderson y colegas, escritos sobre contratos de datos.
ISO/IEC 38505, «Gobernanza de datos».
ISO 8000, serie de normas de «Calidad de datos».