Skip to main content
All articles
reproducibility provenance scientific-ai validation

Reproducible vs Caja Negra

Lo que la reproducibilidad exige realmente en la ciencia asistida por IA: manifiestos de procedencia, scripts deterministas, hashing criptográfico y validación de texto anclado.

Jeff Jaureguy ·

La reproducibilidad es un problema de ingeniería, no de política

Toda revista científica, agencia de financiación y organismo regulador enfatiza hoy la reproducibilidad. Se han redactado políticas. Se han publicado directrices. Y sin embargo, la crisis de reproducibilidad persiste — no porque los investigadores carezcan de buena voluntad, sino porque la mayoría de las herramientas computacionales hacen que la reproducibilidad sea posible en teoría e impracticable en la realidad.

La brecha entre un análisis reproducible y un análisis de caja negra no está en si podrías reproducir el trabajo. Está en si tus herramientas hacen que la reproducción sea el comportamiento por defecto — o una ocurrencia tardía que exige un esfuerzo heroico.

Un flujo de trabajo reproducible es aquel en el que el esfuerzo para reproducir es menor que el esfuerzo para dudar.

Qué exige realmente la reproducibilidad

La reproducibilidad en la investigación computacional no es una única propiedad. Es una pila de requisitos, cada uno apoyado en el anterior. Elimina cualquier capa y toda la estructura se vuelve poco fiable.

La pila de reproducibilidad

CapaRequisitoQué significa
DatosEntradas inmutables con verificación de integridadArchivos de datos crudos con checksums SHA-256; cualquier modificación crea una nueva versión
EntornoEspecificación exacta del entorno computacionalSO, versión del lenguaje, versiones de librerías, dependencias del sistema — todo fijado
CódigoScripts de transformación bajo control de versionesCódigo rastreado por Git con historial de commits significativo; sin cuadernos “mágicos”
PipelineOrden de ejecución deterministaUn sistema de construcción o gestor de flujos de trabajo que ejecuta los pasos en el orden correcto
ProcedenciaSeguimiento completo del linajeUn manifiesto que registra cada entrada, transformación, salida, marca temporal y hash
ValidaciónVerificación automatizada de salidasTests que confirman que las salidas tienen las propiedades esperadas (dimensiones, rangos, tipos)
TextoAfirmaciones ancladasToda frase del resultado referencia un artefacto específico del manifiesto

La mayoría de las herramientas aborda una o dos capas. Un cuaderno bajo control de versiones gestiona el código pero no el entorno. Un contenedor gestiona el entorno pero no la procedencia. Un asistente de escritura gestiona el texto pero no el anclaje.

La reproducibilidad exige las siete capas funcionando juntas.

El espectro de caja negra

“Caja negra” no es binario. Las herramientas se sitúan en un espectro desde totalmente transparentes hasta completamente opacas, y muchas herramientas que parecen transparentes tienen componentes opacos enterrados en sus pipelines.

Reconocer el comportamiento de caja negra

Una herramienta exhibe comportamiento de caja negra cuando se cumple cualquiera de las siguientes condiciones:

  • Salidas no deterministas: Ejecutar el mismo análisis dos veces con las mismas entradas produce resultados diferentes (común con texto generado por IA, algoritmos estocásticos sin semillas fijadas, o llamadas a APIs de servicios que actualizan sus modelos)
  • Procedencia ausente: No puedes determinar qué versión del código, qué versión del modelo o qué configuración produjo una salida específica
  • Transformaciones opacas: Un paso del pipeline transforma los datos de un modo que no puedes inspeccionar ni verificar (común con APIs alojadas que reciben datos y devuelven resultados)
  • Dependencias implícitas: El análisis depende de estado externo — una base de datos que ha sido actualizada, un modelo que ha sido reentrenado, un servicio que ha cambiado su comportamiento

Si no puedes responder “¿qué produjo exactamente esta salida?” con un hash de commit específico, un hash de entrada y una especificación de entorno, estás operando una caja negra.

La auditoría de caja negra

Para cada paso de tu pipeline computacional, responde a estas preguntas:

  1. ¿Es la salida determinista? Dadas entradas y entorno idénticos, ¿producirá este paso siempre una salida idéntica byte a byte?
  2. ¿Es la transformación inspeccionable? ¿Puedes leer el código fuente que realiza este paso?
  3. ¿Es el entorno reproducible? ¿Puedes recrear el entorno computacional exacto donde se ejecutó este paso?
  4. ¿Está la procedencia registrada? ¿Existe un registro legible por máquina de entradas, salidas, versiones y marcas temporales?
  5. ¿Es la salida verificable? ¿Puedes confirmar que la salida tiene las propiedades esperadas sin volver a ejecutar el análisis?

Cualquier respuesta “no” identifica una brecha de reproducibilidad.

Manifiestos de procedencia: la solución de ingeniería

Un manifiesto de procedencia es un registro estructurado de todo lo que contribuyó a un resultado de investigación. Es la solución de ingeniería al problema de la reproducibilidad — no un documento de política, sino un artefacto legible por máquina que puede generarse y verificarse automáticamente.

Qué contiene un manifiesto

{
  "version": "1.0",
  "created": "2026-03-13T10:30:00Z",
  "inputs": [
    {
      "file": "data/rnaseq_counts.csv",
      "sha256": "a3f2b8c9d1e4f5a6b7c8d9e0f1a2b3c4d5e6f7a8",
      "rows": 58347,
      "columns": 12
    }
  ],
  "environment": {
    "os": "Ubuntu 22.04",
    "python": "3.11.7",
    "packages": "requirements.lock"
  },
  "steps": [
    {
      "script": "scripts/normalize.py",
      "git_sha": "abc123",
      "duration_seconds": 12.4,
      "output_hash": "b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3"
    }
  ],
  "outputs": [
    {
      "file": "figures/volcano_plot.png",
      "sha256": "c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4",
      "referenced_in": ["results.md:L42", "results.md:L67"]
    }
  ]
}

Este manifiesto cumple múltiples propósitos:

  • Verificación: Cualquiera puede comprobar que los hashes de salida coinciden, confirmando que las salidas no han sido modificadas
  • Reproducción: El entorno y las versiones de scripts se especifican con la precisión suficiente para recrear el análisis
  • Auditoría: La cadena completa desde los datos crudos hasta la salida final queda documentada en un único archivo legible por máquina
  • Anclaje: El campo referenced_in conecta cada artefacto con ubicaciones específicas del texto, permitiendo la validación automatizada de texto anclado

Scripts deterministas vs cuadernos interactivos

Los cuadernos interactivos son populares para el análisis exploratorio, y con buena razón — permiten iteración rápida y retroalimentación visual. Pero introducen riesgos de reproducibilidad bien documentados y ampliamente conocidos:

  • Ambigüedad en el orden de ejecución: Las celdas pueden ejecutarse en cualquier orden, y el estado del kernel depende de ese orden
  • Estado oculto: Las variables persisten entre celdas, creando dependencias implícitas que no son visibles en el código fuente del cuaderno
  • Deriva de entorno: El cuaderno se ejecuta en el entorno actualmente activo, que puede diferir del entorno en que el análisis se realizó por primera vez
PropiedadCuaderno interactivoScript determinista
Orden de ejecuciónArbitrario (controlado por el usuario)Fijo (orden del script o DAG del pipeline)
Estado ocultoPosible (variables persistentes del kernel)Imposible (cada ejecución parte de cero)
ReproducibilidadExige disciplina cuidadosaComportamiento por defecto
ProcedenciaManual (si se registra)Automática (sistema de construcción + manifiesto)
ColaboraciónConflictos de fusión habitualesFlujos de trabajo git estándar

Esto no significa que los cuadernos deban abandonarse. Significa que pertenecen a la fase de exploración de la investigación, no a la de producción. Cuando un análisis pasa de la exploración a la publicación, debe convertirse en scripts deterministas con seguimiento de procedencia.

Validación de texto anclado

La capa final de la pila de reproducibilidad aborda un problema sutil pero crítico: incluso cuando el procesamiento de datos es totalmente reproducible, el texto que describe los resultados puede divergir de lo que los datos realmente muestran.

La validación de texto anclado es una comprobación automatizada que verifica que toda afirmación de un documento referencia un artefacto específico:

  • “La expresión de TP53 se reguló al alza significativamente (Figura 2A, p = 0,003)” — válida, referencia la Figura 2A y un valor p específico que puede verificarse contra el JSON de estadísticas
  • “Nuestros resultados sugieren una diana terapéutica prometedora” — inválida, hace una afirmación sin referenciar ningún artefacto específico
  • “Observamos expresión diferencial en 1.247 genes” — válida solo si el número 1.247 aparece en el JSON de estadísticas o en los datos fuente

La validación de texto anclado no limita lo que puedes escribir. Garantiza que lo que escribes puede verificarse.

Esta validación puede automatizarse. Un script puede analizar el texto, identificar afirmaciones que referencian artefactos, comprobar esas referencias contra el manifiesto y señalar cualquier afirmación sin referencia concreta. El resultado es un documento donde toda afirmación factual es rastreable hasta su fuente — no porque el investigador fuera meticuloso, sino porque la herramienta lo impuso.

Construir un pipeline reproducible

Si tu pipeline actual tiene componentes de caja negra, abordarlos no exige reconstruirlo todo de una vez. Empieza por los pasos de mayor riesgo: aquellos que producen salidas que aparecen en publicaciones o presentaciones regulatorias.

Para cada paso:

  1. Sustituye las llamadas a APIs alojadas por alternativas autoalojadas cuando sea posible
  2. Fija todas las dependencias (versión del lenguaje, versiones de librerías, paquetes del sistema)
  3. Añade seguimiento de procedencia (hashes de entrada, hashes de salida, marcas temporales, git SHAs)
  4. Escribe tests de validación que comprueben las propiedades de la salida
  5. Convierte cuadernos en scripts para las ejecuciones de producción

Las herramientas y prácticas para el cómputo reproducible están maduras. Contenedores, lockfiles, sistemas de construcción y manifiestos de procedencia son soluciones de ingeniería bien comprendidas. El reto restante es la adopción — elegir herramientas que hagan que la reproducibilidad sea el comportamiento por defecto en lugar de un complemento opcional.


Hordago Labs construye pipelines reproducibles y basados en evidencia para investigación biológica. Toda salida incluye un manifiesto de procedencia con verificación criptográfica. Consulta nuestra plataforma o lee por qué el código abierto importa para la reproducibilidad científica.