Cumplimiento de datos FAIR sin un data manager dedicado

El plan de gestión de datos (DMP) que presentaste con la propuesta decía que los resultados de tu proyecto serían FAIR: localizables (Findable), accesibles (Accessible), interoperables (Interoperable) y reutilizables (Reusable). Dos años y medio después, el estado real de los datos del proyecto es el siguiente: dispersos en los portátiles del equipo, schemas sin documentar, sin identificadores persistentes, sin licencia de reutilización y sin plan de depósito en un archivo. La pregunta del evaluador, "¿dónde puede un investigador acceder a tu conjunto de datos depurado?", no tiene una respuesta clara. El DMP era una aspiración. La ejecución, no.

Este es el patrón más común en el cumplimiento de datos FAIR en la investigación financiada con subvenciones. Los principios se conocen bien. Las prácticas que producen resultados alineados con FAIR no se conocen igual de bien, sobre todo en equipos sin personal dedicado a la gestión de datos. Este artículo es una guía práctica para hacer real el cumplimiento FAIR sin contratar a un data manager.

Qué exige FAIR realmente (en términos operativos)

FAIR es un acrónimo de cuatro letras que describe cuatro propiedades que los datos de investigación deberían tener. En la práctica, cada letra se traduce en un pequeño conjunto de requisitos operativos concretos.

F: Localizable (Findable)

Los datos tienen que poder ser encontrados por cualquiera que quiera reutilizarlos. Esto implica:

• Un identificador persistente (normalmente un DOI de Zenodo, tu repositorio institucional o un archivo específico del dominio)
• Metadata estructurada que describa qué son los datos, quién los produjo, cuándo y bajo qué condiciones
• Indexados en un repositorio consultable que otros investigadores usen de verdad

En términos operativos: deposita tu conjunto de datos en Zenodo o equivalente, con un formulario de metadata completo, y ya cumples la F.

A: Accesible (Accessible)

Los datos tienen que poder recuperarse mediante protocolos estándar, con controles de acceso claros.

• Acceso abierto si los datos no son sensibles y tu financiador lo permite
• Acceso autenticado con procedimientos documentados si los datos están restringidos (clínicos, personales, comercialmente sensibles)
• Disponibilidad a largo plazo: los datos tienen que poder recuperarse años después de que el proyecto termine

La metadata debe ser de acceso abierto incluso cuando los propios datos están restringidos. Un evaluador debería poder ver que el conjunto de datos existe y qué contiene, aunque no pueda descargar los datos sin una solicitud de acceso.

I: Interoperable

Los datos tienen que usar formatos y vocabularios que las máquinas (y otros equipos de investigación) puedan leer.

• Formatos de archivo abiertos (CSV, JSON, Parquet, NetCDF, no formatos propietarios exclusivos de Excel)
• Vocabularios estándar para los nombres de variables cuando existan en tu dominio (ontologías, vocabularios controlados)
• Documentación del schema para que quien reutilice los datos sepa qué significa cada columna sin tener que preguntarte

Esta es la letra que la mayoría de los equipos de investigación infravalora. La interoperabilidad es lo que hace que el conjunto de datos sea útil para cualquiera fuera de tu equipo.

R: Reutilizable (Reusable)

Los datos tienen que ir acompañados de los términos de licencia y la información de procedencia que permiten su reutilización.

• Licencia de reutilización clara (Creative Commons, Open Data Commons, licencia personalizada, no "acceso abierto" en abstracto)
• Metadata de procedencia que describa cómo se recogieron, procesaron y depuraron los datos
• Diccionario de datos que documente variables, unidades, códigos y reglas de decisión

Sin esto, unos datos técnicamente FAIR son prácticamente no reutilizables. La licencia y el diccionario de datos no son negociables.

Las cinco etapas del ciclo de vida de los datos de investigación y dónde encaja FAIR

| Etapa | Qué exige FAIR | Qué suelen pasar por alto los equipos sin data manager | |---|---|---| | Planificación | DMP alineado con la plantilla del financiador, principios FAIR nombrados de forma explícita | DMP escrito una sola vez en la propuesta, nunca revisado | | Recogida | Disciplina de schema, metadata en la ingesta | Los schemas derivan; la metadata se captura a posteriori | | Procesamiento | Depuración reproducible con procedencia | Depuración en Excel sin registro de las decisiones | | Análisis | Análisis versionado ligado a versiones concretas de los datos | Los análisis citan "el conjunto de datos depurado" sin especificar cuál | | Archivo | Depósito con metadata, DOI y licencia | Depósito en archivo hecho con prisas en la última semana, a menudo incompleto |

El ciclo de vida de los datos de investigación es donde FAIR se implementa o no. La mayoría de los equipos sin roles dedicados a la gestión de datos lo hacen bien en Planificación y Recogida, tienen dificultades en Procesamiento y Análisis, y hacen el Archivo con prisas. La inversión con mayor retorno es tratar el Procesamiento como código, no como trabajo ad hoc.

Una auditoría de preparación FAIR en 12 pasos que puedes hacer hoy

Reserva dos horas. Abre la unidad del proyecto y tu DMP.

1. Encuentra tu DMP. Léelo. Anota todos los compromisos FAIR que recoge.
2. Identifica la versión canónica de tu conjunto de datos. Si hay tres archivos "final depurado", elige uno y renombra los demás.
3. Abre tu diccionario de datos. Si no existe, redacta uno ahora: nombre de variable, tipo, unidades, valores permitidos, fuente, reglas de decisión.
4. Localiza el script de depuración. Si la depuración es manual, documenta los pasos manuales en una lista de comprobación con forma de script que otra persona pueda seguir.
5. Confirma el formato de archivo. ¿Tus archivos de datos están en formatos abiertos (CSV, Parquet, NetCDF)? Si no, planifica una conversión.
6. Elige una licencia. CC BY 4.0 es una opción por defecto habitual para datos de investigación no sensibles. CC0 si quieres la máxima reutilización. Licencias personalizadas para datos sensibles, con una justificación documentada.
7. Identifica tu destino de archivo. Zenodo para uso general; tu repositorio institucional si es localizable; archivos específicos del dominio donde existan (NCBI, EBI, neurodata.io, ICPSR).
8. Redacta la metadata de tu repositorio. Título, autores, colaboradores, resumen, palabras clave, publicaciones relacionadas, financiador, número de subvención.
9. Planifica los controles de acceso si los datos están restringidos. Documenta quién puede solicitar acceso, en qué condiciones y mediante qué proceso.
10. Documenta la procedencia. Cómo se recogieron los datos, por quién, con qué protocolos y qué depuración se aplicó.
11. Pon a prueba la reutilización. ¿Un colega que no recogió los datos puede entenderlos solo con la metadata y el diccionario? Si no, corrige la carencia.
12. Programa el depósito real. No lo dejes para la última semana. Deposita una versión casi final entre 4 y 6 semanas antes del cierre, y actualízala si hace falta.

Dos horas de trabajo concentrado suelen llevar un proyecto de "FAIR como aspiración" a "FAIR casi real". Las carencias que quedan suelen ser concretas y abordables.

La brecha de implementación que la mayoría de los equipos pasan por alto

La mayor diferencia práctica entre un proyecto alineado con FAIR y uno que no lo está no son los principios, sino las prácticas de ingeniería que hacen entregables esos principios.

Validación de schema como código

Define tus schemas (nombres de columna, tipos, valores permitidos) en código que se ejecute en la ingesta. Un modelo de Pydantic sencillo o una definición de JSON Schema detecta la deriva el primer día, y no en el sexto mes. Sin esto, tus datos "estructurados" acumulan inconsistencias que la depuración tiene que corregir a posteriori.

Depuración como código

Incluso la depuración sencilla (descartar valores ausentes, estandarizar formatos de fecha, deduplicar sujetos) debería estar en un script versionado y ejecutable de principio a fin. El script es la documentación de procedencia. Sin él, "el conjunto de datos depurado" es una instantánea del trabajo manual de alguien en Excel que nadie puede reproducir.

Análisis ligado a versiones concretas de los datos

Cada análisis debería hacer referencia a la versión concreta del conjunto de datos sobre la que se ejecutó. Cuando el conjunto de datos se actualiza, los análisis pueden volver a ejecutarse sobre la nueva versión, con los cambios documentados. Sin esto, el vínculo entre las figuras publicadas y los datos subyacentes se degrada con el tiempo.

Documentación a medida que se hace el trabajo

La documentación escrita el día del plazo es mala documentación. El README, el diccionario de datos y el registro de decisiones deberían crecer junto a los datos, no montarse en la última semana. Un equipo sin data manager también puede hacerlo: solo requiere la disciplina de actualizar el README cada vez que se toma una decisión relevante sobre los datos.

FAIR para datos sensibles

Los principios FAIR se aplican incluso cuando los datos están restringidos. La metadata debe seguir siendo localizable y accesible; los controles de acceso solo restringen los propios datos.

Para proyectos que trabajan con datos clínicos, datos personales o datos comercialmente sensibles:

• La metadata del conjunto de datos es pública aunque los datos no lo sean. La capacidad de localización lo exige.
• Los procedimientos de acceso están documentados y son localizables. Un evaluador debería saber cómo solicitar acceso.
• El diccionario de datos es público para que quien quiera reutilizar los datos sepa si son relevantes antes de solicitar acceso.
• La anonimización, cuando es posible, es lo estándar. Una versión anonimizada de los datos puede ser publicable de forma abierta aunque los datos en bruto no lo sean.

Cada vez más, los financiadores lo exigen. El principio de Horizon Europe, "tan abierto como sea posible, tan cerrado como sea necesario", es el marco explícito.

Dónde encaja Pragma

Implementamos la gestión de datos de investigación alineada con FAIR como un servicio para equipos financiados con subvenciones que no tienen personal dedicado a la gestión de datos. Un encargo típico dura entre 4 y 8 semanas: validación de schema como código, procesos de depuración reproducibles, estructuras de metadata FAIR, depósito en archivo y documentación de traspaso. El resultado es infraestructura que tu equipo posee y opera sin dependencias adicionales.

Si tu DMP se comprometió con FAIR y las prácticas para cumplirlo no se han materializado, ese es el encargo para el que existimos. Hemos hecho este trabajo para colaboraciones de investigación académica, consorcios financiados por la UE y proyectos del ámbito de la salud en múltiples centros.

Tres cosas que hacer esta semana

1. Haz la auditoría de 12 pasos de arriba. Anota tus tres carencias principales.
2. Elige la carencia que más bloquea y define la corrección más pequeña que la resuelve. A menudo es escribir el diccionario de datos o probar el script de depuración de principio a fin, no un proyecto de varias semanas.
3. Si la carencia acumulada supera la capacidad disponible de tu equipo, pide una revisión de alcance. Seremos honestos sobre qué merece la pena implementar de forma externa y qué debería quedarse tu equipo.

El cumplimiento de datos FAIR sin un data manager es factible. Es una disciplina, no un puesto de trabajo. La clave está en tratar el trabajo con datos como ingeniería con forma de código, construir las prácticas una vez y mantenerlas durante todo el ciclo de vida del proyecto. Los compromisos del DMP dejan de ser una aspiración y pasan a ser ciertos en la práctica.