7. Gobierno práctico de datos

Temas del programa: 3.4

El gobierno práctico no es burocracia

Es lo que permite responder “¿de quién es este dato y quién debe autorizar su cambio?”, la pregunta que nadie pudo responder al inicio de la unidad.

Calidad

Detectar problemas desde la operación

Responsables

Propietario, custodio y usuarios

Metadatos

Catálogo mínimo y diccionario operativo

Fuente: DAMA-DMBOK, marco profesional de gestión de datos. Aquí se trabaja su forma mínima operativa

Ejemplo guiado: calidad desde la operación

SELECT lower(correo) AS correo_normalizado, count(*) AS registros,
       string_agg(id::text, ', ') AS ids
FROM clientes GROUP BY lower(correo) HAVING count(*) > 1;

SELECT id, nombre, rfc FROM clientes
WHERE rfc IS NULL OR rfc !~ '^[A-ZÑ&]{3,4}[0-9]{6}[A-Z0-9]{3}$';

   correo_normalizado   | registros | ids
------------------------+-----------+------
 ana.lopez@example.test |         2 | 1, 7

 id |   nombre   |     rfc
----+------------+--------------
  7 | Ana Lopez  | LOAA850315AB
  8 | Jorge Díaz |

La expresión regular verifica el formato para la práctica. No valida el RFC ante el SAT

El DBA detecta, el propietario decide

El DBA

Ejecuta verificaciones, registra el hallazgo, propone una restricción (CHECK, UNIQUE) y lo escala

El propietario

Decide cuál es el valor correcto, si se fusionan los registros duplicados y si se agrega la restricción

Si el DBA corrige un dato, la tabla de auditoría debe dejar evidencia del cambio. Un hallazgo corregido sin registro desaparece del expediente.

Propietario, custodio y usuario

Figura	Responsabilidad	En clientes
Propietario (data owner)	Decide finalidad, acceso, corrección y eliminación	Gerencia Comercial
Custodio (data custodian)	Opera y protege según esas decisiones	DBA
Usuario	Usa el dato para una finalidad autorizada	Aplicación de ventas, soporte

pg_get_userbyid(relowner) devuelve postgres: es el propietario técnico del objeto, no el propietario del dato en la organización.

Catálogo y diccionario

Catálogo mínimo

¿Qué datos existen y dónde? Una fila por tabla o colección: ubicación, propietario, custodio, clasificación, finalidad, conservación.

Fuente: IBM, "What Is a Data Catalog?"

Diccionario operativo

¿Cómo está estructurado y qué significa? Una fila por columna: tipo, nulos, valor por defecto, descripción, clasificación.

Fuente: Oracle, "Data Dictionary and Dynamic Performance Views"

Ejemplo guiado: diccionario dentro del motor

COMMENT ON COLUMN clientes.rfc IS 'RFC del cliente. Dato personal. Uso: facturación. Cambios auditados en auditoria.cambios_clientes.';

SELECT c.column_name AS columna, c.data_type AS tipo, c.is_nullable AS acepta_nulos,
       col_description('public.clientes'::regclass, c.ordinal_position) AS descripcion
FROM information_schema.columns c
WHERE c.table_schema = 'public' AND c.table_name = 'clientes'
ORDER BY c.ordinal_position;

 columna |       tipo        | acepta_nulos |                     descripcion
---------+-------------------+--------------+------------------------------------------------------
 id      | bigint            | NO           | Identificador interno del cliente. Generado por el sistema.
 correo  | character varying | NO           | Correo de contacto. Dato personal. Uso: notificaciones al cliente.
 rfc     | character varying | YES          | RFC del cliente. Dato personal. Uso: facturación. Cambios auditados...

Fuente: documentación oficial de PostgreSQL, “COMMENT” e “information_schema.columns”

Ejemplo: exportar el diccionario a un archivo

psql -U postgres -d comercial --csv -c "SELECT c.column_name AS columna, c.data_type AS tipo, c.character_maximum_length AS longitud, c.is_nullable AS acepta_nulos, col_description('public.clientes'::regclass, c.ordinal_position) AS descripcion FROM information_schema.columns c WHERE c.table_schema = 'public' AND c.table_name = 'clientes' ORDER BY c.ordinal_position" > evidencias/diccionario-clientes.csv

--csv hace que psql entregue el resultado separado por comas, listo para abrirse en una hoja de cálculo.

columna,tipo,longitud,acepta_nulos,descripcion
id,bigint,,NO,Identificador interno del cliente. Generado por el sistema.
nombre,character varying,120,NO,Nombre completo. Dato personal identificador directo.

Catálogo mínimo de la base comercial

ID	Conjunto	Motor	Ubicación	Propietario	Clasificación	Datos personales
CAT-01	Clientes	PostgreSQL 16	comercial.public.clientes	Gerencia Comercial	Confidencial	Sí
CAT-02	Auditoría de clientes	PostgreSQL 16	comercial.auditoria.cambios_clientes	Por definir	Confidencial	Sí
CAT-03	Registro de cambios	PostgreSQL 16	comercial.gobierno.solicitudes_cambio	Comité de cambios	Interna	No
CAT-04	Clientes (tienda)	MongoDB 7	comercial.clientes	Por definir	Confidencial	Sí
CAT-05	Perfilado	MongoDB 7	comercial.system.profile	Por definir	Confidencial	Sí

CAT-02 y CAT-05 existen para la auditoría, pero contienen datos personales.

Ejemplo guiado: registro de cambios y conciliación

CREATE TABLE gobierno.solicitudes_cambio (
    folio TEXT PRIMARY KEY, descripcion TEXT NOT NULL, solicitado_por TEXT NOT NULL,
    aprobado_por TEXT, ambiente TEXT NOT NULL CHECK (ambiente IN ('desarrollo','pruebas','produccion')),
    fecha_aprobacion TIMESTAMPTZ, ventana_inicio TIMESTAMPTZ, ventana_fin TIMESTAMPTZ
);

Sentencia en la bitácora	Folio	¿Autorizado?
ALTER TABLE clientes ADD COLUMN canal_alta ...	CAM-2026-014	Sí
ALTER TABLE clientes DISABLE TRIGGER trg_auditoria_clientes	—	Hallazgo
GRANT UPDATE ON clientes TO app_ventas	—	Por revisar

Conciliación: comparar lo que ocurrió (bitácora, consultada con dba.bitacora) con lo que estaba autorizado (registro)

Afirmación o evidencia

Afirmación

"Registramos los cambios de privilegios."

Evidencia

Línea de bitácora con el GRANT, el usuario y la hora, más la configuración vigente que lo permitió.

ID	Evidencia técnica del expediente
E1	Configuración de registro vigente (pg_settings)
E2	Privilegios vigentes (information_schema.role_table_grants)
E3	Disparador de auditoría habilitado (pg_trigger)
E4	Muestra de la auditoría, solo metadatos
E5	Bitácora exportada con hash
E6	Evidencias de MongoDB (perfilador, bitácora, comparación)

El expediente de auditoría interna

EXPEDIENTE.md
 1. Alcance
 2. Configuración de auditoría             (E1, E3, E6)
 3. Bitácora interpretada                  (al menos tres eventos)
 4. Elementos de gobierno                  (responsables, catálogo, diccionario)
 5. Conservación
 6. Políticas                              (POL-01 a POL-06)
 7. Conciliación de cambios
 8. Hallazgos                              (severidad, impacto, recomendación, decisión)
 9. Limitaciones y riesgos aceptados       (verificado vs. documentado)
10. Índice de evidencias con hash

Actividad 7: Evidencia oficial de la unidad

Configuración o diseño de auditoría con bitácora interpretada

Debe integrar

(1) mecanismo real de registro disponible en la edición usada, (2) bitácora capturada, (3) al menos tres eventos interpretados, (4) propietario y entrada de catálogo y diccionario

No se acepta

Simular una función de auditoría que no existe en la edición usada, o una interpretación genérica no ligada a la bitácora entregada

Relación con el Laboratorio 03 — Políticas prácticas, gobierno de datos y evidencias: ahí se integra el expediente con lo producido en los Laboratorios 01 y 02.

Relación con el laboratorio

Los responsables, el diccionario, el catálogo y el expediente de auditoría interna se construyen en el Laboratorio 3 — Políticas prácticas, gobierno de datos y evidencias.

Qué sigue

Continúa con 8. Cierre de la unidad.