Procedencia y trazabilidad de datos

Su sistema de IA tomó una decisión. ¿Puede rastrear los datos detrás de ella?

La procedencia de datos es la infraestructura que permite responder a las preguntas sobre los datos de IA — no un panel de control ni una entrada de catálogo, sino un sistema que registra dónde se originaron los datos de entrenamiento, qué transformaciones experimentaron, qué modelos los consumieron y si esa cadena puede verificarse criptográficamente (consulte nuestra investigación sobre la arquitectura de IA verificable para la empresa post-confianza).

Un tribunal acaba de ordenar a OpenAI que presente 78 millones de registros de salida de ChatGPT porque los demandantes necesitaban rastrear cómo los datos de entrenamiento protegidos por derechos de autor influyeron en el comportamiento del modelo. Ese es un ejemplo extremo. La versión cotidiana es más discreta pero igual de trascendental:

• Un regulador que pregunta qué datos entrenaron su modelo de concesión de préstamos.
• Una solicitud de supresión según el RGPD que llegó a sus tablas de origen pero no a los seis modelos posteriores que consumieron los registros eliminados.
• Un incidente de envenenamiento de datos en el que no puede identificar qué lotes de entrenamiento se vieron comprometidos porque nada en su canalización registró la respuesta.

Nuestro enfoque consiste en construir esta capa de procedencia sobre las herramientas de canalización que las empresas ya ejecutan: Spark, dbt, Airflow, Dagster y ETL personalizado.

Por qué el linaje de catálogo no es lo mismo que la procedencia de los datos de entrenamiento

La mayoría de las empresas ya disponen de un catálogo de metadatos. Collibra, Alation, Atlan o DataHub cubren el linaje a nivel de tabla, útil para el análisis de impacto de cambios de esquema. No responde a las preguntas que los reguladores, auditores y litigantes plantean sobre los sistemas de IA. La brecha se manifiesta en tres aspectos:

Nuestro enfoque funciona con cualquier catálogo que ya posea. La capa de procedencia está diseñada para situarse debajo de él, instrumentando la ejecución real de la canalización para capturar el detalle a nivel de registro y de transformación que los catálogos no fueron diseñados para proporcionar.

Qué instrumentamos y cómo

El desafío central radica en capturar la procedencia con la granularidad que exigen los reguladores sin destruir el rendimiento de la canalización. El hashing SHA-256 por registro en un trabajo de Spark que procesa 500 millones de filas añade una sobrecarga del 15–40% , rara vez aceptable para producción. Nuestro enfoque calibra la granularidad de la procedencia según el perfil de riesgo real.

Instrumentación de canalizaciones con OpenLineage

La instrumentación utiliza OpenLineage como estándar de emisión donde existen integraciones (Spark, Airflow, dbt y Dagster cuentan con distintos niveles de compatibilidad), con facetas personalizadas que capturan metadatos específicos de ML: parámetros de ingeniería de características, configuraciones de aumento de datos, estrategias de muestreo y criterios de división de entrenamiento/validación/prueba. Cuando la integración de OpenLineage es incompleta o descarta eventos —se sabe que el listener de Spark pierde silenciosamente facetas personalizadas con un alto recuento de particiones—, el enfoque añade instrumentación suplementaria diseñada para capturar lo que la integración estándar omite, detallada en nuestro informe técnico sobre la protección de la cadena de suministro de ML a lo largo del ciclo de vida.

Procedencia para datos no estructurados

Para datos de entrenamiento no estructurados —documentos, imágenes, audio y vídeo utilizados en canalizaciones de ajuste fino o RAG—, el enfoque aplica huellas digitales de contenido con hashing perceptual (pHash para imágenes, chromaprint para audio) junto con hashes criptográficos, lo que permite el seguimiento de la procedencia incluso cuando el contenido experimenta transformaciones con pérdidas; consulte una demostración práctica del seguimiento de procedencia de audio.

El problema del borrado bajo el RGPD que nadie ha resuelto de forma limpia

El RGPD en su Artículo 17 reconoce el derecho de supresión. Para bases de datos tradicionales: eliminar y confirmar. Para los sistemas de IA, es un problema no resuelto disfrazado de casilla de verificación de cumplimiento. Los modelos lingüísticos grandes no almacenan datos como registros discretos: almacenan patrones estadísticos derivados de los datos de entrenamiento, distribuidos a través de miles de millones de parámetros. Eliminar los datos de una persona de la tabla de origen no elimina su influencia de los pesos del modelo, y el RGPD no ofrece ningún marco para interpretar qué significa la «supresión» una vez que los datos se han integrado en la arquitectura de toma de decisiones de un modelo.

La investigación en desaprendizaje automático está avanzando. En septiembre de 2025, investigadores de UC Riverside demostraron el «desaprendizaje sin datos fuente», un método certificado que funciona sin los datos de entrenamiento originales, utilizando conjuntos de datos sustitutos y ajustes de parámetros basados en actualizaciones de Newton. Sin embargo, ningún método de desaprendizaje está listo para producción a escala empresarial. Los enfoques prácticos actuales combinan tres capas:

• Prevención : mantener la información de identificación personal fuera de los datos de entrenamiento mediante filtros de preprocesamiento.
• Remediación rápida : eliminación en índices de recuperación, cachés y registros.
• Documentación defendible : registros de procedencia que demuestren qué datos entraron en qué modelos, respaldando las decisiones de reentrenamiento cuando el desaprendizaje sea insuficiente.

La infraestructura de procedencia está diseñada para crear el requisito indispensable para cualquier estrategia de supresión: un mapa consultable desde el identificador del interesado hasta cada modelo, canalización y artefacto que haya consumido sus datos. Con él, puede responder «¿qué modelos necesitan reentrenamiento?» a los pocos minutos de recibir una solicitud de supresión, en lugar de descubrir meses después que una ejecución olvidada de ajuste fino utilizó los datos afectados.

Artículo 10 de la Ley de IA de la UE: de documentos de políticas a evidencias de canalización

El Artículo 10 de la Ley de IA de la UE exige que los datos de entrenamiento, validación y prueba estén sujetos a «prácticas de gobernanza y gestión de datos apropiadas para la finalidad prevista». La aplicación obligatoria comienza el 2 de agosto de 2026. El requisito práctico no es un documento de política de gobernanza. Es una evidencia verificable y con marca temporal de que la gobernanza se aplicó en el momento exacto en que los datos entraron en la canalización.

La brecha es real: solo el 3% de las instituciones financieras ha desplegado eficazmente la IA en producción (Informe de confianza en los datos de Ataccama 2025). Existen políticas de gobernanza, pero no la prueba de su cumplimiento a nivel de canalización.

Nuestro enfoque ofrece el cumplimiento del Artículo 10 como una capacidad nativa de la canalización. Cada ejecución está diseñada para generar un registro de procedencia que captura: fuentes de datos con metadatos de origen, resultados de validación de calidad, parámetros de transformación, metodología de muestreo, propiedades estadísticas del conjunto de datos (representatividad, completitud, tasas de error) y políticas de gobernanza activas. Este es el artefacto que examina un auditor —generado automáticamente, no recopilado de forma retroactiva—.

Para las organizaciones sujetas también al Artículo 30 del RGPD (registro de las actividades de tratamiento), el sistema de procedencia está diseñado para generar ambos artefactos de cumplimiento a partir de una única capa de instrumentación. Los requisitos se solapan pero no son idénticos: el Artículo 30 se centra en las finalidades del tratamiento y las bases jurídicas, mientras que el Artículo 10 se enfoca en la calidad y la representatividad de los datos. Un sistema unificado evita la duplicación que afecta a las organizaciones que gestionan vías de cumplimiento independientes.

Atribución de datos de entrenamiento y detección de envenenamiento

Los reguladores están comenzando a preguntar qué ejemplos de entrenamiento influyeron en una predicción específica. Las funciones de influencia, el marco matemático para esto, han sido históricamente demasiado costosas para la producción. Los avances recientes — la proyección de gradiente LoGra y el algoritmo ASTRA — llevan el cálculo de influencia a una escala práctica. Nuestro enfoque implementa la atribución como una capacidad forense: puntuaciones de influencia precalculadas para comportamientos críticos del modelo, almacenadas en caché para su recuperación cuando un auditor o litigante necesite conocer la conexión entre una salida específica y los datos detrás de ella.

La procedencia también sirve como la principal defensa contra el envenenamiento de los datos de entrenamiento (nuestra investigación sobre la protección de modelos empresariales contra el envenenamiento). La investigación confirmó en 2025 que el envenenamiento solo requiere un número constante de muestras independientemente del tamaño del modelo, e incluso un 0,001% de datos adversarios puede degradar la precisión en un 30%. Cuando cada elemento de datos cuenta con una cadena de custodia verificada, los patrones de procedencia anómalos se vuelven detectables:

• Datos de fuentes no verificadas.
• Registros con cadenas de hash rotas.
• Ejemplos que eluden la canalización de ingesta estándar.

Sobre el grafo de procedencia, el enfoque añade capas de detección diseñadas para alertar sobre estos patrones antes de que los datos contaminados lleguen al entrenamiento del modelo.

Cuándo es esta la inversión adecuada

Necesita infraestructura de procedencia cuando sus sistemas de IA consumen datos con riesgos jurídicos, normativos o de seguridad:

• Empresas de servicios financieros que enfrentan el Artículo 10 de la Ley de IA de la UE.
• Sector sanitario bajo FDA 21 CFR Parte 11.
• Empresas con exposición al RGPD que entrenan con datos de usuarios.
• Organizaciones cuyo aprovisionamiento de datos de entrenamiento está bajo escrutinio legal.

No necesita esto si su IA consume únicamente datos propios no regulados con una canalización simple. Si el grafo de linaje de dbt más una instancia de DataHub cubren sus necesidades, utilice esas herramientas; se lo diremos en la primera conversación.