Análisis de brechas del Reglamento de IA: un método control por control con una plantilla de matriz
Realiza un análisis de brechas del Reglamento de IA: delimita sistemas, mapea obligaciones por rol, puntúa cada brecha y prioriza frente al 2 de diciembre
Un análisis de brechas del Reglamento de IA es una comparación control por control de tu gobernanza de IA actual frente a las obligaciones que realmente se aplican a tus sistemas conforme al Reglamento (UE) 2024/1689. Para cada requisito anotas el estado exigido, tu estado actual, el tamaño de la brecha y una prioridad, y el resultado es una lista priorizada de remediación, no un informe narrativo.
La lógica que lo rige es el conjunto de obligaciones del capítulo III, sección 2 (artículos 9 a 15) para los sistemas de alto riesgo, ligado a tu rol conforme al artículo 16 (proveedor) o al artículo 26 (responsable del despliegue). El análisis vale tan solo lo que valga el inventario que lo alimenta: no puedes evaluar una obligación que aún no has mapeado a un sistema y a un rol. Esta guía te da el método de cinco pasos, la matriz de seis columnas y un conjunto de filas de alto riesgo ya resueltas que puedes copiar.
Qué es realmente un análisis de brechas del Reglamento de IA
La definición operativa
Un análisis de brechas es requisito por requisito, no temático. Cada obligación aplicable conforme al Reglamento (UE) 2024/1689 se convierte en una fila, y evalúas el estado actual frente al estado exigido para ese único control. El entregable es una matriz de análisis de brechas más un backlog priorizado de remediación, con cada elemento ligado a un artículo, a un responsable y a un plazo.
Esa es la diferencia entre un ejercicio que produce acción y uno que produce un documento que nadie lee. Un análisis de brechas nombra el control específico, la carencia específica y la solución específica.
Análisis de brechas frente a evaluación de preparación
Estos dos se confunden de forma rutinaria, y la distinción cambia lo que recibes de vuelta.
| Dimensión | Evaluación de preparación | Análisis de brechas |
|---|---|---|
| Altura | Barrido de madurez: "¿tenemos siquiera un proceso de riesgo?" | Nivel de artículo: "¿cubre el artículo 9 todo el ciclo de vida, con evidencias?" |
| Granularidad | Temas (gobernanza, datos, supervisión) | Una fila por obligación (art. 9, art. 10, art. 11…) |
| Resultado | Una puntuación de madurez o estado RAG | Una matriz puntuada más una lista priorizada de remediación |
| Evidencia | Indicativa | Un puntero de evidencia nombrado por control |
| Mejor uso | Orientación inicial, informes al consejo | Planificación de remediación previa al plazo |
Una evaluación de preparación te dice aproximadamente dónde estás. Un análisis de brechas te dice con precisión qué remediar y en qué orden. Si estás decidiendo si empezar o no, arranca por por dónde empezar; si ya sabes que el Reglamento se aplica, el análisis de brechas es el siguiente instrumento.
Qué aspecto tiene el resultado
El artefacto es una matriz de seis columnas que alimenta un backlog. Cada elemento del backlog lleva un responsable, una estimación de esfuerzo, una fecha objetivo y el artículo que cierra. Ningún resumen en prosa lo sustituye, porque un resumen en prosa no se puede secuenciar, asignar ni volver a ejecutar.
El método de análisis de brechas en cinco pasos
El método es lineal y repetible. Ejecútalo una vez para establecer la línea base y vuelve a ejecutarlo tras cada sprint de remediación.
- Delimita qué sistemas. Extrae de tu inventario de IA todo sistema que tome o respalde una decisión relevante, genere salidas usadas aguas abajo o trate datos personales. Las obligaciones se adhieren por sistema, no por empresa, de modo que una sola herramienta que es benigna en un contexto y de alto riesgo en otro necesita dos evaluaciones.
- Determina las obligaciones aplicables por tramo de riesgo y rol. Para cada sistema, fija el tramo de riesgo —prohibido conforme al artículo 5, de alto riesgo conforme al artículo 6 leído con el anexo III, transparencia de riesgo limitado conforme al artículo 50, o mínimo— y tu rol: proveedor conforme al artículo 16 o responsable del despliegue conforme al artículo 26. El tramo y el rol juntos derivan el conjunto de obligaciones. Nuestra guía de clasificación de riesgo recorre la decisión de clasificación por entero.
- Evalúa cada obligación, actual frente a exigida. Escribe el estado exigido (lo que el artículo demanda) junto al estado actual (lo que de verdad tienes hoy, con evidencias). Esta comparación lado a lado es lo que lo convierte en un análisis de brechas y no en una lista de comprobación.
- Puntúa la brecha. Califica cada fila como ninguna (conforme, con evidencias), parcial (existe un control pero está incompleto o sin documentar) o inexistente (sin control). Una calificación de tres estados impulsa una priorización más clara que una puntuación numérica que nadie puede defender.
- Prioriza por riesgo y plazo. Sitúa las obligaciones ya en vigor y los sistemas de alto riesgo residual por encima de las obligaciones cuyo plazo se ha movido y los sistemas de bajo impacto. Mapea cada brecha al tramo de sanción en el que se sitúa para que la ordenación sea defendible, no subjetiva.
La matriz de análisis de brechas (con una plantilla resuelta)
Las seis columnas
El artefacto central usa seis columnas: Requisito | Artículo | Estado actual | Estado exigido | Brecha | Prioridad. Todo el ejercicio existe para poblar esta tabla.
Cada fila debería llevar un puntero de evidencia en la celda de estado actual —un enlace a una política, una muestra de registro, un identificador de documento— para que la matriz haga las veces del rastro de auditoría que solicitaría una autoridad. La prioridad debería referirse tanto al tramo de sanción como al plazo aplicable.
Un conjunto de filas de alto riesgo resuelto
Para un sistema de alto riesgo, la matriz de primera pasada suele tener este aspecto. La mayoría de las empresas puntúan parcial o inexistente en la mayor parte de las filas.
| Requisito | Artículo | Estado actual (evidencia) | Brecha |
|---|---|---|---|
| Sistema de gestión de riesgos | Art. 9 | Registro de riesgos ad hoc, sin proceso de ciclo de vida (RISK-LOG-01) | parcial |
| Gobernanza de datos | Art. 10 | Fuentes de datos documentadas, sin criterios de calidad | parcial |
| Documentación técnica | Art. 11 / Anexo IV | Inexistente | inexistente |
| Registro de eventos / conservación de registros | Art. 12 | Sin registro automático de eventos habilitado | inexistente |
| Transparencia hacia responsables del despliegue | Art. 13 | Borrador de instrucciones de uso (DOC-IFU-02) | parcial |
| Supervisión humana | Art. 14 | Sin medidas de supervisión diseñadas | inexistente |
| Precisión, robustez, ciberseguridad | Art. 15 | Prueba de penetración hecha, sin métricas de precisión definidas | parcial |
| Deberes del proveedor | Art. 16 | SGC parcialmente mapeado a ISO/IEC 42001 | parcial |
| Deberes del responsable del despliegue | Art. 26 | Sin EIDF, sin procedimiento de monitorización | inexistente |
| Alfabetización en IA | Art. 4 | Sin programa de formación | inexistente |
Cómo mantenerla defendible en auditoría
La matriz es un registro vivo, no un entregable único. Vuelve a ejecutarla tras cada sprint de remediación y tras cualquier modificación sustancial (artículo 3(23)) que pudiera cambiar la clasificación de un sistema o tu rol. Una matriz congelada de hace doce meses no es evidencia de nada.
El conjunto de requisitos de alto riesgo: artículos 9 a 15
Para cualquier sistema clasificado de alto riesgo, los artículos 9 a 15 son el núcleo denso del análisis de brechas. Cada uno es su propia fila.
Gestión de riesgos y gobernanza de datos: artículos 9 y 10
El artículo 9 exige un sistema de gestión de riesgos establecido, implementado, documentado y mantenido como un proceso continuo e iterativo a lo largo del ciclo de vida del sistema, no una evaluación puntual. El artículo 10 exige gobernanza de datos: los conjuntos de datos de entrenamiento, validación y prueba deben cumplir criterios de calidad adecuados a la finalidad prevista. Trata el artículo 9 como la columna vertebral: el sistema de gestión de riesgos alimenta los controles de datos, documentación, supervisión y robustez, de modo que una fila ausente del artículo 9 suele predecir brechas en el resto. Consulta el sistema de gestión de riesgos del artículo 9 para el desglose completo del ciclo de vida.
Documentación, registro y transparencia: artículos 11 a 13
El artículo 11 exige documentación técnica elaborada antes de introducir el sistema en el mercado, con el contenido mínimo establecido en el anexo IV. El artículo 12 exige el registro automático de eventos a lo largo de la vida del sistema. El artículo 13 exige transparencia e instrucciones de uso hacia los responsables del despliegue, para que puedan interpretar y usar la salida correctamente.
Supervisión humana y robustez: artículos 14 y 15
El artículo 14 exige que la supervisión humana se diseñe e integre en el sistema y quede habilitada: incorporada, no añadida después. El artículo 15 exige niveles adecuados de precisión, robustez y ciberseguridad, mantenidos a lo largo del ciclo de vida.
Proveedor frente a responsable del despliegue: evaluar los deberes del artículo 16 y del artículo 26
Tu rol determina qué filas de obligación aparecen siquiera en la matriz.
Obligaciones del proveedor: artículo 16
Un proveedor carga con toda la pila: gestión de riesgos, documentación técnica, evaluación de la conformidad, registro y supervisión poscomercialización. Si construyes un sistema de alto riesgo, o introduces uno en el mercado bajo tu propio nombre, cada fila de los artículos 9 a 15 es tuya, más los deberes procedimentales del artículo 16 encima.
Obligaciones del responsable del despliegue: artículo 26
Un responsable del despliegue carga con un conjunto más ligero pero real. Evalúa estas filas: usar el sistema conforme a las instrucciones del proveedor; garantizar la supervisión humana; monitorizar el funcionamiento y notificar incidentes graves; conservar los registros generados automáticamente; y —cuando proceda— realizar una evaluación de impacto sobre los derechos fundamentales conforme al artículo 27.
| Proveedor (art. 16) | Responsable del despliegue (art. 26) | |
|---|---|---|
| Gestión de riesgos (art. 9) | La asume | Se apoya en el proveedor |
| Documentación técnica (art. 11 / anexo IV) | Debe producirla | La recibe vía art. 13 |
| Evaluación de conformidad y registro | Sí | No |
| Supervisión humana | La diseña (art. 14) | La opera (art. 26) |
| Registro de eventos | Lo habilita (art. 12) | Lo conserva (art. 26) |
| EIDF (art. 27) | No | Cuando proceda |
Cuándo los cambios de rol cambian la brecha
El mismo sistema puede situarte en ambos roles para distintas obligaciones. Peor aún, puede pasarte de responsable del despliegue a proveedor conforme al artículo 25 si renombras, modificas sustancialmente o cambias la finalidad prevista de un sistema de alto riesgo. Señala el riesgo de cambio de rol de forma explícita en la matriz: un ajuste o un renombrado previsto puede convertir un conjunto de filas breve de responsable del despliegue en toda la pila de proveedor del artículo 16, ampliando materialmente la brecha. Asignar mal el rol es el error más común del análisis de brechas: lleva a las empresas a invertir de más frente a deberes de proveedor que no tienen, o a omitir deberes de proveedor que sí tienen.
Documentación y alfabetización en IA: dos filas que la mayoría de las empresas omiten
Documentación técnica: artículo 11 / anexo IV
El artículo 11 leído con el anexo IV define la documentación técnica mínima que un proveedor de alto riesgo debe conservar: una descripción general del sistema, especificaciones de diseño, requisitos de datos, el sistema de gestión de riesgos y la supervisión poscomercialización, entre otros elementos. El anexo IV es, en efecto, una lista de comprobación documental por sí mismo, de modo que mapea cada elemento del anexo IV a un puntero de evidencia de estado actual en lugar de puntuar el artículo 11 como una sola línea. De lo contrario, una calificación parcial oculta qué mitad falta.
Alfabetización en IA: artículo 4, ya en vigor
El artículo 4 (alfabetización en IA) se aplica a proveedores y responsables del despliegue y está en vigor desde el 2 de febrero de 2025. No es una obligación futura, así que una calificación inexistente aquí es una exposición en vivo, no un elemento de planificación. Se puntúa a menudo ninguna porque no tiene certificación y parece blanda, pero es un deber documentado en todos los tramos de riesgo. Evalúa si el personal que usa IA tiene una competencia demostrable y adecuada a su rol.
Ambas filas son fáciles de pasar por alto precisamente porque son obligaciones de papeleo y personas más que de ingeniería, que es exactamente por lo que pertenecen de forma explícita a la matriz.
Cómo cronometrar el análisis de brechas: qué está en vigor frente a qué se movió
La columna de prioridad vive o muere según aciertes con las fechas.
Ya en vigor
Tres conjuntos de obligaciones ya están en vivo y se sitúan por encima al margen de cualquier aplazamiento:
- Artículo 5, prohibiciones: desde el 2 de febrero de 2025.
- Artículo 4, alfabetización en IA: desde el 2 de febrero de 2025.
- Obligaciones de modelos GPAI (artículos 51 a 55): desde el 2 de agosto de 2025.
La fecha de alto riesgo del 2 de diciembre de 2027 está acordada pero aún no es ley
Conforme al acuerdo político del Ómnibus Digital (6 y 7 de mayo de 2026, texto del COREPER confirmado en torno al 13 de mayo de 2026), la fecha del alto riesgo autónomo del anexo III se moverá del 2 de agosto de 2026 al 2 de diciembre de 2027, y la del alto riesgo integrado en productos del anexo I del 2 de agosto de 2027 al 2 de agosto de 2028.
Expón la salvedad de actualidad con claridad: a junio de 2026 esto está acordado pero aún NO es ley. Todavía necesita una votación del pleno del Parlamento Europeo, la adopción formal del Consejo y la publicación en el Diario Oficial. Hasta entonces, el texto vigente fija el 2 de agosto de 2026 para el alto riesgo del anexo III, de modo que planifica frente a la fecha anterior y trata la posterior como objetivo de trabajo. El aplazamiento es a fechas de calendario fijas; no está ligado a la disponibilidad de normas armonizadas. La propuesta de "parar el reloj" condicionada a las normas fue rechazada, así que no describas el calendario de alto riesgo como dependiente de las normas.
No todo se movió. Se añadió un nuevo plazo del 2 de diciembre de 2026 (la prohibición de material de abuso sexual infantil/"desnudadores" y los deberes de marcado de contenido), y la mayor parte de la transparencia del artículo 50 no cambia, con el marcado de contenido y las marcas de agua aplicándose desde el 2 de diciembre de 2026.
Cómo cambia el cronometraje tu columna de prioridad
La regla práctica: primero las obligaciones en vigor, luego las fechas futuras fijas más cercanas (2 de diciembre de 2026) y después el conjunto de alto riesgo previsto para el 2 de diciembre de 2027 y el 2 de agosto de 2028. Cruza con los tramos de sanción para que cada prioridad lleve su exposición.
Convertir el análisis de brechas en un plan de remediación
De filas puntuadas a un backlog priorizado
Convierte cada fila parcial e inexistente en un elemento de remediación con un responsable, una estimación de esfuerzo, una fecha objetivo y el artículo que cierra. La lista priorizada es el sentido de todo el ejercicio: aliméntala en la hoja de ruta de implementación del cumplimiento y haz su seguimiento frente a la lista de comprobación de cumplimiento.
Secuenciar frente al plazo
Secuencia hacia atrás desde el plazo operativo de cada sistema. Adelanta las brechas en vigor y el trabajo de alto riesgo de plazo largo —gestión de riesgos del artículo 9, documentación del anexo IV, diseño de supervisión del artículo 14— que tarda meses en montarse. Vuelve a ejecutar el análisis de brechas tras cada sprint para que la matriz muestre el movimiento de inexistente → parcial → ninguna. Ese movimiento es en sí tu evidencia de progreso de buena fe.
Cómo Confir autogenera la lista de brechas
El motor de cumplimiento de Confir autogenera la lista de brechas. Recorre cada entrada del inventario por la clasificación de los artículos 5 y 6 / anexo III, deriva el rol mediante la lógica del artículo 25 y produce las filas de obligación aplicables ya puntuadas, con la regla que se activó mostrada en lenguaje llano.
El motor es determinista y basado en reglas: las mismas entradas siempre producen la misma lista de brechas, con la misma lógica cada vez, sin inferencia de modelos, sin alucinaciones. Cada calificación es trazable hasta el artículo que la activó, que es justo lo que requiere una defensa en auditoría.
Cómo ayuda Confir
Ejecutar a mano un análisis de brechas control por control sobre una flota de sistemas es donde encallan la mayoría de los programas. Confir estructura todo el flujo: el módulo AIRC clasifica cada entrada del inventario conforme a los artículos 5 y 6 / anexo III y asigna el rol mediante la lógica del artículo 25; AITR cubre las filas de datos y robustez técnica (artículos 10 y 15); AITO cubre la transparencia y la supervisión humana (artículos 13 y 14); y AIGM cubre la gobernanza, la gestión de riesgos y la supervisión poscomercialización (artículos 9, 16 y 26). El resultado es la matriz de seis columnas ya poblada y puntuada, con cada calificación trazable hasta el artículo que la activó.
Como el motor de síntesis es determinista y basado en reglas —la misma lógica cada vez, sin inferencia de modelos, sin alucinaciones—, volver a ejecutar el análisis de brechas tras un sprint de remediación produce un delta limpio y comparable que puedes mostrar a una autoridad.
Preguntas frecuentes
¿Qué es un análisis de brechas del Reglamento de IA? Es una comparación control por control de tu gobernanza de IA actual frente a las obligaciones que se aplican a tus sistemas conforme al Reglamento (UE) 2024/1689. Para cada requisito anotas el estado exigido, tu estado actual, la brecha (ninguna, parcial o inexistente) y una prioridad. El resultado es una lista priorizada de remediación, no un informe narrativo.
¿Cuál es la diferencia entre un análisis de brechas y una evaluación de preparación? Una evaluación de preparación es un barrido de madurez de más alto nivel que pregunta si siquiera tienes procesos. Un análisis de brechas es la comparación más profunda, requisito por requisito: nombra el artículo específico, la carencia exacta, la evidencia que conservas y la solución. La evaluación de preparación te dice aproximadamente dónde estás; el análisis de brechas te dice con precisión qué remediar y en qué orden.
¿Cómo hago un análisis de brechas del Reglamento de IA? Cinco pasos. Delimita qué sistemas desde tu inventario; determina las obligaciones aplicables por tramo de riesgo y rol; evalúa cada obligación, estado actual frente a estado exigido; puntúa la brecha como ninguna, parcial o inexistente; y luego prioriza por exposición al riesgo y plazo. El resultado es una matriz de seis columnas (requisito, artículo, estado actual, estado exigido, brecha, prioridad) que alimenta un backlog priorizado de remediación.
¿Qué artículos se aplican a los sistemas de IA de alto riesgo? El conjunto central de requisitos de alto riesgo son los artículos 9 a 15: gestión de riesgos (art. 9), gobernanza de datos (art. 10), documentación técnica (art. 11 con anexo IV), registro de eventos (art. 12), transparencia hacia los responsables del despliegue (art. 13), supervisión humana (art. 14) y precisión, robustez y ciberseguridad (art. 15). Los proveedores añaden luego los deberes del artículo 16; los responsables del despliegue cargan con los deberes del artículo 26.
¿Cuándo se aplican las obligaciones de alto riesgo del Reglamento de IA? El Ómnibus Digital acordado en mayo de 2026 fija la fecha del alto riesgo autónomo del anexo III en el 2 de diciembre de 2027 y la del alto riesgo integrado en productos en el 2 de agosto de 2028. A junio de 2026 esto está acordado pero aún no es ley: todavía necesita la adopción del Parlamento y el Consejo y su publicación, de modo que el texto vigente fija el 2 de agosto de 2026. Planifica frente a la fecha anterior.
¿Qué va en una matriz de análisis de brechas? Seis columnas: el requisito en lenguaje llano; el artículo (y el anexo cuando proceda); el estado actual con un puntero de evidencia; el estado exigido que demanda el artículo; la brecha calificada como ninguna, parcial o inexistente; y una prioridad ligada al tramo de sanción y al plazo. Cada obligación de alto riesgo de los artículos 9 a 15 se convierte en su propia fila, igual que el artículo 16, el artículo 26 y el artículo 4.
¿Cuáles son las sanciones por incumplir el Reglamento de IA? Hay tres tramos. Las infracciones de las prohibiciones del artículo 5 alcanzan hasta 35 millones de euros o el 7 % del volumen de negocios anual a escala mundial (artículo 99(3)). La mayoría de las demás infracciones de obligaciones alcanzan hasta 15 millones de euros o el 3 % (artículo 99(4)). Facilitar información incorrecta, incompleta o engañosa a las autoridades alcanza hasta 7,5 millones de euros o el 1 % (artículo 99(5)). Las pymes y las empresas emergentes tienen límites proporcionales conforme al artículo 99(6).
Guías relacionadas
- la plantilla lista para usar de análisis de brechas del Reglamento de IA
- Por dónde empezar con el cumplimiento del Reglamento de IA
- La hoja de ruta de implementación del cumplimiento
- La lista de comprobación de cumplimiento del Reglamento de IA
- Marco de clasificación de riesgo de IA
- El sistema de gestión de riesgos del artículo 9
- Los tramos de sanción del Reglamento de IA explicados
Gestiona el cumplimiento de la Ley de IA de la UE en un solo lugar
Confir automatiza la clasificación de riesgo, la documentación técnica y los registros de auditoría para cualquier empresa. Sin consultores. Sin proyectos de seis meses. Prueba gratuita de 7 días.
Empieza la prueba gratuita →