Justificación técnica: convertir actividad en evidencias auditables

Faltan tres semanas para el cierre. La AEI espera la justificación técnica del proyecto. El equipo ha hecho mucho trabajo en estos dos años y medio: campañas de campo, datasets recogidos, modelos entrenados, prototipos enseñados en congresos. Pero traducir todo eso en un documento auditable, con figuras, tablas y enlaces a evidencias que un revisor pueda verificar, no se ha empezado. La PI tiene la sensación de que toca reconstruir tres años de actividad en las dos últimas semanas — y no se equivoca.

La justificación técnica de un proyecto de investigación que se entrega al cierre no es la misma que la que defendiste en la propuesta. La de la propuesta argumenta por qué el proyecto debe financiarse. La del cierre demuestra qué se ha hecho realmente con el dinero. Son dos documentos distintos, escritos para audiencias distintas, con criterios de evaluación distintos. Casi todas las guías que encontrarás explican cómo escribir la primera. Esta es sobre la segunda.

Si estás en un proyecto AEI, Plan Estatal, ERC, MSCA o Horizon Europe acercándose al cierre — o a la justificación de medio plazo — este artículo es para ti.

Qué es realmente la justificación técnica de cierre

Es un documento (a veces parte de la memoria final, a veces independiente, según el financiador) que demuestra:

• Qué se ha hecho durante el proyecto, paquete de trabajo a paquete de trabajo
• Cómo se ha hecho — metodología real, no la prometida
• Qué resultados se han obtenido, con evidencias verificables
• Cómo esos resultados se relacionan con los objetivos comprometidos en la propuesta
• Qué desviaciones ha habido y por qué

A diferencia de la justificación económica — que demuestra cómo se ha gastado el dinero — la técnica demuestra qué se ha producido. Para el evaluador final, las dos tienen que cuadrar: el dinero gastado debe corresponderse con la actividad realizada y con las evidencias presentadas.

El error más habitual: tratar la justificación técnica como un ejercicio de redacción retrospectiva. Sentarse en mes 35 a "explicar lo que hicimos". Ese ejercicio funciona si la actividad estuvo bien documentada en tiempo real. Si no, la redacción retrospectiva acaba siendo arqueología — recuperar correos, buscar versiones de Excel en carpetas compartidas, recomponer una metodología que nadie escribió.

La diferencia entre justificación de propuesta y justificación de cierre

Conviene tenerlas separadas mentalmente desde el principio:

| Aspecto | Justificación de propuesta | Justificación técnica de cierre | |---|---|---| | Audiencia | Comité de evaluación de la convocatoria | Evaluador final del proyecto | | Pregunta clave | ¿Por qué este proyecto debe financiarse? | ¿Qué se ha hecho con la financiación? | | Tono | Persuasivo, prospectivo | Demostrativo, retrospectivo | | Contenido principal | Estado del arte, metodología prevista, plan de trabajo | Actividad realizada, resultados, desviaciones, evidencias | | Tipo de evidencia | Bibliografía, antecedentes del equipo | Datasets, código, publicaciones, entregables digitales | | Riesgo si está mal escrita | No te conceden el proyecto | Te conceden menos puntos en la evaluación final, o pagos pendientes condicionados |

La mayoría de equipos sale ganadora de la primera y subóptima de la segunda. La distancia entre ambas es disciplina de documentación durante el proyecto.

Las cinco categorías de evidencia que el evaluador realmente revisa

Tras revisar memorias finales y justificaciones técnicas para AEI, Plan Estatal, ERC y Horizon Europe, los evaluadores miran sistemáticamente cinco categorías de evidencia. Si están bien, la justificación técnica se sostiene; si una falla, suele arrastrar la puntuación.

1. Trazabilidad de actividad

¿Hay evidencia de que la actividad declarada ocurrió realmente? Reuniones de proyecto con actas, asistencias a congresos con certificados o programas, campañas de campo con bitácoras, sesiones experimentales con registros. No hace falta documentar cada minuto, pero sí cada hito relevante.

Cómo se ve cuando está bien: un anexo de actas de las reuniones del consorcio, una tabla de eventos de diseminación con fechas y enlaces, registros de campo firmados.

Cómo se ve cuando está mal: "se realizaron varias campañas de campo" sin fechas, lugares ni evidencias.

2. Trazabilidad de datos

¿Existen los datos que se afirma haber recogido? ¿Pueden los revisores acceder a una versión limpia? ¿Está claro cómo se obtuvieron, procesaron y depositaron?

Cómo se ve cuando está bien: dataset depositado en Zenodo o repositorio institucional con DOI citable, esquema documentado, script de limpieza versionado, mención explícita en la memoria con enlace.

Cómo se ve cuando está mal: "se generó un conjunto de datos de N muestras" sin DOI, sin acceso, sin procesado documentado.

3. Trazabilidad de resultados

¿Las afirmaciones cuantitativas en la memoria pueden trazarse a una tabla, figura o script concretos? Si la memoria dice "mejoramos la precisión un 23%", ¿de qué dataset, con qué métrica, comparado con qué baseline?

Cómo se ve cuando está bien: cada cifra de la prosa se enlaza a un anexo o a una tabla; los anexos referencian los scripts del repositorio que las generan.

Cómo se ve cuando está mal: cifras en el cuerpo del texto sin referencia, generadas en una hoja de cálculo que nadie sabe quién mantiene.

4. Trazabilidad de entregables digitales

¿Los entregables prometidos en el plan de trabajo (apps, dashboards, plataformas, modelos de ML, herramientas) existen y son accesibles? ¿Tienen documentación que un revisor externo pueda seguir?

Cómo se ve cuando está bien: URL estable, README que pasa la prueba del portátil nuevo, credenciales documentadas si requiere autenticación, repositorio de código público o accesible bajo solicitud.

Cómo se ve cuando está mal: "se desarrolló una plataforma web" con un enlace a un servidor caído o a un mock-up de Figma.

5. Justificación de desviaciones

Todo proyecto de investigación se desvía del plan original. Lo que el evaluador valora no es la ausencia de desviaciones, sino su documentación honesta y la justificación científica de las decisiones tomadas.

Cómo se ve cuando está bien: una sección explícita "Desviaciones y modificaciones" que enumera cada cambio respecto a la propuesta, con la justificación científica o operativa, y la consecuencia para los entregables.

Cómo se ve cuando está mal: silencio. El evaluador comparará propuesta y memoria final y verá las desviaciones igualmente. Mejor explicarlas que dejar que las descubra él.

Errores comunes en la justificación técnica de cierre

Después de ver cómo se preparan estas memorias en proyectos AEI, ERC, MSCA y Horizon Europe, los mismos errores aparecen una y otra vez:

• Reconstrucción retrospectiva en las dos últimas semanas. Reescribir la metodología real cuando ya nadie del equipo recuerda con precisión qué se hizo en mes 8. La memoria queda vaga porque la documentación de origen no existe.
• Capturas de Excel como figuras. Cifras citadas en la prosa sin pipeline reproducible detrás. Si el revisor pregunta "¿cómo se calculó este 23%?", la respuesta es "el Mario lo hizo".
• Plataformas digitales no accesibles. El proyecto comprometió un dashboard. Existe un mock-up. La URL del prototipo está caída desde hace meses. El revisor abre el enlace y no carga.
• Repositorios sin documentación. Hay código en GitLab, pero el README está vacío y nadie del equipo recuerda cómo ejecutarlo.
• Evitar mencionar las desviaciones. Pensar que si no se hablan, no se ven. El evaluador las verá comparando propuesta y memoria.
• Justificación técnica desconectada de la económica. El gasto declara una compra de servidor; la justificación técnica no menciona infraestructura. El evaluador detecta la inconsistencia.

Checklist práctico antes de la entrega

Bloquea 90 minutos con el equipo. Para cada paquete de trabajo del proyecto, verifica:

| Comprobación | Puntuación 0–2 | |---|---| | Hay evidencia documental de la actividad realizada (actas, bitácoras, programas de eventos) | | | Los datasets generados están depositados con DOI o son accesibles bajo solicitud documentada | | | Cada afirmación cuantitativa de la memoria traza a una tabla, figura o script | | | Los entregables digitales están accesibles desde fuera del entorno del equipo | | | Las desviaciones respecto a la propuesta están documentadas con justificación | | | Los repositorios de código tienen README que pasa la prueba del portátil nuevo | | | La justificación técnica y la económica no se contradicen entre sí | | | Hay un anexo metodológico que un revisor externo podría reproducir | |

Total sobre 16. Por debajo de 10: alto riesgo de observaciones del evaluador. Por debajo de 6: pide ayuda externa antes de la entrega.

Cuándo conviene incorporar ayuda externa

Un proyecto de cierre digital es la decisión correcta cuando:

• La justificación técnica está pendiente y faltan menos de 8 semanas
• El equipo tiene la información dispersa pero no la capacidad de ingeniería para construir las evidencias auditables (datasets depositados, plataformas desplegadas, repositorios documentados)
• El proyecto tiene desviaciones significativas respecto a la propuesta que requieren explicación cuidadosa
• Los entregables digitales prometidos existen como prototipos pero no como artefactos accesibles
• La revisión de medio plazo o intermedia ya señaló observaciones técnicas que no se han resuelto

Para esto está construido nuestro Pack digital de cierre de proyecto. Cubrimos la parte técnica: depósito de datasets en repositorio con DOI, despliegue de entregables digitales con documentación, pipelines de análisis reproducibles, anexo metodológico auditable y conexión coherente con la justificación económica. La duración típica es 3–6 semanas.

Tres cosas para hacer esta semana

1. Localiza la última versión de la memoria final o de la justificación técnica intermedia, si existe. Si no existe, dedica 60 minutos a esbozar el índice contra el plan de trabajo de la propuesta.
2. Para el paquete de trabajo más crítico, ejecuta el checklist de 90 minutos. Anota las tres comprobaciones más débiles.
3. Si la entrega está a menos de 8 semanas y dos o más comprobaciones críticas están en rojo, solicita una revisión de proyecto. Evaluaremos qué evidencias se pueden construir en el tiempo disponible y cuáles conviene reformular.

La justificación técnica que sobrevive al evaluador no es la más larga ni la más elegante. Es la que tiene cada afirmación trazable a una evidencia concreta, cada desviación documentada con honestidad, y cada entregable digital accesible cuando el revisor abra el enlace. Lo demás es prosa.