Documentación técnica del AI Act: el Anexo IV explicado para pymes

La documentación técnica es el expediente que todo provider de un sistema de IA de alto riesgo debe tener listo antes de comercializarlo. La exige el Artículo 11 del AI Act y su contenido mínimo está en el Anexo IV: qué hace el sistema, cómo se desarrolló, con qué datos se entrenó, cómo se supervisa y cómo se gestionan sus riesgos. Sin ella no hay evaluación de conformidad, no hay marcado CE y no hay producto legal en el mercado europeo.

Si tu empresa desarrolla software con IA —aunque sea una herramienta interna que luego ofreces a clientes— este artículo te explica qué tienes que documentar, en qué orden y con qué nivel de detalle. Y si solo usas IA de terceros, te interesa igualmente: vas a aprender qué documentación debes exigir a tus proveedores.

Por qué la documentación técnica importa ahora

El 2 de agosto de 2026 es la fecha de aplicación general del AI Act. A partir de ahí, ningún sistema de IA de alto riesgo puede introducirse en el mercado de la UE sin su documentación técnica completa. No es un trámite posterior: el Artículo 11 exige que esté elaborada antes de la comercialización y que se mantenga actualizada después.

Existe una propuesta de retraso de parte del calendario (el paquete Digital Omnibus, que podría mover ciertas obligaciones a finales de 2027). Pero es solo una propuesta. La recomendación seria es planificar con la fecha original, porque preparar esta documentación desde cero lleva meses, no semanas.

Este artículo es para dos perfiles. Primero, la empresa española que desarrolla un producto con IA de alto riesgo: un SaaS de selección de personal, un software de scoring, una herramienta de evaluación educativa. Segundo, la empresa que usa esos sistemas y necesita saber qué pedirle a su proveedor antes de firmar.

Vamos por partes: quién está obligado, qué pide exactamente el Anexo IV y cómo abordarlo siendo pyme.

Quién está obligado: el provider (y los disfraces de provider)

La documentación técnica del Artículo 11 es una obligación del provider (proveedor): quien desarrolla un sistema de IA y lo introduce en el mercado o lo pone en servicio bajo su propio nombre o marca. Si tienes dudas sobre tu rol, aquí está explicada la diferencia entre provider y deployer.

El matiz importante es que se puede ser provider sin saberlo. El Artículo 25 del Reglamento convierte en provider a cualquier empresa que:

• Ponga su nombre o marca en un sistema de IA de alto riesgo ya existente (white label).
• Modifique sustancialmente un sistema de alto riesgo ya comercializado.
• Cambie la finalidad de un sistema que no era de alto riesgo de forma que pase a serlo.

Esto afecta a más pymes de las que parece. La consultora que coge un modelo open source, lo ajusta y lo vende a sus clientes como producto propio es provider. La empresa que contrata un desarrollo a medida de un sistema de filtrado de candidatos y lo explota bajo su marca, también. En ambos casos, la documentación técnica del Anexo IV es suya.

¿Y esto aplica a cualquier sistema? No. Solo a los sistemas de IA de alto riesgo: los de componentes de seguridad de productos regulados (Anexo I) y los casos de uso del Anexo III, que es donde caen la mayoría de empresas: empleo y selección de personal, acceso a servicios esenciales, educación, scoring crediticio, entre otros. Un chatbot de atención al cliente o un recomendador de productos no necesitan expediente del Anexo IV; tienen obligaciones más ligeras de transparencia.

Los providers de modelos de IA de uso general (GPAI, como los modelos detrás de ChatGPT o Claude) tienen su propio régimen documental en los Anexos XI y XII. Es un mundo aparte que no toca a la pyme típica, así que aquí nos centramos en el Anexo IV.

Qué es exactamente la documentación técnica según el Artículo 11

El Artículo 11 del AI Act define la documentación técnica con una idea central: debe demostrar que el sistema cumple los requisitos de la Sección 2 del Capítulo III del Reglamento (gestión de riesgos, gobernanza de datos, transparencia, supervisión humana, precisión, robustez y ciberseguridad). No es un manual de usuario ni un documento comercial. Es la prueba documental de conformidad.

Tres características la definen:

1. Es previa. Se elabora antes de introducir el sistema en el mercado o ponerlo en servicio. Es el insumo principal de la evaluación de conformidad y, por tanto, condición para el marcado CE y el registro en la base de datos de la UE.

2. Es viva. Hay que mantenerla actualizada. Cada cambio relevante del sistema (reentrenamiento significativo, nueva funcionalidad, cambio de finalidad) debe reflejarse en el expediente.

3. Es exigible. El Artículo 18 obliga al provider a conservarla diez años a disposición de las autoridades nacionales competentes. En España, la autoridad de referencia será la AESIA. Si te la piden y no la tienes, el problema no es el papeleo: es una infracción sancionable.

Sobre el formato: el Reglamento no impone una plantilla cerrada (salvo el formulario simplificado para pymes que veremos después). Impone un contenido mínimo, que es el Anexo IV. Vamos a él.

El Anexo IV punto por punto: los 9 bloques del expediente

El Anexo IV estructura la documentación técnica en nueve bloques. Esta tabla resume qué pide cada uno y qué significa en la práctica:

Tres observaciones que ahorran disgustos:

El bloque 2 es el más exigente. Documentar los datos de entrenamiento (de dónde salen, cómo se limpiaron, qué sesgos se examinaron) es lo que más trabajo da, sobre todo si el desarrollo fue iterativo y nadie lo registró en su momento. Si estás desarrollando ahora, documenta sobre la marcha: reconstruirlo a posteriori multiplica el coste.

Los bloques 5 y 9 no son documentos, son procesos. El sistema de gestión de riesgos y la vigilancia poscomercialización tienen que existir de verdad. El expediente solo los describe. Una descripción de un proceso que no existe es exactamente el tipo de incoherencia que una autoridad detecta en la primera inspección.

El bloque 7 te da el camino fácil. Cumplir las normas armonizadas que se vayan publicando (los estándares de CEN-CENELEC para el AI Act) da presunción de conformidad. Para una pyme, seguir el estándar es casi siempre más barato que justificar una solución propia.

El formato simplificado para pymes y startups

Aquí está la parte del Artículo 11 que casi nadie cuenta: las pymes, incluidas las empresas emergentes, pueden presentar la documentación técnica de forma simplificada. El Reglamento encarga a la Comisión Europea un formulario simplificado de documentación técnica orientado a las necesidades de las pequeñas empresas y las microempresas, y obliga a las autoridades a aceptarlo.

Que la simplificación no te confunda:

• Simplifica el formato y el nivel de detalle, no el contenido. Hay que cubrir los mismos nueve bloques del Anexo IV.
• No exime de la evaluación de conformidad, ni del marcado CE, ni de los diez años de conservación.
• El formulario lo elabora la Comisión; mientras no esté publicado en su versión final, lo prudente es estructurar el expediente siguiendo directamente el Anexo IV, que es el contenido que el formulario va a recoger sí o sí.

Es un alivio real de carga administrativa —pensado precisamente para que una empresa de diez personas no necesite el departamento de compliance de un banco— pero no es una vía de escape. El texto oficial del Reglamento (UE) 2024/1689 está disponible en EUR-Lex y conviene trabajar siempre contra él, no contra resúmenes de terceros.

Y si solo soy deployer: qué documentación me toca a mí

Si tu empresa usa sistemas de IA de alto riesgo de terceros pero no los desarrolla ni los comercializa con su marca, el Anexo IV no es tuyo. Pero no estás libre de papeles. Como deployer tienes tu propio bloque documental:

• Conservar los logs que genere el sistema durante al menos seis meses (Artículo 26), cuando estén bajo tu control.
• Usar el sistema conforme a las instrucciones de uso del provider. Esas instrucciones salen, precisamente, del bloque 1 del Anexo IV. Si tu proveedor no te las entrega, mala señal.
• Evaluación de impacto en derechos fundamentales (FRIA) si eres organismo público o prestas ciertos servicios esenciales (Artículo 27).
• Informar a los trabajadores cuando el sistema de alto riesgo se use con ellos, una obligación reforzada en España por el Estatuto de los Trabajadores.

Y una tarea de pura autodefensa: exigir documentación a tu proveedor antes de contratar. Pídele la declaración UE de conformidad, el marcado CE, las instrucciones de uso y evidencia de su registro en la base de datos de la UE. Un proveedor de un sistema de alto riesgo que no puede enseñarte nada de esto te está transfiriendo su riesgo regulatorio. El resto de obligaciones del deployer están desarrolladas en la guía práctica de obligaciones del AI Act para pymes.

Caso práctico: un SaaS español de selección de personal

Imagina una startup española de doce empleados con un SaaS que ordena candidaturas usando un modelo propio. Selección de personal: Anexo III, punto 4. Sistema de alto riesgo. La empresa es provider y el Anexo IV es suyo.

Su expediente, en versión pyme, se construye así:

1. Bloque 1 en una semana. Descripción del producto, finalidad prevista ("apoyo a la preselección de candidaturas, con decisión final humana"), versiones, y unas instrucciones de uso claras para sus clientes: qué hace el sistema, qué no hace, y qué supervisión humana requiere.

2. Bloque 2 con lo que ya existe. El repositorio de código, los notebooks de entrenamiento y las decisiones de arquitectura ya documentan la mitad. Falta lo que casi nadie tiene escrito: origen y licencias de los datos de entrenamiento, qué análisis de sesgo se hizo (por sexo, edad, origen) y con qué resultado.

3. Bloques 3 y 4 desde las métricas reales. Precisión del modelo en validación, tasas de falsos descartes, y una justificación honesta de por qué esas métricas son las relevantes para un sistema que filtra personas.

4. Bloque 5 como proceso ligero pero real. Un registro de riesgos vivo: riesgo de sesgo, riesgo de uso fuera de finalidad por parte del cliente, riesgo de degradación del modelo. Responsable, mitigación y fecha de revisión para cada uno.

5. Bloques 6 a 9 al cierre. Registro de cambios desde la primera versión, estándares seguidos, la declaración de conformidad firmada y un plan de vigilancia: qué señales del uso real va a monitorizar (quejas de candidatos, deriva de métricas) y cada cuánto.

Con dedicación parcial de una persona técnica y revisión externa puntual, es un trabajo de seis a ocho semanas. Empezarlo en julio de 2026 no es un plan: es una confesión. Y el incentivo económico es claro: las sanciones por incumplir las obligaciones de provider llegan a 15 millones de euros o el 3% de la facturación global, y dar información incorrecta a la autoridad tiene un tramo sancionador propio.

Empieza por saber si necesitas este expediente

Toda esta obligación depende de dos clasificaciones previas: si tu sistema es de alto riesgo y si tu rol es de provider o deployer. Esa es la primera pieza, y la más barata de resolver.

Lo importante

La documentación técnica del Artículo 11 es la columna vertebral del cumplimiento para cualquier provider de IA de alto riesgo: sin ella no hay evaluación de conformidad, ni marcado CE, ni producto legal en la UE. El contenido lo fija el Anexo IV en nueve bloques, las pymes cuentan con un formato simplificado que alivia la forma pero no el fondo, y el expediente debe conservarse diez años a disposición de las autoridades.

Si desarrollas IA de alto riesgo, documenta sobre la marcha y estructura el expediente directamente contra el Anexo IV. Si solo la usas, exige a tu proveedor su parte y cubre la tuya: logs, instrucciones de uso y transparencia con tu plantilla. Y si aún no sabes en qué lado estás, ese es el primer hueco que cerrar, como detalla la guía completa del AI Act para pymes.

Esta información es orientativa y no constituye asesoramiento jurídico. Consulte con un profesional cualificado para una evaluación vinculante de su situación concreta.