El Reglamento de Inteligencia Artificial (RIA o AI Act) ya lleva un tiempo con nosotros, pero su despliegue normativo continúa avanzando por etapas. A las directrices y el código de buenas prácticas para modelos de propósito general hay que sumarle ahora una pieza que tiene implicaciones muy concretas para cualquier empresa que desarrolle o comercialice sistemas de IA en Europa: el borrador del Reglamento de Ejecución de la Comisión Europea sobre los procedimientos de supervisión de modelos de IA de propósito general.
Este texto, publicado como borrador el 12 de marzo de 2026 y todavía pendiente de adopción oficial, detalla cómo la Comisión llevará a cabo las evaluaciones de modelos de IA y los procedimientos sancionadores previstos en el artículo 101 del AI Act. Es importante subrayar que, hasta el 9 de abril, ha estado en una fase de solicitud de comentarios y que todavía no representa una posición oficial de la Comisión, pero precisamente por eso conviene conocerlo: da una idea muy concreta de hacia dónde se dirige la aplicación práctica de la normativa y, sobre todo, de qué puede exigirle la Comisión a una empresa si decide auditar uno de sus modelos.
¿De qué trata realmente este borrador?
El texto regula dos cosas. Por un lado, cómo la Comisión puede acceder a un modelo de IA para evaluarlo. Por otro, las garantías procedimentales que rodean un posible expediente sancionador. Dicho más claro: cómo te van a auditar y qué opciones tienes durante ese proceso.
Algo que llama la atención es la amplitud con la que se concibe el acceso al modelo. Cuando la Comisión decida evaluar un sistema de IA de propósito general, puede exigir acceso a través de APIs, pero también al código fuente, a los pesos del modelo, a la infraestructura con la que se ejecuta e incluso al mismo nivel de acceso del que disfrutan los propios empleados de la empresa. Estamos hablando de abrir el modelo por completo. Y a eso se añade la posibilidad de que la Comisión solicite desactivar los sistemas de registro de actividad durante la evaluación, lo que significaría que la empresa pierde trazabilidad de qué hacen los evaluadores en sus propios sistemas. Hay que insistir en que se trata de un borrador y, por ejemplo, este último punto ya ha sido cuestionado por varios de los comentarios que pueden verse en la propia página donde se comparte el documento. Veremos en qué queda.
El problema de la caja negra
¿Por qué el regulador necesita llegar a ese nivel de intrusión? La respuesta es sencilla: porque los modelos de IA actuales, en su gran mayoría, son cajas negras. No ofrecen por sí mismos una explicación comprensible de cómo llegan a sus resultados. Si un evaluador externo quiere entender por qué un modelo toma determinadas decisiones, tiene pocas alternativas: o accede a sus entrañas, o confía en lo que le dice el proveedor. Y la normativa, lógicamente, ha optado por la primera vía.
Aquí es donde la explicabilidad se convierte en una herramienta imprescindible. Un modelo que justifica sus decisiones de forma comprensible —que muestra qué variables han influido en cada predicción, qué regiones de una imagen han determinado un diagnóstico, qué características de un caso clínico han llevado a una recomendación— reduce drásticamente la necesidad de que el auditor acceda al código fuente para entender lo que ocurre.
La documentación como primera línea de defensa
El borrador establece que, una vez que la Comisión notifica sus hallazgos preliminares, la empresa investigada dispone de un plazo mínimo de 14 días para presentar sus observaciones por escrito. Catorce días para rebatir, con argumentos técnicos sólidos, las conclusiones de un proceso de evaluación que puede haber durado meses. Es un plazo que, en contextos de alta complejidad técnica, resulta muy ajustado.
¿Qué documentación necesitaría una empresa para responder con garantías? Básicamente, una descripción precisa, estructurada y comprensible del modelo: cómo funciona, con qué datos fue entrenado, cuál es su comportamiento esperado y cómo se verificó. Es decir, la información que se suele encontrar en una model card.
Las model cards no son una idea nueva —Google las incluye sistemáticamente al publicar nuevas versiones de Gemini—, pero lo que plantea el marco normativo europeo es ir más allá de la publicación voluntaria: disponer de una documentación estandarizada y alineada con los requisitos del RIA que sirva para demostrar conformidad ante el regulador y que usuarios y autoridades puedan entender el sistema en su contexto de uso. Eso requiere un trabajo técnico previo que no puede improvisarse en 14 días.
Cuando el modelo ya está en el mercado
El artículo 5 del borrador contempla que la Comisión adopte medidas provisionales de urgencia —incluida la retirada del modelo del mercado— basándose en una apreciación preliminar de riesgo grave, incluso antes de que el procedimiento sancionador se haya completado. Es una medida para situaciones excepcionales, pero su mera existencia cambia el cálculo de riesgo: si no puedes demostrar rápidamente que tu modelo es robusto y predecible, la carga de la prueba cae sobre ti en el peor momento posible.
La clave aquí no es solo tener documentación, sino disponer de evidencia objetiva sobre el comportamiento del modelo: qué tan estables son sus predicciones ante variaciones pequeñas en los datos de entrada, con qué fiabilidad opera en distintos rangos, cuándo reconoce que se enfrenta a un caso fuera de su dominio de entrenamiento. Son preguntas técnicas cuyas respuestas, si están disponibles y son verificables, pueden marcar la diferencia entre una medida cautelar y su evitación.
El papel de eXplAIn
En este contexto es donde el proyecto eXplAIn, que desarrollamos en ITI, adquiere relevancia, ya que sus líneas de trabajo responden directamente a las exigencias descritas.
Por un lado, eXplAIn está desarrollando herramientas de explicabilidad que reducen la necesidad de acceso intrusivo a los modelos. Si un sistema de IA puede articular, de forma comprensible y verificable, por qué toma cada decisión —mediante la identificación de características relevantes en datos tabulares o mediante mapas de calor que señalan las regiones de una imagen determinantes en un diagnóstico médico—, el evaluador externo tiene una alternativa real a la disección del modelo. Esto incluye métricas objetivas para evaluar la calidad de las explicaciones: cuán fieles son a lo que realmente hace el modelo, cuán consistentes ante casos similares, cuán robustas frente a variaciones en los datos. Estas métricas tienen un valor doble: permiten al desarrollador mejorar y validar sus explicaciones, y proporcionan al proveedor argumentos verificables para defenderse ante el regulador o para demostrar proactivamente que el modelo no representa un riesgo sistémico.
Por otro lado, el proyecto trabaja en la definición de model cards alineadas con los requisitos del RIA. No son simplemente documentación técnica; están diseñadas para ser comprensibles por distintos perfiles de usuario, desde el equipo de desarrollo hasta la autoridad regulatoria. Disponer de ellas con antelación convierte lo que podría ser una respuesta improvisada en 14 días en una presentación ordenada de evidencias ya preparadas.
Para las empresas que desarrollan o utilizan sistemas de IA, la conclusión es clara: prepararse para una eventual auditoría no puede dejarse para cuando llegue el requerimiento. En ITI estamos construyendo las herramientas para hacerlo, y el equipo del Grupo de IA Responsable está disponible para colaborar con cualquier organización que quiera dar ese paso.
