Respuesta directa
En pocas palabras
El lineage de un sistema de IA es un grafo de entidades versionadas, ejecuciones y responsables que permite recorrer desde un resultado hasta el release, modelo, prompt, datos, fuentes RAG, herramientas, política y evaluación que intervinieron. La reproducibilidad no exige obtener siempre el mismo texto: exige poder reconstruir la configuración, entradas autorizadas, versiones, parámetros y condiciones conocidas, además de explicar qué no puede repetirse. Un lineage útil se captura durante cada ejecución, usa identificadores inmutables y conserva las relaciones, no solo una lista de versiones.
Distingue lineage, versionado, procedencia y reproducibilidad
Lineage describe cómo se relacionan objetos, ejecuciones y decisiones a lo largo del tiempo. Versionado identifica estados distintos de un componente. Procedencia explica de dónde vino un artefacto y cómo se produjo. Reproducibilidad permite reconstruir una ejecución con la evidencia y las condiciones registradas. Se complementan, pero una tabla con números de versión no demuestra ninguna de las otras tres capacidades.
Define la pregunta que el sistema debe responder. Por ejemplo: qué combinación preparó una propuesta, qué dataset alimentó una evaluación, qué release estaba activo durante un incidente o qué consumidores dependen de una fuente que debe retirarse. El alcance determina qué nodos y relaciones hacen falta. Registrar todo sin consultas concretas produce una base costosa que nadie sabe utilizar.
Modela entidades, actividades y agentes como un grafo
El modelo PROV-DM del W3C separa entidades, actividades y agentes. Una entidad puede ser un dataset, prompt, modelo, evaluación, política, release o respuesta. Una actividad usa o genera entidades: entrenar, indexar, evaluar, promover, desplegar o inferir. Un agente asume responsabilidad: persona, equipo, servicio o proveedor. Las relaciones permiten expresar uso, generación, derivación, atribución y asociación.
Adapta ese vocabulario sin copiarlo de forma ceremonial. Cada nodo necesita un identificador estable, tipo, tiempo y ubicación o referencia. Cada arista expresa un hecho: ejecución usó prompt, evaluación calificó release, despliegue resolvió digest o decisión autorizó promoción. Evita una arista genérica relacionado con; si la relación no dice qué ocurrió, no ayuda a reconstruir ni analizar impacto.
| Criterio | Ejemplo | Pregunta que responde |
|---|---|---|
| Entidad | Prompt, dataset, modelo, reporte | ¿Qué objeto exacto intervino? |
| Actividad | Evaluación, build, inferencia | ¿Qué ocurrió y qué usó o produjo? |
| Agente | Pipeline, proveedor, aprobador | ¿Quién ejecutó o asumió responsabilidad? |
| Contexto | Release, experimento, incidente | ¿En qué recorrido se agrupan los hechos? |
Asigna identidad inmutable a cada estado material
Usa digest para contenido, commit para código, versión de esquema para contratos y un identificador único para ejecuciones y decisiones. Si cambia el contenido de un prompt, la selección de fuentes, una regla, un conjunto de evaluación o la configuración de una herramienta, existe una entidad nueva. Un nombre legible y un alias ayudan a descubrir, pero no deben sobrescribir la identidad anterior.
Distingue versión declarada y contenido resuelto. Un endpoint llamado modelo-estable puede cambiar detrás del mismo nombre; una consulta RAG puede leer documentos que se actualizaron; una herramienta SaaS puede publicar comportamiento nuevo sin exponer digest. Conserva el identificador más preciso disponible, la hora, la región y la evidencia del proveedor. Si una dependencia no permite fijar versión, registra esa limitación como fuente de no reproducibilidad.
Crea un sobre de versión para el sistema completo
El comportamiento de un AI Sales Copilot no depende solo del modelo. El sobre de release relaciona aplicación, modelo y parámetros, instrucciones, plantillas, fuentes RAG, índice, reglas, herramientas, permisos, feature flags, policy bundle, esquema de datos y configuración visible. También enlaza pruebas, evaluación, aprobación, rollout, monitoreo y rollback.
No copies secretos dentro del sobre. Registra versión o identificador de la configuración y una referencia al gestor autorizado. Separa configuración pública, material sensible y estado dinámico. Dos ejecuciones con el mismo modelo pueden diferir porque una recuperó otra fuente o utilizó una herramienta con permisos distintos. La unidad reproducible es la combinación resuelta, no el nombre del modelo aislado.
Captura inputs y outputs en el momento de cada actividad
TensorFlow ML Metadata registra artifacts, executions, events y contexts. Sus eventos vinculan cada ejecución con los artefactos usados y producidos, lo que permite recorrer inputs aguas arriba y outputs aguas abajo. Aplica el mismo principio aunque utilices otra tecnología: la relación debe escribirse durante la actividad, no reconstruirse meses después desde nombres de archivos.
Para una inferencia registra execution ID, release envelope, rol, fuente de solicitud, artefactos recuperados, llamadas de herramienta, política aplicada, salida y resultado operativo autorizado. Para un build registra inputs, parámetros, entorno y outputs. Usa un evento idempotente y una hora confiable. Si la telemetría se pierde, marca un hueco; no inventes relaciones para completar el dibujo.
Fija snapshots o manifiestos de las fuentes mutables
Una consulta, URL o nombre de colección no identifica el contenido leído. Para datasets y RAG conserva snapshot, digest de manifest, lista versionada de documentos o watermark verificable. Registra transformaciones, filtros, chunking, embeddings, modelo de embeddings, parser y versión del índice. Si el volumen impide guardar una lista completa en cada ejecución, referencia un manifest inmutable compartido.
Distingue dato de negocio actual y evidencia histórica. No debes congelar para siempre una copia completa del CRM solo para reproducir una sugerencia. Conserva los identificadores, versiones y hechos mínimos permitidos, la salida observada y, cuando proceda, un snapshot protegido con retención definida. Reproducibilidad no autoriza duplicar datos personales, secretos o material de terceros sin necesidad.
Relaciona cada evaluación con la versión que realmente midió
Una puntuación sin lineage puede pertenecer a otro modelo, prompt, dataset, juez, criterio o fecha. La ejecución de evaluación debe enlazar el sobre candidato, suite y versión de casos, datos permitidos, métricas, juez humano o automático, thresholds, código y reporte. Conserva resultados por escenario; un promedio no permite localizar qué control crítico falló.
Cuando una versión cambia, recorre el grafo para decidir qué pruebas repetir. Un ajuste de copy puede requerir regresiones de claridad; un cambio de permisos, fuente, herramienta o moneda exige casos de seguridad y negocio. El resultado aprobado no se hereda automáticamente por compartir modelo base. Registra diferencias, decisión y riesgos conocidos para que cada conclusión tenga alcance explícito.
Haz de la aprobación y la promoción nodos auditables
La decisión usa evidencia y produce una autorización acotada. Registra versión candidata, criterio, política, evaluaciones, hallazgos, excepciones, aprobadores, alcance, vigencia y resultado: aprobar, condicionar, rechazar o pedir evidencia. La promoción usa esa decisión y produce un evento distinto. Aprobar no demuestra que el despliegue ocurrió; desplegar no demuestra que estaba aprobado.
MLflow permite relacionar versiones con source run, aliases y tags. También advierte que los aliases pueden reasignarse. Conserva el alias como referencia operativa y el identificador exacto como evidencia histórica. Un grafo debe mostrar qué digest resolvió champion en cada despliegue, no solo cuál resuelve hoy. Así el rollback selecciona un estado conocido sin reescribir el pasado.
Observa la combinación que el runtime resolvió de verdad
El estado deseado vive en el registro y el estado efectivo vive en producción. En inicio o despliegue, el runtime resuelve referencias y publica release, digests, configuración y policy revision efectivas. Cada ejecución conserva esa identidad. Reconciliar descubre versiones no registradas, aliases movidos, cachés vencidos, fuentes incompletas o workers que nunca actualizaron.
Para recorridos distribuidos propaga un correlation ID sin incluir contenido sensible. Une solicitud, recuperación, inferencia, herramientas y resultado final. Define qué ocurre si una capa no puede adjuntar su versión: bloquear una acción crítica, marcar la salida como no reproducible o entrar en modo limitado. No presentes una traza parcial como historia completa.
Prepara una receta de reproducción segura y honesta
La receta recupera el sobre, inputs permitidos, parámetros, reloj o ventana temporal, seeds cuando apliquen, identidades simuladas y dependencias. Se ejecuta en un ambiente aislado, sin acciones reales y con datos sintéticos o minimizados cuando sea posible. Compara hechos obligatorios, fuentes, herramientas, decisiones y propiedades de salida; no exige el mismo estilo palabra por palabra si el sistema es estocástico.
Clasifica el resultado: reproducido, equivalente dentro del criterio, no reproducido o no reproducible. Explica la causa: dependencia mutable, datos eliminados, proveedor cambiado, aleatoriedad, versión desconocida o evidencia incompleta. Preservar una salida histórica puede ser suficiente para investigar un caso aun cuando no sea legal o técnicamente posible recrear todas sus entradas.
Conserva ramas y comparaciones sin mezclar producción
Un experimento deriva una entidad candidata desde una base conocida. Registra hipótesis, cambio, población, datos, evaluación y resultado. Las variantes comparten ancestros, pero mantienen identidades propias. No sobrescribas el prompt estable con el candidato ni reutilices el mismo ID de índice para dos contenidos. Agrupa mediante contexto de experimento y conserva la arista de derivación.
Al promover, crea una decisión y un release; no conviertas el experimento en producción cambiando una etiqueta sin historial. Si combinas cambios de varias ramas, genera un sobre nuevo y repite las pruebas necesarias. La comparación debe controlar lo que permanece fijo. Si modelo, dataset y herramienta cambian a la vez, la diferencia observada no puede atribuirse a un solo componente.
Usa el grafo para analizar impacto, incidentes y retiro
Recorre aguas abajo para saber qué modelos, evaluaciones, releases y respuestas utilizaron un dataset, biblioteca, prompt o proveedor afectado. Recorre aguas arriba para reconstruir una salida, incidente o decisión. Define límites de profundidad y tiempo para que una consulta no se vuelva inmanejable. Guarda índices de relaciones frecuentes y prueba que no existan nodos huérfanos críticos.
Ante un hallazgo, marca el nodo y sus relaciones; no borres la evidencia antes de identificar consumidores. El retiro puede bloquear nuevos usos, mover aliases, contener releases y abrir reevaluaciones. Después documenta qué se corrigió y qué historial permanece. Un grafo ayuda a encontrar alcance, pero no sustituye el juicio de seguridad, privacidad, legal, datos y negocio.
Define retención, acceso y eliminación para el lineage
El grafo puede revelar arquitectura, proveedores, personas, clientes y operaciones. Aplica acceso por función, cifrado, registros de consulta y separación por organización. Conserva identificadores y relaciones; evita almacenar prompts completos, credenciales o datos personales cuando un hash, manifest o referencia controlada basta. La evidencia restringida puede vivir fuera del grafo con autorización propia.
Alinea retención con incidentes, contratos, privacidad y rollback. Cuando elimines un artefacto, conserva un tombstone permitido con ID, tipo, momento y razón para no romper la historia. Si una solicitud exige borrar datos personales, elimina o desvincula el contenido correspondiente sin falsificar que la ejecución nunca existió. Documenta qué preguntas dejarán de poder responderse.
Mide cobertura y capacidad de respuesta, no cantidad de nodos
Prueba consultas operativas: reconstruir una respuesta, hallar consumidores de un dataset, comparar dos releases, identificar producción por digest y localizar evaluaciones vencidas. Mide ejecuciones con sobre completo, relaciones faltantes, nodos sin propietario, fuentes mutables sin snapshot, deployments discrepantes, decisiones sin evidencia y tiempo para responder una investigación.
NIST AI RMF Playbook propone inventariar sistemas y artefactos para mantenimiento, responsabilidad e incidentes como práctica voluntaria. El lineage aporta relaciones técnicas y operativas al inventario, pero no demuestra por sí solo que el sistema sea válido, seguro o conforme. Revisa calidad del grafo por muestreo y por incidentes reales; una cobertura declarada del cien por ciento no sirve si las aristas son ambiguas.
Aplica lineage al release y los recorridos de Cerravi
En Cerravi, el release ID relaciona código, imagen, dependencias, migraciones, configuración pública, pruebas, guías, system card, AI/ML-BOM, provenance y evidencia de despliegue. El runtime publica el release efectivo; readiness, journal, backup y rollback conservan la secuencia. Para un recorrido comercial, el execution ID puede enlazar rol, fuentes autorizadas, propuesta, catálogo, monedas y salida visible sin duplicar datos sensibles dentro del grafo.
Lineage no amplía la autoridad del producto. Cerravi organiza contexto y propone siguientes pasos para revisión humana; los recorridos públicos no envían mensajes ni cambian etapas automáticamente. Las propuestas utilizan productos y precios conocidos y solicitan confirmación si falta un importe. Forecast aplica reglas transparentes del CRM, no es un modelo predictivo entrenado o calibrado y no garantiza cierres. Poder reconstruir una versión mejora la investigación; no certifica seguridad, cumplimiento o resultado comercial.
Preguntas frecuentes
Dudas comunes sobre este proceso
¿Qué es el lineage de un sistema de IA?
Es el grafo que vincula entidades versionadas, ejecuciones y responsables. Permite recorrer desde una salida hasta el release, modelo, prompt, datos, fuentes, herramientas, políticas, evaluaciones y decisiones que intervinieron, o desde un componente hasta todos sus consumidores.
¿Lineage y procedencia significan lo mismo?
No exactamente. La procedencia explica el origen y proceso de producción de un artefacto. Lineage cubre relaciones más amplias entre artefactos, ejecuciones, decisiones, despliegues y resultados a lo largo del ciclo de vida. La procedencia puede formar parte del grafo de lineage.
¿Reproducibilidad significa obtener exactamente la misma respuesta?
No siempre. En sistemas generativos puede existir variación aun con versiones y parámetros iguales. La reproducción debe reconstruir factores controlados, conservar la salida observada y comparar hechos, fuentes, herramientas y criterios. También debe declarar dependencias o datos que ya no pueden recrearse.
¿Qué debe incluir el sobre de versión de un AI Sales Copilot?
Debe relacionar release, código, imagen, modelo, parámetros, prompts, reglas, fuentes RAG, índice, herramientas, permisos, feature flags, políticas, esquemas, evaluación, decisión, rollout y rollback mediante identificadores inmutables o la evidencia más precisa disponible.
¿Es necesario guardar prompts y datos completos para tener lineage?
No. Deben conservarse identificadores, digests, manifests, relaciones y referencias protegidas suficientes para la finalidad. Secretos y datos personales no deben duplicarse por comodidad. Cuando un contenido se elimina, un tombstone permitido puede mantener la coherencia histórica sin conservar el dato.