Gestión de datos de investigación sin data manager dedicado
Cómo los equipos de investigación con financiación gestionan todo el ciclo de vida de los datos (recogida, limpieza, FAIR, entrega) sin data manager dedicado.
La mayoría de los proyectos de investigación con financiación necesitan a alguien que se ocupe de los datos. Menos aún cuentan con alguien cuyo trabajo sea precisamente ese. El financiador espera un plan de gestión de datos (DMP), resultados alineados con FAIR, una entrega lista para archivo y una cadena de custodia que sobreviva a la marcha del postdoc. El equipo tiene un IP, dos doctorandos, un postdoc y 0,2 FTE de un ingeniero de software de investigación institucional que, además, da soporte a otros cuatro proyectos.
Este es el hueco en el que vive la gestión de datos de investigación. Las universidades la enmarcan como una función de la biblioteca. Los financiadores, como una obligación de cumplimiento. Los equipos que de verdad hacen investigación la tratan como algo que tiene que ocurrir entre la presentación de dos propuestas, además del trabajo de campo, el análisis y la redacción. El puesto de data manager existe en la mente del financiador; en el presupuesto del proyecto, rara vez.
Este artículo es para equipos de investigación con financiación que no tienen uno ni van a tenerlo. Cubre qué implica realmente la gestión de datos de investigación a lo largo del ciclo de vida del proyecto, dónde están los huecos de mayor impacto y cómo gestionar el trabajo sin contratar un puesto de datos a tiempo completo.
Qué significa realmente la gestión de datos de investigación
La gestión de datos de investigación (RDM) es el conjunto de prácticas que hacen que los datos recogidos, generados o curados por un proyecto de investigación sigan siendo utilizables más allá del momento de su recogida. Abarca todo el ciclo de vida de los datos de investigación: desde el plan de gestión de datos redactado en la fase de propuesta, pasando por la recogida y el procesamiento, el análisis y la publicación, hasta el archivo a largo plazo y la reutilización por parte de otros equipos.
Una lectura errónea habitual: que la RDM es almacenamiento y copias de seguridad. Lo es, pero solo de forma superficial. La parte más difícil es todo lo que hace que los datos sean legibles para alguien que no los recogió. Schemas. Metadatos. Procedencia. Versionado. Políticas de licencia y de acceso. Documentación que sobreviva al equipo. Nada de eso ocurre por accidente, y la mayor parte no puede añadirse a posteriori cuando llega el plazo de entrega.
Los requisitos de cara al financiador se han endurecido. Horizonte Europa espera datos alineados con FAIR. Los financiadores nacionales exigen cada vez más repositorios de datos abiertos. La mayoría de las instituciones tienen políticas de gestión de datos, aunque los proyectos individuales no las cumplan. La pregunta no es si la RDM es obligatoria, sino cómo hacerla sin personal dedicado.
Dónde están realmente los huecos
En la práctica, los huecos en la gestión de datos de investigación se concentran en tres puntos.
Deriva del schema durante la recogida
El plan de gestión de datos define un schema limpio. Seis meses después, los datos reales tienen tres columnas de más que nadie documentó, dos conflictos de nombres de campo entre centros y un formato de fecha que oscila entre ISO y DD/MM/AAAA según qué ayudante de investigación estuviera de turno. Nada fue malintencionado: cada cambio tenía su razón en su momento. Pero ahora el documento del schema ya no es correcto, y el equipo no sabe a qué versión debería realinearse.
Solución: el schema como código, no como documento. Un pequeño script de validación ejecutado en cada ingesta de datos detecta la deriva el primer día, no en el sexto mes. Si la validación falla, o se corrigen los datos o se corrige el schema: de forma explícita, con un incremento de versión.
Limpieza que no es reproducible
Para cuando se ejecuta el análisis, al menos tres personas han tocado el dataset, casi siempre en Excel y casi siempre sin registrar lo que hicieron. Las figuras publicadas citan «el dataset limpio». Nadie puede reproducir ese dataset a partir de los datos en bruto de forma determinista.
Solución: la limpieza como código, aunque sea sencilla. Un único notebook o script que transforme bruto → limpio, ejecutable de principio a fin y con control de versiones. No tiene que ser sofisticado. Tiene que existir y poder reejecutarse. La gestión de datos científicos sin una limpieza reproducible es una ficción.
Documentación que vive en las cabezas
El IP sabe por qué se excluyen las mediciones de principios de 2025. El postdoc sabe qué sujetos tuvieron problemas de calibración de los sensores. El doctorando sabe que los códigos de sujeto que empiezan por BCN- son de la fase piloto y no deberían entrar en el análisis principal. Nada de esto está documentado. Cuando cualquiera de esas personas se marcha, el conocimiento institucional sobre el dataset se va con ella.
Solución: un README.md a nivel de dataset y un notes.md por cada decisión relevante. Nada glamuroso. Mantiene la interpretabilidad del dataset tras la rotación de personal.
El ciclo de vida en cinco etapas, en la práctica
| Etapa | Qué requiere | Cómo es «hacerlo bien» | |---|---|---| | Planificación | DMP en la propuesta, actualizado en el arranque | Alineado con la plantilla del financiador (Horizonte Europa, AEI, AGAUR), revisado cada año | | Recogida | Disciplina de schema, validación en la ingesta | Datos en bruto versionados, schema aplicado, cada lote registrado | | Procesamiento | Limpieza reproducible, decisiones documentadas | Limpieza como código, decisiones registradas, trazabilidad de bruto → listo para análisis | | Análisis | Pipelines de análisis, decisiones documentadas | Análisis como código, parámetros configurables, figuras regenerables | | Archivo | Metadatos FAIR, depósito en repositorio, claridad de licencia | Zenodo / repositorio institucional / repositorio temático, DOI citable, licencia de reutilización indicada |
La mayoría de los equipos van bien en Planificación y Recogida. El fallo se produce en el Procesamiento y el Análisis. El Archivo suele relegarse a la última semana, a contrarreloj.
La acción de mayor impacto para los equipos sin data manager: invertir en la etapa de Procesamiento. Una limpieza reproducible vuelve manejable todo lo que viene después. Sin ella, la etapa de análisis es frágil y la de archivo, deshonesta.
Cómo es un enfoque «done-with-you»
El planteamiento de todo o nada de la gestión de datos de investigación (o contratas a un data manager o lo ignoras) no es la única opción. Hay una tercera vía: incorporar a un socio externo que se encargue del trabajo de implementación, deje a tu equipo un código mantenible y se retire. Este es el modelo de servicios de gestión de datos que tiene sentido para proyectos con financiación sin necesidades recurrentes de ingeniería de datos.
En concreto, esto se traduce en:
- Una colaboración acotada (4–8 semanas) que lleva tus datos de «dispersos en los portátiles del equipo» a «estructurados, documentados y reproducibles».
- Pipelines de limpieza, validación de schema y estructura de metadatos, entregados como código que tu equipo posee.
- Un paquete de documentación (diccionario de datos, registro de decisiones, README, notas de alineación con FAIR) que la siguiente persona del proyecto pueda usar de verdad.
- Depósito en archivo (Zenodo, repositorio institucional) con DOI citables y licencias de reutilización indicadas.
El resultado es una infraestructura de datos de investigación que tu equipo opera sin más dependencias. El criterio de salida es que el equipo pueda reejecutar, documentar nuevos datasets y responder a las solicitudes de datos del financiador de forma autónoma. Sin suscripción. Sin iguala. Sin dependencia de proveedor.
Esto es lo que entendemos por done-with-you: la implementación la hacemos nosotros; el modelo operativo es tuyo.
Qué piden realmente los evaluadores
Una lista práctica, extraída de comentarios reales de evaluación de Horizonte Europa y del ERC:
- «¿Dónde se puede acceder al dataset limpio?». Necesita una URL o un DOI.
- «¿Cómo se tomaron y registraron las decisiones de calidad?». Tienen que ser legibles.
- «¿Puede un revisor reejecutar tu análisis?». Un solo comando, no «sigue estos 12 pasos».
- «¿Qué licencia rige la reutilización?». El nombre de una licencia concreta, no «acceso abierto».
- «¿Cuál es el plan a largo plazo?». No «el repositorio de la institución», sino quién lo mantiene, hasta cuándo y con qué apoyo.
Fallar en cualquiera de estos puntos no suele hundir el proyecto. Pero, a lo largo de suficientes entregables, mueve la puntuación de difusión e impacto, y ahí es donde los consorcios pierden puntos sin darse cuenta de que los estaban perdiendo.
Una auditoría de 90 minutos que puedes hacer esta tarde
Bloquea 90 minutos. Abre la unidad de tu proyecto.
- Encuentra la versión canónica de tu dataset. Si hay tres archivos «final limpio» fechados con menos de un mes de diferencia entre ellos, documenta cuál es la verdadera y borra o renombra los demás.
- Abre el script de limpieza (si existe). Reejecútalo de bruto → limpio. Si la salida no coincide con la versión canónica, tienes pasos manuales ocultos. Documéntalos.
- Lee el README de la carpeta del dataset. Si no existe, escribe un borrador ahora mismo.
- Comprueba si tu plan de gestión de datos se ha actualizado en algún momento posterior al arranque del proyecto. Si no es así, márcalo.
- Localiza tu destino de depósito en archivo (Zenodo, repositorio institucional). Confirma que tienes una cuenta y que conoces el proceso de depósito.
Cinco pasos, noventa minutos, y tendrás una imagen más clara de dónde están realmente los huecos. La mayoría resultan ser más pequeños de lo que temías. Unos pocos resultan ser la diferencia entre un cierre limpio y uno frenético.
Dónde encaja Pragma
En Pragma ofrecemos la gestión de datos de investigación como servicio para equipos con financiación que no tienen, ni quieren contratar, un data manager interno. La colaboración es finita: uno de nuestros Data-to-Report Sprints habituales dura 2–4 semanas, deja un pipeline reproducible y se cierra de forma limpia. Hemos hecho este trabajo para consorcios financiados por la UE, grupos de investigación universitarios y colaboraciones académicas en los ámbitos de la salud, la neurociencia y las políticas públicas.
Si llevas la carga de la gestión de datos sin personal dedicado, esa es justo la colaboración para la que existimos.
Tres cosas que hacer esta semana
- Realiza la auditoría de 90 minutos anterior. Anota los tres huecos principales.
- Identifica el hueco que, una vez resuelto, evitaría el mayor agobio en el momento del cierre. Esa es tu inversión de mayor impacto.
- Si la capacidad disponible del equipo está por debajo de lo que el hueco requiere, pide una revisión de alcance. Seremos honestos sobre qué conviene externalizar y qué conviene que mantenga tu equipo.
La gestión de datos de investigación sin un data manager a tiempo completo es factible. La clave está en tratarla como trabajo de ingeniería con forma de código, no como una obligación administrativa. El resto viene solo.
Notas relacionadas
Cumplimiento de datos FAIR sin un data manager dedicado
La mayoría de los equipos de investigación prometió datos FAIR en la propuesta y nunca lo llevó a la práctica. Cómo hacerlo real sin un data manager.
Ingeniería de software de investigación como servicio
Tu proyecto prometió una herramienta y tu equipo no tiene quién la construya. Qué hace un ingeniero de software de investigación y cuándo elegir un RSE externo.
Subcontratar servicios técnicos en tu proyecto europeo
Si tu proyecto necesita servicios técnicos o digitales que el equipo no puede asumir, esto es lo que dicen las reglas sobre subcontratación y elegibilidad.