El gobierno del dato no es un documento de políticas. Es una capa que se aplica o no se aplica

En una organización sanitaria con varios centros hospitalarios, existe una regla que no admite discusión: un profesional de un centro no puede acceder a los datos de pacientes de otro centro. Es una separación por diseño, no una preferencia.

En una plataforma de datos centralizada, esa regla deja de ser una norma que la gente cumple por costumbre y pasa a ser algo que hay que implementar. Y ahí apareció la complicación real: surgió un caso de uso de investigación que necesitaba analizar datos agregados de varios centros a la vez. Legítimo, útil, y en aparente contradicción directa con la regla de segregación.

La respuesta no fue hacer una excepción puntual ni relajar la norma para ese caso. Fue crear un rol específico, con permisos definidos a nivel de dataset dentro de la propia capa de gestión de accesos de la plataforma, que permitía ese cruce concreto sin abrir la puerta a nada más. La regla general seguía intacta. Lo que cambió fue que el sistema, no una persona, decidía quién podía ver qué.

La diferencia entre una política y un mecanismo

Es fácil confundir "tenemos gobierno del dato" con "tenemos un documento que dice cómo debería comportarse la gente con los datos". Son cosas distintas, y la diferencia se nota exactamente en momentos como este.

Una política en un documento depende de que alguien la lea, la recuerde y decida cumplirla cada vez. Funciona razonablemente bien mientras no aparece presión, prisa o un caso de uso nuevo que no estaba contemplado. En el momento en que alguien necesita de verdad ese acceso —porque tiene una investigación que sacar adelante, porque hay una fecha límite— la política escrita no tiene forma de impedir ni de permitir nada. Solo puede recomendar.

Un mecanismo aplicado en la plataforma no depende de que nadie se acuerde de nada. La pregunta deja de ser "¿debería tener acceso esta persona?" y pasa a ser "¿tiene el rol que le da ese acceso, sí o no?". Cuando aparece un caso nuevo, como la investigación multicéntrica, la respuesta no es debatir si hacer una excepción a la política. Es decidir si el mecanismo necesita un nuevo rol, bien definido y bien acotado.

Por qué esto también determina si el EHDS es sostenible

En posts anteriores hemos hablado de describir datasets y etiquetar su calidad como obligaciones del EHDS. Ambas dan por hecho que existe control real sobre quién puede acceder a qué dato y en qué condiciones. Si ese control vive solo en un documento de políticas, cualquier descripción o etiqueta de calidad que pongas encima es una fotografía de un momento, no una garantía sostenida en el tiempo.

El gobierno del dato aplicado como mecanismo tiene otra ventaja, menos obvia: cuando aparece un caso de uso legítimo que hoy no encaja en la regla general —como el de la investigación multicéntrica— no obliga a elegir entre bloquear el proyecto o saltarse la norma. Permite construir la excepción de forma controlada, trazable y reversible. Eso es exactamente lo que un organismo de acceso a datos, un auditor o un investigador externo necesita poder ver cuando pide explicaciones sobre cómo se gestiona un dataset.

La pregunta que sustituye a "¿tenemos una política de acceso?"

La pregunta que de verdad importa no es si existe un documento de gobierno del dato. Es si, cuando aparece mañana un caso de uso nuevo que no estaba previsto, tu organización puede resolverlo ajustando un mecanismo, o si depende de que alguien decida hacer una excepción y confiar en que se respete.

Si la respuesta es la segunda, no tienes gobierno del dato. Tienes buenas intenciones, y eso no aguanta bien la primera vez que alguien tiene prisa.