En esta página
- ¿Qué es un AI-BOM?
- AI-BOM frente a SBOM: ¿cuál es la diferencia?
- ¿Qué exige realmente el Reglamento Europeo de IA?
- Qué cambió en 2026 y qué no
- ¿Por qué falla justo la parte del inventario?
- ¿Qué tiene que capturar un inventario de IA?
- ¿Qué formato de AI-BOM conviene usar?
- ¿Cómo se construye un AI-BOM que siga siendo cierto?
- Cómo genera CybeDefend el AI-BOM
- Preguntas frecuentes
- ¿Qué es un AI-BOM?
- ¿Cuál es la diferencia entre un AI-BOM y un SBOM?
- ¿El Reglamento Europeo de IA exige un AI-BOM?
- ¿El AI Omnibus eliminó la obligación de documentación técnica?
- ¿Qué formato debe usar un AI-BOM, CycloneDX o SPDX?
- ¿Soy el proveedor si solo ajusté el modelo de otro?
- ¿Cómo se encuentra el shadow AI en un repositorio?
- ¿Con qué frecuencia debe regenerarse un AI-BOM?
El artículo 11 del Reglamento Europeo de IA exige documentación técnica. El anexo IV dedica después nueve secciones a describir qué debe contener esa documentación, y casi cada línea es una pregunta sobre composición: qué modelos, qué conjuntos de datos, qué decisiones de diseño, qué supervisión, qué cambios a lo largo del ciclo de vida. Nada de eso puede redactarse mientras nadie sepa responder a una pregunta mucho más pequeña. ¿Qué IA hay en este repositorio? La mayoría de las organizaciones no puede responderla. No porque la norma sea confusa, sino porque la IA de un repositorio moderno llega de commit en commit, a menudo escrita por un agente, y ningún documento sobrevive a esa cadencia. Para eso sirve un AI Bill of Materials, y por eso su versión útil es un artefacto de build y no una hoja de cálculo.
¿Qué es un AI-BOM?
Un AI-BOM, o AI Bill of Materials, es un inventario legible por máquina de todos los componentes de inteligencia artificial que contiene un sistema de software, junto con los hechos de procedencia y gobernanza de cada uno. Donde un SBOM enumera paquetes, versiones y licencias, un AI-BOM enumera modelos, conjuntos de datos, prompts, agentes, herramientas y guardrails, y registra de dónde viene cada uno, qué tiene permitido hacer y en qué clase de riesgo regulatorio cae.
La idea desciende directamente del inventario de software. La orden ejecutiva estadounidense 14028 convirtió el SBOM en condición de compra pública federal en 2021, y la práctica sobrevivió a los vaivenes políticos de esa orden porque resultó ser la única respuesta operativa a «qué está corriendo aquí realmente». Los sistemas de IA plantean la misma pregunta sobre una superficie más ancha. Una dependencia tiene una versión y una licencia. Un modelo tiene una versión, una licencia, un proveedor, unos pesos que pueden ser locales o remotos, un corpus de entrenamiento que quizá no controlas, un historial de ajuste fino, una configuración de inferencia, un registro de evaluación y una envolvente de capacidades. Nada de eso cabe en un package.json.
AI-BOM frente a SBOM: ¿cuál es la diferencia?
Responden preguntas distintas sobre el mismo repositorio, y la diferencia no es cosmética. Un SBOM es una lista de cosas que instalaste. Un AI-BOM es una lista de cosas que toman decisiones.
| SBOM | AI-BOM | |
|---|---|---|
| Unidad de inventario | Paquete, biblioteca, imagen de contenedor | Modelo, conjunto de datos, prompt, agente, herramienta, guardrail |
| Pregunta de procedencia | Qué registro, qué versión, qué licencia | Qué proveedor, qué datos de entrenamiento, qué ajuste fino, qué licencia |
| Pregunta de riesgo | ¿Hay un CVE conocido en esta versión? | ¿Qué puede decidir este componente, y sobre quién? |
| Disparador de cambio | Una subida de versión de dependencia | Una nueva cadena de modelo, un prompt reescrito, una herramienta concedida a un agente |
| Anclaje regulatorio | NIS2, CRA, reglas de compra pública, EO 14028 | Reglamento de IA art. 11 + anexo IV, NIST AI RMF, ISO/IEC 42001 |
| Detección | Ficheros de manifiesto, lockfiles | Referencias en el código, config, notebooks, definiciones de agentes, ficheros de prompts |
La última fila es donde se detiene la mayoría de las herramientas. Una dependencia se declara en un lockfile. Un modelo no. openai/gpt-4o-mini aparece como cadena literal en un fichero de servicio. Un modelo local aparece como una ruta .gguf en una configuración. Un servidor MCP aparece como una URL en .mcp.json. Un prompt aparece como un fichero markdown que nadie registró en ninguna parte. No hay manifiesto que parsear, así que un inventario de IA hay que derivarlo leyendo el propio código.
¿Qué exige realmente el Reglamento Europeo de IA?
El artículo 11 obliga a los proveedores de sistemas de IA de alto riesgo a elaborar documentación técnica antes de que el sistema se introduzca en el mercado o se ponga en servicio, y a mantenerla actualizada. El anexo IV fija el contenido mínimo. El artículo 18 obliga al proveedor a conservar esa documentación, junto con los registros del sistema de gestión de la calidad y la declaración UE de conformidad, durante diez años tras la introducción en el mercado.
Lee el anexo IV como un cuestionario y su forma se vuelve evidente. Son nueve secciones, y la mayoría son preguntas sobre de qué está hecho el sistema y de dónde vinieron esas piezas.
Punto por punto, la correspondencia es lo bastante estrecha como para que la tarea documental se convierta en un problema de exportación para la mayor parte del expediente, y en trabajo de análisis real para el resto.
| Sección del anexo IV | Qué pide | Qué lo responde |
|---|---|---|
| §1 Descripción general | Finalidad prevista, proveedor, versión, interacciones con otro hardware y software | Entrada de sistema, versión, propietario, más cada endpoint de modelo externo y cada herramienta con la que habla |
| §2(b) Especificaciones de diseño | Lógica del sistema, algoritmos, decisiones clave de diseño | Referencias de modelos, framework de orquestación, prompts versionados, topología de agentes |
| §2(c) Arquitectura y cómputo | Arquitectura del sistema y recursos de cómputo empleados | Runtime de inferencia, destino de despliegue, pesos locales, endpoints alojados |
| §2(d) Requisitos de datos | Fichas sobre metodologías de entrenamiento, conjuntos de datos, procedencia, etiquetado, limpieza | Referencias de conjuntos de datos con origen, licencia y rol (entrenamiento, ajuste, evaluación, corpus RAG) |
| §2(e) Supervisión humana | Las medidas de supervisión integradas en el sistema | Cobertura de guardrails, más un diseño de supervisión que ningún formato de BOM contiene de forma nativa |
| §2(g) Validación y pruebas | Procedimientos, métricas, registros e informes de prueba | Campañas de evaluación y métricas de rendimiento adjuntas por componente |
| §2(h) Ciberseguridad | Las medidas que protegen el sistema | Manejo de secretos, alcance de herramientas, controles de inyección en las entradas de los agentes |
| §3 Capacidades y limitaciones | Exactitud, incluida la referida a personas o grupos concretos | Métricas de equidad por subgrupo, que tampoco ningún formato de BOM contiene de forma nativa |
| §5 Gestión de riesgos | El sistema de gestión de riesgos del artículo 9 | Clasificación de riesgo por componente conforme a los artículos 5, 6 y 50 |
| §6 Cambios del ciclo de vida | Los cambios introducidos en el sistema a lo largo de su vida | El diff entre dos inventarios, commit a commit |
| §9 Vigilancia poscomercialización | El plan de vigilancia del artículo 72 | Reescaneo continuo, más un estado de deriva por componente |
Dos secciones de esa tabla están marcadas como no cubiertas de forma nativa por ningún formato de inventario, y son justamente las dos que más tiempo de auditoría consumen en la práctica: la exactitud por subgrupo (§3) y el diseño de la supervisión humana (§2(e)). Ningún estándar de BOM tiene un campo para «quién puede anular esta decisión, mediante qué interfaz, con qué formación». Un AI-BOM te da la composición. No te da la evaluación. Quien te venda lo contrario te está vendiendo una hoja de cálculo con nombre nuevo.
Qué cambió en 2026 y qué no
El AI Omnibus entró en vigor el 27 de julio de 2026, tras su adopción por el Parlamento Europeo el 16 de junio y por el Consejo el 29 de junio. Es una simplificación selectiva del Reglamento más que una reescritura, y el titular es un aplazamiento.
El Omnibus también creó una categoría de «pequeña empresa de mediana capitalización», definida como menos de 750 empleados y una facturación igual o inferior a 150 millones de euros, y le extendió las plantillas simplificadas de documentación técnica y los requisitos proporcionados de gestión de la calidad que antes solo podían usar las pymes. No tocó el contenido del anexo IV. La lista de cosas que tienes que poder decir sobre tu sistema es la misma que en 2024.
Otros dos cambios del Omnibus importan específicamente para el trabajo documental. El artículo 10(5) ofrece ahora una base jurídica más clara para tratar datos personales de categorías especiales cuando sea estrictamente necesario para detectar y mitigar sesgos, con salvaguardias, lo que rompe un círculo vicioso real: los equipos no podían medir la exactitud por subgrupo porque no tenían permitido recoger el atributo que se lo permitiría. Y el artículo 40(2) obliga a la Comisión a solicitar normas unificadas que cubran conjuntamente el Reglamento de IA y la legislación de armonización existente, para que un mismo producto no tenga que satisfacer dos regímenes documentales paralelos.
¿Por qué falla justo la parte del inventario?
Porque los componentes de IA entran en un repositorio por canales que no se diseñaron para ser inventariados, y ahora entran más rápido que cualquier cadencia de revisión.
La versión medida es cruda. El Cost of a Data Breach Report 2026 de IBM, realizado por el Ponemon Institute sobre 602 organizaciones con brechas entre marzo de 2025 y febrero de 2026, halló que la proporción de incidentes de seguridad con shadow AI implicado más que se duplicó interanualmente.
de los incidentes de seguridad implicaron shadow AI, más del doble que el año anterior
organizaciones no tienen ningún proceso de gobernanza para limitar el shadow AI
de las organizaciones restringen el acceso a sus sistemas de IA; el resto no
El shadow AI se suele plantear como un problema de empleados: alguien pega datos de clientes en un chatbot de consumo. Ese encuadre lo infravalora gravemente. La versión más amplia y silenciosa es el shadow AI en el repositorio. Una cadena de modelo añadida a un servicio. Un conjunto de datos de HuggingFace traído a un notebook. Un servidor MCP apuntando a una base de producción para una sesión de depuración y nunca retirado. Un fichero de prompt editado para relajar una restricción. Cada uno es un cambio de una línea. Cada uno cambia lo que el sistema es, y por tanto lo que su documentación del anexo IV tendría que decir. Ninguno se anuncia.
Ese tercer paso es el que ha cambiado desde que se redactó el Reglamento. Cuando un ingeniero humano elegía un modelo, había una decisión, normalmente una conversación, a veces un documento de diseño. Cuando un agente de código de IA escribe la integración, selecciona un modelo, una biblioteca cliente y una configuración por defecto en una sola edición, y el registro de esa decisión es un diff que nadie lee línea a línea. Describimos la forma general de este problema en por qué la mayoría de los hallazgos SAST son ruido y en fallos de lógica de negocio en código generado por IA; el caso del AI-BOM es la versión de gobernanza del mismo desfase de cadencia.
Un inventario mantenido como documento describe el día en que se escribió. Un inventario derivado del código describe hoy. Solo uno de los dos sobrevive a una auditoría que llega dieciocho meses después de la última reunión de revisión.
¿Qué tiene que capturar un inventario de IA?
Seis categorías, y cada una es un lugar donde se decide la composición del sistema. Si falta alguna, el expediente del anexo IV tiene un agujero que un auditor encontrará leyendo el código que tú mismo entregaste como evidencia.
Modelos
Cadenas de modelos alojados (OpenAI, Anthropic, Google, Mistral), identificadores de HuggingFace y pesos locales en .gguf u .onnx. Cada uno necesita proveedor, versión fijada, licencia y referencia de model card. Un modelo referenciado solo como valor por defecto de una variable de entorno sigue siendo un modelo en producción.
Conjuntos de datos
Corpus de entrenamiento, ajuste, evaluación y RAG, cada uno con un origen y una licencia. El anexo IV §2(d) pregunta específicamente por procedencia, etiquetado y limpieza. Un conjunto de datos interno sin licencia registrada y sin origen documentado es la carencia más común en un primer escaneo.
Prompts
Prompts de sistema, plantillas y ficheros de instrucciones, versionados. Un prompt es una especificación de diseño según el anexo IV §2(b): define la lógica del sistema. Tratarlo como contenido no rastreado es la razón por la que la deriva de prompts permanece invisible hasta que el comportamiento cambia en producción.
Agentes y orquestación
LangChain, LlamaIndex, CrewAI, Semantic Kernel, AutoGen y los bucles ReAct hechos a mano. El framework determina la envolvente de capacidades: qué se le permite al sistema intentar por su cuenta, y cuántos pasos puede dar antes de que un humano vea algo.
Servidores MCP y herramientas
Cada endpoint de herramienta que un agente puede invocar, con su alcance. Es la superficie que más rápido crece y menos se inventaría de las seis. Una herramienta apuntada a un almacén de datos de producción convierte una función de generación de texto en un sistema capaz de actuar sobre registros, que es otra clase de riesgo por completo.
Guardrails
Llama Guard, NeMo Guardrails, Guardrails AI y cualquier filtro propio. Lo que más importa aquí es el resultado negativo: el componente que no tiene ningún guardrail. Los huecos de cobertura son evidencia a efectos del anexo IV §2(e), y solo afloran si los enumeras deliberadamente.
¿Qué formato de AI-BOM conviene usar?
CycloneDX es la opción por defecto más pragmática. Soporta modelos de aprendizaje automático desde la versión 1.5 en 2023, la especificación actual es la 1.7 (publicada el 21 de octubre de 2025) y está normalizada como ECMA-424, así que es un estándar real y no un esquema de fabricante. SPDX 3.0 ofrece una alternativa alineada con ISO mediante su AI Profile. Ambos son serializables en JSON, ambos encajan en los pipelines de SBOM existentes y ambos cuentan con herramientas abiertas.
Un componente ML-BOM mínimo de CycloneDX tiene este aspecto.
{
"bomFormat": "CycloneDX",
"specVersion": "1.6",
"version": 1,
"components": [
{
"type": "machine-learning-model",
"bom-ref": "pkg:huggingface/mistralai/Mistral-7B-Instruct-v0.3",
"name": "support-triage-v4",
"version": "2026-06-11",
"modelCard": {
"modelParameters": {
"approach": { "type": "supervised" },
"architectureFamily": "Transformer (Mistral-7B, fine-tuned)",
"datasets": [
{ "ref": "urn:cdx:dataset-support-tickets-2025h2", "type": "training" }
]
},
"quantitativeAnalysis": {
"performanceMetrics": [
{ "type": "accuracy", "value": "0.881", "slice": "all locales" }
]
},
"considerations": {
"useCases": ["tier-1 support triage"],
"technicalLimitations": ["degrades below 0.72 on locales unseen in training"]
}
}
}
]
}
Eso cubre el anexo IV §1, §2(b), §2(c), §2(d) y parte del §2(g) en un solo objeto. Lo que no cubre, y que por tanto llevarás como propiedades personalizadas o como documentos aparte, se agrupa en tres bloques.
Linaje de datos más allá de una referencia
Un ref de conjunto de datos dice qué corpus. El anexo IV §2(d) pregunta cómo se obtuvo, cómo se etiquetó y limpió, y qué se excluyó y por qué. Eso es un expediente de procedencia, no un puntero.
Sesgo y evaluación por subgrupo
Qué métrica de equidad, medida sobre qué atributo protegido, con qué umbral. CycloneDX lleva métricas de rendimiento; no lleva una metodología de equidad ni sus resultados.
Diseño de la supervisión humana
El artículo 14 quiere puntos de intervención, mecanismos de parada y el perfil de competencia de quien supervisa. Ningún estándar de BOM modela esto. Es un documento de diseño que el inventario debe enlazar, no sustituir.
La justificación de la clasificación de riesgo
Si un componente es de riesgo prohibido, alto, limitado o mínimo conforme a los artículos 5, 6 y 50, y por qué llegaste a esa conclusión. La clasificación es un juicio; el inventario es lo que hace ese juicio auditable.
Junto al formato está la capa de reporting. El NIST AI Risk Management Framework (AI 100-1) organiza el trabajo de riesgo de IA en Govern, Map, Measure y Manage, y su función Map se acerca a una definición de la tarea de inventario: documentar el contexto, los componentes, las capacidades y las limitaciones del sistema. La ISO/IEC 42001 exige un sistema de gestión de IA con un inventario de IA y una evaluación de riesgos en su núcleo. Ninguno de los dos es un formato. Ambos consumen los mismos hechos subyacentes, que es el argumento práctico para generar esos hechos una vez, de forma mecánica, y proyectarlos al marco que hable cada auditor o cada cuestionario de seguridad de cliente.
¿Cómo se construye un AI-BOM que siga siendo cierto?
El modo de fallo de todo inventario de gobernanza es idéntico, y no tiene nada que ver con el esfuerzo inicial. Alguien lanza un ejercicio de descubrimiento, entrevista a los equipos, rellena una hoja de cálculo, y el artefacto es exacto durante una semana aproximadamente. Lo que viene después no es pereza; es aritmética. Los componentes cambian más rápido que los ciclos de revisión.
Así que la restricción de diseño va primero, y los pasos se derivan de ella.
-
Deriva el inventario del código, nunca de un cuestionario. Un cuestionario captura lo que la gente recuerda. Un escaneo captura lo que se envió. Ambos divergen de inmediato, y solo uno de ellos es lo que leerá un auditor.
-
Ancla cada componente a un fichero y una línea. Una entrada de inventario sin ubicación de origen es una afirmación. Una entrada con
src/lib/triage.ts:23al lado es evidencia, y es también lo que hace la remediación asignable a un equipo en lugar de a un comité. -
Clasifica a nivel de componente, no de sistema. Los artículos 5, 6 y 50 se aplican a lo que hace un componente. Un mismo repositorio contiene habitualmente un asistente de chat de riesgo mínimo, un asistente de cara al cliente de riesgo limitado y un modelo de puntuación genuinamente de alto riesgo. Una etiqueta única a nivel de sistema esconde justo el componente que importa.
-
Marca estado, no solo presencia. Gobernado, shadow, desviado, ausente. Un componente con model card y licencia es un objeto distinto del mismo componente sin ninguna de las dos, y todo el valor de un primer escaneo está en la proporción entre esos dos montones.
-
Regenera en cada push y haz el diff. El anexo IV §6 pide los cambios introducidos en el sistema a lo largo de su vida. Si el inventario se regenera por commit, esa sección se escribe sola; el diff es el registro de cambios. Si se regenera por trimestre, alguien tendrá que reconstruirlo de memoria.
-
Bloquea el pipeline ante cualquier componente nuevo no gobernado. Un build que falla cuando aterriza un componente prohibido o de alto riesgo sin documentación es el único control que evita que la proporción del paso 4 se desvíe. Todo lo más blando que un bloqueo degenera en un panel que nadie abre.
-
Contrata lo que no puedes escanear. Tu escaneo ve lo que contiene tu repositorio. No ve el corpus de entrenamiento de un proveedor. Los artículos 25(2) y 25(4) sitúan la obligación de cooperación en el proveedor aguas arriba, así que ponla también en el contrato: model cards, resúmenes de datos de entrenamiento y notificación cuando una versión de modelo cambie bajo tus pies.
-
Consérvalo diez años. El artículo 18 es explícito, y diez años es más que la mayoría de las políticas de retención de artefactos, más que la retención por defecto de la mayoría de los proveedores de CI, y bastante más que la permanencia media del ingeniero que construyó el sistema. Exporta el expediente a un soporte duradero.
Cómo genera CybeDefend el AI-BOM
Todo lo anterior es el caso general. Así lo implementamos nosotros, porque la restricción de diseño de la sección anterior es exactamente aquella para la que construimos.
El escáner AI-BOM de CybeDefend recorre un repositorio y cataloga las seis categorías directamente desde el código: modelos (cadenas alojadas, identificadores de HuggingFace, pesos locales .gguf y .onnx), conjuntos de datos referenciados en código o configuración, prompts versionados, frameworks de agentes y orquestación, los servidores MCP que consumen tus agentes y las bibliotecas de guardrails en uso. Cada elemento aterriza con su fichero de origen y su línea, su versión fijada y un estado: gobernado, shadow, deriva o ausente. Sin cuestionario y sin ronda de entrevistas.
Un escaneo emite después tres artefactos en ./.ai-bom/, y esa es la parte que importa para el trabajo descrito arriba.
El primero es un informe de conformidad con el Reglamento de IA mapeado al Reglamento (UE) 2024/1689, con cada componente clasificado en riesgo prohibido, alto, limitado o mínimo conforme a los artículos 5, 6 y 50, los componentes GPAI contados aparte y los componentes de riesgo sistémico señalados. El segundo es un mapeo de cobertura NIST AI RMF sobre Govern, Map, Measure y Manage, con los huecos nombrados en lugar de diluidos en una media. El tercero es el AI-BOM CycloneDX legible por máquina, para que el inventario encaje en las herramientas de SBOM que ya ejecutas.
Corre donde tú entregas. Añade la cybedefend-action a un workflow de GitHub, o llama a la CLI de CybeDefend desde GitLab CI, un Jenkinsfile o Tekton, y el escaneo se ejecuta en cada push con el informe publicado como artefacto de build.
- name: CybeDefend Security Scan
uses: CybeDefend/cybedefend-action@v2
with:
pat: ${{ secrets.CYBEDEFEND_PAT }}
project_id: ${{ secrets.CYBEDEFEND_PROJECT_ID }}
branch: ${{ github.ref_name }}
break_on_severity: high
Eso son los pasos 5 y 6 de la lista anterior, implementados: el inventario se regenera por commit, así que el anexo IV §6 se convierte en un diff, y el build sale con error cuando un nuevo componente prohibido o de alto riesgo aterriza sin documentación de gobernanza. El escaneo lee tu repositorio y produce un inventario estructurado; el código fuente no sale de tu entorno, y el panel recibe únicamente metadatos de componentes, nunca código bruto ni contenido de prompts.
El AI-BOM se sitúa junto al resto de la plataforma y no dentro del bucle del agente. Es un escáner de repositorio y de pipeline, que es el sitio correcto para un inventario: necesita el árbol completo, no la edición en curso. Lo que corre dentro del bucle del agente es VibeDefend, que carga tus reglas de negocio y de seguridad en el agente antes de que escriba, intercepta acciones inseguras y mantiene vivos en el contexto del agente los hallazgos de SAST, SCA, secretos, IaC y CI/CD. Son complementarios. VibeDefend gobierna lo que hace el agente mientras escribe; el AI-BOM registra en qué se ha convertido el repositorio.
Preguntas frecuentes
¿Qué es un AI-BOM?
Un AI-BOM, o AI Bill of Materials, es un inventario legible por máquina de todos los componentes de IA de un sistema: modelos, conjuntos de datos, prompts, agentes y frameworks de orquestación, las herramientas y servidores MCP que esos agentes invocan, y los guardrails que se les aplican. Cada entrada lleva hechos de procedencia y gobernanza: proveedor, versión, licencia, origen de los datos, alcance de capacidades y clasificación de riesgo. Extiende el concepto de SBOM desde los paquetes de software a los activos de IA, y es la evidencia subyacente de la documentación técnica del artículo 11 y el anexo IV del Reglamento Europeo de IA, del reporting NIST AI RMF y de los inventarios de IA de la ISO/IEC 42001.
¿Cuál es la diferencia entre un AI-BOM y un SBOM?
Un SBOM enumera componentes de software (paquetes, versiones, licencias) y sirve sobre todo para encontrar vulnerabilidades conocidas. Un AI-BOM enumera componentes de IA y sus facetas de gobernanza específicas de la IA: origen de los datos de entrenamiento, linaje de ajuste fino, versiones de prompts, alcance de capacidades de los agentes, cobertura de guardrails y riesgo residual. Son complementarios más que competidores, y CycloneDX puede expresar ambos, así que un AI-BOM puede producirse en el mismo formato y el mismo pipeline que tu SBOM actual.
¿El Reglamento Europeo de IA exige un AI-BOM?
No con ese nombre. El Reglamento nunca usa el término. El artículo 11 obliga a los proveedores de sistemas de IA de alto riesgo a elaborar documentación técnica antes de la introducción en el mercado y a mantenerla actualizada, y el anexo IV fija el contenido mínimo: descripción general, especificaciones de diseño, arquitectura, requisitos y procedencia de los datos, supervisión humana, validación y pruebas, ciberseguridad, capacidades y limitaciones, gestión de riesgos, cambios del ciclo de vida y vigilancia poscomercialización. Un AI-BOM es la vía práctica para producir mecánicamente la mayor parte de ese expediente. El artículo 18 obliga después a conservar la documentación diez años tras la introducción en el mercado.
¿El AI Omnibus eliminó la obligación de documentación técnica?
No. El AI Omnibus entró en vigor el 27 de julio de 2026 y aplazó las obligaciones de alto riesgo de los sistemas autónomos del anexo III del 2 de agosto de 2026 al 2 de diciembre de 2027, y las de la IA de alto riesgo integrada en productos regulados del 2 de agosto de 2027 al 2 de agosto de 2028. También creó una categoría de «pequeña empresa de mediana capitalización» (menos de 750 empleados, facturación igual o inferior a 150 millones de euros) que puede usar plantillas simplificadas de documentación técnica. El contenido del anexo IV no cambió, las obligaciones de transparencia del artículo 50 se mantuvieron en su fecha original, y las obligaciones GPAI se aplican desde el 2 de agosto de 2025, con poderes de ejecución de la Comisión activos desde el 2 de agosto de 2026.
¿Qué formato debe usar un AI-BOM, CycloneDX o SPDX?
CycloneDX es la opción pragmática por defecto. Soporta modelos de aprendizaje automático desde la versión 1.5 (2023), la especificación actual es la 1.7 (octubre de 2025) y está normalizada como ECMA-424, con los campos modelCard, modelParameters, las referencias de conjuntos de datos y quantitativeAnalysis cubriendo la mayoría de los hechos de composición. El AI Profile de SPDX 3.0 es la alternativa alineada con ISO y es una elección razonable si tu organización ya estandariza sobre SPDX. Ninguno tiene campos nativos para la metodología de evaluación de sesgos ni para el diseño de la supervisión humana, así que en ambos casos eso se lleva como propiedades personalizadas o documentos enlazados.
¿Soy el proveedor si solo ajusté el modelo de otro?
Normalmente sí. El artículo 25(1) considera proveedor de un sistema de IA de alto riesgo a quien lo introduce en el mercado bajo su propio nombre o marca, a quien lo modifica sustancialmente, o a quien cambia su finalidad prevista de modo que pase a ser de alto riesgo. Ajustar un modelo existente con tus propios datos y publicarlo bajo tu nombre de producto suele activar las tres. La model card del laboratorio original documenta únicamente el modelo base; la obligación documental del artículo 11 para tu sistema recae en ti, y los artículos 25(2) y 25(4) obligan al proveedor aguas arriba a cooperar y aportar información, no a redactar tu expediente.
¿Cómo se encuentra el shadow AI en un repositorio?
Escaneando el código en lugar de encuestar a los equipos. Los componentes de IA rara vez se declaran en un manifiesto: un modelo alojado aparece como cadena literal, un modelo local como una ruta de pesos en configuración, un conjunto de datos como una URI en un notebook, un servidor MCP como una URL en la configuración de un agente, un prompt como un fichero markdown sin seguimiento. Un escaneo del repositorio resuelve cada uno en un componente con fichero y línea, y luego marca los que no tienen model card, ni licencia, ni versión fijada, ni propietario registrado. El Cost of a Data Breach Report 2026 de IBM halló shadow AI implicado en el 43 % de los incidentes de seguridad y más de dos tercios de organizaciones sin proceso de gobernanza para limitarlo, así que la expectativa razonable para un primer escaneo es que el montón shadow sea mayor que el gobernado.
¿Con qué frecuencia debe regenerarse un AI-BOM?
En cada push. El anexo IV §6 pide los cambios introducidos en el sistema a lo largo de su vida, y un inventario por commit convierte esa sección en un diff en lugar de un ejercicio de reconstrucción. Un inventario trimestral queda obsoleto en días en cualquier repositorio donde agentes de código de IA escriban las integraciones, porque un cambio de modelo, un nuevo permiso de herramienta o una edición de prompt es un commit de una línea. Regenerar en CI y hacer fallar el build cuando aterriza un componente nuevo de alto riesgo o prohibido sin documentación es lo que mantiene el artefacto y el repositorio de acuerdo.
