Traceable Trust for action-ready artificial intelligence in bioscience

El problema que resuelve

En biosciencia, la IA ya no es solo una herramienta de predicción: empieza a formar parte de la infraestructura de trabajo del laboratorio. Un modelo puede predecir estructuras biomoleculares, diseñar proteínas, priorizar variantes, anotar imágenes, recomendar cepas u optimizar condiciones experimentales. El problema de fondo no es que la IA produzca una salida, sino qué ocurre después: si esa salida se usa para decidir una acción real, como preparar una reacción, seleccionar una mutante, programar una secuencia de síntesis o priorizar un ensayo.

El paper aborda una grieta importante entre el rendimiento de un modelo y su uso responsable en investigación. Una métrica de precisión no basta. Una estructura predicha no basta. Una recomendación de variante no basta. Lo que falta es una capa de confianza operativa: un mecanismo que permita demostrar, de forma auditable, por qué una salida concreta de IA puede usarse para guiar una acción de laboratorio. El argumento central, tal como lo plantea el resumen, es que la decisión de usar un resultado de IA no debe ser un salto de fe, sino un punto crítico de gobernanza técnica, sujeto a un proceso definido y revisable.

En términos prácticos, el problema es de trazabilidad epistémica. No se trata solo de saber “qué dijo el modelo”, sino de poder responder: qué datos alimentaron la predicción, qué versión del modelo la produjo, qué contexto experimental se asumió, qué incertidumbre acompaña la salida, qué evidencias externas la soportan, qué restricciones de seguridad o de dominio se aplicaron y quién validó la decisión final. Sin esa cadena, la IA se convierte en una caja negra operativa: útil, pero difícil de auditar cuando la acción tiene consecuencias experimentales, económicas o de seguridad.

Arquitectura y mecanismo (con detalle técnico)

A partir del resumen disponible, el mecanismo central no parece ser un nuevo modelo de IA, sino una arquitectura de confianza trazable alrededor de la salida del modelo. La idea puede leerse como un sistema de provenance para decisiones de laboratorio: cada recomendación de IA se envuelve en un registro que vincula la acción propuesta con su base de evidencia.

Una implementación coherente tendría al menos cinco capas.

Primero, una capa de identificación. Cada salida de IA debe tener un identificador estable, una versión de modelo, una versión de prompt, una versión de dataset o corpus, parámetros de inferencia y un timestamp. Esto evita la ambigüedad típica de los pipelines de IA: “¿qué versión de la cadena generó este resultado?”. En un entorno de investigación, esa ambigüedad es inaceptable cuando se actúa sobre el resultado.

Segundo, una capa de evidencia. La salida no se evalúa en el vacío. Debe ligarse a evidencias recuperables: papers, datasets, estructuras, ensayos, organismos, vías biológicas, métricas de validación y restricciones de dominio. En biosciencia esto es especialmente importante porque la validez de una predicción depende del contexto: una variante puede ser plausible en un organismo, en una expresión proteica o en una condición experimental, pero no en otra.

Tercero, una capa de incertidumbre y confianza. No basta con un score de probabilidad. El sistema debe capturar confianza calibrada, calidad de los datos, cobertura del dominio, conflictividad entre fuentes y grado de validación experimental. Una recomendación con alta confianza numérica pero baja evidencia experimental debería ser tratada de forma distinta a una recomendación respaldada por múltiples fuentes independientes.

Cuarto, una capa de revisión y aprobación. El mecanismo debe incorporar una frontera humana o institucional: quién revisa la salida, bajo qué criterios y con qué autoridad para aprobarla. En un pipeline de laboratorio, esa revisión no es un adorno burocrático; es parte del diseño técnico. La salida de IA puede ser “action-ready” solo si supera un umbral de confianza, cumple políticas de seguridad y ha sido revisada por el actor competente.

Quinto, una capa de trazabilidad de la acción. Cuando la salida se convierte en una acción experimental, el sistema debe registrar esa transición. No solo “el modelo propuso X”, sino “el laboratorio decidió ejecutar X a partir de la salida Y, bajo la revisión Z, usando la evidencia W”. Esto permite auditoría posterior: si el experimento falla, se puede rastrear si el problema estuvo en el modelo, en los datos, en la interpretación, en la revisión o en la ejecución.

Desde el punto de vista técnico, este mecanismo puede implementarse como un grafo de provenance. Cada nodo representa un artefacto: paper, dataset, modelo, prompt, predicción, evidencia, revisión, acción experimental. Cada arista representa una relación: producedBy, supportedBy, reviewedBy, constrainedBy, enabledAction. Esa estructura permite consultas potentes: “¿qué acciones de laboratorio derivan de este modelo?”, “¿qué evidencias soportan esta recomendación?”, “¿qué salidas fueron aprobadas sin revisión humana?” o “¿qué cambios de modelo afectaron decisiones experimentales en los últimos 30 días?”.

Qué lo hace genuinamente nuevo

Lo más relevante del paper no es que proponga un modelo nuevo, sino que desplaza la unidad de análisis. En muchos trabajos de IA para ciencias de la vida, la unidad de análisis es el modelo: su precisión, su F1, su AUC, su capacidad de predicción. Aquí la unidad de análisis es la decisión de usar la salida para actuar. Ese cambio de perspectiva es importante.

También diferencia el enfoque de los marcos generales de IA confiable. La confianza no se trata como una propiedad abstracta del sistema, sino como una propiedad local de una salida concreta en un contexto concreto. No pregunta “¿es este modelo confiable?”, sino “¿puede esta salida específica, con esta evidencia específica, bajo estas restricciones específicas, guiar una acción experimental justificable?”. Esa granularidad es lo que la hace útil en un laboratorio real.

Otra novedad es la orientación a “action-ready”. No se trata de producir información, sino de habilitar acción de forma responsable. Eso introduce requisitos de ingeniería de software: versionado, trazabilidad, revisión, rollback, auditoría y control de acceso. La IA deja de ser un oráculo y se convierte en un componente de un pipeline gobernado.

Finalmente, el enfoque en biosciencia no es decorativo. La biosciencia tiene características que hacen especialmente peligrosa la opacidad: datos heterogéneos, validación experimental costosa, organismos vivos, reacciones químicas, seguridad biológica y consecuencias que pueden no ser reversibles. Un marco de confianza debe adaptarse a ese dominio, no limitarse a métricas genéricas de clasificación.

Cómo integrarlo en Zeropithos o Dibroclaw (componente concreto: RAG, BDI, knowledge graph, inferencia, seguridad + pasos de implementación)

La integración más natural en Zeropithos sería un módulo llamado Action Provenance Gate, que conecte el pipeline RAG, el knowledge graph, el loop BDI y la capa de inferencia local. El objetivo sería que ninguna respuesta o recomendación derivada del agente se considere “lista para acción” sin pasar por una verificación de provenance.

El componente concreto sería un ProvenanceBundle generado por el RAG en Rust. En lugar de devolver solo texto recuperado, el RAG devolvería un paquete estructurado con: fuentes recuperadas, identificadores de papers, hashes de chunks, metadatos de dataset, versión del modelo, parámetros de inferencia, confianza estimada, restricciones de dominio y posibles conflictos entre fuentes. Ese bundle sería la unidad mínima de decisión.

El knowledge graph en Fuseki/SPARQL almacenaría la ontología de confianza. Podría usar relaciones como zp:hasProvenance, zp:supportsEvidence, zp:reviewedBy, zp:enablesAction, zp:violatesPolicy y zp:derivesFrom. Cada nodo de paper, modelo, dataset, claim o acción tendría identificadores estables. Esto permitiría que el agente no solo recupere contexto, sino que audite la cadena de justificación.

El loop BDI sería donde se aplica la gobernanza. Las beliefs representarían el estado de confianza: “hay evidencia suficiente para esta recomendación”, “la fuente es primaria”, “no hay conflicto con seguridad biológica”. Los desires representarían objetivos experimentales: “priorizar una variante para mejorar estabilidad térmica”. Las intentions solo se materializarían si el ProvenanceBundle cumple una política. Por ejemplo, para una recomendación de laboratorio, la política podría exigir: al menos un paper primario, un dataset validado, revisión humana, ausencia de conflicto de seguridad y registro de la decisión en el grafo.

La inferencia local con llama-server en GPU de 32 GB podría usarse para generar explicaciones, resumir evidencias y redactar auditorías, pero no debería ser la autoridad final de la decisión. La decisión debe ser determinística y verificable. Para auditoría, se deberían registrar prompts, semillas, temperatura, versión del modelo, hashes de entrada y salida. Si la temperatura es cero o el sampling está controlado, la cadena de inferencia puede reproducirse más fácilmente.

En seguridad, WireGuard protegería la comunicación hacia la infraestructura, pero el control de acceso interno debe ser más fino. El sistema debería distinguir roles: lectura de corpus, generación de explicaciones, aprobación de acciones, ejecución de pipelines y auditoría. Los registros de decisión deberían ser inmutables, firmados o con hash, y consultables mediante SPARQL. Un pipeline de Dagster podría orquestar la ingesta, la actualización del grafo, la revalidación de políticas y la generación de reportes de auditoría.

Pasos de implementación concretos:

1. Definir una ontología mínima de provenance para IA en biosciencia, con nodos de Paper, Model, Dataset, Claim, Evidence, Review, Action y Policy.
2. Modificar el RAG en Rust para emitir ProvenanceBundle junto a cada respuesta, con metadatos y hashes.
3. Almacenar esos bundles en Fuseki/SPARQL como triples auditables.
4. Añadir un policy engine en el BDI que evalúe si una intención puede convertirse en acción.
5. Registrar toda aprobación humana como nodo de Review vinculado a la acción.
6. Exponer consultas de auditoría: acciones por modelo, acciones por paper, acciones aprobadas sin revisión, acciones con evidencia conflictiva.
7. Generar reportes periódicos con Dagster sobre la salud del pipeline de confianza.

Retos prácticos (VRAM, datos, dependencias)

El primer reto es VRAM. Con una GPU de 32 GB, es posible ejecutar modelos de 13B a 27B con buen margen, o modelos más grandes con cuantización agresiva, pero el contexto largo, los embeddings y la inferencia explicativa compiten por memoria. Si el sistema necesita modelos de 70B para generar auditorías de alta calidad, puede ser necesario usar cuantización Q4/Q5, limitar el contexto, descargar pesos al CPU o alternar entre modelos ligeros para triage y modelos grandes para revisión profunda.

El segundo reto es la heterogeneidad de datos. Biosciencia combina papers, secuencias, estructuras, imágenes, ensayos, organismos y condiciones experimentales. Normalizar eso no es trivial. Se necesitan ontologías y identificadores estables: UniProt, PDB, Gene Ontology, ChEBI, accession numbers, organismos, vías y tipos de ensayo. Sin normalización, el grafo de provenance se vuelve ruidoso y difícil de auditar.

El tercer reto es la calibración de confianza. Un modelo puede parecer confiado aunque esté equivocado. El sistema no puede depender solo de la confianza declarada por el modelo. Debe combinar señales externas: calidad de la fuente, consistencia entre papers, validación experimental, antigüedad del dataset y cobertura del dominio. Esto exige métricas compuestas, no un solo score.

El cuarto reto es la complejidad de dependencias. El stack probablemente requeriría Rust para el RAG y el agente ReAct, Fuseki para SPARQL, Dagster para orquestación, un vector store para retrieval, llama.cpp para inferencia local, Python para ETL de papers y datasets, y un policy engine para reglas de aprobación. Mantener esa integración estable es un problema real de ingeniería, no solo de investigación.

También hay riesgos de uso indebido. Si el gate de confianza es demasiado laxo, se convierte en un sello decorativo. Si es demasiado estricto, el sistema se vuelve inutilizable. El diseño debe equilibrar seguridad, trazabilidad y productividad experimental.

Conclusión

El paper propone una idea que encaja directamente con la infraestructura de Zeropithos: la confianza en IA para biosciencia no debería medirse solo por la calidad de la predicción, sino por la trazabilidad de la decisión que permite. En lugar de preguntar “¿el modelo es bueno?”, el enfoque relevante es “¿esta salida específica puede justificarse como base para una acción experimental?”.

Para Dibroclaw o Zeropithos, la integración más valiosa sería un gate de provenance que conecte RAG, knowledge graph, BDI, inferencia local y seguridad. El sistema no solo respondería, sino que demostraría por qué una respuesta puede usarse. Eso convierte al agente de IA en un componente auditable de un pipeline científico, no en una caja negra que produce recomendaciones. En un dominio donde la acción experimental tiene coste, riesgo y consecuencias, esa trazabilidad no es un extra: es la condición mínima para que la IA sea realmente útil.