Documentación de sistemas de IA: qué exige el Reglamento de IA

Lo esencial

• La documentación de un sistema de IA es el conjunto de pruebas que demuestra que un sistema se diseñó, probó y supervisó de forma responsable. No es lo mismo que usar la IA para redactar documentación.
• Con el Reglamento de IA, la documentación técnica es obligatoria para los sistemas de IA de alto riesgo. El artículo 11 la exige antes de la introducción en el mercado, y debe mantenerse actualizada.
• El anexo IV define nueve secciones que esa documentación debe contener, desde la descripción general del sistema hasta el plan de vigilancia poscomercialización.
• Artefactos ya conocidos (tarjetas de modelo, fichas de conjuntos de datos, registros) responden directamente a estas obligaciones: la mayor parte del trabajo consiste en organizar pruebas que usted ya debería producir.
• Una base de pruebas bien estructurada satisface a la vez el Reglamento de IA, la ISO/IEC 42001 y el NIST AI RMF, y por eso la documentación pertenece a un proceso de gobernanza y no a una carpeta de última hora.

Documentación de IA y documentación de sistemas de IA: dos cosas distintas

Quien busca «artificial intelligence documentation» encuentra sobre todo software: herramientas que leen documentos (Document AI, procesamiento inteligente de documentos) o herramientas que redactan la documentación por usted. Ese significado existe, pero no es lo que necesita un equipo de cumplimiento o de riesgos. Esta guía aborda el otro significado: la documentación de sistemas de IA, es decir, el expediente estructurado que describe cómo funciona un sistema de IA concreto, con qué datos se entrenó, cómo se probó, qué riesgos conlleva y cómo se supervisa. Es el rastro escrito (cada vez más digital) que permite a un auditor, a una autoridad o a su propio consejo confirmar que el sistema hace lo que usted afirma sin causar daños. La distinción importa porque los destinatarios son distintos. Un redactor técnico quiere elaborar un manual más rápido. El proveedor de un sistema de IA de alto riesgo debe demostrar, cuando se le solicite, que el sistema cumple requisitos legales. La autoridad estadounidense NTIA lo expresa con claridad: la documentación es un insumo esencial para la transparencia y la evaluación, ya sea interna o externa, voluntaria o exigida. ¿A quién afecta? Con el Reglamento de IA, los proveedores y los responsables del despliegue de sistemas de alto riesgo asumen las obligaciones más exigentes, y los proveedores de modelos de IA de propósito general (GPAI) tienen sus propios deberes documentales. Si usted diseña, vende o despliega IA en un sector regulado, este tema le concierne, y la plataforma AI Sigil está concebida para estructurar precisamente estas pruebas.

Por qué la documentación de sistemas de IA es ahora una obligación legal

Durante años, documentar la IA fue una buena práctica. El Reglamento de IA la convirtió en obligación. El artículo 11 exige que la documentación técnica de un sistema de alto riesgo se elabore antes de su introducción en el mercado o su puesta en servicio, y que se mantenga actualizada. Debe ofrecer a las autoridades nacionales y a los organismos notificados información suficiente, de forma clara y completa, para evaluar la conformidad. Este último punto redefine todo el ejercicio. La documentación no se redacta para sus usuarios, sino para que un tercero pueda verificar la conformidad. Si un evaluador no puede seguir sus pruebas, el sistema no es demostrablemente conforme, por muy bien diseñado que esté. Dos factores hacen que el tema sea urgente. El primero es el calendario: las obligaciones documentales de los sistemas de alto riesgo enumerados en el anexo III se aplican desde el 2 de agosto de 2026, de modo que las pruebas deben existir antes del lanzamiento, no después de un incidente. El segundo es la rendición de cuentas: como sostiene el informe de la NTIA, un registro integrado en la evaluación es la base de una rendición de cuentas de extremo a extremo. La documentación es lo que conecta una decisión de diseño con un resultado de prueba y luego con un comportamiento en producción. AI Sigil se construyó para esa disciplina de trazabilidad.

Qué exige el anexo IV del Reglamento de IA (las nueve secciones)

El anexo IV es la lista de referencia. Establece, como mínimo, nueve ámbitos que la documentación técnica debe cubrir para un sistema de alto riesgo.

1. Descripción general. La finalidad prevista del sistema, el proveedor, las versiones, la interacción con hardware y software y las instrucciones de uso.
2. Proceso de desarrollo y elementos. Especificaciones de diseño, arquitectura del sistema, requisitos de datos, metodología de entrenamiento, evaluación de la supervisión humana y procedimientos de validación y prueba.
3. Seguimiento, funcionamiento y control. Capacidades y limitaciones del sistema, exactitud esperada para grupos concretos, resultados no deseados previsibles y medidas técnicas de supervisión humana.
4. Métricas de rendimiento. Por qué los indicadores elegidos son adecuados para este sistema.
5. Sistema de gestión de riesgos. El proceso de gestión de riesgos exigido por el artículo 9, con los riesgos detectados y las medidas de mitigación.
6. Cambios en el ciclo de vida. Un registro de los cambios introducidos en el sistema a lo largo de su vida.
7. Normas aplicadas. Las normas armonizadas aplicadas o, en su defecto, las soluciones adoptadas para cumplir los requisitos.
8. Declaración UE de conformidad. La declaración formal a la que se refiere el artículo 47.
9. Plan de vigilancia poscomercialización. El sistema de seguimiento del rendimiento tras el despliegue, conforme al artículo 72.

Los proveedores más pequeños disponen de un alivio. El Reglamento permite a las pymes y a las empresas emergentes presentar los elementos del anexo IV de forma simplificada, y la Comisión debe publicar un formulario simplificado dirigido a las microempresas y pequeñas empresas. El alivio afecta a la forma, no al fondo: las mismas preguntas exigen respuesta, lo que hace que vincular cada sección a un control reutilizable resulte especialmente rentable.

La cadena de dependencias documentales

El anexo IV parece compuesto por nueve entregables separados. En la práctica, cada sección se alimenta de otra obligación que usted ya debe cumplir. Reconocer esta cadena evita escribir dos veces la misma documentación.

• La gobernanza de datos (artículo 10) alimenta la sección 2. Sus descripciones de conjuntos de datos, registros de procedencia y controles de calidad se convierten en la parte de datos del expediente de desarrollo.
• La gestión de riesgos (artículo 9) alimenta la sección 5. El registro de riesgos y las pruebas de mitigación constituyen la sección de gestión de riesgos, no una nota aparte.
• El registro (artículo 12) alimenta la sección 3. El artículo 12 obliga a los sistemas de alto riesgo a conservar registros automáticos durante toda su vida; esos registros son la prueba operativa del seguimiento y el control.
• La transparencia (artículo 13) alimenta la sección 1. El artículo 13 exige instrucciones de uso claras, y ese mismo contenido ancla la descripción general.
• La supervisión humana (artículo 14) alimenta las secciones 2 y 3. El modo en que una persona puede intervenir, anular o detener el sistema pertenece tanto al expediente de diseño como a la descripción del control.

La lección es sencilla: la documentación es un subproducto de una buena gobernanza. Si los artículos 9, 10, 12, 13 y 14 se gestionan correctamente, el anexo IV es sobre todo ensamblaje más que redacción.

Los artefactos documentales clave

No hace falta inventar formatos. El campo ya dispone de artefactos probados, y cada uno responde a las obligaciones anteriores.

• Tarjetas de modelo (model cards). Introducidas por Mitchell y colegas en 2019, una tarjeta de modelo resume el uso previsto de un modelo, su rendimiento entre grupos, sus limitaciones y sus consideraciones éticas. Apoya las secciones 1, 3 y 4 del anexo IV.
• Fichas de conjuntos de datos (datasheets). Propuestas por Gebru y colegas en 2018, una ficha documenta la motivación, la composición, el proceso de recogida y los usos recomendados de un conjunto de datos. Apoya la sección 2 y la gobernanza de datos subyacente.
• Tarjetas de sistema (system cards). Una vista a nivel de sistema que describe cómo se combinan los componentes, usada por varios grandes proveedores. Apoya las secciones 1 y 3.
• Evaluaciones de impacto relativas a la protección de datos. Cuando intervienen datos personales, la EIPD vincula la documentación de la IA con las obligaciones existentes del RGPD.
• Registros y control de cambios. Los registros automáticos (artículo 12) y un registro de cambios versionado apoyan las secciones 3 y 6.

Para la IA de propósito general, el código de buenas prácticas GPAI de la Oficina de IA prevé un compromiso de documentación y un formulario de documentación del modelo, lo que ofrece a los proveedores GPAI una plantilla lista para la información que los responsables del despliegue posteriores solicitarán. El informe de la NTIA agrupa estas herramientas y recomienda que las tarjetas de modelo, las fichas de datos y las tarjetas de sistema se conviertan en práctica habitual como insumos de rendición de cuentas.

Una sola base de pruebas, tres marcos

Las mismas pruebas responden a más de un marco. Es la idea más útil para un equipo de cumplimiento sobrecargado. La ISO/IEC 42001, la norma de sistemas de gestión de la IA, contiene requisitos generalizados de «información documentada» en el apartado 7.5 y un conjunto de controles en el anexo A (evaluaciones de impacto, políticas, registros). El NIST AI RMF exige perfiles documentados que capten contexto, medición y seguimiento. El Reglamento de IA exige el anexo IV. Leídos en paralelo, estos textos se solapan ampliamente. Una ficha de datos satisface a la vez parte de la sección 2 del anexo IV, parte de los controles de gestión de datos de la ISO 42001 y parte de la función «Map» del NIST. Construya la prueba una vez, asóciela a cada marco y reutilícela. Duplicar la documentación por marco es el desperdicio más común y más evitable en la gobernanza de la IA; AI Sigil asocia un único conjunto de controles a varios marcos para que la prueba se introduzca una sola vez.

Mantener la documentación lista para auditoría

Producir la documentación una vez no es el objetivo. Mantenerla veraz sí lo es. El anexo IV obliga a tener el expediente actualizado, y las obligaciones de conservación se prolongan años después de la retirada de un sistema. Algunas prácticas distinguen a los equipos listos para auditoría del resto.

• Tratar la documentación como prueba viva. Actualizarla cuando cambien el modelo, los datos o el perfil de riesgo, no con una periodicidad anual.
• Versionarlo todo. Un evaluador necesita ver qué versión del modelo corresponde a qué resultado de prueba y a qué despliegue.
• Mantener una matriz de trazabilidad. Asociar cada sección del anexo IV (y cada control ISO o NIST) al artefacto exacto que la satisface, de modo que las lagunas se vean antes de que las encuentre una auditoría.
• Asignar responsabilidad. Cada artefacto necesita un propietario designado, o se desactualiza.
• Planificar la conservación. Conservar los registros durante el periodo que exige la ley, que puede superar con creces la vida activa del sistema.

Aquí es donde una carpeta de PDF deja de funcionar y una plataforma de gobernanza ocupa su lugar. Cuando la documentación vive en el mismo sistema que gestiona controles, riesgos y pruebas, mantenerla actualizada se convierte en un flujo de trabajo en lugar de una carrera. Descubra cómo lo resuelve la plataforma AI Sigil.

Preguntas frecuentes

¿Qué es la documentación de un sistema de IA? Es el expediente estructurado que describe cómo se diseñó, entrenó, probó y supervisó un sistema de IA y qué riesgos conlleva. Con el Reglamento de IA se denomina documentación técnica y es obligatoria para los sistemas de alto riesgo. Su finalidad es permitir que una autoridad o un auditor confirmen la conformidad, algo distinto de un manual de usuario y de las herramientas de IA que redactan documentación. ¿La documentación de IA es obligatoria por ley? Para los sistemas de IA de alto riesgo con el Reglamento de IA, sí. El artículo 11 exige documentación técnica antes de la introducción en el mercado, mantenida actualizada. Los proveedores de modelos de IA de propósito general también tienen deberes documentales. Los sistemas fuera de las categorías de alto riesgo pueden requerir documentación más ligera o voluntaria, pero la dirección de la regulación y las normas apunta a más, no a menos. ¿Qué debe contener la documentación técnica del Reglamento de IA? Como mínimo, los nueve ámbitos del anexo IV: descripción general, proceso de desarrollo y elementos, seguimiento y control, justificación de las métricas, sistema de gestión de riesgos, cambios en el ciclo de vida, normas aplicadas, declaración UE de conformidad y plan de vigilancia poscomercialización. ¿Cuál es la diferencia entre una tarjeta de modelo y la documentación técnica? Una tarjeta de modelo resume la finalidad, el rendimiento y las limitaciones de un solo modelo. La documentación técnica del Reglamento de IA es más amplia: abarca todo el sistema, sus datos, su gestión de riesgos y sus pruebas de conformidad. La tarjeta de modelo es un componente útil de la documentación, no un sustituto. ¿Cuándo se aplican estas obligaciones documentales? Las obligaciones documentales de los sistemas de alto riesgo enumerados en el anexo III se aplican desde el 2 de agosto de 2026. Como la documentación debe existir antes de la introducción en el mercado, los equipos deben construirla durante el desarrollo, no después del lanzamiento. ¿Pueden las pequeñas empresas documentar de forma más sencilla? Sí. El Reglamento de IA permite a las pymes y a las empresas emergentes presentar los elementos del anexo IV de forma simplificada, y la Comisión debe publicar un formulario simplificado para las microempresas y pequeñas empresas. La simplificación afecta a la forma y al esfuerzo, no a la omisión de las preguntas de fondo.

Conclusión

La documentación de un sistema de IA no es una tarea de redacción añadida al final. Es la prueba que convierte las afirmaciones sobre un sistema en algo que una autoridad, un auditor o un consejo puede verificar. El Reglamento de IA lo hace explícito mediante el artículo 11 y las nueve secciones del anexo IV, pero esos mismos registros responden también a la ISO/IEC 42001 y al NIST AI RMF. Los equipos que construyen la documentación como subproducto de una buena gobernanza, versionada, con responsable y reutilizada, están listos cuando llega una evaluación. Los que la tratan como papeleo no lo están. Vea cómo AI Sigil convierte la documentación de la IA en un flujo de gobernanza.