Gobernanza de datos para el RGPD: del requisito normativo a la práctica operativa

El RGPD indica a las organizaciones qué deben hacer con los datos personales, pero no prescribe un marco de gobernanza de datos ni un modelo operativo. Esta omisión es deliberada: el RGPD se diseñó para aplicarse a sectores, organizaciones de distintos tamaños y entornos técnicos demasiado diversos como para prescribir un único enfoque. El reglamento define los resultados exigidos, no los métodos para lograrlos.

Para lograr esos resultados, las organizaciones necesitan algo más que una política. Una gobernanza de datos eficaz para el RGPD implica poder identificar los datos personales que posee una organización, rastrear cómo se utilizan, mostrar qué controles se aplican y aportar pruebas de que estos funcionan de forma coherente en sistemas reales.

El RGPD está en vigor desde mayo de 2018. Se aplica a cualquier organización que trate datos personales de residentes de la UE, con independencia del lugar donde esté establecida. Las obligaciones fundamentales del reglamento —saber qué datos personales se poseen, garantizar que sean exactos y se utilicen únicamente para los fines definidos y protegerlos mediante controles adecuados— requieren que la organización disponga de sistemas operativos. El principio de responsabilidad proactiva (artículo 5, apartado 2) lo deja claro: las organizaciones deben poder demostrar que cumplen los principios del RGPD, no limitarse a afirmarlo.

Las políticas documentadas, los roles definidos, los controles técnicos y los registros de auditoría deben vincular las políticas con el tratamiento de datos real. Un registro de auditoría no es opcional en virtud del RGPD.

Tanto los responsables como los encargados del tratamiento tienen obligaciones en virtud del RGPD, aunque los responsables asumen una carga de responsabilidad proactiva más amplia. Cuando se requiere un delegado de protección de datos (DPD), este debe tener una visibilidad real de las actividades de tratamiento, los controles y las decisiones sobre riesgos, y no limitarse a ser una persona de contacto designada.

La forma más clara de entender qué exige el RGPD a un programa de gobernanza es relacionar cada artículo con las capacidades operativas que implica.

Esta correspondencia resulta útil porque el RGPD está redactado como un reglamento, no como una guía de implementación. Establece lo que debe aplicarse —los datos deben ser exactos, el tratamiento debe registrarse y el acceso debe ser adecuado— sin especificar los sistemas o procesos que permiten hacerlo. Un programa de gobernanza cumple esta función.

El artículo 25 merece especial atención. La “privacidad desde el diseño” exige integrar la protección de datos en el tratamiento de estos desde el principio y restringir los datos personales por defecto, en lugar de conceder acceso a ellos de forma predeterminada. En términos de gobernanza, esto implica clasificar los datos durante la ingesta o en un punto cercano a ella, asociar controles a los activos de datos y aplicar automáticamente la lógica de las políticas, en lugar de depender de decisiones humanas caso por caso.

Los requisitos de la EIPD del artículo 35 se aplican específicamente a las operaciones de tratamiento de datos de alto riesgo: la supervisión sistemática a gran escala, las categorías especiales de datos y la toma de decisiones automatizada con efectos significativos. No todas las operaciones de tratamiento de datos requieren una EIPD, pero un programa de gobernanza necesita un proceso claro para determinar cuándo se requiere una y someterla a la revisión adecuada.

Un programa preparado para el RGPD suele apoyarse en cuatro pilares fundamentales: inventario, clasificación, aplicación de controles de acceso y auditabilidad.

Los datos personales no pueden gobernarse si no pueden localizarse. Un inventario permite saber qué datos personales existen, dónde se encuentran, cómo se desplazan entre los sistemas y qué procesos empresariales los utilizan. Esto contribuye directamente al mantenimiento de los registros exigido por el artículo 30, pero también sustenta todo lo demás: la evaluación de riesgos, la revisión del acceso, las decisiones sobre conservación y la respuesta ante incidentes.

Un catálogo de datos y las capacidades de linaje permiten operacionalizar el inventario. Una tabla que contenga direcciones de correo electrónico de clientes, transcripciones de asistencia o atributos relacionados con la salud no solo debe ser visible como objeto técnico, sino también en su contexto: qué la alimenta, qué sistemas alimenta y qué finalidad empresarial cumple. Las decisiones de gobernanza dependen de cómo se utilizan realmente los datos, no solo de dónde se almacenan.

Los principios del RGPD son mucho más fáciles de aplicar cuando los datos personales se etiquetan de forma coherente durante la ingesta o en un punto cercano a ella. La clasificación proporciona la señal de la que dependen los controles posteriores. Una vez que los datos se etiquetan como personales, confidenciales o de otro tipo, las políticas de enmascaramiento, las reglas de acceso, los plazos de conservación y la supervisión pueden aplicarse automáticamente. Esta es la lógica operativa que sustenta el artículo 25. El requisito consiste en integrar la protección en el diseño del tratamiento desde el principio.

La minimización de datos debe aplicarse mediante mecanismos técnicos, no limitarse a figurar en una política. Un programa de gobernanza necesita una posición de acceso predeterminada que parta de la restricción y conceda acceso de forma deliberada, en función del rol y de la finalidad declarada.

El control de acceso basado en roles (RBAC), la seguridad a nivel de columna y el enmascaramiento son los mecanismos prácticos. Es preferible asociar la política a los propios datos para que los controles evalúen el rol o la finalidad del usuario y muestren únicamente lo que requiere la tarea, sin tener que volver a crear un caso de acceso para cada campo y cada consulta.

Un programa de gobernanza conforme al RGPD está incompleto si no aporta pruebas. No basta con que exista una política. Deben existir registros que demuestren que la política se aplicó al acceso a datos y a las actividades de tratamiento reales.

Los registros de acceso, el historial de consultas y las auditorías que tienen en cuenta el linaje aportan esas pruebas. Si se pregunta a una organización qué usuarios consultaron una columna de datos personales, si un atributo restringido se propagó a una vista posterior o qué actividad de tratamiento respaldó una finalidad empresarial determinada, las respuestas deben proceder de registros, no de una reconstrucción manual realizada a partir de varios sistemas.

La solidez de un programa de gobernanza depende de los controles aplicados en la capa de datos. Snowflake proporciona una capa de aplicación que ayuda a las organizaciones a aplicar la clasificación, los controles de acceso y los registros de auditoría a los activos de datos, en lugar de limitar su existencia a la documentación.

El requisito de responsabilidad proactiva del RGPD establece que una organización debe demostrar que los controles se aplican de forma coherente a datos reales. Una plataforma que aplica las políticas en la capa de datos —de forma automática y a escala— puede ayudar a las organizaciones a reforzar y agilizar su capacidad para demostrar el cumplimiento.

Por ejemplo, Snowflake Horizon permite la clasificación automática de datos confidenciales, identifica los datos personales y asigna etiquetas definidas por el sistema y por los usuarios. El enmascaramiento basado en etiquetas puede utilizarse para restringir el acceso de forma predeterminada, lo que puede contribuir a aplicar el requisito de “privacidad desde el diseño” del artículo 25.

La seguridad a nivel de columna y el RBAC aplican la minimización de datos a nivel de campo, lo que garantiza que los usuarios vean únicamente lo necesario para su función y la finalidad declarada (artículos 25 y 32). El historial de acceso registra todas las consultas de datos personales (el usuario, la consulta y las columnas específicas leídas o escritas), lo que ayuda a las organizaciones a generar registros de auditoría en consonancia con el artículo 30 y las expectativas de responsabilidad proactiva del artículo 5, apartado 2. Las capacidades de catálogo de datos y linaje de Snowflake respaldan el inventario de las actividades de tratamiento del que depende el mantenimiento de registros exigido por el artículo 30.

Existe también una dimensión transfronteriza. El capítulo V del RGPD regula las transferencias de datos personales a terceros países u organizaciones internacionales. De forma predeterminada, los compromisos de Snowflake relativos a la residencia de los datos vinculan los datos en reposo a la región de despliegue del cliente. Esto puede ayudar a las organizaciones a diseñar casos de uso sujetos a requisitos de residencia, aunque el cumplimiento en materia de transferencias sigue dependiendo del contexto jurídico y contractual más amplio, incluidas, cuando proceda, las decisiones de adecuación, las cláusulas contractuales tipo o las normas corporativas vinculantes.

El cumplimiento del RGPD suele plantearse principalmente como una cuestión jurídica. El principio de responsabilidad proactiva deja claro que también es una cuestión operativa. Una organización capaz de identificar sus datos personales, rastrear cómo se desplazan, aplicar controles de acceso y generar registros de auditoría está construyendo el tipo de base operativa que hace sostenible la gobernanza de datos para el RGPD.