Plan de gestión de datos: qué preparar antes del cierre

Escribiste un Plan de Gestión de Datos en la propuesta. La convocatoria de la AEI lo exigía, le dedicaste un par de tardes, lo entregaste, te concedieron el proyecto. Han pasado dos años. El PGD vive en una carpeta del Drive del coordinador. Nadie lo ha vuelto a abrir. La realidad de los datos del proyecto no se parece a lo que decía aquel documento. La revisión final llega en seis meses y la pregunta del evaluador será: ¿dónde puede un revisor acceder a tus datos limpios?

El plan de gestión de datos que sobrevive al proyecto no es el que escribes una vez. Es un sistema operativo que tu equipo puede mantener — un puente entre lo que prometiste al financiador y lo que de verdad pasa con los datos durante 36 meses.

Este artículo es una guía narrativa del ciclo completo del PGD para proyectos de investigación: de la convocatoria al borrador, del borrador a la revisión del comité, de la revisión al sistema que el equipo opera. Cubre AEI, Plan Estatal, ERC, MSCA y Horizon Europe — los requisitos formales varían, la lógica subyacente no.

Qué espera el financiador realmente del PGD

La mayoría de PGDs se escriben para superar la evaluación de la propuesta. Eso es legítimo, pero deja fuera tres cosas que el evaluador final sí va a revisar:

• Trazabilidad técnica: ¿pueden los revisores acceder a los datos limpios? ¿Existe una versión canónica? ¿Está depositada con DOI citable?
• Coherencia entre PGD y realidad: ¿el documento describe lo que el equipo hace realmente, o lo que se prometió hace dos años?
• Mantenibilidad: ¿alguien podría continuar operando los datos del proyecto si el postdoc que los gestiona se va mañana?

Las plantillas oficiales de la AEI, Horizon Europe y los repositorios institucionales cubren la primera capa: secciones, contenidos mínimos, calendarios de revisión. Lo que no cubren es la traducción operativa — cómo convertir cada compromiso del PGD en una práctica de trabajo concreta que el equipo pueda sostener.

La pregunta útil al escribir el PGD inicial: ¿este compromiso es algo que vamos a cumplir, o es algo que estamos prometiendo porque queda bien? Si es lo segundo, mejor reformularlo ahora que defenderlo en la revisión final.

Las cuatro fases del PGD que sobrevive al proyecto

Fase 1: Lectura de la convocatoria (semana 0)

Antes de empezar a redactar, lee la convocatoria con el PGD en mente. Identifica:

• Qué tipo de plantilla espera el financiador. AEI/Plan Estatal usa estructura propia; Horizon Europe usa la plantilla de la Comisión Europea actualizada por convocatoria; las MSCA tienen su propio formato.
• Cuándo es el primer entregable formal del PGD. En Horizon Europe normalmente al mes 6; en AEI suele depender de la modalidad. Marca la fecha en el calendario antes de redactar nada.
• Qué se espera respecto a FAIR y ciencia abierta. Las convocatorias actuales son cada vez más explícitas: "as open as possible, as closed as necessary" en Horizon Europe, mandato de depósito en repositorios públicos en muchas modalidades AEI.
• Qué dice la convocatoria sobre datos sensibles. Si el proyecto trabaja con datos personales, sanitarios o sujetos a IRB/CEIm, el PGD necesita una sección de protección de datos coherente con la base legal del tratamiento.

Esta lectura es de 30 minutos y ahorra dos semanas de redacción ciega. La mayoría de PGDs débiles se escriben sin haber leído la convocatoria con esta mirada.

Fase 2: Redacción inicial (semanas 1–3)

El PGD inicial debe ser específico, no genérico. Las secciones clásicas son:

• Descripción de los datos (tipos, volumen estimado, formatos)
• Estándares y metadatos (esquemas, vocabularios controlados, alineación FAIR)
• Almacenamiento y seguridad durante el proyecto
• Compartición y acceso (qué se comparte, cuándo, bajo qué licencia)
• Conservación a largo plazo (depósito final, DOI, mantenimiento)
• Responsabilidades (quién hace qué, con qué presupuesto)

Errores que vemos a menudo en esta fase:

• Datos descritos en abstracto: "datos clínicos del proyecto" en lugar de "registros longitudinales de 200 pacientes con 32 variables fenotípicas y 4 medidas neurofisiológicas".
• Estándares mencionados sin compromiso real: "alinearemos con los principios FAIR" sin decir cómo. Mejor: "depositaremos en Zenodo con metadatos Dublin Core extendido y licencia CC-BY 4.0".
• Compartición prometida pero sin plan de anonimización: si los datos son sensibles, hay que decir cómo se comparten, no solo que se compartirán.
• Conservación delegada a la institución: decir "la universidad mantendrá los datos" sin confirmar con la biblioteca o el servicio de TI es un compromiso falso.

El PGD inicial bueno tiene una propiedad: si lo lees con el equipo en una reunión de 30 minutos, todos pueden decir qué tienen que hacer la próxima semana. Si la respuesta es "no sé", el PGD es demasiado genérico.

Fase 3: Revisión y entrega formal (mes 6)

Para Horizon Europe la primera entrega formal del PGD suele ser al mes 6. Para AEI los plazos varían, pero la lógica es la misma: hay que entregar al financiador una versión revisada que refleje lo aprendido en los primeros meses del proyecto.

Aquí es donde la mayoría de proyectos pierden la oportunidad. La revisión se hace deprisa, con copy-paste del PGD inicial y unos cambios cosméticos. Lo que el evaluador espera es lo contrario: evidencia de que el equipo ha aprendido sobre sus propios datos en los primeros seis meses.

Lo que merece la pena revisar antes de la entrega del mes 6:

• Volúmenes reales vs estimados: si dijiste 200 pacientes y vas a tener 350, dilo. Si dijiste 200 y vas a tener 80, dilo también — y explica por qué (cambios en el protocolo, retrasos en el reclutamiento).
• Esquema actualizado: los nombres de variables, unidades y vocabularios que de verdad estás usando, no los que escribiste antes de tocar los datos.
• Decisiones de calidad tomadas: criterios de exclusión, manejo de valores faltantes, deduplicación. Si tu equipo discutió estas decisiones en marzo, deja constancia en el PGD revisado.
• Repositorio confirmado: si dijiste "Zenodo o repositorio institucional" en la propuesta, ahora elige uno con motivo.
• Plan de protección de datos validado por el comité de ética: si aplica, con número de aprobación.

Esta revisión es la oportunidad de cerrar la brecha entre lo prometido y lo posible sin quedar en mal lugar.

Fase 4: Mantenimiento operativo (meses 7 al cierre)

Aquí el PGD deja de ser un documento y se convierte en una práctica. Lo que distingue un PGD operativo de uno administrativo:

• El esquema de datos vive en código, no solo en el documento. Una validación Pydantic / JSON Schema corre cada vez que entran datos nuevos.
• Las decisiones de calidad están en scripts, no solo en actas. El pipeline de limpieza es reproducible — python clean.py lleva de crudo a limpio sin pasos manuales.
• El depósito en repositorio se ensaya pronto. Mejor depositar una versión preliminar al mes 18 que esperar al mes 36 y descubrir que el repositorio no acepta el formato.
• El PGD se revisa una vez al año, mínimo. Idealmente acompañando a los hitos de informe del financiador.
• El repositorio de código tiene un README que un revisor externo podría seguir. Esto es la diferencia entre un proyecto FAIR de verdad y uno que lo dice.

Errores comunes que hacen que un PGD no sobreviva

Tras revisar PGDs de proyectos AEI, ERC, MSCA y Horizon Europe, los mismos errores aparecen una y otra vez:

• Tratar el PGD como obligación administrativa, no como herramienta operativa. El PGD debería ser el documento más útil del proyecto para el equipo, no el más invisible.
• Delegarlo en una sola persona sin presupuesto. "El doctorando hará el PGD en sus ratos libres" es la frase que precede a todos los desastres de cierre.
• No validar las afirmaciones FAIR. Decir "alineado con FAIR" sin metadatos estructurados, sin DOI, sin licencia de reutilización es un compromiso falso que el evaluador detectará.
• Olvidar la versión revisada. El financiador espera evolución del documento. Una versión idéntica al borrador inicial es una señal de que nadie lo ha trabajado.
• No conectar el PGD con la justificación técnica final. El PGD describe los datos; la justificación técnica del cierre referencia esos datos como evidencia. Si los dos documentos no se hablan, el evaluador lo nota.

La revisión anual del PGD: agenda de 60 minutos

Una vez al año, idealmente alineada con un hito de informe, bloquea 60 minutos con el equipo. Agenda concreta:

| Tema | Tiempo | Resultado | |---|---|---| | Repaso del esquema de datos vigente | 10 min | Esquema actualizado o validado | | Decisiones de calidad nuevas desde la última revisión | 10 min | Decisiones documentadas en el PGD | | Volúmenes reales vs proyectados | 10 min | Sección actualizada | | Estado del repositorio y deposiciones preliminares | 10 min | Plan claro hasta la próxima revisión | | Cambios en el equipo y traspaso de responsabilidades | 10 min | Asignaciones actualizadas | | Próximos hitos del PGD y del financiador | 10 min | Calendario hasta la próxima revisión |

Una hora al año. Es la inversión que separa un PGD vivo de un PGD que solo aparece en el cierre.

Cuándo conviene incorporar ayuda externa

Un proyecto de gestión de datos de investigación externo es la decisión correcta cuando:

• El equipo no tiene un data manager dedicado y el PGD lleva sin actualizarse más de un año
• La revisión del mes 6 está cerca y la realidad de los datos no se parece al PGD inicial
• El cierre se acerca y el depósito en repositorio no se ha ensayado
• Hay datos sensibles (salud, personales, sujetos a CEIm) y el plan de protección de datos no se ha validado con el comité
• El consorcio es multi-sitio y los esquemas no están alineados entre socios

Para esto está construido nuestro proyecto de gestión de datos. Cubrimos la implementación: validación de esquema como código, pipelines de limpieza reproducibles, metadatos FAIR, depósito en archivo, documentación de traspaso. La duración típica es 4–8 semanas y el equipo posee el resultado.

Tres cosas para hacer esta semana

1. Localiza la última versión de tu PGD. Si tiene más de seis meses sin actualizar, agéndale una revisión de 60 minutos con el equipo.
2. Para cada compromiso FAIR del PGD, escribe en una frase qué pasa la próxima semana para hacerlo realidad. Si no puedes, ese compromiso necesita reformularse.
3. Si la revisión revela una brecha grande entre lo prometido y la realidad, solicita una revisión de proyecto. Definiremos el plan mínimo viable para cerrar la brecha antes del próximo informe.

El PGD que sobrevive al proyecto no es el más detallado ni el más extenso. Es el que el equipo puede operar sin pensarlo cada mañana, y el que el evaluador puede verificar sin sorpresas en el cierre. Lo demás es papel.