Cómo construir tu inventario de IA antes del 2 de agosto de 2026: guía práctica para pymes de la UE

En síntesis

El grueso de las obligaciones sustantivas del Reglamento (UE) 2024/1689 entra en aplicación el 2 de agosto de 2026: los deberes para sistemas de alto riesgo del Anexo III conforme a los artículos 8 a 22, las obligaciones del responsable del despliegue del artículo 26, los deberes de transparencia del artículo 50 y la inscripción en la base de datos de la Unión prevista en el artículo 49. Ninguna de esas obligaciones puede ejecutarse sin un inventario completo, vigente y con propietario nombrado de cada sistema de IA en su perímetro. Las prohibiciones del artículo 5 resultan exigibles desde el 2 de febrero de 2025 y las obligaciones para modelos de IA de uso general (IAFG) desde el 2 de agosto de 2025 (art. 113), de modo que cualquier inventario que se levante hoy debe abarcar también el cribado de prácticas prohibidas, las trazas documentales del régimen IAFG en el papel de implantador y la asignación ordinaria de niveles. La buena noticia, especialmente para pymes con recursos limitados: su empresa casi con seguridad ya mantiene registros análogos —el Registro de Actividades de Tratamiento del artículo 30 del RGPD, los inventarios de activos exigidos por la transposición de NIS2 y el control A.5.9 del Anexo A de ISO/IEC 27001:2022—. El inventario de IA se construye mejor como extensión federada de esos registros, no como artefacto paralelo. Esta guía recoge el esquema de campos, el mapa de reutilización, tres ejemplos prácticos en pymes, las brechas que con más frecuencia pillan a las organizaciones desprevenidas y un plan de 60 días para entregar el registro antes de que llegue la fecha.

Por qué un inventario de IA es clave antes del 2 de agosto de 2026

El Reglamento de IA no impone una obligación nominal de "mantener un inventario". Lo que impone es más de una docena de obligaciones cuya ejecución resulta imposible si la organización ignora qué sistemas de IA opera, qué hacen, quién los gobierna y a qué nivel de riesgo pertenecen. La gestión de riesgos del artículo 9 presupone una lista de sistemas sobre la que aplicar el análisis. La documentación técnica del artículo 11 presupone que los sistemas en el perímetro están identificados. Las obligaciones del responsable del despliegue del artículo 26 —supervisión humana, monitorización, registro, información a los trabajadores afectados— se aplican sistema por sistema, y no es posible aplicarlas sistema por sistema sin un registro sistema por sistema. La inscripción del artículo 49 es, por su propia naturaleza, una declaración de un sistema concreto. Sin el inventario, ninguna de las piezas restantes puede ordenarse, priorizarse ni evidenciarse.

El régimen sancionador está diseñado para que la laguna salga cara. El artículo 99 fija multas administrativas de hasta 35 millones de euros o el 7 % del volumen de negocios anual mundial por infracción de las prohibiciones del art. 5 (art. 99.3); de hasta 15 millones o el 3 % por incumplir las obligaciones de alto riesgo (art. 99.4); y de hasta 7,5 millones o el 1 % por suministrar información incorrecta, incompleta o engañosa a los organismos notificados y a las autoridades competentes (art. 99.5). Las pymes obtienen una mitigación parcial al amparo del artículo 99.6 —la sanción se calcula sobre el menor de los dos importes en lugar del mayor—, pero la mitigación no elimina el techo y, sobre todo, no impide la categoría de error más dañina: descubrir, en mitad de una actuación inspectora, que la organización no sabe qué IA opera. Un inventario incompleto es la condición previa para el tercer tramo de multa, porque cada respuesta que la empresa entregue a la autoridad acaba siendo, necesariamente, una estimación.

A todo ello se suma una dimensión de acceso al mercado. El artículo 79 faculta a la autoridad de vigilancia del mercado para imponer medidas correctoras a los sistemas de alto riesgo no conformes, incluida la retirada del producto del mercado de la Unión. Para una pyme proveedora de SaaS B2B con cláusulas de cumplimiento normativo en sus contratos —cuyos clientes empezarán a exigir el visto bueno conforme al Reglamento de IA en sus procesos de compra desde el segundo semestre de 2025—, la incapacidad de presentar un inventario sistema por sistema cuando se solicite es un pasivo comercial mucho antes que regulatorio. Los primeros clientes en preguntar serán las grandes empresas alemanas, francesas, neerlandesas y nórdicas que ya tienen procesos maduros de diligencia debida sobre proveedores en materia de RGPD. "Aún estamos cartografiando" no será una respuesta aceptable a finales de 2026.

Qué entiende el artículo 3.1 por "sistema de IA"

El artículo 3.1 define un sistema de IA como un sistema basado en una máquina diseñado para funcionar con distintos niveles de autonomía, que puede mostrar capacidad de adaptación tras su despliegue y que, para objetivos explícitos o implícitos, infiere, a partir de las entradas que recibe, cómo generar resultados —predicciones, contenidos, recomendaciones o decisiones— capaces de influir en entornos físicos o virtuales. La definición está deliberadamente alineada con la actualización de 2023 de la OCDE y es amplia. Cualquier organización que la lea con detenimiento llega a la misma primera conclusión: el ámbito es más extenso de lo que se asumía.

Tres consecuencias se siguen a efectos del alcance del inventario. Primera, el aprendizaje automático no es una condición previa. Un sistema experto basado en reglas que infiere resultados a partir de entradas contrastadas con una base de conocimientos encaja en la definición, aunque la mayoría de los ingenieros no lo llamarían IA. El considerando 12 acota algunas técnicas estadísticas y de optimización clásicas en las que no media inferencia, pero la acotación es estrecha y discutida en sus márgenes. En caso de duda, lo prudente es incluir el sistema en el inventario y documentar la razón por la que no requiere clasificación de riesgo.

Segunda, "distintos niveles de autonomía" implica que la frontera entre IA y software convencional no se traza por la presencia humana en el bucle. Un sistema con aprobación humana obligatoria para cada salida sigue siendo un sistema de IA si infiere esas salidas. La supervisión humana del artículo 14 es, por tanto, una característica de diseño del sistema de IA, no una vía de escape del Reglamento. Las herramientas de cribado de currículums que muestran al seleccionador una lista corta priorizada son sistemas de IA aunque la decisión formal de contratación recaiga en una persona.

Tercera, la noción de "resultados capaces de influir en entornos físicos o virtuales" abarca una larga lista de software operativo que las organizaciones rara vez etiquetan como IA: motores de tarificación dinámica, modelos de scoring antifraude, predictores de abandono de clientes, clasificadores de moderación de contenido, sistemas de recomendación, enrutamiento automatizado de correo, previsión de demanda, modelos de mantenimiento predictivo. La mayoría acabarán siendo de riesgo mínimo tras el análisis por niveles, pero corresponde incluirlos en el inventario igualmente. La finalidad del registro es demostrar que se realizó una clasificación, no listar únicamente los sistemas que resultaron ser de alto riesgo.

Asignar el inventario a los niveles de riesgo del RIA

Cada entrada del inventario lleva una etiqueta de nivel, y la etiqueta gobierna el resto del expediente. Las cinco categorías —prácticas prohibidas, alto riesgo, riesgo limitado, riesgo mínimo y la capa transversal de IAFG— se montan sobre el mismo registro, y un único producto puede generar varias entradas cuando contiene casos de uso de IA distintos. Conviene tratar las entradas como unidades de trabajo de cumplimiento, no como un catálogo de proveedores.

Los sistemas de riesgo inaceptable del artículo 5 —ocho familias prohibidas que cubren las técnicas manipuladoras, la explotación de vulnerabilidades, la puntuación social, la actuación policial predictiva basada exclusivamente en perfilado, el raspado masivo de imágenes faciales, el reconocimiento de emociones en el lugar de trabajo y en centros educativos, la categorización biométrica por atributos sensibles y la identificación biométrica remota en tiempo real con fines policiales en espacios públicos— no deberían figurar como entrada activa del inventario. Si un sistema existente o una contratación prevista coincide con alguna prohibición, la ficha del registro existe únicamente para documentar la decisión de cese. Las prohibiciones resultan exigibles desde el 2 de febrero de 2025, de modo que ya no cabe tratarlas como una obligación futura.

Las entradas de alto riesgo —categorías del Anexo III más los componentes de seguridad del artículo 6.1 relativos a productos del Anexo I— soportan el conjunto de campos más pesado. El paquete de trece obligaciones que va del artículo 9 al artículo 49 genera requisitos documentales que una ficha ligera no puede sostener. Para las entradas de alto riesgo, lo razonable es tratar el inventario como un índice que apunta a un expediente técnico independiente regulado por el artículo 11 y el Anexo IV, mientras la propia ficha conserva únicamente los metadatos que un auditor necesita para navegar hasta dicho expediente. Las obligaciones sustantivas son exigibles desde el 2 de agosto de 2026 para los sistemas de alto riesgo del Anexo III, y desde el 2 de agosto de 2027 para la rama de seguridad de productos del Anexo I asociada al art. 6.1.

Un segundo filtro opera dentro del Anexo III. El artículo 6.3 permite descartar el alto riesgo cuando un sistema del Anexo III no presenta un riesgo significativo de daño, ya sea porque desempeña una tarea procedimental restringida, porque mejora el resultado de una actividad humana ya completada, porque detecta patrones o desviaciones sin sustituir la evaluación humana, o porque realiza tareas preparatorias para una evaluación del Anexo III. La elaboración de perfiles de personas físicas inhabilita la excepción en todos los supuestos. Cada entrada del Anexo III en el inventario requiere un análisis escrito del artículo 6.3: una conclusión positiva (con el inciso concreto invocado) y su razonamiento, o una conclusión negativa que confirme la permanencia del sistema en alto riesgo.

Las entradas de riesgo limitado —agentes conversacionales, generadores de ultrafalsificaciones, texto o multimedia generados por IA, sistemas de reconocimiento de emociones cuando no estén prohibidos— se rigen por los deberes de transparencia del artículo 50. El inventario debe consignar el mecanismo de divulgación sistema por sistema: la ubicación del aviso en el chatbot, la técnica de marcado de los resultados sintéticos, el registro de revisión editorial del texto generado por IA publicado sobre asuntos de interés público, la notificación que el implantador entrega al destinatario en el caso de las ultrafalsificaciones. Las obligaciones de riesgo limitado también son exigibles desde el 2 de agosto de 2026 y, a diferencia del recorrido de alto riesgo, no existe una vía derogatoria que las module: cada chatbot necesita su divulgación y el inventario tiene que evidenciarla.

Las entradas de riesgo mínimo conforman el grueso del registro. El Reglamento de IA no impone obligaciones materiales para estos sistemas, pero el inventario debe consignar igualmente la conclusión negativa: el razonamiento documentado de que el sistema no encaja en el Anexo III, no interactúa directamente con personas físicas y no genera contenido sintético. El deber de alfabetización en IA del artículo 4 se aplica con independencia del nivel, de modo que la ficha debe registrar qué colectivo de personal opera cada sistema de riesgo mínimo y confirmar su inclusión en el programa de alfabetización.

La capa de IAFG no es un nivel adicional, sino una capa transversal. Casi cualquier ficha de inventario en una pyme construida sobre un modelo fundacional —GPT-4o, Claude, Gemini, Mistral Large, Llama, Command— es un registro de implantador en virtud del artículo 53.1.b, con la información que fluye en cascada desde el proveedor aguas arriba. La ficha necesita un campo específico para la identidad y versión del modelo subyacente, el proveedor, la referencia al resumen del contenido de entrenamiento publicado y la fecha en que se revisaron por última vez las instrucciones de uso del proveedor. Conviene mantener nítidas dos reglas que se confunden con frecuencia. El artículo 25 traslada las obligaciones del proveedor de un sistema de alto riesgo a un actor situado aguas abajo en tres supuestos: cuando este pone el sistema de alto riesgo en el mercado bajo su nombre o marca, cuando modifica sustancialmente un sistema de alto riesgo ya comercializado, o cuando modifica la finalidad prevista de un sistema que no era de alto riesgo (incluido un IAFG) de manera que pase a serlo conforme al artículo 6. El considerando 109 aborda un caso distinto: una organización que ajusta finamente o modifica de otra forma un IAFG sin convertirlo en sistema de alto riesgo. En ese supuesto, las obligaciones del actor aguas abajo se circunscriben a la modificación misma —típicamente, completar la documentación técnica del proveedor con la información sobre los cambios introducidos, incluidas, en su caso, las nuevas fuentes de datos de entrenamiento—. La mayoría de las pymes no cruzan ninguno de los dos umbrales, pero el inventario es el único lugar en el que la línea queda documentada para cada sistema.

Campos requeridos en el inventario

Un inventario de IA defendible se sostiene con unos quince campos por entrada. Conviene resistir la tentación de añadir más: cada campo adicional es una carga de mantenimiento, y el registro sostenible es aquel que el personal actualiza realmente cuando los sistemas cambian. La lista que sigue es el conjunto mínimo que da soporte a las obligaciones aplicables desde el 2 de agosto de 2026.

• Nombre del sistema e identificador único: una etiqueta estable utilizada de manera coherente en el expediente técnico, en la inscripción en la base de datos de la Unión, en los contratos con proveedores y en los tiques internos de gestión del cambio.
• Responsable nombrado: una persona física concreta dentro de la organización que asume la rendición de cuentas por mantener actualizada la ficha y por activar la reclasificación cuando el sistema cambie sustancialmente. Un equipo o un departamento no son responsables.
• Indicador de desarrollo interno o proveedor externo: si el sistema se desarrolla internamente, se contrata como SaaS o viene embebido en un producto mayor. De este campo depende si su empresa actúa como proveedor, como responsable del despliegue (implantador) o en ambos papeles, conforme a los artículos 25 y 26.
• Nivel de riesgo del RIA: prohibido, alto riesgo (art. 6.1 o 6.2 con el punto concreto del Anexo III), riesgo limitado (con el apartado correspondiente del art. 50), riesgo mínimo, más una marca transversal de IAFG cuando proceda.
• Justificación de la clasificación: una breve fundamentación en prosa, incluida cualquier invocación de la excepción del artículo 6.3. Las justificaciones genéricas no superan una auditoría: el estándar es "documentado porque razonado".
• Modelo subyacente: para las entradas en las que su empresa actúa como implantador de un IAFG, identidad del modelo, versión, proveedor y fecha de la última revisión de las instrucciones de uso del proveedor previstas en el art. 53.1.b.
• Finalidad prevista: el caso de uso concreto comunicado a los implantadores, en los términos de las instrucciones de uso del artículo 13. La desviación entre la finalidad prevista y el uso efectivo es una de las observaciones más frecuentes en auditoría.
• Base jurídica del RGPD: para cualquier sistema que trate datos personales, la base del artículo 6 del RGPD (y la condición del artículo 9 cuando intervienen categorías especiales). Referencia cruzada al registro del artículo 30 del RGPD correspondiente.
• Origen de los datos de entrenamiento: resumen de procedencia que cubra fuente, condiciones de licencia, cumplimiento de los mecanismos de exclusión por derechos de autor y cualquier minimización o anonimización aplicada. Para entradas de implantador de IAFG, el campo puede remitir al resumen publicado por el proveedor sobre el contenido de entrenamiento.
• Tipo de salida: predicción, recomendación, clasificación, generación de contenido, decisión. El tipo de salida activa los deberes de transparencia del artículo 50 y el análisis del artículo 22 del RGPD.
• Impacto decisional: si las salidas influyen en decisiones consecuentes sobre personas físicas identificables y, en tal caso, qué población se ve afectada (empleados, candidatos, clientes, pacientes, beneficiarios). Este es el campo que indica cuándo procede una EIPD del artículo 35 del RGPD o una evaluación de impacto en derechos fundamentales (EIDF) del artículo 27 del RIA.
• Diseño de la supervisión humana: las medidas del artículo 14 efectivamente implantadas —revisión previa al despliegue, validación de salidas, capacidad de anulación, umbrales de intervención, vías de escalado—. Una entrada genérica del estilo "una persona revisa la salida" no supera el estándar de auditoría.
• Estado de la evaluación de conformidad: para las entradas de alto riesgo, vía adoptada (control interno conforme al Anexo VI, evaluación por tercero conforme al Anexo VII para biometría, evaluación integrada para productos del Anexo I), fecha de la última evaluación y referencia de la declaración UE de conformidad del artículo 47.
• Inscripción en la base de datos de la UE: para las entradas de alto riesgo dentro del ámbito del artículo 49, identificador de inscripción y fecha de la última actualización.
• Fecha de la última revisión y próximo desencadenante: la fecha calendaria de la última revisión de la clasificación y los eventos de cambio que forzarán una nueva revisión (cambio de modelo, modificación de los datos de entrenamiento, ampliación de la finalidad prevista, integración en un nuevo flujo de negocio).

Reutilizar los registros existentes

El inventario de IA más barato es el que se construye como extensión de registros ya existentes, no desde cero. Tres artefactos preexistentes cubren la mayor parte de los campos descritos y aportan, además, la disciplina de gobernanza necesaria para mantenerlos al día.

El Registro de Actividades de Tratamiento (RAT) del artículo 30 del RGPD cubre el espinazo de datos personales de cualquier sistema de IA que trate información sobre personas físicas identificables. El RAT ya recoge la base jurídica, las categorías de datos, las categorías de interesados, los destinatarios, las transferencias internacionales y los plazos de supresión —datos que el inventario de IA, o bien debe replicar, o bien debe referenciar—. La medida pragmática consiste en añadir una columna "sistema de IA asociado" al RAT existente y, en sentido inverso, hacer que la ficha del inventario remita al RAT correspondiente en lugar de duplicar los campos de datos personales. Las EIPD del artículo 35 del RGPD y, en su caso, las EIDF del artículo 27 del RIA —aplicables a despliegues por entidades públicas o por entidades privadas que prestan servicios públicos, y, separadamente, a cualquier implantador (público o privado) de un sistema del Anexo III §5(b) de evaluación de la solvencia o de un sistema del Anexo III §5(c) de evaluación de riesgos y tarificación en seguros de vida o de salud— deben enlazarse desde la ficha del inventario en lugar de copiarse en ella.

Los inventarios de activos NIS2, allí donde existan, cubren el espinazo operativo y de seguridad de la información. Las leyes nacionales de transposición de NIS2 —el plazo de transposición concluyó el 17 de octubre de 2024 y la Comisión Europea abrió procedimientos de infracción en noviembre de 2024 contra 23 Estados miembros que lo habían incumplido; la transposición ha continuado por oleadas a lo largo de 2025 y 2026— exigen a las entidades esenciales e importantes mantener un registro de activos y dependencias de TIC. Para las pymes incluidas en el ámbito de NIS2, el registro suele incorporar ya las plataformas en la nube, las dependencias SaaS y los sistemas críticos sobre los que corren las cargas de IA. Etiquetar los sistemas de IA dentro del registro NIS2 y remitir cruzadamente al inventario de IA armoniza ambos regímenes y evita la situación —demasiado frecuente— en la que el inventario NIS2 muestra un SaaS de tercero sin advertir que ese SaaS embebe un caso de uso de IA dentro del ámbito del Reglamento.

El control A.5.9 del Anexo A de ISO/IEC 27001:2022 (antes A.8.1.1 en la versión de 2013) exige un inventario de información y otros activos asociados, incluidos software, servicios y la propia información. Para las pymes certificadas en ISO 27001, el inventario de activos exigido por A.5.9 es el portador natural del registro de IA. La traza de auditoría que pide ISO 27001 —responsable, clasificación, registro de cambios— se mapea ya con los campos del inventario de IA. Tratar el inventario de IA como un subconjunto del inventario de activos del SGSI, en lugar de como un artefacto nuevo, ahorra mantenimiento duplicado, da al registro de IA el beneficio de la cadencia de revisión existente y evita el estado —demasiado habitual— en el que el inventario del SGSI y el inventario de IA derivan a versiones mutuamente incoherentes.

Más allá de esos tres registros, dos repositorios adyacentes merecen una visita: el registro de proveedores que mantiene el área de compras (que normalmente captura cada SaaS externo en uso por la organización y suele ser la vía más rápida para una barrida exhaustiva de IA en la sombra) y el registro de protección de datos sobre consentimiento o base contractual (que ya sostiene la cara del RGPD de cualquier sistema de IA orientado al cliente). Cuando el inventario de IA se construye como una federación de referencias entre estos registros existentes, en vez de como una hoja de cálculo nueva, la sobrecarga de mantenimiento se reduce en torno a la mitad y la coherencia entre regímenes que un auditor busca emerge de manera natural.

Tres ejemplos de inventario en pymes

Los ejemplos prácticos afilan la disciplina. Los tres casos breves que siguen muestran cómo aterriza el esquema del inventario en una pyme proveedora de tecnología de RR. HH., en una FinTech y en una MedTech, cada una característica del tipo de empresa europea en fase temprana más expuesta a la fecha del 2 de agosto de 2026.

RR. HH.: pyme SaaS de 50 personas en Múnich

El producto ofrece un sistema de seguimiento de candidaturas con dos funcionalidades de IA: el resumen de currículums apoyado en GPT-4o y la priorización de candidatos entrenada sobre el historial de contrataciones del cliente. El inventario contiene dos entradas distintas, no una. La entrada A —resumen de currículums— es un sistema de riesgo limitado por sí mismo (transparencia tipo agente conversacional del artículo 50.1, dado que el seleccionador ve un resumen claramente etiquetado como generado por IA), con una capa transversal de implantador de IAFG que apunta a OpenAI como proveedor aguas arriba. La entrada B —priorización de candidatos— es de alto riesgo de manera inequívoca conforme al punto 4(a) del Anexo III (empleo, contratación, selección de candidatos), con la pyme actuando como proveedor porque el sistema se introduce en el mercado de la Unión bajo su nombre. La entrada B carga con el paquete íntegro de trece obligaciones que va del artículo 9 al 49; la entrada A solo soporta la divulgación del artículo 50.1 más la traza documental del régimen IAFG. El responsable compartido de ambas entradas es el director de Producto, con un responsable secundario nombrado en el equipo jurídico como AI compliance lead. La ficha cruza referencias con el inventario de activos de ISO 27001 (la empresa está certificada) en ambas entradas y con el RAT del RGPD para los campos de datos personales. Las dos entradas marcan la fecha de aplicación del 2 de agosto de 2026 como desencadenante para completar el expediente técnico del artículo 11 y del Anexo IV.

FinTech: empresa emergente de crédito al consumo de 30 personas en Vilna

El producto ofrece una solicitud de crédito al consumo con dos componentes de IA: un modelo de scoring crediticio entrenado sobre datos internos más señales de open banking, y un modelo de detección de fraude superpuesto a la telemetría transaccional. El modelo de scoring crediticio cae en el punto 5(b) del Anexo III —evaluación de la solvencia de personas físicas— y es de alto riesgo por defecto; la empresa actúa como proveedor, comercializa el sistema en su propia plataforma y opta por la evaluación de conformidad mediante control interno conforme al Anexo VI. El modelo de detección de fraude se acoge a la exclusión textual escrita directamente dentro del Anexo III §5(b), que excluye, en sus propios términos, "los sistemas de IA destinados a detectar el fraude financiero" de la categoría de evaluación de la solvencia desde el primer momento; se trata de una exclusión distinta de la derogación procedimental del artículo 6.3 que filtra los sistemas del Anexo III en general, y la ficha del inventario debe dejar claro qué salida se está utilizando en cada caso. Como la exclusión textual es estrecha (cubre la detección de fraude, no toda la puntuación de riesgo transaccional), el equipo jurídico mantiene una posición defensiva manteniendo un conjunto parcial de controles de alto riesgo sobre el modelo antifraude y activa una reclasificación toda vez que la finalidad del modelo se extienda más allá de la detección del fraude. El caso fronterizo es un agente conversacional de soporte construido sobre Mistral Large; ese sistema se convierte en una entrada C de riesgo limitado con capa transversal de implantador de IAFG. La referencia cruzada al RAT del RGPD resulta crítica aquí porque el artículo 22 del RGPD (decisiones individuales automatizadas) se aplica a la entrada de scoring crediticio, y el inventario debe evidenciar el derecho del interesado a obtener intervención humana, a expresar su punto de vista y a impugnar la decisión. El artículo 27 del RIA también aplica en este caso: cualquier implantador de un sistema del Anexo III §5(b) está obligado a realizar una evaluación de impacto en derechos fundamentales, con independencia de que se trate de un implantador público o privado. La DPD es la responsable nombrada de las dos entradas de alto riesgo; el director de operaciones de cliente lo es del agente conversacional.

MedTech: empresa emergente de monitorización remota de 20 personas en Dublín

El producto es una aplicación de monitorización remota de pacientes con un único caso de uso de IA: un algoritmo que detecta cambios clínicamente significativos en las constantes vitales a partir de la telemetría continua de un dispositivo vestible. El sistema está regulado como producto sanitario al amparo del Reglamento (UE) 2017/745 (MDR) y porta marcado CE bajo ese régimen. La ficha del inventario es de alto riesgo conforme al artículo 6.1: la IA es un componente de seguridad de un producto cubierto por la legislación de armonización de la Unión del Anexo I (productos sanitarios), que exige evaluación de la conformidad por tercero. Las obligaciones sustantivas de alto riesgo del Reglamento de IA son exigibles para esta entrada desde el 2 de agosto de 2027, no desde el 2 de agosto de 2026, debido al calendario diferido del artículo 6.1 que establece el artículo 113. La evaluación de conformidad se integra en el procedimiento existente del MDR; el organismo notificado bajo MDR cubre también el trabajo específico exigido por el RIA, con los entregables propios del Reglamento de IA (documentación técnica del artículo 11, gestión de riesgos del artículo 9, transparencia hacia los profesionales sanitarios del artículo 13) sumados al expediente técnico ya existente. La ficha del inventario remite al expediente técnico del MDR en lugar de duplicarlo, el responsable del SGC es la misma persona que ya preside la responsabilidad del sistema de gestión de la calidad bajo el artículo 10 del MDR, y la ficha cruza referencia con el RAT del RGPD para el tratamiento de datos personales de salud al amparo del artículo 9.2.h del RGPD. El plazo diferido es la trampa en este caso: una MedTech que tome erróneamente el 2 de agosto de 2026 como desencadenante acaba ejecutando trabajo de conformidad en paralelo doce meses antes de tiempo.

Brechas que pillan a las pymes

Tres categorías de brecha aparecen una y otra vez en los proyectos de inventario en pymes, y cada una mina silenciosamente el registro si no se rastrea de manera deliberada.

La IA en la sombra es la mayor de las tres. Los equipos de marketing adoptan Jasper, ChatGPT Team o Copy.ai para redactar contenidos. Los equipos de ventas conectan Gong, Apollo o Lavender a las grabaciones de llamadas y al alcance por correo electrónico. Los equipos de ingeniería usan GitHub Copilot, Cursor o Codeium sin una decisión formal de compra. RR. HH. lanza encuestas a través de ChatGPT y procesa las respuestas abiertas con clasificadores de sentimiento. Cada uno de esos usos es un caso de uso de IA en el ámbito del artículo 3.1, casi con seguridad de riesgo limitado o mínimo por sí mismo, pero invisible para el inventario central a menos que alguien pregunte. La solución es procedimental: una declaración de una página dirigida a cada responsable de departamento que liste cada herramienta de IA utilizada por su equipo en los seis meses anteriores, repetida trimestralmente, con los extractos de tarjetas corporativas y el libro de gastos de SaaS empleados como contraste. La primera ronda de declaraciones en una pyme SaaS típica de 50 personas saca a la luz entre doce y veinte herramientas de IA que la función central de cumplimiento desconocía.

La IA embebida en SaaS es la segunda brecha. Cada vez con más frecuencia, el SaaS B2B estándar que la organización lleva años usando ha incorporado funcionalidades de IA durante 2024 y 2025 —Salesforce Einstein, HubSpot AI, Notion AI, Slack AI, Zoom AI Companion, Microsoft 365 Copilot, las funciones de Google Workspace Gemini, Atlassian Intelligence—. La organización anfitriona es responsable del despliegue de cada uno de esos subsistemas de IA, aunque la contratación inicial fuera por la herramienta de productividad subyacente. El inventario debe capturar cada subfuncionalidad de IA como entrada distinta, no fundirlas en la línea del SaaS principal. Cada proveedor es, a su vez, implantador de IAFG por encima de un proveedor aguas arriba del modelo, de modo que la cascada documental discurre a tres niveles: modelo fundacional (OpenAI / Anthropic / Google) → proveedor SaaS (HubSpot / Microsoft / Slack) → organización anfitriona. La ficha del inventario debe nombrar las tres capas para que las obligaciones del implantador resulten ejecutables.

Los cambios de modelo aguas arriba constituyen la tercera brecha y la más resbaladiza. Un proveedor SaaS cambia el IAFG subyacente —por ejemplo, de GPT-4 a GPT-4o, o de Claude 3.5 a Claude 4— sin alterar la superficie del producto, y la ficha del inventario en el lado del implantador queda desactualizada sin que nadie lo advierta. La solución pasa por incorporar un campo "versión del modelo bloqueada" al inventario y por exigir un desencadenante de reclasificación cuando el modelo aguas arriba cambie. Para los proveedores maduros, el cambio se anuncia en un canal de notas de versión al que el área de compras debería estar suscrita; para los menos maduros, la ficha debe consignar de manera explícita que la identidad del modelo aguas arriba es volátil y la cadencia de revisión de esa entrada debe estrecharse (trimestral en lugar de anual).

Problemas habituales de asignación de responsable

La razón más frecuente por la que un inventario de IA se descompone hasta dejar de ser útil es que la propiedad se asigna a un equipo o departamento en lugar de a una persona física nombrada. "El equipo de Producto es responsable de la entrada 7" es una no respuesta cuando el sistema cambia sustancialmente y nadie actualiza la ficha, porque ninguna persona concreta había contraído la obligación de hacerlo. La disciplina que sostiene cualquier otro registro normativo —la DPD nombrada detrás del RAT, el CISO nombrado detrás del inventario de activos de ISO 27001, el contacto nombrado en la notificación NIS2 al Estado miembro— es la misma disciplina que necesita el inventario de IA.

Tres patrones funcionan en la práctica. El primero consiste en designar un responsable único del Reglamento de IA, alojado típicamente en la función jurídica o de cumplimiento, que asume la titularidad del registro central y el papel de responsable nombrado en las entradas más críticas (los sistemas de alto riesgo del Anexo III en los que el expediente técnico del artículo 11 requiere aportación interfuncional). El segundo es un modelo federado en el que el responsable del Reglamento de IA conserva la titularidad del registro y la metodología, mientras que cada entrada lleva un responsable de producto o de funcionalidad nombrado individualmente: adecuado para organizaciones SaaS donde se publican nuevas funcionalidades de IA cada trimestre y la centralización de la titularidad sería un cuello de botella. El tercero es un modelo de copropiedad en el que cada entrada de alto riesgo cuenta con un responsable de negocio designado (el director de producto o el responsable funcional correspondiente) y un responsable de control designado (la DPD o el AI compliance lead): el primero rinde cuentas por mantener la ficha al día conforme evoluciona el sistema, el segundo rinde cuentas por que se cumplan las obligaciones aplicables. Cualquiera de los tres modelos es defendible; lo que no es defendible es dejar entradas con propiedad de equipo o sin propietario.

Un segundo problema de asignación es la ausencia de copropietario en las entradas interfuncionales. El ejemplo de RR. HH. desarrollado más arriba es el caso canónico: el responsable de producto de la funcionalidad de priorización de candidatos está naturalmente situado para mantener al día el expediente técnico, pero la obligación de informar a los trabajadores afectados que recoge el artículo 26.7 reside en la función de RR. HH. del propio cliente —del lado del implantador—, no en la del proveedor. Si la ficha del proveedor no nombra un responsable contraparte dentro de cada organización cliente, las obligaciones en cascada del artículo 26 no pueden evidenciarse y las instrucciones de uso del artículo 13 del proveedor no pueden articularse adecuadamente. La documentación de incorporación de clientes y la plantilla del Acuerdo Marco de Servicios deberían incluir una cláusula que exija al cliente nombrar un responsable del despliegue del Reglamento de IA antes de la activación.

El artículo 26.5 merece una mención final porque es una de las pocas obligaciones del implantador que pillan desprevenidos incluso a inventarios disciplinados. Los responsables del despliegue de sistemas de IA de alto riesgo deben supervisar el funcionamiento del sistema sobre la base de las instrucciones de uso y, cuando proceda, informar al proveedor con arreglo al artículo 72. Cuando el implantador tenga motivos para considerar que el uso conforme a las instrucciones puede dar lugar a que el sistema presente un riesgo en el sentido del artículo 79.1, debe, sin demora indebida, informar al proveedor o distribuidor y a la autoridad de vigilancia del mercado competente, y suspender el uso del sistema. Operativamente, esto implica que cada entrada de alto riesgo del inventario necesita un responsable de monitorización nombrado del lado del implantador, una vía documentada de escalado que termine en la autoridad nacional competente y un protocolo de suspensión por escrito que pueda activarse sin nuevas firmas internas. Designar a esos roles tarde, una vez el sistema ya está en producción, es una de las observaciones de cumplimiento más recurrentes en los primeros expedientes sancionadores.

Plan de implantación en 60 días

Sesenta días bastan para entregar una primera versión defendible del inventario si la secuencia se gestiona con limpieza, el órgano de dirección se compromete con la cadencia desde el primer día y los registros existentes se reutilizan en lugar de duplicarse. El plan que sigue asume una pyme estándar de 30 a 100 personas, sin función previa de gobernanza de IA, con un único responsable interfuncional del Reglamento de IA designado para el trabajo.

Días 1 a 10: alcance y mapa de reutilización. El responsable del Reglamento de IA reúne el RAT del RGPD existente, el inventario de activos de ISO 27001 cuando aplique, el registro NIS2 cuando esté en el ámbito, la lista de proveedores que mantiene compras y el libro de gastos de SaaS. Cada entrada de cada uno de esos registros se revisa por su relevancia respecto a la IA, y las que tocan IA quedan marcadas para el inventario. El responsable redacta el esquema del inventario —el conjunto de quince campos descrito más arriba, con las extensiones específicas que la organización necesite— y lo somete a la firma de la DPD, del CISO cuando exista y de un patrocinador del órgano de dirección. La elección de herramienta se cierra en la misma ventana: hoja de cálculo, plataforma de GRC o extensión del soporte que ya da sostén al RAT. Para pymes sin plataforma GRC, una hoja de cálculo estructurada bajo control de versiones y con campos obligatorios de revisión es suficiente para la primera versión.

Días 11 a 30: descubrimiento y población. La barrida de IA en la sombra discurre en esta ventana: la declaración de una página a cada responsable de departamento, la conciliación con los gastos de SaaS y entrevistas estructuradas con cada responsable funcional (producto, ingeniería, marketing, ventas, soporte al cliente, RR. HH., finanzas y operaciones). Cada declaración se convierte en un borrador de ficha. El responsable del RIA cumplimenta los campos de metadatos a partir del RAT y de los registros de activos existentes en todas las casillas en las que el dato ya consta, y solo abre un hilo nuevo de recogida cuando se trata de campos genuinamente específicos de IA (finalidad prevista, tipo de salida, modelo subyacente, origen de los datos de entrenamiento, diseño de la supervisión humana). Al cierre del día 30, cada caso de uso de IA conocido por la organización debe disponer de un borrador de ficha, aunque la asignación de nivel sea provisional y la justificación todavía esquemática.

Días 31 a 50: clasificación y análisis de carencias. El responsable del RIA recorre cada borrador a través del árbol de decisión de niveles (ocho preguntas que cubren el artículo 5, el Anexo III, el artículo 6.1, el artículo 6.3, la condición de proveedor o implantador, la capa transversal de IAFG, la interacción del artículo 50.1, el contenido sintético de los apartados 50.2 y 50.4 y el riesgo sistémico del artículo 51). Cada entrada recibe un nivel asignado con su justificación escrita. Para las entradas de alto riesgo y de riesgo limitado, el responsable ejecuta un análisis de carencias frente al paquete de obligaciones correspondiente: para alto riesgo, la línea base de trece elementos del artículo 9 al 49; para riesgo limitado, las cuatro obligaciones de divulgación del artículo 50. Cada carencia se convierte en una tarea de remediación con responsable nombrado y fecha objetivo, secuenciada contra el 2 de agosto de 2026 (o el 2 de agosto de 2027 para las entradas del Anexo I amparadas en el artículo 6.1). El alcance de las EIPD y de las EIDF del artículo 27 se decide en la misma ventana: cada entrada de alto riesgo que trate datos personales activa una revisión de EIPD, y cualquier entrada de alto riesgo desplegada por una entidad pública, por una entidad privada que preste servicios públicos o por cualquier implantador de un sistema del Anexo III §5(b) de evaluación de la solvencia o del Anexo III §5(c) de tarificación en seguros de vida o de salud activa una EIDF del artículo 27.

Días 51 a 60: aprobación y cadencia operativa. El inventario y el listado de remediación se presentan al órgano de dirección para su aprobación. El punto del Reglamento de IA pasa a formar parte permanente del orden del día trimestral del consejo. El responsable de cada entrada de alto riesgo se designa formalmente por escrito, y los responsables de monitorización del lado del implantador previstos en el artículo 26.5 se confirman junto con su autoridad de suspensión. Los contratos con clientes y la documentación de incorporación se revisan para incluir las cláusulas de instrucciones de uso del artículo 13 y de cascada al implantador del artículo 26. El programa de alfabetización en IA del artículo 4 queda dimensionado, con el inventario utilizado para identificar los colectivos de personal que operan o utilizan cada sistema. Una primera auditoría interna del inventario se programa para el cierre del primer trimestre de 2027 —seis meses después de que las obligaciones empiecen a morder, plazo suficiente para que la operación en vivo aflore la primera ronda de incidencias y suficientemente corto como para que las carencias todavía puedan remediarse antes del primer ciclo de auditoría externa—. La revisión de segunda versión del propio inventario se programa para el cierre del segundo trimestre de 2027.

Conclusión y próximos pasos

La fecha del 2 de agosto de 2026 es fija y asimétrica: el coste de llegar tarde con el inventario es muy superior al de llegar pronto, porque casi todas las demás obligaciones del Reglamento de IA dependen de él. El trabajo está, además, inusualmente bien alineado con lo que las pymes europeas ya hacen bien —el RAT del artículo 30 del RGPD, los registros de activos de NIS2, los inventarios de activos de ISO 27001—, de modo que el esfuerzo marginal es sensiblemente menor de lo que la lectura de la norma sugiere a primera vista. La trampa consiste en tratar el inventario de IA como un artefacto paralelo y no como una extensión federada de los registros que ya existen. Constrúyalo como una federación, nombre a una persona física como responsable de cada entrada y trate la IA en la sombra, la IA embebida en SaaS y los cambios de modelo aguas arriba como las tres categorías de brecha que socavan silenciosamente el registro si no se rastrean de forma explícita.

En términos prácticos, los próximos sesenta días para una pyme que parta de cero tienen este aspecto: nombrar al responsable del Reglamento de IA en la primera semana, cerrar el esquema y el plan de reutilización en la segunda, ejecutar la barrida de IA en la sombra en la tercera y la cuarta, completar el primer borrador del registro en la cuarta y la quinta, clasificar y analizar carencias en cada entrada en la sexta y la séptima, y presentar al órgano de dirección un registro firmado y un mapa de remediación en la novena. Para la décima, el inventario deja de ser un proyecto y se convierte en un activo operativo permanente, con cadencia de revisión trimestral y propietario nombrado en cada entrada. Esa es la postura que recompensa la fecha del 2 de agosto de 2026 y la postura que vuelve abordable el resto del backlog de cumplimiento del Reglamento de IA.