Saltar al contenido
Marcos de gobernanza

Un modelo RACI para cumplir el Reglamento de IA

Guía sectorial26 de agosto de 2026· 7 min de lectura

Mapea Responsable, Aprobador, Consultado, Informado sobre deberes del RIA —art. 9, 10, 11, 14, 26, 49, 73— a funciones reales. Una RACI de pyme.

El Reglamento de IA te dice qué debe hacerse; no te dice quién en tu empresa lo hace. Ese vacío es donde el cumplimiento falla en silencio —un deber que todos suponen que es de otro. Un modelo RACI cierra el vacío asignando, para cada obligación, quién es Responsable de ejecutar (R) (hace el trabajo), Aprobador (A) (posee el resultado, una sola persona), Consultado (C) (aporta input) e Informado (I) (se le mantiene al tanto). Que quede claro de entrada: la RACI es una práctica de gestión, no un término legal. El Reglamento (UE) 2024/1689 nunca la menciona. Pero es la forma más limpia de convertir los deberes del Reglamento en propiedad con nombre y apellidos —y esa trazabilidad es exactamente lo que un auditor quiere ver.

Esta página mapea los deberes centrales a funciones y recorre una RACI de pyme de ejemplo que puedes adaptar.


Por qué una RACI, en concreto

El Reglamento reparte los deberes por toda la organización: trabajo técnico, interpretación jurídica, seguridad, datos, decisiones de producto, y un único aprobador por sistema. Sin un mapa deliberado, recurren tres modos de fallo:

  • Dos-personas-o-nadie. Un deber no tiene un dueño claro o tiene varios, así que se cuela.
  • Rendición de cuentas sin autoridad. Alguien es «aprobador» pero no puede dirigir el trabajo en realidad.
  • El cajón de sastre del DPD. Todo lo que tenga forma de IA aterriza en el delegado de protección de datos, que carece del contexto de ingeniería para cumplirlo.

Una RACI fuerza la elección. La disciplina es sencilla pero inquebrantable: exactamente un aprobador por deber. El responsable de ejecutar puede compartirse; el aprobador no.


Los deberes que mapear (y el artículo correcto en cada uno)

Mapea las obligaciones que de verdad generan trabajo. Cita el artículo correcto en cada una —esta es la columna vertebral del modelo:

DeberArtículoQué es
Sistema de gestión de riesgosArt. 9Identificar y mitigar riesgos a lo largo del ciclo de vida
Datos y gobernanza de datosArt. 10Datos de entrenamiento/validación/prueba pertinentes, representativos y verificados de errores
Documentación técnicaArt. 11El expediente técnico del anexo IV
Supervisión humanaArt. 14Diseñar y operar un control humano significativo
Obligaciones del responsable del despliegueArt. 26Usar conforme a las instrucciones, asignar supervisión, vigilar, conservar registros
Registro en la base de datos de la UEArt. 49Registrar el sistema de alto riesgo
Notificación de incidentes gravesArt. 73Notificar los incidentes graves a la autoridad

Dos notas sobre exactitud. El artículo 10 es gobernanza de datos, no formación del personal —la competencia del personal es el artículo 4 (alfabetización en IA), un deber separado y ya en vigor que conviene añadir al mapa. Y el artículo 73 es la notificación de incidentes graves del proveedor; la vigilancia poscomercialización por parte del proveedor es el artículo 72 —mantén ambos distintos.


Las funciones a las que mapearlos

En el otro eje se sitúan las funciones que cargan con el trabajo:

  • Aprobador con nombre (por caso de uso): normalmente un responsable de producto o de negocio; el único aprobador de ese sistema de principio a fin.
  • Cumplimiento / riesgo: ejecuta la evaluación, posee el registro, sigue el estado.
  • Jurídico / DPD: decisiones de clasificación, EIDF donde aplica, interfaz con el RGPD; consultado, rara vez responsable de ejecutar tareas de ingeniería.
  • TI / seguridad: controles de ciberseguridad (la rama del artículo 15), registro, acceso.
  • Datos: gobernanza de datos conforme al artículo 10, documentación de conjuntos de datos.
  • Producto / ingeniería: construye los mecanismos de supervisión, los insumos del expediente técnico, las correcciones.

Al DPD se le consulta en la mayoría de los deberes de IA y es aprobador solo de las piezas que solapan con el RGPD —no el dueño por defecto de todo.


Átala al registro de casos de uso

Una RACI vale tanto como la lista de sistemas que cubre. Anclala a tu registro de casos de uso de IA —el inventario de cada sistema de IA que construyes o despliegas— de modo que cada entrada lleve su propia fila RACI: clasificación, aprobador y el estado de cada deber mapeado. El registro es donde vive la RACI; sin él, el modelo es una rejilla abstracta sin nada a lo que engancharse. (Véase el registro de casos de uso de IA.)


Ejemplo práctico: la RACI de una pyme

Brightform GmbH —una empresa alemana ficticia de software de RR. HH. de 90 personas (~16 M€ de facturación)— despliega una herramienta de cribado de CV de un tercero (alto riesgo, punto 4 del anexo III) y provee su propia función de IA que redacta descripciones de puestos (riesgo limitado). Construye una RACI por sistema, anclada a su registro de casos de uso.

Para el despliegue de cribado de CV de alto riesgo:

DeberAprobador (uno)Responsable de ejecutarConsultadoInformado
Gestión de riesgos del art. 9Responsable de People OpsResponsable de cumplimientoJurídico, proveedorEquipo directivo
Gobernanza de datos del art. 10Responsable de People OpsResponsable de datosProveedorCumplimiento
Supervisión humana del art. 14Responsable de People OpsResponsable de selecciónJurídicoTI
Deberes de responsable del despliegue del art. 26Responsable de People OpsResponsable de cumplimientoJurídico/DPDEquipo directivo
Registro del art. 49Responsable de People OpsResponsable de cumplimientoJurídico—
Notificación de incidentes del art. 73Responsable de People OpsTI/seguridadJurídico, proveedorEquipo directivo

El aprobador con nombre es el responsable de People Ops —la persona que de verdad posee el resultado de la contratación— no el DPD, que es consultado. Como Brightform despliega esta herramienta en lugar de construirla, el expediente técnico del artículo 11 reside en el proveedor; el trabajo de Brightform es confirmar que el proveedor lo suministra y que se cumplen los deberes de responsable del despliegue del artículo 26. Para su propia función de descripciones de puestos, una RACI más ligera cubre el aviso de transparencia del artículo 50. Como pyme, la exposición a sanciones de Brightform está limitada a la cifra menor conforme al artículo 99, apartado 6.

El veredicto: dos sistemas, dos RACI, un aprobador cada uno —y un auditor puede rastrear cada deber hasta una persona con nombre. Ese es el sentido entero del ejercicio.


Una salvedad sobre la fecha límite

Los deberes de alto riesgo que mapea esta RACI aplican desde el 2 de diciembre de 2027 para los sistemas autónomos del anexo III en virtud del Ómnibus Digital, con acuerdo político en mayo de 2026 y ya adoptado: el Parlamento Europeo votó en el pleno el 16 de junio de 2026 y el Consejo lo adoptó formalmente el 29 de junio de 2026. Solo falta su publicación en el Diario Oficial, prevista antes del 2 de agosto de 2026. La alfabetización en IA del artículo 4 y las prohibiciones del artículo 5 ya están en vigor, así que el trabajo de gobernanza —incluido asignar la propiedad— no debería esperar a 2027.


Cómo ayuda Confir

Confir construye el registro de casos de uso del que cuelga la RACI: cada sistema de IA registrado, clasificado conforme a los artículos 5 y 6, y con su rol asignado —proveedor (art. 16), responsable del despliegue (art. 26), importador (art. 23) o distribuidor (art. 24). Cada entrada lleva las obligaciones que aplican y un dueño con nombre, de modo que la RACI se asienta sobre sistemas reales en lugar de una rejilla en blanco. La lógica de clasificación y de rol es determinista y basada en reglas, con cada hallazgo citado a su artículo. Confir no asigna a tu gente por ti —ese juicio se queda contigo— pero te da la lista estructurada de deberes-por-sistema sobre la que asignar.

Guías relacionadas

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 14 días.

Empieza la prueba gratuita →

Sigue leyendo

Guía completa

Gobernanza de la IA para el cumplimiento de la Ley de IA de la UE: el modelo operativo para pymes

Cree un programa de gobernanza de la Ley de IA de la UE para su pyme. Mapa de artículos correcto (Art. 9, 14, 43, 72), plazo del 2 dic 2027, sanciones, RACI y un plan a 90 días.

Guía sectorial

Comité de ética de IA: qué hace un órgano de gobernanza de IA bajo el Reglamento de IA

Un comité de ética de IA es una práctica, no un órgano legal: cómo filtra usos del artículo 5 y autoriza despliegues de alto riesgo del anexo III.

Guía sectorial

Preparación para auditorías del Reglamento de IA: qué puede pedirte realmente una autoridad de vigilancia del mercado

Qué evidencia puede exigir una autoridad de vigilancia del mercado (art. 74): inventario, anexo IV, registros, EIDF, registro. Tu dosier listo.

Guía sectorial

Informes de IA al consejo de administración: qué reportar y con qué cadencia

Qué reportar al consejo sobre la IA: inventario, % clasificado, estado de alto riesgo, incidentes del art. 73 y formación del art. 4, ligado al art. 9.

Guía

La guía de cumplimiento de la Ley de IA de la UE para el CISO

Los CISO y la Ley de IA de la UE: inventario de IA, ciberseguridad del Artículo 15, notificación de incidentes del Artículo 73, solapamiento con NIS2, informes al consejo. Plazo de alto riesgo: dic 2027.

Guía sectorial

La Ley de IA de la UE para el sector fintech: clasificación de alto riesgo, obligaciones y el plazo que importa

La Ley de IA de la UE para el sector fintech: la calificación crediticia (Anexo III, 5, letra b)) es de alto riesgo; la detección de fraude no lo es. Obligaciones, EIDF y el plazo del 2 de diciembre de 2027.