La plataforma de datos de AlpinaShop funciona. Los pedidos entran solos, Dataflow los limpia, Spark calcula la cesta media, Data Fusion trae el fichero del transportista y Workflows lo coordina todo cada noche con su comprobación de calidad. Técnicamente es un éxito.

Y sin embargo, tres cosas siguen sin funcionar.

Nadie sabe qué hay. En alpinashop_analitica hay dieciséis tablas, seis vistas, dos vistas materializadas y una llamada pedidos_evento que nadie recuerda por qué existe. Cuando alguien de marketing pregunta "¿dónde está el dato de conversión?", la respuesta es "pregúntale a Lucía". Y si Lucía se va de vacaciones, la respuesta es "no lo sé".

Nadie sabe qué significa. La columna ventas_eur aparece en cuatro tablas. ¿Incluye IVA? ¿Descuenta devoluciones? ¿Cuenta los pedidos cancelados? Marta cree que sí, Lucía cree que no, y el informe que va a dirección usa una de las dos definiciones sin decir cuál. Nadie lo ha escrito nunca.

Nadie sabe quién puede ver qué. En 04-01 se protegió email_cliente con una etiqueta de política. Pero desde entonces han pasado seis lecciones: Dataflow escribe en pedidos_streaming, la suscripción de Pub/Sub vuelca en pedidos_evento, el archivo de eventos va a Cloud Storage y Data Fusion trajo el CSV del transportista con el nombre del destinatario. ¿Hay emails de clientes en alguno de esos sitios sin protección? Nadie lo ha comprobado.

Y hay una cuarta cosa que falta, la que dirección lleva pidiendo desde el módulo 3: el cuadro de mando. Los datos están impecables y nadie los ve.

En esta lección cerramos el módulo resolviendo las cuatro. Verás qué es el gobierno del dato y por qué una pyme lo necesita tanto como una multinacional, organizarás y documentarás la plataforma con Dataplex, definirás reglas de calidad que se comprueban solas, descubrirás y desidentificarás los datos personales con Sensitive Data Protection, y construirás por fin en Looker Studio el cuadro de mando de AlpinaShop, evitando el error de permisos que convierte un informe compartido en una fuga de datos.

1. Qué es el gobierno del dato y por qué también en una pyme
2. Dataplex: lagos, zonas y activos
3. El catálogo universal y la búsqueda de datos
4. Etiquetas y plantillas: documentar alpinashop_analitica
5. Perfiles de datos: qué hay realmente en tus tablas
6. Reglas de calidad y qué hacer cuando fallan
7. Linaje automático de extremo a extremo
8. Sensitive Data Protection: descubrir dónde están los datos personales
9. Desidentificación: enmascarado y tokenización
10. Looker Studio: conectar y modelar
11. El cuadro de mando de dirección de AlpinaShop
12. Coste y rendimiento: extracción, consulta viva y BI Engine
13. Permisos: el error clásico de las credenciales del propietario
14. Looker y LookML: cuándo justifica su precio
15. Checklist de una plataforma de datos sana

El gobierno del dato es el conjunto de prácticas que garantizan que los datos de una organización sean encontrables, comprensibles, fiables, seguros y gestionados a lo largo de su vida. Cinco patas:

La objeción habitual es que esto es cosa de bancos y multinacionales. Es exactamente al revés, y merece argumentarse:

El RGPD no distingue por tamaño. Una empresa de 40 personas que trata datos de clientes europeos tiene las mismas obligaciones que una de 40.000: saber qué datos personales tiene, dónde están, con qué base legal, cuánto tiempo los conserva, y poder atender un derecho de supresión. Si no se sabe dónde está el email de un cliente, no se puede borrar cuando lo pida.

El coste del desconocimiento es proporcionalmente mayor. En una empresa grande hay redundancia: si alguien se va, otro sabe. En AlpinaShop, si Lucía se va, el conocimiento de la plataforma se va con ella. La documentación no es burocracia, es continuidad.

Los errores llegan antes a dirección. Con tres personas y un cuadro de mando, un dato mal calculado no pasa por ningún filtro intermedio. Va directo a una decisión.

Y el momento correcto es ahora. Gobernar dieciséis tablas es un trabajo de tarde. Gobernar doscientas, después de tres años de crecimiento desordenado, es un proyecto de meses. La deuda de gobierno se acumula con intereses.

Dataplex es la capa de gestión unificada de datos de Google Cloud. Su idea central: los datos de una organización están repartidos entre BigQuery, Cloud Storage y otros sistemas, y hace falta una capa lógica por encima que los organice, los describa y les aplique políticas comunes sin moverlos.

Su jerarquía:

Las zonas tienen dos tipos con semántica distinta:

• Raw: datos en su formato original, sin validar. Cualquier formato.
• Curated: datos ya limpios y estructurados, con esquema. Solo formatos estructurados (Parquet, Avro, ORC) o tablas de BigQuery. Dataplex valida que lo que se registra aquí cumple.

Creación:

La opción --discovery-enabled es la que aporta valor inmediato: Dataplex rastrea automáticamente los activos, infiere esquemas de los ficheros del bucket, detecta particiones por la estructura de carpetas, y crea tablas externas de BigQuery para que esos ficheros sean consultables con SQL sin que nadie las declare.

Para AlpinaShop eso significa que los Parquet que el trabajo de Spark deja en gs://alpinashop-datalake/resultados/cesta/ aparecen como tabla consultable sin trabajo adicional. Es descubrimiento automático de datos, y es la razón práctica de registrar los buckets aunque el gobierno formal no interese.

El Universal Catalog de Dataplex —heredero de Data Catalog— indexa automáticamente los metadatos de BigQuery, Cloud Storage, Pub/Sub, Spanner y Bigtable de toda la organización. Y sobre ese índice hay un buscador.

La sintaxis de búsqueda:

Desde la línea de comandos:

Esa consulta responde en segundos a una pregunta que sin catálogo requiere abrir tabla por tabla: ¿dónde hay emails? Es el primer paso del apartado 8.

La respuesta a la pregunta de marketing —"¿dónde está el dato de conversión?"— pasa de "pregúntale a Lucía" a buscar conversion en el catálogo y encontrar agg_embudo_dia con su descripción. Ese cambio es todo el valor del catálogo.

El catálogo indexa lo que existe, pero no sabe lo que significa. Para eso están las etiquetas (tags), que añaden metadatos de negocio a tablas y columnas, estructurados según una plantilla.

Primero la plantilla, que define qué campos se documentan y con qué valores permitidos:

Y ahora se etiqueta cada tabla:

Ese campo definicion_negocio es la solución al segundo problema del inicio de la lección. Una frase escrita una vez elimina para siempre la discusión sobre si total_pedido lleva IVA. Y queda donde se busca, no en un documento que nadie abre.

La disciplina de etiquetado que AlpinaShop adopta:

La columna apto para informes es la más útil en el día a día: distingue lo que puede alimentar un cuadro de mando de lo que es fontanería. Sin ella, alguien acabará construyendo un informe de dirección sobre pedidos_staging, que se vacía cada noche.

Antes de definir reglas de calidad hay que saber cómo son los datos. El perfilado de Dataplex analiza una tabla y produce estadísticas por columna: valores nulos, distintos, mínimos, máximos, medias, percentiles y los valores más frecuentes.

Un perfil típico revela cosas que nadie sospechaba:

Tres hallazgos accionables en una sola pasada: el 12 % de compras sin cliente identificado (que puede ser normal o puede ser un fallo del registro), la inconsistencia de mayúsculas en canal que rompe cualquier GROUP BY, y un total_pedido negativo, que probablemente sea un abono mal modelado y que está distorsionando todas las medias.

Ese último es el ejemplo perfecto de por qué el perfilado va antes que las reglas: la regla "total nunca negativo" no se inventa, se descubre.

Con el perfil en la mano se definen las reglas. Un escaneo de calidad ejecuta un conjunto de comprobaciones y da un resultado de aprobado o fallido con el detalle por regla.

Las seis dimensiones de calidad estándar, con su interpretación en AlpinaShop:

Qué hacer cuando una regla falla. Esta es la parte que más se descuida, y sin ella el escaneo es decorativo:

La integración con el orquestador de 04-06 cierra el círculo:

Con fail_on_dq_failure=True, un fallo de calidad detiene el proceso nocturno antes de propagar datos malos al cuadro de mando. Es la versión industrializada de la comprobación de calidad que escribimos a mano en 04-06.

En 04-05 vimos el linaje de Data Fusion, limitado a sus pipelines. Dataplex Lineage lo hace de forma transversal: captura automáticamente el linaje de BigQuery (cada consulta que escribe en una tabla), Dataflow, Data Fusion, Composer y Dataproc.

Y ya está: a partir de ahí, cada trabajo registra su linaje solo.

El grafo completo de AlpinaShop, que Dataplex construye sin que nadie lo dibuje:

Las preguntas que este grafo responde en un clic:

• "El margen del informe sale raro. ¿De dónde viene?" → agg_ventas_categoria_dia ← lineas_pedido + costes_producto_erp ← Datastream ← MySQL del ERP. En cuatro saltos se llega al origen.
• "Vamos a cambiar el esquema del ERP. ¿Qué se rompe?" → Todo lo que cuelga de costes_producto_erp, incluido el cuadro de mando de dirección.
• "Un cliente ejerce su derecho de supresión. ¿Dónde está su dato?" → Se rastrea pedidos hacia adelante y aparecen todas las tablas derivadas.
• "¿Podemos apagar la exportación nocturna de Cloud SQL?" → El grafo muestra que pedidos_staging depende de ella. No.

Esa última pregunta es la que más dinero ahorra en la práctica: saber qué se puede apagar. Toda plataforma de datos con dos años acumula procesos que ya no alimentan nada, y sin linaje nadie se atreve a tocarlos.

Aviso de RGPD. Este apartado y el siguiente tratan datos personales. Las herramientas que se describen son controles técnicos, no un dictamen jurídico. Determinar la base legal de un tratamiento, los plazos de conservación, la necesidad de una evaluación de impacto o si una seudonimización es suficiente corresponde a un profesional de compliance o al delegado de protección de datos, y debe hacerse antes de poner nada en producción. Todos los datos de este curso son ficticios.

Sensitive Data Protection —el servicio antes conocido como Cloud DLP— hace dos cosas: inspeccionar para descubrir dónde hay datos sensibles, y desidentificar para que dejen de serlo.

Empecemos por la inspección, que responde al tercer problema del inicio de la lección: ¿hay emails de clientes en sitios donde no debería haberlos?

Un trabajo de inspección sobre todo el dataset:

Dos decisiones deliberadas en esa configuración:

• includeQuote: false: los hallazgos no incluyen el valor encontrado. Si lo pusieras en true, la tabla de hallazgos contendría los emails reales, es decir, habrías creado una copia sin proteger de los datos que intentas proteger. Es un error clásico y grave.
• rowsLimitPercent: 10: para descubrir si hay datos sensibles no hace falta escanear el 100 %. Un muestreo del 10 % encuentra el problema y cuesta la décima parte.

Y una consulta sobre los hallazgos:

Resultado típico en AlpinaShop, y por qué duele:

Cuatro de los cinco hallazgos son sorpresas. Ninguno es fruto de mala fe: son consecuencias naturales de mover datos. La suscripción de BigQuery de 04-04 vuelca el mensaje entero. El transportista escribe lo que quiere en el campo de incidencia. Los clientes ponen su teléfono en una opinión. Y una IP, que parece técnica, es dato personal.

Esto es exactamente lo que ninguna organización sabe sin inspeccionar. Y es la razón por la que este apartado existe.

Para hacerlo continuo, Dataplex ofrece perfilado de datos sensibles a nivel de organización, que escanea automáticamente todo BigQuery y mantiene un inventario actualizado de dónde hay datos sensibles y con qué nivel de riesgo, sin lanzar trabajos a mano.

Descubierto el problema, hay que actuar. Las técnicas, de menor a mayor utilidad conservada:

La distinción crítica es entre hash y tokenización determinista:

• El hash con clave produce el mismo resultado para el mismo valor, así que permite contar y agrupar clientes distintos, pero no se puede volver atrás. Es lo correcto para analítica pura.
• La tokenización determinista con preservación de formato produce un token que parece un email y se puede revertir con la clave. Es lo correcto cuando un sistema autorizado necesita recuperar el valor original.

Configuración de desidentificación para AlpinaShop:

Qué hace cada transformación:

• email_cliente → hash con clave envuelta en KMS. Reutiliza clave-pedidos del keyring alpinashop-keyring creado en 03-06. La clave nunca sale de KMS, así que ni siquiera quien tenga acceso a la tabla puede revertir el hash. Lucía sigue pudiendo contar clientes únicos con COUNT(DISTINCT email_hash).
• codigo_postal → enmascarado de los 3 últimos. 08013 se convierte en 08XXX. Se conserva la provincia, que es lo que sirve para el análisis geográfico, y se pierde la calle, que es lo que identifica.
• texto_opinion → sustitución por tipo dentro del texto libre. "Llamadme al 611223344, soy Ana" se convierte en "Llamadme al [PHONE_NUMBER], soy [PERSON_NAME]". La opinión sigue siendo analizable —incluido el análisis de sentimiento del módulo 5— sin datos personales dentro.

La última es la más valiosa y la que ninguna otra herramienta hace bien: desidentificar dentro de texto libre, donde el dato personal no está en una columna sino incrustado en una frase.

Y la vista que expone Lucía y el cuadro de mando:

El principio operativo: los datos personales existen en la tabla base, protegida y con acceso restringido a gcp-seguridad@; todo lo demás —analítica, cuadros de mando, exploración— consume vistas desidentificadas. La minimización no es una limpieza puntual, es una arquitectura.

Looker Studio (antes Data Studio) es la herramienta gratuita de visualización de Google. Se conecta a BigQuery y a decenas de orígenes, y permite construir informes interactivos sin código.

Hay tres formas de conectarlo a BigQuery, y elegir bien determina el coste y el rendimiento:

La regla de oro: nunca conectes Looker Studio directamente a una tabla de detalle grande. Conéctalo a una tabla agregada o a una vista materializada. Un cuadro de mando con seis gráficos que consulta lineas_pedido ejecuta seis consultas cada vez que alguien cambia un filtro, y con diez usuarios refrescando, la factura de BigQuery se dispara —exactamente el escenario del ejercicio 3 de 04-01.

Para AlpinaShop, el origen del cuadro de mando será una tabla preparada por el proceso nocturno:

Esa tabla tiene unos pocos miles de filas —dos años × 3 canales × 14 países × 6 categorías— frente a los millones de lineas_pedido. Consultarla es prácticamente gratis.

Los campos calculados de Looker Studio se definen sobre el origen y se comportan como columnas:

Consejo de modelado: define los campos calculados en la vista de BigQuery, no en Looker Studio, siempre que puedas. Un campo definido en SQL está versionado en Git, es reutilizable por otros informes y por Spark, y no se pierde si alguien duplica el informe. Un campo definido en Looker Studio vive dentro de ese informe y nadie más lo ve.

Diseñemos el informe que dirección lleva pidiendo desde el módulo 3.

Estructura en tres páginas:

Los indicadores clave, con su definición explícita —que es lo que evita la discusión de "este número no es el que yo tenía":

El coste de adquisición merece una nota honesta: requiere un dato que AlpinaShop no tiene todavía en la plataforma —la inversión mensual en publicidad—. Hay dos opciones: cargarlo como una tabla manual mantenida por marketing, o integrarlo desde la API de la plataforma publicitaria. La primera es la sensata para empezar. Y hay que mostrarlo en el informe indicando de dónde sale, porque un indicador cuyo origen nadie conoce acaba desacreditando al resto.

Buenas prácticas de diseño, que son las que separan un informe que se usa de uno que se abre una vez:

• Lo más importante arriba a la izquierda. Es donde va la vista.
• Cuatro tarjetas de indicador, no doce. Un cuadro de mando con veinte cifras no se lee: se ignora.
• Comparación siempre. Un número sin contexto no informa. 42.180 € no dice nada; +12,4 % frente al mes anterior sí.
• Un tipo de gráfico por pregunta: línea para evolución, barras para comparar categorías, tabla para el detalle. Nada de gráficos de tarta con doce porciones.
• Filtros arriba y comunes a la página, no repartidos por los gráficos.
• Colores con significado y accesibles: verde y rojo tienen sentido para bueno y malo, pero hay que asegurarse de que se distinguen también para daltónicos, añadiendo flechas o signos además del color.
• Fecha de última actualización visible. Un informe sin ella genera desconfianza y llamadas.
• Una nota metodológica al pie. Dónde se define cada indicador. Es la diferencia entre un informe y una discusión.

Los tres mecanismos, en orden de coste creciente:

1. Extracción de datos. Looker Studio copia hasta un límite de datos en su propia caché y los sirve desde ahí. Refresco programable de hasta una vez al día. Coste de BigQuery prácticamente nulo, rendimiento excelente. Es la opción por defecto para un informe con datos agregados que no necesita ser de hoy mismo.

2. Consulta viva con caché. Looker Studio cachea los resultados durante un tiempo configurable (hasta 12 horas). Con la caché activada, diez personas mirando el mismo informe generan una consulta, no diez. Es lo que debe usarse en un cuadro de mando compartido.

3. BI Engine. Un servicio de aceleración en memoria de BigQuery. Se reserva una capacidad y las consultas que caben en ella se responden en milisegundos y sin coste de bytes escaneados.

Con la tabla bi_resumen_diario, que ocupa unos pocos megabytes, 2 GB de BI Engine caben de sobra: el cuadro de mando entero se sirve desde memoria, con latencia de milisegundos y sin facturar escaneo. El coste de la reserva es del orden de unos pocos euros al mes, y suele salir más barato que pagar las consultas que evita.

Comprobar que BI Engine se está usando:

Si modo es FULL, la consulta se resolvió íntegramente en memoria. Si es DISABLED o PARTIAL, el campo bi_engine_statistics.acceleration_mode explica por qué —normalmente porque la consulta usa una función no soportada o la tabla no cabe.

La receta completa de AlpinaShop, resumida: tabla agregada pequeña + caché activada + BI Engine + informe conectado a la vista desidentificada. Coste mensual del cuadro de mando: unos pocos euros. Sin esa disciplina, los mismos gráficos costarían cientos.

Aquí está el error más peligroso de toda la lección, y ocurre constantemente porque la interfaz lo pone fácil.

Cuando se crea un origen de datos en Looker Studio hay que elegir con qué credenciales se ejecutan las consultas:

El escenario del desastre, paso a paso:

1. Lucía crea el cuadro de mando conectado a BigQuery con credenciales del propietario. Es lo cómodo, y es lo que la interfaz sugiere.
2. Lucía tiene, además de acceso a los agregados, permiso de lectura sobre pedidos completo.
3. Lucía comparte el informe con "cualquier persona con el enlace" para que un proveedor externo vea un gráfico.
4. Ese proveedor —o cualquiera a quien reenvíen el enlace— puede explorar los datos con los permisos de Lucía. Puede añadir campos, cambiar dimensiones y, si el origen es una tabla con datos personales, verlos.
5. Nadie en BigQuery le ha dado ningún permiso a esa persona. Los permisos de BigQuery no lo protegen, porque las consultas no se hacen en su nombre.

Eso es una brecha de datos personales con obligación de notificación bajo el RGPD.

Las reglas que AlpinaShop adopta, sin excepción:

1. El origen apunta siempre a una vista desidentificada y autorizada, nunca a una tabla con datos personales. Aunque el modo de credenciales sea el equivocado, no hay nada sensible detrás. Esta es la defensa que no depende de que nadie se acuerde.
2. Credenciales del espectador en cualquier informe que salga del equipo de datos.
3. Nunca "cualquier persona con el enlace" para informes con datos de negocio. Compartir siempre con personas o grupos concretos (gcp-datos@, direccion@).
4. Revisión trimestral de con quién están compartidos los informes. Los permisos se acumulan solos.
5. Si hace falta credenciales del propietario —porque los espectadores no tienen ni deben tener permisos de BigQuery—, entonces el origen tiene que ser una vista agregada sin ningún dato personal ni confidencial. Sin negociación.

Verificación desde BigQuery de quién está consultando desde Looker Studio:

Si en esa lista aparece una sola dirección de correo —la de Lucía— cuando el informe lo miran quince personas, estás en modo credenciales del propietario. Es la comprobación de treinta segundos que conviene hacer hoy.

Looker (sin "Studio") es un producto distinto y mucho más caro. Su diferencia esencial es LookML, un lenguaje de modelado donde se define una sola vez qué significa cada métrica y cada dimensión, y todos los informes de la empresa consumen esas definiciones.

Cuándo justifica su precio: cuando el coste de la incoherencia supera el coste de la licencia. Es decir, cuando hay decenas de analistas creando informes, cuando "ventas" significa cosas distintas en tres departamentos y las reuniones se dedican a discutir de quién es el número bueno, o cuando se necesita gobierno del modelo semántico con revisión por pull request.

Para AlpinaShop, Looker Studio es la respuesta obvia: tres personas, un cuadro de mando, presupuesto de pyme. La coherencia se garantiza con la disciplina del apartado 10 —definir las métricas en vistas de BigQuery versionadas en Git— que es el 80 % del valor de LookML por el 0 % del precio.

Organización y descubrimiento

• [ ] Todos los datasets y buckets registrados en un lago de Dataplex con sus zonas.
• [ ] Descubrimiento automático activado en los activos de Cloud Storage.
• [ ] Toda tabla con description y con etiquetas de gobierno.
• [ ] Distinción explícita entre tablas aptas para informes y tablas de fontanería.
• [ ] Cada tabla con un propietario nombrado.

Calidad

• [ ] Perfilado ejecutado sobre las tablas principales.
• [ ] Reglas de calidad definidas para completitud, unicidad, validez, exactitud y frescura.
• [ ] Escaneos programados diariamente.
• [ ] El orquestador bloquea el proceso si falla una regla crítica.
• [ ] Resultados históricos exportados a BigQuery para ver la tendencia.

Linaje

• [ ] API de linaje activada.
• [ ] Grafo revisado tras cada cambio de arquitectura.
• [ ] Procesos sin consumidores identificados y apagados.

Seguridad y privacidad

• [ ] Inspección de datos sensibles ejecutada sobre todo el dataset, no solo donde se sospecha.
• [ ] Columnas con datos personales etiquetadas con política de acceso.
• [ ] Vistas desidentificadas como única superficie de exposición analítica.
• [ ] Ninguna herramienta de BI conectada a una tabla con datos personales.
• [ ] Claves de hash y tokenización en KMS, nunca en el código.
• [ ] Revisión por un profesional de compliance o el DPO antes de producción.

Coste

• [ ] Tablas particionadas y clusterizadas; require_partition_filter en las grandes.
• [ ] Cuadros de mando conectados a agregados, nunca a tablas de detalle.
• [ ] Caché de informes activada; BI Engine si compensa.
• [ ] Presupuestos y alertas por etiqueta de centro de coste.
• [ ] Nada permanentemente encendido que no lo necesite: sin clústeres de Dataproc olvidados, sin instancias de Data Fusion encendidas, sin pipelines de streaming huérfanos.
• [ ] Auditoría periódica de consultas caras con INFORMATION_SCHEMA.

Operación

• [ ] Todos los procesos orquestados, ninguno en un cron de una VM.
• [ ] Tareas idempotentes; reprocesos seguros.
• [ ] Alertas que llegan a una persona concreta, no a un correo genérico.
• [ ] Código —DDL, DAG, pipelines, flujos— versionado en Git.
• [ ] Documentación de qué hace cada proceso y a quién avisar.

Documentar solo al principio. Un catálogo con etiquetas de hace un año es peor que ninguno, porque genera confianza injustificada. Documentar debe ser parte de crear la tabla, no un proyecto aparte.

Poner reglas de calidad sin perfilar antes. Se acaban definiendo umbrales inventados que fallan a diario, todo el mundo ignora las alertas, y el sistema deja de servir. Perfila, mira los datos reales, y luego define.

Reglas de calidad que no bloquean nada. Si un fallo de calidad no detiene el proceso ni avisa a nadie, es decoración.

Inspeccionar con includeQuote: true. Se crea una tabla de hallazgos que contiene los datos sensibles que se querían proteger. Es empeorar el problema.

Confundir hash con anonimización. Un hash sin sal ni clave de un email es reversible por fuerza bruta —el espacio de emails plausibles no es tan grande—. Sigue siendo dato personal a efectos del RGPD. La clave debe estar en KMS.

Conectar Looker Studio a una tabla de detalle. Cada filtro dispara consultas sobre millones de filas. Es el camino directo a una factura sorpresa.

Credenciales del propietario más enlace público. El error más grave de la lección. Cualquiera con el enlace consulta con los permisos del propietario.

No poner la fecha de actualización en el informe. Genera desconfianza, llamadas y decisiones basadas en datos de la semana pasada creyendo que son de hoy.

Definir las métricas en Looker Studio en vez de en BigQuery. Se quedan encerradas en ese informe, no se versionan, y al duplicarlo divergen.

Consejo: escribe la definición de negocio de cada métrica y publícala. La mitad de las discusiones sobre datos son discusiones sobre definiciones, no sobre números.

Consejo: pon un enlace al catálogo en el pie del cuadro de mando. Quien quiera saber qué significa un número, que pueda llegar solo.

Consejo: haz la inspección de datos sensibles hoy, no cuando haya un incidente. Cuesta una tarde y casi siempre encuentra algo que nadie sabía.

Para la tabla alpinashop_analitica.opiniones: (a) escribe el comando que la registra como activo en la zona curada del lago; (b) crea la etiqueta de gobierno indicando propietario, dominio, sensibilidad, frescura, retención, aptitud para informes y una definición de negocio precisa; (c) define un escaneo de calidad con al menos cinco reglas que cubran completitud, unicidad, validez de rango, conjunto de valores y una regla SQL propia; (d) explica qué acción tomarías ante el fallo de cada regla.

El campo texto de opiniones es texto libre escrito por clientes. Diseña: (a) el trabajo de inspección que descubra qué tipos de datos personales contiene, con las opciones correctas para no crear una copia de los datos sensibles; (b) la plantilla de desidentificación que permita conservar el texto analizable —para el análisis de sentimiento del módulo 5— eliminando los datos personales; (c) la vista que se expondría a Looker Studio; (d) la advertencia de RGPD que acompañaría la propuesta antes de llevarla a producción.

El cuadro de mando de dirección lleva dos meses funcionando y hay cuatro problemas. Uno: tarda 40 segundos en cargar y el coste de BigQuery del proyecto ha pasado de 12 € a 310 € al mes. Dos: INFORMATION_SCHEMA muestra que todas las consultas del informe las hace [email protected], aunque lo miran doce personas. Tres: el informe está compartido como "cualquier persona con el enlace" porque hubo que enseñárselo a un consultor externo. Cuatro: dirección dice que el número de ventas del informe no coincide con el de contabilidad.

Diagnostica cada problema, indica su gravedad relativa y propón la solución concreta con el orden de actuación.

Solución 1

(a) Registrar el activo. La tabla ya está dentro del dataset alpinashop_analitica, que se registró completo como activo activo-analitica en zona-curada. Por tanto no hay que registrar la tabla individualmente: Dataplex la descubre al rastrear el dataset. Si se quisiera un activo separado —por ejemplo, para un dataset distinto— sería:

(b) Etiqueta de gobierno.

sensibilidad: datos-personales y apto_para_informes: false son las dos decisiones clave: aunque el campo texto parezca inocuo, es texto libre y por tanto imprevisible.

(c) Escaneo de calidad.

(d) Acción ante cada fallo:

Solución 2

(a) Inspección.

Las tres decisiones que se evalúan:

• includeQuote: false: sin esto, la tabla hallazgos_dlp_opiniones contendría los teléfonos y nombres reales encontrados. Se habría creado una segunda copia sin proteger de exactamente lo que se quiere proteger.
• minLikelihood: POSSIBLE en lugar de LIKELY: en texto libre escrito por personas, los datos aparecen en formatos irregulares ("llamadme al seis once..."). Un umbral bajo genera más falsos positivos, que es preferible a no detectar un dato real. En una columna estructurada se usaría LIKELY.
• identifyingFields: permite saber qué opinión contiene el hallazgo sin guardar el valor, lo que hace el resultado accionable.

(b) Plantilla de desidentificación.

Por qué replaceWithInfoTypeConfig y no supresión. Sustituye cada hallazgo por su tipo entre corchetes:

• Original: "Muy comoda. Si teneis dudas escribidme a [email protected] o al 611223344, soy Ana Ruiz"
• Resultado: "Muy comoda. Si teneis dudas escribidme a [EMAIL_ADDRESS] o al [PHONE_NUMBER], soy [PERSON_NAME]"

El texto sigue siendo analizable. La opinión conserva su estructura, su longitud aproximada y —lo importante para el módulo 5— su sentimiento: "Muy cómoda" sigue ahí. Con supresión pura se perdería la coherencia sintáctica y el análisis de sentimiento se degradaría.

(c) Vista expuesta.

El pipeline nocturno escribe en opiniones_desidentificadas aplicando la plantilla, y la tabla original opiniones queda con acceso restringido a gcp-seguridad@. Looker Studio, Lucía y los futuros modelos del módulo 5 consumen exclusivamente la vista.

(d) Advertencia de RGPD.

Las opiniones de clientes contienen datos personales, tanto en campos estructurados (pais combinado con sku y fecha puede ser reidentificable si el volumen es bajo) como incrustados en texto libre. Esta propuesta aplica dos medidas técnicas: desidentificación automática del texto mediante Sensitive Data Protection y restricción de acceso a la tabla original.

Antes de pasar a producción es necesario que un profesional de compliance o el delegado de protección de datos determine: la base legal del tratamiento analítico de las opiniones; si la desidentificación aplicada constituye anonimización efectiva o mera seudonimización —lo que determina si el RGPD sigue aplicando al resultado—; el plazo de conservación adecuado; el riesgo de reidentificación por combinación de campos aparentemente no identificativos; y si el uso previsto en el módulo 5 (análisis de sentimiento) requiere información adicional al interesado. La desidentificación automática no es infalible: un cliente que escriba "soy el que compró la mochila azul el martes en la tienda de Sabadell" no será detectado por ningún tipo de dato predefinido. Todos los datos de este curso son ficticios.

Solución 3

Gravedad relativa, de mayor a menor:

Problema 3 (enlace público) + Problema 2 (credenciales del propietario) = INCIDENTE DE SEGURIDAD. No son dos problemas: son uno solo y grave. Que todas las consultas las haga Lucía significa modo credenciales del propietario. Combinado con "cualquier persona con el enlace", cualquiera que tenga o reciba ese enlace consulta BigQuery con los permisos de Lucía, que incluyen la tabla pedidos con email_cliente. Si el consultor externo reenvió el enlace, o si acabó en un correo o un chat, hay una posible brecha de datos personales con obligación de notificación. Se actúa primero, hoy, en minutos.

Problema 4 (el número no cuadra con contabilidad) = CRISIS DE CONFIANZA. Es el segundo en gravedad porque destruye el valor de todo lo construido. Un cuadro de mando en el que dirección no confía deja de usarse, y el trabajo de siete lecciones se pierde.

Problema 1 (lento y caro) = OPERATIVO. 310 € al mes duelen, pero no comprometen ni la seguridad ni la confianza. Se arregla en una tarde.

Actuación en tres fases:

Fase 1 — Hoy, en minutos: cortar la exposición.

Y en paralelo: avisar al responsable de seguridad y al DPO. La valoración de si esto constituye una brecha notificable bajo el RGPD no la toma el equipo técnico. Hay que documentar qué datos eran accesibles, durante cuánto tiempo y a quién se compartió el enlace.

Fase 2 — Esta semana: recuperar la confianza en el número.

La discrepancia con contabilidad tiene tres causas candidatas, y hay que determinar cuál es antes de tocar nada:

Casi con total seguridad, contabilidad usa la definición C —ventas netas sin IVA— y el informe muestra la A. No es un error de datos: es un error de definición no documentada, exactamente el segundo problema del inicio de esta lección.

La corrección:

1. Acordar con contabilidad una definición canónica y escribirla.
2. Implementarla en la tabla bi_resumen_diario, exponiendo ambas magnitudes con nombres inequívocos: ventas_brutas_iva_incl y ventas_netas_sin_iva.
3. Escribirla en la etiqueta definicion_negocio del catálogo de Dataplex.
4. Añadir una nota metodológica visible al pie del cuadro de mando.

Fase 3 — Este mes: coste y rendimiento.

El diagnóstico primero:

El resultado esperado: el informe está conectado directamente a lineas_pedido o a pedidos, y cada uno de los ocho gráficos ejecuta su propia consulta cada vez que alguien mueve un filtro. Doce personas × varios filtros al día × ocho gráficos = miles de consultas sobre millones de filas.

Las cuatro correcciones, por orden de impacto:

1. Repuntar el informe a bi_resumen_diario, la tabla agregada de unos pocos miles de filas que produce el proceso nocturno. Sola, esta medida suele dividir el coste por cien y bajar la carga de 40 segundos a menos de 3.
2. Activar la caché del informe con 12 horas de vigencia. Doce personas mirando generan una consulta, no doce.
3. Reservar 2 GB de BI Engine. La tabla agregada cabe entera en memoria: respuesta en milisegundos y cero bytes facturados.
4. Poner una cuota diaria de bytes en el proyecto y una alerta de presupuesto sobre la etiqueta centro-coste:analitica, para que un problema equivalente se detecte a los 20 € y no a los 310 €.

Resultado esperado: de 310 €/mes a menos de 10 €, y de 40 segundos a menos de 3.

La lección transversal del ejercicio: los cuatro problemas eran evitables con lo que ya sabíamos. El coste, con lo de 04-01. Los permisos, con lo de 03-04 y el apartado 13. La discrepancia de definiciones, con el etiquetado del apartado 4. Ninguno era un fallo técnico difícil: los cuatro eran fallos de gobierno.

El módulo 4 se cierra aquí, y se cierra con la plataforma completa.

Has entendido qué es el gobierno del dato —catálogo, linaje, calidad, clasificación y ciclo de vida— y por qué una pyme lo necesita igual o más que una multinacional: el RGPD no distingue por tamaño, el conocimiento no tiene redundancia cuando el equipo son tres personas, los errores llegan a dirección sin filtros intermedios, y la deuda de gobierno se acumula con intereses.

Has organizado la plataforma en Dataplex: el lago alpinashop-lago-comercial con su zona cruda y su zona curada, con los buckets y el dataset registrados como activos y con descubrimiento automático que convierte los Parquet de Spark en tablas consultables sin declarar nada. Has usado el catálogo universal para responder en segundos a "¿dónde está el dato de conversión?" y a "¿dónde hay columnas que se llamen email". Y has documentado con una plantilla de etiquetas que obliga a declarar propietario, dominio, sensibilidad, frescura, retención, aptitud para informes y —lo más valioso— la definición de negocio, esa frase escrita una vez que zanja para siempre si total_pedido incluye IVA.

Has perfilado las tablas antes de juzgarlas, descubriendo lo que nadie sospechaba: un 12 % de pedidos sin cliente, cinco valores en canal donde debía haber tres, y un total_pedido negativo que distorsionaba todas las medias. Y sobre ese conocimiento has definido reglas de calidad en las seis dimensiones, con umbrales, con exportación de resultados y —esto es lo que las hace útiles— con una acción asignada a cada fallo y con integración en el orquestador para que un fallo crítico detenga el proceso antes de propagar datos malos.

Has activado el linaje automático y tienes el grafo completo desde Cloud SQL y el ERP de Sabadell hasta el cuadro de mando, capaz de responder de dónde viene un número, qué se rompe si cambias un esquema, dónde está el dato de un cliente que ejerce su derecho de supresión, y qué proceso se puede apagar sin miedo.

Has inspeccionado con Sensitive Data Protection y has encontrado lo que siempre se encuentra: emails en el volcado crudo de Pub/Sub, nombres en el campo de incidencias del transportista, teléfonos dentro de opiniones de clientes, e IP en los datos de navegación. Cuatro sorpresas de cinco hallazgos, ninguna por mala fe. Y has desidentificado con criterio: hash con clave de KMS para poder contar clientes sin saber quiénes, enmascarado del código postal conservando la provincia, y sustitución por tipo dentro del texto libre para que las opiniones sigan siendo analizables sin datos personales dentro. Con la advertencia expresa, repetida donde tocaba, de que esto son controles técnicos y de que la decisión jurídica corresponde a un profesional de compliance o al DPO.

Y has construido por fin el cuadro de mando que dirección pedía: conectado a una tabla agregada pequeña y no a la tabla de detalle, con caché, con BI Engine, con campos calculados definidos en SQL versionado y no encerrados en el informe, con cuatro indicadores y no doce, con comparación siempre, con fecha de actualización visible y con nota metodológica al pie. Y con la lección de permisos que vale por sí sola toda la lección: credenciales del espectador, compartición con personas concretas, y el origen apuntando siempre a una vista desidentificada, porque es la única defensa que no depende de que nadie se acuerde. Sabes cuándo Looker con LookML justifica su precio —cuando el coste de la incoherencia supera el de la licencia— y por qué AlpinaShop no está en ese caso.

Mira lo que existe ahora y que no existía hace siete lecciones. Los pedidos entran por Pub/Sub sin acoplar la tienda a nada. Dataflow los transforma en lote y en streaming, con el tiempo del evento bien entendido. Dataproc calcula lo algorítmico en clústeres que viven cuatro minutos. Data Fusion trae lo que llega sucio de fuera. BigQuery lo guarda y lo responde en segundos, particionado, clusterizado y sin arruinar a nadie. Workflows lo orquesta cada noche con comprobaciones que bloquean si algo no cuadra. Dataplex lo cataloga, lo mide y lo rastrea. Y Looker Studio lo enseña. AlpinaShop ha pasado de no saber qué mochila se vende más en Cataluña a tener una plataforma de datos gobernada por la que Lucía no le pide nada a nadie.

Pero fíjate en lo que todo esto tiene en común: describe lo que ya pasó. Cuenta las ventas de ayer, el embudo del mes, el margen del trimestre, qué productos se compraron juntos. Es memoria, y la memoria es valiosísima. No es predicción, y no es automatización.

Y AlpinaShop tiene ahora mismo cuatro preguntas que la memoria no puede responder. Cuando un cliente mete unos crampones en el carrito, ¿qué debería sugerirle la web en ese instante, aprovechando la matriz de coocurrencia que calculó Spark? Cuando entran 60 GB de imágenes nuevas al catálogo, ¿tiene que etiquetarlas alguien a mano o puede la máquina decir "esto es una mochila azul de 40 litros"? Con 8.000 opiniones en texto libre ya desidentificadas, ¿alguien las va a leer todas para saber qué falla en los frontales? Y con 2.400 fichas de producto que describir, ¿quién las escribe?

En el módulo 5, Aprendizaje automático e IA, AlpinaShop pasa de describir a predecir y automatizar. Empezaremos por 05-01, Vertex AI, la plataforma que unifica todo el ciclo de vida del modelo —datos, entrenamiento, evaluación, despliegue y monitorización— y que conectará directamente con el dataset alpinashop_analitica que acabas de gobernar. Después llegarán AutoML para entrenar sin escribir código, TensorFlow para cuando haga falta control total, las API de lenguaje natural y de visión que responden a las preguntas de las opiniones y de las imágenes sin entrenar nada, la IA generativa con Gemini para las descripciones, y MLOps con Vertex AI Pipelines para que un modelo no sea un experimento en el portátil de alguien sino un sistema de producción con la misma disciplina de idempotencia, calidad, linaje y coste que has aplicado en todo este módulo.

Los datos ya están limpios, gobernados, documentados y consultables. Eso no era el objetivo: era el requisito. Ahora empieza lo interesante.