El pipeline está completo: ingesta, casa, transformación, orquestación, calidad, y los cuatro consumidores de IA alimentados. El módulo final se ocupa de que sobreviva a la organización — al analista nuevo que no sabe qué tabla usar, al cambio que rompe consumidores desconocidos, a la auditoría que pregunta quién accede a qué, y a la factura que crece sin que nadie sepa por qué. Gobernanza no es el comité que frena: es el conjunto de respuestas automáticas a cuatro preguntas que, sin sistema, se responden con arqueología.

La tesis del módulo

Cuatro preguntas definen la gobernanza — ¿qué datos existen y qué significan? (catálogo), ¿de dónde viene esto y a quién rompo si lo cambio? (linaje), ¿quién puede ver qué, según lo que contiene? (clasificación y acceso), ¿cuánto cuesta y qué palanca lo baja? (FinOps) — y la buena noticia de este curso es que las dos primeras se cosechan casi gratis de la disciplina ya construida: el linaje vive en los ref() de dbt y los assets del orquestador; el catálogo, en sus descripciones. La gobernanza cara es la que se instala después; la barata es la que el pipeline emite por diseño.

Catálogo y linaje: cosechar lo sembrado

El catálogo de datos responde “¿qué existe y qué significa?” — la diferencia entre el analista (o el agente con herramientas) que encuentra marts.metricas_triaje documentada con dueño, y el que le pregunta a un colega qué tabla usar y le llega la equivocada. La semilla ya está: las descripciones y dueños en los YAML del módulo 5 y el registro de features del 11. Las plataformas de catálogo (DataHub, OpenMetadata, los administrados de cada nube) agregan eso en una interfaz buscable — valen cuando la escala humana lo exige (decenas de consumidores, cientos de tablas); antes, el propio sitio de docs de dbt es el catálogo honesto del equipo chico.
El linaje de punta a punta responde las dos preguntas operativas más caras: hacia atrás — “¿de qué fuentes desciende este número/dataset/respuesta del RAG?” (la pregunta de la auditoría y del debugging) — y hacia adelante — “¿a quién rompo si cambio esta columna?” (la pregunta del análisis de impacto, que convierte el cambio sorpresivo en cambio anunciado — el contrato del módulo 7, ahora con mapa). Los ref() de dbt dan el linaje de transformación; los assets del módulo 6 lo extienden a ingesta y consumidores; el estándar OpenLineage lo unifica entre herramientas. Para IA, el linaje completo es además la trazabilidad que la reproducibilidad y el cumplimiento exigen: este modelo se entrenó con el dataset v14, que desciende de estos correos, bajo esta guía de anotación — una cadena consultable, no una reconstrucción forense.

Clasificación y acceso: quién ve qué, según qué contiene

La serie cloud dejó los mecanismos (IAM, llaves, políticas); este módulo aporta la capa de datos: el acceso se decide por lo que el dato contiene, y eso exige clasificarlo primero. El esquema mínimo que funciona: público / interno / confidencial / restringido (PII, datos regulados) — aplicado por columna y tabla como metadato (los tags de clasificación en el warehouse/catálogo), del que se derivan las reglas: el bronce con PII restringido a la service account del pipeline; la plata enmascarada, de acceso amplio; las columnas sensibles de oro tras enmascaramiento dinámico para quien no tiene el rol. Las tres verdades operativas: la clasificación es parte del contrato de entrada (la fuente declara qué trae — módulo 7); el enmascaramiento de PII del módulo 9 es la versión pipeline de esta política; y los consumidores de IA heredan la clasificación de sus insumos — el dataset destilado de correos confidenciales es confidencial, y el índice RAG que los contiene filtra por permisos (módulo 10) o es una fuga con búsqueda semántica.

El FinOps del pipeline: la factura con palancas

El FinOps de la serie cloud dio la disciplina (atribuir, ver, alertar, frenar); aquí, las palancas específicas de datos — porque el 80% del trabajo es también una factura con estructura conocida:

Rubro	La palanca	El módulo que la enseñó
Almacenamiento	Tiers por temperatura (caliente/frío/archivo) + TTL por capa: el bronce viejo a archivo, lo derivado reconstruible con retención corta	2, 4
Cómputo de consultas	Parquet particionado (leer menos es la palanca reina) + modelos incrementales	4, 5
Ingesta	Incremental vs. full extract + el NAT/egress de la nube vigilado	3
Embeddings	El diff por hash del RAG (re-embeber 2%, no 100%) + batch API para lotes	10
Orquestación	Corridas por SLA real (¿de verdad cada 5 minutos?) + assets que no se reconstruyen sin cambio	6

Y la regla de atribución de siempre: tags/labels por pipeline y por consumidor — para que “¿cuánto cuesta mantener el índice del RAG?” sea una fila del reporte y no un misterio — con el gasto de datos entrando al mismo dashboard operativo que el resto (la lección cloud: el gasto es métrica operativa, no arqueología mensual).

El mapa final: el curso en una pantalla

   EL PIPELINE COMPLETO Y SUS CONSUMIDORES DE IA

  fuentes ──► ingesta ──► lakehouse ──► dbt ──► calidad
  (m1-2)      (m3)        (m4)        (m5)     (m7)
                │                       │
                │  orquestador (m6)     │ dirige todo
                ▼                       ▼
        ┌───────────────────────────────────────┐
        │ CONSUMIDORES:                         │
        │ dataset entrenamiento (m8) ──► FT/ML  │
        │ corpus LLM (m9)            ──► FT     │
        │ índice RAG (m10)           ──► agentes│
        │ features (m11)             ──► ML prod│
        │ marts BI                   ──► negocio│
        └───────────────────────────────────────┘
        gobernanza (m12): catálogo · linaje ·
        clasificación · FinOps — sobre todo

El examen final del curso es el de la serie de nubes, versión datos: toma el caso de tu organización (o el del catálogo — los correos y el cotizador), dibuja este mapa con tus fuentes y consumidores, y marca qué etapa existe, cuál cojea y cuál falta. Ese diagnóstico — no las herramientas — es lo que este curso vino a instalar.

Errores comunes

Gobernanza como proyecto aparte. El comité que llega a ordenar lo que el pipeline no emitió: caro y tarde. Descripciones, dueños y ref() desde el día uno — la gobernanza barata es la sembrada.
Catálogo enterprise para equipo de cinco. La plataforma de catálogo sin masa crítica de consumidores es el feature-store-para-batch del módulo 11, versión metadatos. El sitio de dbt primero; la plataforma cuando la escala humana la pida.
Cambios sin análisis de impacto. Renombrar la columna y descubrir los consumidores por sus gritos. El linaje hacia adelante existe para preguntarle antes — y su respuesta alimenta el aviso del contrato.
Clasificar sin derivar reglas (o al revés). Tags de “confidencial” que no restringen nada, o permisos artesanales sin criterio de contenido. La clasificación genera las reglas de acceso, o es decoración.
Consumidores de IA exentos de la política. El dataset “de ML” con PII sin clasificar, el índice sin filtro de permisos: los consumidores más nuevos heredando las obligaciones más viejas — sin excepción por novedad.
La factura de datos sin estructura. “Data cuesta X al mes” sin rubros ni palancas es un número que solo crece. La tabla de palancas se recorre trimestre a trimestre — es FinOps, no fatalismo.

La frase para llevarse

“Cuatro preguntas gobiernan: qué existe, de dónde viene, quién lo ve, cuánto cuesta — y las dos primeras se cosechan gratis si sembraste disciplina. El modelo es commodity, el pipeline es el foso; y el foso gobernado — con catálogo, linaje, clasificación y palancas — es el que sobrevive a la organización que lo construyó.”

Qué viene

Aquí cierra el curso de Data Engineering — el eslabón entre “tengo un problema” y “entreno/recupero” que el catálogo pedía. Los caminos siguen según tu rol: MLOps para el ciclo del modelo que estos datos alimentan, Fine-tuning y RAG para los consumidores a fondo, y la serie de nubes para la infraestructura donde todo esto corre. El pipeline ya no es el eslabón que falta.

Data Engineering — Módulo 12: gobernanza, linaje y costo