¿Qué es un paquete de retención de registros y evidencias de IA?
Gobernanza, riesgo y aseguramiento
Un paquete de retención de registros y evidencias de IA es una colección controlada y versionada de registros mantenidos a lo largo del ciclo de vida de un sistema de IA, para que una organización pueda demostrar posteriormente qué construyó o adquirió, qué datos y modelos se utilizaron, qué pruebas y aprobaciones tuvieron lugar, qué registros e incidentes existieron, qué cambió y por qué estaban justificadas sus afirmaciones de gobernanza o cumplimiento. No es un formulario único, sino un conjunto estructurado de evidencias vinculado a reglas de retención, controles de acceso y preparación para auditorías.
Revisado por Jackie, Head of Learning & Development, Levellers - Última revisión: 8 de junio de 2026
Qué significa esto
Puede entenderse como el expediente que respalda la historia de gobernanza de la IA de una organización. Suele reunir políticas, evaluaciones de riesgos, registros de diseño, notas sobre datos, informes de pruebas, registros de validación, aprobaciones, instrucciones para usuarios, registros de incidentes, datos de monitoreo, documentos de proveedores y calendarios de retención. Los buenos paquetes son consultables y están bajo control de versiones, no son un archivo desordenado.
Un paquete de evidencias es más amplio que una ficha de modelo o una ficha de sistema. Esos artefactos explican un sistema a sus lectores. El paquete de evidencias conserva la prueba de trabajo que respalda esa explicación, incluidas las decisiones fechadas, los informes firmados, los historiales de cambios y los registros necesarios si un regulador, cliente, asegurador o auditor interno pregunta qué ocurrió realmente.
También es diferente de una copia de seguridad o un data lake. El objetivo no es conservar todo indefinidamente, sino conservar las pruebas adecuadas, durante el período adecuado y bajo los controles adecuados.
Por qué es importante
La gobernanza de la IA suele fallar después del despliegue, cuando alguien solicita pruebas. Un consejo de administración puede preguntar quién aprobó el lanzamiento. Un cliente puede preguntar qué pruebas respaldan una afirmación. Un regulador puede solicitar documentación técnica, registros, lógica de retención o una evaluación de privacidad. Una revisión de incidentes puede preguntar qué versión del modelo estaba activa, qué datos la alimentaban, qué se comunicó a los usuarios y qué cambió entre una versión y la siguiente.
Si esos registros están dispersos, sobreescritos o perdidos, incluso un sistema bien gestionado puede parecer descontrolado. Un paquete de evidencias sólido hace que la auditoría, la garantía, la revisión de adquisiciones, la respuesta a incidentes, la transparencia pública y el desmantelamiento sean más rápidos y creíbles. También ayuda a evitar el problema contrario: conservar demasiada información personal o confidencial durante demasiado tiempo sin una razón clara.
Cómo funciona
Se construye a partir de controles ya existentes
La mayoría de las organizaciones no deberían tratar el paquete como un archivo de cumplimiento puntual. Es el registro retenido que genera la actividad ordinaria de gobernanza: incorporación e inventario, revisión legal y de privacidad, documentación de datos y modelos, pruebas, aprobación, despliegue, monitoreo, gestión de incidentes y control de cambios. En términos de NIST, las partes importantes son los requisitos legales documentados, los roles documentados, el inventario de sistemas, las pruebas y el monitoreo documentados, y el seguimiento documentado del riesgo a lo largo del tiempo. En el EU AI Act, la misma lógica aparece de forma más formal para los sistemas de alto riesgo, a través de un sistema de gestión de calidad documentado, procedimientos escritos y un marco de responsabilidad que asigna responsabilidades a la dirección y al personal.
En la práctica, un responsable operativo debe rendir cuentas del paquete por cada sistema activo, generalmente el propietario del sistema o del producto. Los equipos de privacidad, legal, seguridad, adquisiciones, garantía y técnico añaden entonces evidencias controladas a ese expediente. El paquete es más sólido cuando cada elemento lleva un identificador de sistema, versión, fecha, autor, aprobador y regla de retención.
Suele contener varias familias de evidencias
La mayoría de los paquetes funcionan mejor cuando se organizan por familia de evidencias y no por departamento. Una familia cubre identidad y alcance: nombre del sistema, propósito previsto, contexto de despliegue, historial de versiones, interfaces e instrucciones para usuarios. Otra cubre diseño y datos: arquitectura, métodos de entrenamiento, procedencia de los datos, métodos de selección y limpieza, enfoques de etiquetado, componentes de terceros y diseño de supervisión humana. Una tercera cubre pruebas y riesgos: planes de validación, conjuntos de datos de prueba, métricas, registros de pruebas, informes de pruebas firmados, limitaciones conocidas y evaluaciones de riesgos. Una cuarta cubre operaciones: registros generados automáticamente, registros de monitoreo, comentarios de usuarios, informes de incidentes, acciones correctivas y notas de retirada. Una quinta cubre gobernanza y legislación: aprobaciones, mapa de responsabilidades, registros de privacidad, calendario de retención y cualquier evaluación de impacto requerida. Una sexta cubre proveedores y afirmaciones externas: registros de diligencia debida, cláusulas contractuales, posibles aprobaciones de adquisición y cualquier resumen público derivado del expediente interno.
Para la IA de alto riesgo bajo el EU AI Act, el Anexo IV ilustra el nivel de detalle que los reguladores pueden esperar. Su modelo de documentación técnica incluye el propósito previsto, el historial de versiones, la arquitectura del sistema, la procedencia de los datos, las medidas de supervisión humana, los procedimientos de validación y prueba, las métricas, los registros de pruebas, los informes de pruebas firmados, los cambios en el ciclo de vida, la gestión de riesgos y el material de monitoreo poscomercialización. Es uno de los ejemplos legales más claros de cómo es un paquete de evidencias de IA serio.
Por eso una ficha de modelo o ficha de sistema no es lo mismo. Esos son artefactos más breves, orientados al lector. El paquete de evidencias conserva la prueba más profunda que los respalda.
Los períodos de retención derivan de normas superpuestas
No existe un período de retención global único para las evidencias de IA. La respuesta correcta depende de qué acredita el registro, qué legislación se aplica, si hay datos personales implicados, si las normas sectoriales añaden plazos más largos y si una disputa, investigación o medida cautelar interrumpe la eliminación habitual.
El EU AI Act ofrece ejemplos inusualmente explícitos. En el texto base, los proveedores de sistemas de alto riesgo conservan la documentación técnica, la documentación del sistema de gestión de calidad, los registros de cambios del organismo notificado y la declaración UE de conformidad durante 10 años desde que el sistema se comercializa o entra en servicio. Los proveedores y los responsables del despliegue también conservan los registros generados automáticamente durante un período adecuado al propósito del sistema, de al menos seis meses, sujeto a la legislación sobre privacidad y nacional. Los proveedores de modelos de IA de uso general también conservan la documentación técnica durante 10 años. Aunque estas obligaciones concretas no sean aplicables, muestran un patrón de gobernanza duradero: conservar los registros que acrediten el diseño, las pruebas, las aprobaciones y el monitoreo durante más tiempo que la telemetría operativa, y conservarlos en un formato que pueda presentarse posteriormente.
Al mismo tiempo, la legislación sobre privacidad actúa en sentido contrario. El GDPR exige registros de las actividades de tratamiento y, cuando sea posible, plazos de supresión, y establece que los datos personales no deben conservarse más tiempo del necesario. Por ello, un paquete sensato utiliza un calendario de retención por tipo de artefacto. Los registros de aprobación firmados pueden necesitar un período de archivo más largo que los prompts en bruto. Los resúmenes públicos pueden conservarse más tiempo que los registros detallados de interacción con usuarios. Los informes de pruebas pueden mantenerse tras la retirada de un modelo, mientras que los datos de prompts o de usuarios pueden requerir una eliminación más temprana, una minimización más estricta o controles de acceso más rigurosos.
Los sistemas de terceros deben incluir derechos sobre las evidencias
Si se adquiere o integra IA, el paquete no puede limitarse a la orden de compra. El EU AI Act establece que los proveedores de sistemas de alto riesgo y los terceros que suministren sistemas, herramientas, servicios, componentes o procesos de IA deben utilizar acuerdos escritos que especifiquen la información, las capacidades, el acceso técnico y la asistencia necesarios para el cumplimiento. Esto es importante porque una organización no puede demostrar mucho sobre un sistema que no puede inspeccionar, monitorear ni mantener.
El perfil de IA generativa de NIST añade más detalles prácticos para los servicios de terceros. Orienta a las organizaciones hacia la evaluación de riesgos de proveedores, listas de proveedores aprobados, contratos y niveles de servicio que cubran la propiedad, los derechos de uso, la seguridad y la procedencia, registros de los cambios realizados por terceros con fuentes, marcas de tiempo y metadatos, e incidentes documentados que involucren datos o sistemas externos. Un paquete de evidencias utilizable incluye, por tanto, la diligencia debida con proveedores, las condiciones contractuales, los avisos de versión del modelo o la API, los resultados de las revisiones de seguridad, los mecanismos de respaldo, los contactos para incidentes y un plan de salida.
Por eso las adquisiciones y la gobernanza deben utilizar la misma estructura de registros. Si el proveedor no aporta evidencias suficientes, no es solo un problema comercial: es un riesgo de gobernanza.
Los registros de transparencia pública son solo una capa
Algunas organizaciones necesitan publicar un subconjunto de sus registros de IA. En la práctica del sector público del Reino Unido, el Algorithmic Transparency Recording Standard exige que ciertos organismos publiquen registros comprensibles sobre las herramientas algorítmicas en su ámbito, designen un responsable o punto de contacto único (SPOC), recopilen información de los equipos internos y, en ocasiones, de los proveedores, y decidan qué puede publicarse o debe limitarse o redactarse. El registro publicado ayuda a explicar cómo y por qué se utiliza una herramienta, pero no es el paquete de evidencias completo.
El expediente interno es más amplio. Puede incluir evidencias de pruebas más detalladas, rutas de aprobación internas, detalles de seguridad, análisis de privacidad, evaluaciones de proveedores y registros no aptos para su publicación. Esta distinción es importante para las organizaciones que elaboran fichas de modelo, fichas de sistema o declaraciones públicas de garantía. Los artefactos públicos suelen ser extractos del paquete de evidencias más profundo, no sustitutos del mismo.
Los estándares pueden estructurar el paquete, pero no reemplazan las pruebas
Los marcos y estándares son útiles porque hacen que la documentación sea más sistemática y más fácil de comparar entre equipos. Pueden ayudar a definir qué debe registrarse, cuándo, por quién y en qué formato. Pero no eliminan la necesidad de conservar pruebas a nivel de registro.
Esto es especialmente importante en la UE. La Comisión señala que se están desarrollando normas armonizadas para áreas como el registro, los sistemas de gestión de calidad y el monitoreo poscomercialización. También indica que ISO/IEC 42001 puede ayudar a las organizaciones a establecer un sistema de gestión de IA, pero no está alineado con el sistema de gestión de calidad exigido por el AI Act. La lección práctica es sencilla: usar los estándares para estructurar el paquete, pero vincular el paquete a las obligaciones legales y contractuales reales que se aplican al sistema.
Ejemplos
Una organización que se prepara para comercializar un sistema de IA de alto riesgo en el mercado de la UE necesita más que una declaración de política. Necesita un expediente técnico que recoja el propósito previsto, el historial de versiones, la arquitectura, la procedencia de los datos, el diseño de supervisión humana, el material de validación y pruebas, las métricas, los registros de pruebas, los informes firmados, la gestión de riesgos y el monitoreo poscomercialización. También necesita un sistema de gestión de calidad documentado y un plan de retención para esos materiales. Los registros del proveedor y del responsable del despliegue necesitan entonces su propia lógica de retención, con la legislación sobre privacidad estableciendo límites cuando hay datos personales implicados.
Un organismo público del Reino Unido que utilice una herramienta algorítmica en su ámbito necesita tanto una capa publicable como una interna. El Algorithmic Transparency Recording Standard espera que un responsable o SPOC recopile información de los equipos internos pertinentes y, cuando sea necesario, de los proveedores. El registro público explica cómo y por qué se utiliza la herramienta. El paquete de evidencias interno es más amplio, porque también conserva el registro de pruebas, la ruta de aprobación, el material del proveedor y cualquier información restringida no apta para su publicación.
Una empresa que despliega una API de IA generativa de terceros necesita un paquete que evolucione con el ciclo de lanzamientos del proveedor. Esto implica conservar la diligencia debida con el proveedor, las cláusulas contractuales, las condiciones de uso aprobadas, los avisos de cambios en el modelo, los registros de procedencia y metadatos, los registros de incidentes, el historial de versiones y las evidencias de revisión tras cada cambio significativo. Si el proveedor realiza un cambio que afecta al rendimiento, la seguridad o el uso permitido, la organización debe poder demostrar cuándo tuvo conocimiento de ese cambio, qué probó, qué actualizó y quién aprobó el uso continuado.
Malentendidos frecuentes
Idea errónea: es simplemente una carpeta de capturas de pantalla y documentos PDF de políticas.
Corrección: un paquete real está versionado, estructurado y vinculado a versiones del sistema, aprobaciones, pruebas, incidentes y reglas de retención.
Idea errónea: una ficha de modelo o ficha de sistema es el paquete de evidencias.
Corrección: esos son resúmenes. El paquete de evidencias conserva la prueba más profunda que respalda el resumen.
Idea errónea: las buenas prácticas implican conservar todos los prompts, registros y datos de usuarios indefinidamente.
Corrección: las buenas prácticas implican conservar los registros adecuados durante el período adecuado. La privacidad, la seguridad y la minimización siguen siendo aplicables.
Idea errónea: solo la IA fuertemente regulada o del sector público necesita esto.
Corrección: las obligaciones formales son más estrictas en algunos contextos, pero cualquier organización que haga afirmaciones de gobernanza, seguridad, calidad o cumplimiento sobre IA se beneficia de un paquete de evidencias proporcionado.
Idea errónea: un certificado o estándar hace innecesario el paquete.
Corrección: los estándares pueden estructurar el trabajo, pero no reemplazan los registros subyacentes que acreditan lo que se hizo.
Riesgos y límites
Un paquete de evidencias no es un puerto seguro. Un expediente ordenado no hace aceptable un sistema ilegal, inseguro o con pruebas deficientes. Solo mejora la capacidad de demostrar qué se hizo, qué se sabía y cómo se respondió.
También puede estar mal diseñado. Volcar todos los prompts, correos electrónicos, instantáneas de conjuntos de datos y artefactos de modelos en un único archivo genera fallos de búsqueda, riesgos de privacidad y exposición de seguridad. El paquete debe estar curado e indexado. No es una licencia para el almacenamiento permanente.
Es fácil aplicar el mecanismo de forma incorrecta a registros de escaso valor mientras se omiten los elementos más importantes, como los registros de aprobación, los informes de pruebas firmados, los avisos de proveedores, los registros de tratamiento o las instrucciones finales que se enviaron realmente a los usuarios. La cadena de custodia importa tanto como el volumen. Si las versiones, fechas y autores no están claros, el valor probatorio cae drásticamente.
También existe incertidumbre jurídica actual en Europa. A fecha de 4 de junio de 2026, el AI Act publicado sigue conteniendo obligaciones detalladas de documentación, registro y retención, pero la Comisión Europea también señala que un acuerdo político alcanzado el 7 de mayo de 2026 simplificaría algunos plazos de alto riesgo y retrasaría muchas fechas para sistemas de alto riesgo, incluidos los sistemas del Anexo III hasta el 2 de diciembre de 2027 y ciertos sistemas integrados en productos hasta el 2 de agosto de 2028. Las organizaciones con exposición en la UE deben, por tanto, seguir el texto de modificación definitivo, las normas armonizadas y el material de aplicación, y no basarse en una tabla de fechas anterior.
Por último, el paquete no es propiedad exclusiva del equipo de IA. Los registros importantes suelen estar en manos de las funciones de privacidad, adquisiciones, seguridad, recursos humanos, seguridad de productos o cumplimiento sectorial. Si esos equipos no participan en el diseño, el paquete parecerá completo hasta el primer desafío real.
Próximos pasos
Designar un responsable para cada sistema de IA relevante y definir un repositorio controlado único o un patrón de repositorios vinculados para las evidencias.
Publicar una taxonomía mínima de evidencias. Como mínimo, decidir cómo la organización almacenará la identidad del sistema, el propósito previsto, el historial de versiones, las aprobaciones, los informes de pruebas, las evaluaciones de riesgos, los registros de monitoreo, los incidentes, los documentos de proveedores, los registros de privacidad y las notas de retirada o sustitución.
Establecer la retención por tipo de artefacto, no por conveniencia. Distinguir las pruebas de gobernanza de larga duración de los registros operativos de corta duración, y distinguir los registros que contienen datos personales de las evidencias técnicas no personales.
Incluir en los contratos las obligaciones de acceso y actualización de evidencias. Si el modelo o servicio de un proveedor cambia, la organización debe tener derecho a recibir aviso e información suficientes para actualizar su paquete y reevaluar el uso.
Separar la prueba interna de la explicación pública. Conservar el expediente más detallado internamente y derivar de él las fichas de modelo, fichas de sistema, resúmenes de garantía o registros de transparencia pública.
Realizar un ejercicio de recuperación. Pedir a un equipo que responda cinco preguntas incómodas sobre un sistema de IA activo, como quién aprobó el despliegue, qué cambió el trimestre pasado, qué pruebas respaldan el conjunto de afirmaciones actual, qué datos de usuarios se conservan y qué ocurre si el proveedor cambia el modelo. Si esas respuestas son lentas o inconsistentes, el paquete no está listo.
¿Tiene alguna pregunta o sugerencia, o desea saber cómo investigamos y revisamos estas guías? Lea sobre nuestros estándares editoriales y cómo contactarnos.
Preguntas frecuentes
¿Es un paquete de retención de registros y evidencias de IA un término jurídico formal?
Generalmente no. Es una etiqueta de gobernanza para el conjunto de registros que las leyes, los estándares y los controles internos exigen por separado. Algunas jurisdicciones nombran documentos y registros específicos, pero el paquete en sí suele ser una compilación interna de esos elementos.
¿Quién debe ser su responsable?
La responsabilidad cotidiana suele recaer en el propietario del sistema o del producto. Los equipos de privacidad, legal, seguridad, adquisiciones, datos y garantía añaden entonces evidencias controladas. Para los sistemas relevantes, un patrocinador ejecutivo debe poder dar cuenta del estado del expediente.
¿En qué se diferencia de una ficha de modelo o ficha de sistema?
Una ficha de modelo o ficha de sistema explica. Un paquete de evidencias demuestra. El artefacto de resumen está orientado al lector; el paquete conserva las aprobaciones fechadas, los informes de pruebas, los registros de proveedores, los registros y el historial de cambios que lo respaldan.
¿Cuánto tiempo debemos conservarlo?
Por tipo de artefacto, no con un período único. Por ejemplo, el texto base del EU AI Act establece 10 años para cierta documentación de sistemas de alto riesgo y modelos de uso general, y al menos seis meses para ciertos registros, mientras que la legislación sobre privacidad establece que los datos personales no deben conservarse más tiempo del necesario. La legislación sectorial, los contratos y las disputas pueden modificar la respuesta.
¿Necesitamos uno para la IA interna o de menor riesgo?
Generalmente sí, pero a un nivel más ligero. Incluso un asistente interno o una herramienta de clasificación puede necesitar una declaración clara de propósito, un registro de aprobación, diligencia debida con el proveedor, notas de pruebas, una ruta de incidentes y una regla de retención.
¿Qué ocurre si un proveedor no comparte suficiente información?
Trátelo como un riesgo de gobernanza. Busque cláusulas contractuales que den acceso a la información necesaria. Si la brecha persiste, reduzca la dependencia, limite el caso de uso, añada controles adicionales o elija un proveedor que pueda satisfacer sus necesidades de evidencias.
¿Deben los prompts y las salidas formar parte del paquete?
En ocasiones, pero no de forma automática. Consérvelos solo cuando sean necesarios para el monitoreo, la revisión de incidentes, las pruebas o la prueba legal, y aplique entonces reglas de minimización, redacción, control de acceso y eliminación.
¿Es suficiente la certificación por sí sola?
No. La certificación puede apoyar la estructura y la comparabilidad, pero no reemplaza los registros subyacentes que muestran qué se probó, aprobó, cambió, monitoreó y conservó.