Usamos cookies para mejorar tu experiencia. Al continuar, aceptas su uso. Leer nuestra política de privacidad

    Volver a The Signal

    The Signal

    Procedencia de los datos para la IA: qué registrar y por qué importa

    Procedencia de los datos para la IA: qué registrar, diferencias con el linaje y obligaciones de registro según el EU AI Act y las normas de privacidad.

    29 de octubre de 2026 · 16 min de lectura

    Procedencia de los datos para la IA: qué registrar y por qué importa

    La procedencia de los datos para la IA es el registro documentado de dónde provienen los datos, quién los ha tratado, bajo qué condiciones y qué les ha ocurrido antes de influir en un modelo o en una salida. La Administración Nacional de Telecomunicaciones e Información de Estados Unidos (NTIA) utiliza el término para referirse al origen de los datos o de las salidas de los sistemas de IA. En la práctica, abarca dos niveles: los datos con los que se ha entrenado un sistema o que le sirven de base, y las conversaciones y decisiones que el sistema genera una vez que está operativo. Las organizaciones que despliegan agentes de IA conversacional necesitan ambos.

    Lexic AI
    lexic.ai
    Verifique las evidencias que respaldan a los agentes de IA
    Lexic Compass evalúa de forma independiente los agentes de IA conversacional y aporta evidencias prácticas para ayudar a las organizaciones a gobernarlos en producción.
    Descubra Lexic Compass

    Resumen

    • La procedencia de los datos registra su origen, los derechos asociados y su historial. El linaje de los datos registra cómo se han trasladado y transformado. La gobernanza de la IA necesita ambos.
    • Los conjuntos de datos de entrenamiento suelen tener una documentación deficiente: con frecuencia faltan las licencias o están mal etiquetadas, y muchas fuentes no se revelan.
    • En los agentes de IA desplegados, la procedencia se extiende a las evidencias de ejecución: qué se le preguntó al agente, qué respondió, cuándo derivó el caso y qué versión produjo la respuesta.
    • El EU AI Act exige que los sistemas de IA de alto riesgo permitan el registro automático de eventos y que los responsables del despliegue y los proveedores conserven los registros durante al menos seis meses, en equilibrio con la minimización de datos del RGPD.
    • Los registros solo resultan útiles si están completos, tienen el acceso controlado y permiten detectar manipulaciones. Las pruebas independientes muestran si los registros coinciden con el comportamiento real del agente.

    Índice

    Qué significa la procedencia de los datos para la IA

    En un almacén de datos tradicional, la procedencia responde a una pregunta concreta: ¿de dónde viene esta tabla? En la IA, la pregunta se amplía. El comportamiento de un modelo depende de los datos de entrenamiento, los datos de ajuste fino, las fuentes de recuperación, los prompts, las instrucciones del sistema y las personas o sistemas que hayan modificado cualquiera de estos elementos. La procedencia es la cadena de evidencias que conecta una salida con esas entradas.

    El primer nivel es el origen de los datos. La investigación sobre cómo se construye la IA muestra que este nivel está poco documentado. Una auditoría a gran escala de las licencias y la atribución de los conjuntos de datos, publicada en Nature Machine Intelligence en 2024, constató que entre las fuentes de texto más utilizadas figuran Wikipedia (14.9%), rastreos de páginas web no revelados (7.0%), Reddit (6.2%) y Twitter (4.0%). La proporción de material rastreado cuyo origen no se revela muestra por qué la procedencia sigue siendo un problema abierto, no resuelto.

    Data Provenance Initiative, un grupo de investigadores responsable de esa auditoría, describe las prácticas de recopilación de datos para IA como inmaduras, con conjuntos de datos que a menudo carecen de información clara sobre su contenido y origen, según informó MIT Technology Review. Para una empresa que compra o integra un agente de IA, esto tiene una consecuencia directa: el comprador rara vez ve los datos de entrenamiento, por lo que no puede verificar la procedencia en origen. Sin embargo, sí puede exigir evidencias sobre el comportamiento del agente.

    Qué significa la procedencia de los datos para la IA — diagrama general

    De dónde provienen los datos de la IA

    Los sistemas de IA se nutren de cuatro grandes tipos de datos:

    • Web pública y corpus con licencia. Páginas rastreadas, libros, código, foros y conjuntos de datos adquiridos que se utilizan para el preentrenamiento.
    • Datos seleccionados y sintéticos. Ejemplos etiquetados por personas, conjuntos de instrucciones y datos generados por otros modelos.
    • Datos empresariales. Bases de conocimiento, políticas, catálogos de productos y registros de CRM que sirven de base a un agente mediante recuperación de información.
    • Datos de interacción. Llamadas, chats, correos electrónicos y tickets generados cuando los clientes hablan con el agente.

    Cada tipo tiene un titular, una base jurídica y un riesgo diferentes. La procedencia es la disciplina que mantiene visibles esas diferencias.

    Qué debe recoger la procedencia a lo largo del ciclo de vida de la IA

    Un registro de procedencia útil es lo bastante específico como para que un tercero pueda reconstruir lo sucedido. A lo largo del ciclo de vida, el conjunto mínimo de campos se divide en cinco grupos.

    Etapa del ciclo de vida Qué registrar Por qué importa
    Recopilación Fuente, fecha de recopilación, método de recopilación, licencia o fundamento del consentimiento, jurisdicción Acredita el derecho a utilizar los datos y permite atender solicitudes de supresión o exclusión
    Preparación Pasos de limpieza, reglas de filtrado, proceso de etiquetado, quién realizó cada paso, versiones de las herramientas Permite explicar posteriormente sesgos, carencias y problemas de calidad
    Entrenamiento y configuración Versión del modelo, versiones de los conjuntos de datos, hiperparámetros, prompt del sistema, reglas de protección, fuentes de recuperación Vincula una salida con la configuración exacta que la produjo
    Despliegue Fecha de lanzamiento, historial de cambios, aprobaciones, identidad del proveedor y de los subencargados del tratamiento Establece responsabilidades cuando un proveedor modifica el comportamiento
    Funcionamiento Entradas y salidas con marca temporal, llamadas a herramientas, eventos de derivación, información comunicada al usuario, errores Facilita la investigación de incidentes, las reclamaciones y las consultas de las autoridades reguladoras

    Las tres primeras filas suelen ser responsabilidad del desarrollador del modelo. Las dos últimas corresponden a la organización que opera el agente, y son aquellas en las que la mayoría de las empresas invierten menos de lo necesario.

    Procedencia y linaje de los datos: en qué se diferencian

    Ambos términos se utilizan a menudo indistintamente. Sin embargo, responden a preguntas diferentes. Los trabajos de normalización sobre procedencia de datos de OASIS describen la procedencia como el origen de los datos y la base jurídica de su tratamiento, y el linaje como el qué, dónde, quién y cómo del tratamiento de los datos.

    Una forma sencilla de mantener la distinción:

    • La procedencia pregunta: ¿de dónde viene esto y tenemos permiso para utilizarlo de esta manera?
    • El linaje pregunta: ¿qué le ha ocurrido durante el proceso, qué sistemas lo han tratado y qué depende de ello ahora?

    En el caso del linaje de la IA, esto supone trazar un mapa desde las fuentes originales, pasando por las transformaciones, hasta los conjuntos de datos, los modelos, los prompts y, finalmente, las salidas. Si posteriormente se descubre que una fuente carece de licencia o está contaminada, el linaje muestra qué modelos y decisiones se ven afectados. La procedencia muestra si esa fuente debería haberse utilizado siquiera.

    OASIS también subraya que los datos deben tratarse como un activo independiente con un linaje rastreable, de modo que mantengan su interoperabilidad y fiabilidad al trasladarse entre plataformas y jurisdicciones. Ese principio es importante para los despliegues multinacionales, en los que una conversación puede pasar por un proveedor de nube, un proveedor de modelos, un CRM y un sistema de gestión de tickets situados en distintos países.

    De los datos de entrenamiento a las evidencias de ejecución

    La mayoría de los textos sobre procedencia se detienen en los datos de entrenamiento. Para los agentes de IA conversacional, la mayor exposición al riesgo se produce durante la ejecución. Un agente de atención al cliente hace afirmaciones en nombre de la empresa, recopila información personal, decide si debe derivar un caso y, en ocasiones, ejecuta acciones. Cada uno de esos eventos necesita un registro.

    El registro de ejecución debe responder a estas preguntas para cualquier conversación:

    1. ¿Qué agente, versión del modelo y configuración la gestionaron?
    2. ¿Se informó al cliente de que estaba hablando con una IA?
    3. ¿Qué datos recuperó el agente y de qué fuente?
    4. ¿Qué dijo y fue esa afirmación exacta y conforme a la normativa?
    5. ¿Derivó el caso a una persona cuando debía hacerlo y con qué rapidez?
    6. ¿Quién revisó el resultado y qué cambió después?

    La sexta pregunta es donde la gobernanza se materializa. Las auditorías de Lexic han mostrado que el 85% de los agentes evaluados no derivan los problemas adecuadamente a un representante humano. El panel de un proveedor puede mostrar tasas de resolución elevadas mientras las conversaciones subyacentes revelan que los clientes quedan atrapados en bucles. Sin registros independientes, esa brecha permanece invisible.

    Requisitos de registro de la IA conforme al EU AI Act

    Quienes preguntan por los requisitos de registro de la IA suelen referirse al EU AI Act, que establece las normas más detalladas hasta la fecha. El artículo 12 exige que los sistemas de IA de alto riesgo permitan técnicamente el registro automático de eventos durante toda la vida útil del sistema. Las capacidades de registro deben permitir la trazabilidad, incluido el registro de eventos pertinentes para identificar situaciones de riesgo, realizar el seguimiento posterior a la comercialización y supervisar el funcionamiento del sistema.

    La conservación se establece en otras dos disposiciones. Los artículos 19 y 26(6) exigen que los proveedores y los responsables del despliegue de sistemas de alto riesgo conserven los registros generados automáticamente durante al menos seis meses, salvo que el Derecho de la Unión o nacional, en particular la legislación sobre protección de datos personales, disponga lo contrario. En los sistemas biométricos de alto riesgo, también deben registrarse datos específicos, como los datos de entrada, la información sobre coincidencias y las personas que verificaron los resultados.

    Hay tres aspectos que merecen la atención de las empresas estadounidenses que entran en el mercado europeo:

    • El alcance depende de la categoría de riesgo. La obligación detallada de registro se aplica a los sistemas de alto riesgo, no a todos los chatbots. Los agentes de atención al cliente pueden quedar fuera de esa categoría, pero las obligaciones de transparencia hacia los usuarios y las propias obligaciones contractuales y de seguridad de la empresa siguen requiriendo registros. La clasificación debe confirmarse con asesoramiento jurídico.
    • Los plazos han cambiado. Las fechas de aplicación de las obligaciones para sistemas de alto riesgo han sido objeto de propuestas de aplazamiento y modificaciones. Consulte el texto oficial y a la Comisión Europea para conocer el calendario vigente, en lugar de basarse en una fecha citada en una guía.
    • Los responsables del despliegue también tienen obligaciones. Una empresa que compra un agente a un proveedor no está exenta. Los responsables del despliegue deben conservar los registros que estén bajo su control, lo que convierte la transparencia del proveedor en una cuestión contractual.

    Conciliar los registros con la privacidad y la minimización de datos

    El registro y la privacidad apuntan en direcciones opuestas. Los registros de conversaciones con clientes contienen nombres, datos de cuentas y, en ocasiones, información sanitaria o financiera. Conservarlos con fines de auditoría entra en conflicto con el principio de no almacenar datos personales durante más tiempo del necesario.

    Las orientaciones prácticas coinciden: mantener el mínimo de seis meses para los registros de alto riesgo y conciliarlo con los principios de limitación del plazo de conservación y minimización de datos del RGPD. En términos operativos, esto significa definir la finalidad de cada campo del registro, conservar únicamente lo que esa finalidad requiera y suprimir o anonimizar los datos conforme a un calendario.

    Las orientaciones del Gobierno de Canadá para las aplicaciones de asistencia basadas en IA son un ejemplo claro de esta misma lógica. Indican que las organizaciones deben mantener registros de auditoría que detallen todos los accesos y actividades, con controles de acceso basados en roles que limiten el acceso a quienes necesiten conocer la información. También definen la minimización de datos como la recopilación exclusiva de la información personal que la IA necesita para funcionar, e indican que la información personal de las conversaciones no debe conservarse, utilizarse para fines secundarios ni divulgarse.

    Un diseño práctico de conservación distingue tres niveles:

    Nivel Contenido Gestión
    Registros operativos Marcas temporales, versión del modelo, tipo de evento, indicador de derivación, códigos de error Conservación más prolongada, bajo contenido de datos personales
    Registros de conversaciones Transcripciones completas Acceso restringido, ocultación de datos cuando sea posible, conservación conforme a la finalidad declarada y al mínimo legal
    Conjuntos de evidencias Muestras conservadas para una investigación o auditoría Conservación sujeta a una obligación legal de preservación, protección de la integridad y supresión al levantarse dicha obligación

    Cómo garantizar la fiabilidad de los registros

    Un registro que el propietario del sistema puede editar constituye una evidencia débil. Las orientaciones sobre gestión documental, resumidas en una guía de registros del sector público español incluida en el Observatorio de Políticas de IA de la OCDE, indican que los registros deben proteger la confidencialidad y la integridad y garantizar la disponibilidad, la autenticidad, la accesibilidad y la trazabilidad. Estas cinco propiedades constituyen una lista de comprobación práctica para cualquier registro de IA.

    Los equipos suelen combinar varios controles:

    • Eventos estructurados y con marca temporal conforme a un esquema coherente, para poder consultar registros de distintos proveedores.
    • Almacenamiento de solo adición para que las entradas anteriores no puedan modificarse sin dejar rastro.
    • Aplicación de hashes o firmas criptográficas a las evidencias, idealmente por una parte independiente del proveedor, para poder verificar su integridad posteriormente.
    • Correspondencia con marcos de referencia. ISO/IEC 42001 y el Marco de Gestión de Riesgos de IA del NIST ofrecen a los auditores un vocabulario conocido para los controles de registro y las pistas de auditoría.
    • Acceso basado en roles y registro de accesos, para que también exista constancia de quién consultó una conversación.

    La independencia importa tanto como la tecnología. Cuando el proveedor que opera un agente también produce el único registro de su comportamiento, el comprador dispone de una afirmación, no de una evidencia.

    Una hoja de ruta práctica

    Las organizaciones que parten de una base limitada pueden avanzar por este orden:

    1. Inventariar todos los agentes de IA utilizados en la atención al cliente, incluidos los integrados en productos de proveedores. Registrar el responsable, el proveedor, el modelo, la finalidad y los mercados atendidos.
    2. Clasificar cada uno según su riesgo conforme al EU AI Act y a las normas estatales o sectoriales de Estados Unidos que sean aplicables, y documentar el razonamiento.
    3. Definir el esquema de registro. Decidir qué eventos y campos sirven para identificar riesgos, supervisar e investigar, y qué datos personales requiere cada uno.
    4. Establecer reglas de conservación y acceso que cumplan el mínimo de seis meses cuando corresponda y las obligaciones de minimización de la legislación sobre privacidad.
    5. Exigir evidencias al proveedor en los contratos: acceso a los registros, avisos de cambios en las actualizaciones del modelo o de los prompts y listas de subencargados del tratamiento.
    6. Probar el comportamiento de forma independiente con una periodicidad definida y comparar después lo que el agente hizo realmente con lo que afirman los registros y los informes del proveedor.
    7. Incorporar los hallazgos a la configuración, los datos de entrenamiento y las reglas de derivación, y registrar el cambio.

    Perspectiva: la solidez de la procedencia depende de las evidencias que la respaldan

    Vemos el mismo patrón en una auditoría tras otra. Las organizaciones solicitan a los proveedores documentación sobre los datos de entrenamiento, reciben una declaración general y dan el asunto por cerrado. La documentación dice para qué se diseñó el agente. No muestra qué hace cuando un cliente está enfadado, confundido o pregunta algo fuera del guion.

    Perspectiva: la solidez de la procedencia depende de las evidencias que la respaldan — diagrama general

    Esa brecha es la razón por la que interactuamos con los agentes como lo hacen los usuarios reales. Un registro de procedencia que se detiene en el conjunto de datos deja sin respuesta las preguntas de mayor impacto: ¿informó el agente de que era una IA, gestionó correctamente un intento de sondeo de seguridad, transfirió la atención a una persona cuando el caso lo requería? Nuestro hallazgo de que el 85% de los agentes evaluados no derivan los casos adecuadamente surgió de conversaciones, no de especificaciones.

    También sostenemos que las evidencias deben poder ser verificadas por alguien distinto de la parte que las produjo. La aplicación de hashes criptográficos por terceros a las evidencias de auditoría facilita la trazabilidad y permite que un equipo de cumplimiento, un proveedor y una autoridad reguladora examinen el mismo registro y coincidan en que no ha cambiado. La procedencia en la IA debe tratarse como un control continuo que acompaña al agente en cada actualización, no como un documento que se archiva en el lanzamiento.

    — Sergio Llorens

    Evidencias independientes para agentes de IA desplegados

    Lexic Compass es una plataforma de auditoría de agentes de IA que evalúa agentes conversacionales de cualquier proveedor interactuando con ellos como lo harían los usuarios reales. Examina la experiencia del cliente, la seguridad, la fiabilidad técnica y el cumplimiento normativo, y genera hallazgos que los equipos pueden utilizar para gobernar los agentes en producción y exigir responsabilidades a los proveedores. La página de Lexic Compass describe el enfoque en detalle.

    Lexic AI

    Las modalidades de servicio abarcan desde Flash Preview y Audit Sprint hasta Enterprise Continuous Trust para una supervisión continua; la página de opciones de auditoría explica cada una. Los equipos que también quieran analizar todas las conversaciones con clientes para detectar sentimiento, riesgo de abandono y señales de oportunidad pueden consultar Lexic Pulse. Ambos productos parten de la misma premisa: las decisiones sobre IA deben basarse en registros de conversaciones reales.

    Preguntas frecuentes

    ¿Qué significa la procedencia de los datos?

    La procedencia de los datos es el registro histórico de dónde se originaron los datos, cómo se crearon y qué les ocurrió después. Suele almacenarse como metadatos. En la IA, también abarca los derechos asociados a los datos, como la licencia y el consentimiento.

    ¿En qué se diferencia el linaje de los datos de IA de la procedencia de los datos?

    La procedencia establece el origen de los datos y la base jurídica para utilizarlos. El linaje traza cómo se trataron y trasladaron los datos, incluidos los sistemas y las personas que los manejaron. La procedencia indica a una organización si puede utilizar un conjunto de datos, y el linaje le indica a qué afecta ese conjunto.

    ¿De dónde provienen los datos de la IA?

    La mayoría de los modelos de gran tamaño se entrenan con una combinación de rastreos de la web pública, corpus con licencia, libros, código, foros y datos sintéticos. La investigación sobre conjuntos de datos de texto muestra que fuentes como Wikipedia, Reddit y los rastreos web no revelados representan una proporción importante. Los agentes empresariales añaden documentos de la empresa e interacciones con clientes a esa base.

    ¿Qué requisitos de registro de la IA se aplican en la UE?

    El EU AI Act exige que los sistemas de IA de alto riesgo permitan el registro automático de eventos durante toda su vida útil. Los proveedores y los responsables del despliegue deben conservar los registros durante al menos seis meses, salvo que otra legislación, como la de protección de datos, disponga lo contrario. Que un agente de atención al cliente concreto se considere de alto riesgo depende de su uso, por lo que la clasificación debe confirmarse con asesoramiento jurídico.

    ¿Durante cuánto tiempo deben conservarse los registros de conversaciones con IA?

    Para los sistemas de alto riesgo, el mínimo de la UE es de seis meses, y la limitación del plazo de conservación del RGPD puede exigir la supresión de los datos personales una vez cumplida su finalidad. Establezca la conservación por tipo de registro: los metadatos operativos pueden conservarse durante más tiempo, mientras que las transcripciones completas deben tener acceso restringido y un plazo limitado. Documente la finalidad que justifica cada periodo elegido.

    Fuentes

    ¿Quieres un veredicto independiente sobre tu agente de IA?

    Volver a The Signal