Inventario de sistemas de IA: qué exige cada norma y cómo crearlo

Inventario de sistemas de IA con responsables, nivel de riesgo y evaluaciones vinculadas por sistema

Claves del artículo

  • Un inventario de sistemas de IA es el registro interno de todos los sistemas, modelos, agentes y servicios de IA de terceros que una organización desarrolla, compra o utiliza.
  • Ninguna norma lo titula así, pero el Reglamento de IA, el NIST AI RMF, la ISO/IEC 42001, la OMB y la Reserva Federal lo presuponen.
  • No es lo mismo que el registro en la base de datos de la UE, el registro de modelos de MLOps ni el AI-BOM.
  • Cada columna responde a una obligación concreta: rol, nivel de riesgo, responsable, evaluaciones vinculadas, número de registro.
  • Un inventario que funciona cruza varias fuentes de descubrimiento, tiene una puerta de entrada obligatoria y se actualiza ante cada cambio.

Inventario de sistemas de IA: qué es y qué no es

Un inventario de sistemas de IA es la lista interna, mantenida y con responsable, de cada sistema de inteligencia artificial que la organización desarrolla, adquiere o utiliza, incluidos los modelos, los agentes y la IA integrada en servicios de terceros. Para cada entrada recoge la finalidad, el rol de la organización, el nivel de riesgo, los responsables, las evaluaciones realizadas y el estado en el ciclo de vida. Su precedente más cercano es el registro de actividades de tratamiento del artículo 30 del RGPD, y muchas organizaciones empiezan precisamente ampliando ese registro. Cinco objetos se confunden a menudo. El inventario de sistemas de IA es el único que cubre todo el perímetro; los demás son subconjuntos, vistas técnicas o salidas reguladas que se alimentan de él. <table header-row=»true»> <tr> <td>Objeto</td> <td>Qué es</td> <td>Quién lo mantiene</td> <td>Estatus jurídico</td> </tr> <tr> <td>Inventario de sistemas de IA</td> <td>Registro interno de todos los usos de IA, propios y de terceros</td> <td>Gobernanza de IA o cumplimiento, con los responsables de negocio</td> <td>Presupuesto por varios marcos; base de las demás obligaciones</td> </tr> <tr> <td>Registro en la base de datos de la UE</td> <td>Inscripción de ciertos sistemas en la base de datos de la Comisión</td> <td>El proveedor y, en algunos casos, el responsable del despliegue público</td> <td>Obligación expresa de los artículos 49 y 71 del Reglamento de IA</td> </tr> <tr> <td>Registro de modelos (MLOps)</td> <td>Repositorio de versiones, artefactos y métricas de modelos propios</td> <td>Ciencia de datos y plataforma</td> <td>Herramienta de ingeniería, sin valor normativo</td> </tr> <tr> <td>AI-BOM</td> <td>Lista de materiales: modelos, datos, bibliotecas y dependencias</td> <td>Ingeniería y seguridad de la cadena de suministro</td> <td>Formato técnico (SPDX 3.0, CycloneDX ML-BOM), útil como prueba</td> </tr> <tr> <td>Registro de riesgos</td> <td>Riesgos identificados, su valoración y sus mitigaciones</td> <td>Gestión de riesgos</td> <td>Exigido por los sistemas de gestión; cada riesgo apunta a una entrada del inventario</td> </tr> </table> La relación práctica es sencilla: el inventario de sistemas de IA identifica el sistema, el registro de riesgos describe lo que puede fallar, el AI-BOM documenta de qué está hecho y la base de datos de la UE recibe solo lo que la ley obliga a declarar. Sin inventario, los otros cuatro quedan huérfanos, y los sistemas de IA de alto riesgo no pueden identificarse sin haber enumerado antes todos los demás.

Cómo un inventario de sistemas de IA sostiene una gobernanza responsable

La pregunta suele formularse literalmente: ¿cómo contribuye mantener un inventario de sistemas de IA a una gobernanza responsable? No «porque es una buena práctica», sino porque cinco mecanismos de control dependen de él y fallan en silencio cuando falta.

  1. Fija el alcance de todos los demás controles. El inventario de sistemas de IA delimita el perímetro: lo que no figura en él no se evalúa, no se supervisa y no se audita.
  2. Impulsa la clasificación del riesgo. El nivel del Reglamento de IA (prohibido, alto riesgo, transparencia, riesgo mínimo) y el nivel interno se asignan entrada por entrada. Sin una lista completa, la clasificación se hace sobre una muestra y sus conclusiones no valen para el conjunto.
  3. Nombra un responsable por sistema. Cada entrada lleva un responsable de negocio y un responsable técnico. Así se permite al comité de gobernanza de IA saber a quién pedir cuentas.
  4. Detecta el cambio. Una nueva finalidad, una nueva versión del modelo, un nuevo proveedor o un nuevo mercado pueden cambiar la clasificación de un sistema. Un inventario de sistemas de IA con fecha de revisión y registro de cambios hace visible esa deriva antes de que la descubra un tercero.
  5. Es la prueba sobre la que trabaja el auditor. Un auditor de la ISO/IEC 42001, un supervisor bancario o una autoridad de vigilancia del mercado no revisan todos los sistemas: extraen una muestra. Esa muestra sale del inventario de sistemas de IA, y la auditoría solo vale si la población está completa.

En otras palabras, el inventario de sistemas de IA es la tabla de la que leen todos los demás procesos. Cuando los equipos de cumplimiento normativo en IA se preguntan por qué sus controles no escalan, la causa suele ser un inventario incompleto o desactualizado, no los controles mismos.

Qué normas hacen obligatorio un inventario de sistemas de IA

Ninguna gran norma contiene un artículo titulado «inventario de IA». La obligación es estructural: las normas exigen registrar, clasificar, evaluar o informar sobre cada sistema, y eso es imposible sin una lista previa. La tabla resume las fuentes principales a septiembre de 2026. <table header-row=»true»> <tr> <td>Régimen</td> <td>Disposición</td> <td>A quién se aplica</td> <td>Qué exige</td> <td>Situación en septiembre de 2026</td> </tr> <tr> <td>Reglamento de IA (UE) 2024/1689</td> <td>Arts. 6.4, 26.8, 49 y 71</td> <td>Proveedores y responsables del despliegue públicos</td> <td>Registro en la base de datos de la UE y documentación de las excepciones del art. 6.3</td> <td>Registro mantenido por el Ómnibus; anexo III aplazado al 2 de diciembre de 2027</td> </tr> <tr> <td>NIST AI RMF 1.0</td> <td>GOVERN 1.6</td> <td>Organizaciones que adoptan el marco</td> <td>Mecanismos para inventariar los sistemas de IA</td> <td>Voluntario, referencia muy usada</td> </tr> <tr> <td>ISO/IEC 42001:2023</td> <td>Anexo A.4</td> <td>Organizaciones certificadas o en proceso</td> <td>Documentar los recursos de cada sistema</td> <td>Certificable</td> </tr> <tr> <td>Agencias federales de EE. UU.</td> <td>OMB M-25-21, EO 13960</td> <td>Agencias federales</td> <td>Inventario anual público de casos de uso</td> <td>En vigor; inventario 2025 publicado en abril de 2026</td> </tr> <tr> <td>Bancos de EE. UU.</td> <td>SR 26-2</td> <td>Entidades supervisadas por la Fed, la OCC y la FDIC</td> <td>Inventario de modelos graduado por materialidad</td> <td>En vigor desde el 17 de abril de 2026</td> </tr> <tr> <td>Sector público británico</td> <td>ATRS</td> <td>Departamentos centrales y organismos adscritos</td> <td>Fichas públicas por herramienta algorítmica</td> <td>Obligatorio desde 2025</td> </tr> </table>

Reglamento de IA: el registro presupone un inventario

El Reglamento (UE) 2024/1689 obliga al proveedor a registrar los sistemas de alto riesgo del anexo III en la base de datos de la UE antes de introducirlos en el mercado o ponerlos en servicio (art. 49.1). Si concluye, con arreglo al art. 6.3, que un sistema del anexo III no es de alto riesgo, debe documentar esa evaluación y registrarlo igualmente (arts. 6.4 y 49.2). Los responsables del despliegue que son autoridades públicas o instituciones de la UE registran su uso (arts. 49.3 y 26.8); las entradas de aplicación de la ley, migración y fronteras van a una sección segura no pública (art. 49.4), y la Comisión mantiene la base de datos (art. 71). El artículo 49 no menciona un inventario, pero no se cumple sin uno. El Ómnibus digital sobre IA, Reglamento (UE) 2026/1744, en vigor desde el 27 de julio de 2026, aplazó el anexo III al 2 de diciembre de 2027 y el anexo I al 2 de agosto de 2028, pero mantuvo el registro, también para los sistemas exentos por el art. 6.3. Las prácticas prohibidas rigen desde el 2 de febrero de 2025.

NIST AI RMF: GOVERN 1.6

La subcategoría GOVERN 1.6 del NIST AI RMF dice: «Mechanisms are in place to inventory AI systems and are resourced according to organizational risk priorities» (existen mecanismos para inventariar los sistemas de IA, dotados de recursos según las prioridades de riesgo de la organización). El Playbook del NIST sugiere enumerar los sistemas de la organización y extender el inventario a la procedencia de los datos, los problemas conocidos, los roles de supervisión humana y los modelos fundacionales subyacentes.

ISO/IEC 42001: documentación de recursos del anexo A.4

La ISO/IEC 42001:2023 dedica su control A.4 a los recursos de los sistemas de IA. En esencia, el apartado A.4.2 pide identificar y documentar, para cada sistema, los datos, las herramientas, los recursos de sistema y de cómputo, y los recursos humanos. Esa documentación por sistema es, en la práctica, un inventario de sistemas de IA enriquecido, y los auditores de certificación ISO 42001 lo piden desde la fase documental.

Agencias federales de EE. UU.: OMB M-25-21

El inventario federal de casos de uso de IA de 2025, publicado por la OMB en abril de 2026, recoge 3.611 casos de uso notificados por 56 agencias, 445 de ellos de alto impacto. Se basa en la Orden Ejecutiva 13960 (sección 5), la Advancing American AI Act y el Memorando M-25-21, y excluye los sistemas de seguridad nacional y la investigación. La cifra duplica con creces los 1.757 casos de 2024.

Bancos: el inventario de modelos de la SR 26-2

La carta SR 26-2 de la Reserva Federal, del 17 de abril de 2026 y conjunta con la OCC y la FDIC, sustituyó a la SR 11-7. Estrecha la definición de modelo, gradúa los controles por materialidad y permite mantener los modelos no materiales en el inventario con controles más ligeros. Los comentaristas señalan que la IA generativa y los agentes quedan en gran parte fuera de esa definición: la gestión del riesgo de modelos necesita, junto al inventario de modelos, un inventario de sistemas de IA más amplio.

Registros de transparencia del sector público

En el Reino Unido, el Algorithmic Transparency Recording Standard (ATRS) es obligatorio desde 2025 para los departamentos del Gobierno central y sus organismos adscritos, que publican en GOV.UK una ficha por herramienta. En España, la Agencia Española de Supervisión de la Inteligencia Artificial (AESIA), creada por el Real Decreto 729/2023 y con sede en A Coruña, actúa en la vigilancia del mercado: cuando pida información sobre un sistema, la respuesta empezará por su entrada en el inventario de sistemas de IA.

Inventario de sistemas de IA: los campos necesarios

Un buen inventario de sistemas de IA no nace de una plantilla genérica, sino de lo que cada norma va a preguntar. La tabla vincula cada campo con el régimen que lo exige. <table header-row=»true»> <tr> <td>Campo</td> <td>Por qué importa</td> <td>Régimen que lo pide</td> </tr> <tr> <td>Identificador único y nombre</td> <td>Enlaza evaluaciones, riesgos, incidentes y pruebas con un mismo sistema</td> <td>Todos; base del registro del art. 49</td> </tr> <tr> <td>Finalidad de negocio y caso de uso</td> <td>La clasificación depende del uso, no de la tecnología</td> <td>Reglamento de IA (anexo III), OMB M-25-21</td> </tr> <tr> <td>Rol (proveedor, responsable del despliegue, importador, distribuidor)</td> <td>Determina qué obligaciones se aplican</td> <td>Reglamento de IA, arts. 16, 23, 24 y 26</td> </tr> <tr> <td>Estado en el ciclo de vida</td> <td>Distingue piloto, producción y retirada</td> <td>NIST AI RMF, ISO/IEC 42001</td> </tr> <tr> <td>Responsable de negocio y responsable técnico</td> <td>Asigna la rendición de cuentas</td> <td>NIST GOVERN 1.6, ISO/IEC 42001</td> </tr> <tr> <td>Proveedor y procedencia del modelo, incluido el fundacional</td> <td>Hace visible la dependencia de terceros</td> <td>NIST Playbook, SR 26-2, AI-BOM</td> </tr> <tr> <td>Categorías de datos, incluidos datos personales y de categoría especial</td> <td>Vincula el sistema con el RGPD y la EIPD</td> <td>RGPD arts. 30 y 35, ISO/IEC 42001 A.4</td> </tr> <tr> <td>Personas afectadas e impacto de las decisiones</td> <td>Identifica los usos de alto impacto</td> <td>OMB M-25-21, Reglamento de IA art. 27</td> </tr> <tr> <td>Clasificación del riesgo (nivel del Reglamento de IA y nivel interno)</td> <td>Gradúa la intensidad de los controles</td> <td>Reglamento de IA art. 6, SR 26-2</td> </tr> <tr> <td>Evaluaciones vinculadas (EIPD, FRIA, evaluación de impacto de IA, evaluación de la conformidad)</td> <td>Demuestra que se hizo el trabajo exigido</td> <td>RGPD, Reglamento de IA arts. 27 y 43</td> </tr> <tr> <td>Mecanismo de supervisión humana</td> <td>Documenta quién puede intervenir y cómo</td> <td>Reglamento de IA art. 14, NIST Playbook</td> </tr> <tr> <td>Número de registro en la base de datos de la UE, si procede</td> <td>Conecta el registro interno con la obligación pública</td> <td>Reglamento de IA arts. 49 y 71</td> </tr> <tr> <td>Fecha de revisión y registro de cambios</td> <td>Hace auditable la evolución del sistema</td> <td>ISO/IEC 42001, NIST AI RMF</td> </tr> </table> Dos campos merecen atención especial. El de evaluaciones vinculadas: un inventario de sistemas de IA que no enlaza la evaluación de impacto de la IA, la EIPD o la evaluación de la conformidad obliga a reconstruir esa relación en cada auditoría. Y el de supervisión humana, que el art. 14 del Reglamento exige diseñar: el inventario es el lugar natural para registrar quién la ejerce. Tampoco sustituye a la documentación del sistema de IA: debe apuntar a ella.

Cómo construir y mantener un inventario de sistemas de IA

Construir el inventario de sistemas de IA es un proyecto; mantenerlo es un proceso, y lo segundo es lo que casi todas las organizaciones subestiman.

  1. Cruzar varias fuentes de descubrimiento. Contratos de compras y proveedores, registros de SSO y CASB (que revelan la IA en la sombra), facturación de la nube y de las API de modelos, repositorios de código y plataformas de ML, y una campaña de declaración en las unidades de negocio.
  2. Establecer una puerta de entrada. Ningún sistema pasa a producción sin estar registrado. Lo más eficaz es integrar el registro en la aprobación de compras, la due diligence de proveedores de IA y la revisión de cambios.
  3. Clasificar y graduar. Cada nueva entrada pasa un triaje: rol, posible encaje en el anexo III, prácticas prohibidas, transparencia, nivel interno de riesgo. El resultado fija las evaluaciones necesarias.
  4. Asignar responsables. Uno de negocio para la finalidad, uno técnico para el funcionamiento. Sin nombre, la entrada no está completa.
  5. Definir desencadenantes de actualización. Nueva finalidad, nueva versión del modelo, nuevo proveedor, incidente o nueva jurisdicción obligan a revisar la entrada y, si procede, la clasificación.
  6. Pedir una atestación periódica. Cada responsable confirma a intervalos regulares (trimestrales para el alto riesgo, anuales para el resto) que la entrada sigue siendo exacta.
  7. Registrar la retirada. Un sistema dado de baja no se borra del inventario de sistemas de IA: se marca como retirado, con la fecha y el destino de los datos y los modelos.

Los agentes y las herramientas conectadas por MCP (Model Context Protocol) son objetos de inventario por derecho propio. Un agente puede actuar sobre sistemas de producción o modificar datos, y debe figurar con sus herramientas autorizadas, el modelo que lo impulsa y los límites de su autonomía. La distinción entre IA agéntica e IA generativa importa aquí: un asistente de redacción y un agente que ejecuta pagos no comparten los mismos campos.

Dónde fallan los inventarios de IA

Los fallos se repiten, y casi ninguno es técnico.

  • La hoja de cálculo que envejece. Se construye para un proyecto, nadie la actualiza y a los seis meses ya no refleja la realidad.
  • Contar herramientas en lugar de usos. Registrar «ChatGPT Enterprise» como una sola entrada oculta que la misma herramienta sirve para redactar correos y para preseleccionar candidatos. Cada uso relevante necesita su propia entrada en el inventario de sistemas de IA.
  • Olvidar la IA integrada en el SaaS. CRM, herramientas de recursos humanos y plataformas de atención al cliente activan funciones de IA con una simple actualización.
  • Entradas sin responsable. Nadie las revisa, nadie las atesta y nadie las defiende ante el auditor.
  • Sin vínculo con las evaluaciones. Las pruebas se reconstruyen en cada revisión.
  • Un inventario construido una sola vez para una auditoría. Supera la auditoría y muere con ella.

La consecuencia es la misma: los controles se aplican con rigor a una lista incompleta y la organización se cree cubierta sin estarlo. En la IA en la sombra esa brecha suele ser la más amplia.

Preguntas frecuentes

¿Es obligatorio un inventario de sistemas de IA según el Reglamento de IA? El Reglamento no contiene un artículo que lo exija con ese nombre, pero impone obligaciones que no pueden cumplirse sin él: registrar en la base de datos de la UE los sistemas de alto riesgo del anexo III, documentar y registrar los que el proveedor considera exentos con arreglo al art. 6.3, registrar el uso por autoridades públicas y cumplir las obligaciones de los responsables del despliegue. Saber qué sistemas entran en cada categoría exige una lista completa. El inventario de sistemas de IA es, pues, una condición previa del cumplimiento. ¿Qué diferencia hay entre un inventario de IA y la base de datos de la UE? El inventario de sistemas de IA es interno, cubre todos los sistemas sea cual sea su nivel de riesgo e incluye información no publicada: responsables, evaluaciones, proveedores. La base de datos de la UE, que la Comisión mantiene en virtud del art. 71, solo recibe los sistemas y usos que el art. 49 obliga a registrar, con los datos que fija el Reglamento. El inventario alimenta la base de datos, no al revés, y guarda el número de registro obtenido. ¿Quién debe ser el responsable del inventario? Hay dos niveles. El inventario de sistemas de IA en su conjunto pertenece a la función de gobernanza de IA, que define el modelo, la puerta de entrada y el calendario de revisiones. Cada entrada tiene un responsable de negocio y uno técnico, que responden de su exactitud. Delegarlo todo en TI o en protección de datos suele dar un inventario técnicamente preciso pero ciego a las finalidades, que son justo lo que determina el riesgo. ¿Con qué frecuencia debe actualizarse? Por eventos y por calendario. Por eventos, cada vez que cambian la finalidad, la versión del modelo, el proveedor o la jurisdicción, o se produce un incidente relevante. Por calendario, mediante una atestación periódica de los responsables, más frecuente para los sistemas de alto riesgo (por ejemplo, trimestral) que para los de riesgo mínimo (anual). Un inventario de sistemas de IA revisado solo antes de una auditoría deja de ser fiable en pocos meses. ¿Sirve una hoja de cálculo? Para empezar, sí. Pero no impone una puerta de entrada, no conserva el historial de cambios de forma fiable, no enlaza con las evaluaciones ni con las pruebas y no avisa cuando vence una revisión. Con varias decenas de sistemas, mantenerla a mano cuesta más que una herramienta dedicada. ¿Deben inventariarse los agentes de IA? Sí, y con más detalle que un sistema convencional. Un agente combina un modelo, instrucciones y herramientas con las que actúa sobre otros sistemas. Su entrada en el inventario de sistemas de IA debe recoger el modelo subyacente, las herramientas autorizadas (incluidas las conectadas por MCP), los permisos sobre datos y sistemas, los límites de autonomía y la supervisión humana. Cada herramienta nueva es un cambio que revisar.

Conclusión

Un inventario de sistemas de IA no es un trámite, sino la condición de todo lo demás: el registro en la base de datos de la UE, la clasificación del riesgo, las evaluaciones de impacto, la supervisión humana y la auditoría leen de él. Las normas no siempre lo nombran, pero todas lo presuponen. Lo que separa un inventario útil de una hoja de cálculo olvidada es el mantenimiento: fuentes de descubrimiento cruzadas, una puerta de entrada, responsables con nombre y desencadenantes de actualización. Para pasar de la lista a la gobernanza, un registro de IA que enlaza cada entrada con sus evaluaciones, sus responsables y sus pruebas permite responder a un auditor desde un único lugar.

Software de cumplimiento HIPAA: guía de compra 2026

Un software de cumplimiento HIPAA gobierna el programa, no los modelos. Qué debe cubrir en 2026 y las doce preguntas que conviene hacer en la demo.

Inventario de sistemas de IA: qué exige cada norma y cómo crearlo

Inventario de sistemas de IA: qué campos exigen el Reglamento de IA, NIST, ISO 42001 y la SR 26-2, cómo crearlo y en qué difiere de la base de datos de la UE.

Regulación de la IA en China: guía de cumplimiento 2026

Guía de la regulación de la IA en China en 2026: registro ante la CAC, etiquetado, IA de compañía, multas y comparación con el Reglamento de IA de la UE.

Chatbots acompañantes: qué exige ahora California

Chatbots acompañantes: la ley SB 243 rige desde enero de 2026 y Adam's Law añade evaluación de riesgos, controles parentales y auditorías independientes.

Ley de transparencia de IA de California: qué exige SB 942

La ley de transparencia de IA de California se aplica desde el 2 de agosto de 2026. Obligaciones de SB 942, cambios de SB 1000 y pruebas que conservar.

IA agéntica frente a IA generativa: qué cambia en la gobernanza

La IA agéntica no es solo una diferencia técnica. Vea qué cambia en clasificación, supervisión, riesgos y pruebas cuando la IA actúa sola.