El registro de casos de uso de IA: donde el cumplimiento de la Ley de IA empieza de verdad
El registro de casos de uso de IA es el paso uno del cumplimiento de la Ley de IA: los campos que necesita, cómo mapea cada uso al artículo 6 y por qué
Un solo modelo de lenguaje dentro de tu empresa puede ser tres problemas de cumplimiento a la vez. El mismo modelo usado para cribar currículums es de alto riesgo bajo la Ley de IA; usado para redactar textos de marketing es de riesgo mínimo; usado para alimentar un chatbot de atención al cliente arrastra deberes de transparencia. La clasificación se adhiere a lo que estás haciendo, no al modelo que compraste, y por eso el primer artefacto que construyes es un registro de usos, no una lista de herramientas.
Un registro de casos de uso de IA es el libro mayor de gobernanza de cada uso de negocio distinto que tu organización hace de la IA: una fila por finalidad prevista, no una fila por licencia. Está deliberadamente aguas arriba de —y es más ligero que— un expediente completo de documentación técnica: su función es alimentar la clasificación, no ser el propio paquete de evidencia.
Esta página explica exactamente qué es un registro de casos de uso, por qué es el paso uno del cumplimiento bajo el Reglamento (UE) 2024/1689, los campos que debe contener, cómo fluye cada fila hacia la cadena de clasificación del artículo 6, y qué cuesta hacerlo mal.
Qué es realmente un registro de casos de uso de IA
El caso de uso, no el modelo ni la licencia
La unidad de análisis es el caso de uso —una única finalidad prevista a la que se aplica la IA—, no la herramienta que lo entrega. La clasificación jurídica bajo la Ley de IA se adhiere a la finalidad prevista tal y como la define el artículo 3(12): el uso para el que está destinado un sistema de IA, incluidos el contexto y las condiciones de uso específicos. Esa definición es el gancho del que cuelga toda la cadena de clasificación, y apunta al uso, no al modelo subyacente.
Esto importa porque un mismo modelo fundacional o herramienta de proveedor genera de forma rutinaria varios casos de uso distintos que clasifican de manera diferente. El mismo modelo de uso general puede estar detrás de la criba de currículums (alto riesgo), la redacción de textos de marketing (mínimo) y un chatbot de soporte (transparencia de riesgo limitado). Contarlo como «una herramienta de IA» oculta tres perfiles de obligaciones distintos. Contarlo como tres casos de uso los saca a la luz.
Por qué «registro» es un artefacto de gobernanza, no un inventario de software
Distingue con nitidez el registro de casos de uso del sentido de stock de almacén de un inventario de IA: el ejercicio de contar los modelos desplegados, las licencias SaaS y las claves de API. El inventario pregunta ¿qué tenemos en marcha? El registro de casos de uso pregunta ¿qué estamos usando la IA para hacer, y a quién aplica? Esa segunda pregunta es la que responde el texto legal.
El registro es la entrada que alimenta la clasificación, la evaluación de riesgo y el registro. Es intencionadamente ligero: un control de gobernanza, no un expediente de documentación de 40 páginas. Mantenlo como el índice que apunta aguas abajo, no como el lugar donde duplicas la evidencia de aguas abajo.
La regla de una fila por caso de uso
La disciplina rectora es simple: una fila por finalidad prevista distinta. Si una sola herramienta sirve a dos finalidades genuinamente diferentes —puntuar candidatos y redactar cartas de oferta— se gana dos filas, porque cada una se clasificará por separado. Si dos herramientas distintas sirven a la misma finalidad, eso es una cuestión de aprovisionamiento de la fila, no dos filas. El registro rastrea usos; las herramientas son un atributo de cada uso.
Por qué el registro de casos de uso es el paso uno del cumplimiento de la Ley de IA
No puedes clasificar lo que no has catalogado
Toda obligación aguas abajo presupone que ya has enumerado tus casos de uso. La clasificación de alto riesgo bajo el artículo 6, el sistema de gestión de riesgos del artículo 9, la documentación técnica del artículo 11 y el registro en la base de datos de la UE del artículo 49 dan por hecho un conjunto conocido de usos sobre el que actuar. No puedes clasificar, evaluar el riesgo ni registrar un caso de uso que nunca has anotado. El registro es cómo el conjunto pasa a ser conocido.
Dimensiona todo el programa de cumplimiento
El registro dimensiona el problema antes de que gastes un euro en resolverlo. Te dice cuántos de tus casos de uso tocan un área del anexo III y, por tanto, cuán grandes son en realidad tus obligaciones de alto riesgo. Sin ese recuento, las organizaciones caen por defecto en uno de dos errores: sobredimensionar, tratando todo como alto riesgo y quemando esfuerzo en usos de riesgo mínimo; o infradimensionar, omitiendo por completo un caso de uso del anexo III y entrando de lleno en un incumplimiento real. Un registro poblado sustituye las conjeturas por una carga de trabajo priorizada.
También es la evidencia de que actuaste con diligencia
Los deberes de alfabetización en IA del artículo 4 se aplican desde el 2 de febrero de 2025, y un registro de casos de uso es precisamente cómo una organización demuestra que sabe qué IA tiene a su cargo y ha equipado a su gente en consecuencia. Más allá de la alfabetización, un registro mantenido es en sí mismo evidencia de diligencia de buena fe cuando una autoridad de vigilancia del mercado pregunta. La ausencia de uno señala lo contrario: que no conocías tu propio patrimonio. El registro es a la vez la herramienta de planificación y la prueba de que la usaste.
Los campos que debe contener un registro de casos de uso
Cada campo lleva una referencia a un artículo porque cada campo hace un trabajo regulatorio. Esta es la especificación campo a campo: columna, qué captura y por qué la Ley de IA lo necesita.
| Campo | Qué captura | Por qué lo necesita la Ley |
|---|---|---|
| ID del caso de uso | Un identificador estable del uso | Permite que cada artefacto aguas abajo (registro de riesgos, documentación) referencie una fila canónica |
| Nombre / descripción del caso de uso | Declaración en lenguaje llano del uso | Lo que se clasifica; un auditor lee esto primero |
| Sistema / herramienta que lo entrega | El sistema de IA o producto detrás del uso | Vincula el uso con la tecnología y con su proveedor |
| Nombre del proveedor (vendor) | Quién suministra el sistema subyacente | Determina si aplican los deberes de GPAI / proveedor aguas arriba |
| Función de negocio | Departamento o proceso dueño del uso | Encamina el uso al área responsable adecuada |
| Rol: proveedor o responsable del despliegue | Si actúas como proveedor o responsable del despliegue para este uso (artículo 25 / artículo 26) | El campo más trascendente: decide qué obligaciones aplican |
| Finalidad prevista | La finalidad del artículo 3(12), en lenguaje operativo | La clasificación se realiza contra este texto exacto |
| Mapeo al anexo III | Qué epígrafe del anexo III aplica, o «ninguno» con su razón | Decide si la vía de alto riesgo está siquiera abierta |
| Nivel de riesgo | Prohibido / alto riesgo / limitado / mínimo, más la justificación | La conclusión de la clasificación y su base |
| Responsable nominal | Una persona con nombre responsable del uso | Alguien a quien una autoridad pueda escalar; no un equipo |
| Fecha y estado de revisión | Activo / piloto / retirado, más la fecha de última revisión | Mantiene el registro como documento vivo, no una foto fija |
| Puntero a artefactos más profundos | Una línea que enlaza al registro de riesgos / la documentación | Mantiene el registro ligero en vez de duplicar la evidencia |
Campos centrales de identificación y propiedad
El bloque de identificación es la columna vertebral: ID del caso de uso, nombre y descripción, el sistema o herramienta que lo entrega, el proveedor (vendor) y la función de negocio. El responsable nominal debe ser una persona con nombre: «el equipo de datos» no es un responsable; «el responsable de Operaciones de Personas» sí. Esa persona certifica la exactitud de la fila y dispara sus revisiones.
Los campos de clasificación que dirigen todo aguas abajo
Tres campos cargan con el peso. El campo de rol —proveedor o responsable del despliegue— es la columna individual más trascendente del registro. La mayoría de las empresas que usan herramientas de terceros son responsables del despliegue, cuyos deberes están en el artículo 26; pero bajo el artículo 25, modificar sustancialmente un sistema, renombrarlo como propio o cambiar su finalidad prevista te convierte a ti en proveedor. La misma herramienta puede hacerte responsable del despliegue para un caso de uso y proveedor para otro. El campo de finalidad prevista, expresado en lenguaje operativo llano, es contra lo que se ejecuta la clasificación. Y el campo de mapeo al anexo III registra qué epígrafe aplica —por ejemplo, empleo bajo el anexo III, punto 4, o educación bajo el anexo III, punto 3— o «ninguno», con la razón registrada para que la conclusión sea defendible.
Campos de estado, revisión y pista de auditoría
El campo de nivel de riesgo registra la clasificación resultante —prohibido bajo el artículo 5, alto riesgo bajo el artículo 6, limitado/transparencia bajo el artículo 50, o mínimo—, más una justificación breve y cualquier excepción reclamada del artículo 6(3). Los campos de fecha y estado de revisión (activo, piloto, retirado) mantienen el registro al día. Y un puntero de una sola línea a artefactos más profundos —el registro de riesgos, el expediente de documentación técnica— mantiene el registro ligero en lugar de convertirlo en un duplicado de todo lo de aguas abajo.
Cómo el registro alimenta la cadena de clasificación
Cada fila no es un punto final; es un alimentador. Una vez capturado, cada caso de uso se pasa por la misma lógica de clasificación en un orden fijo.
Del caso de uso a la decisión de alto riesgo del artículo 6
Criba cada fila en secuencia. Primero, contra las prohibiciones del artículo 5: ¿es este uso una de las prácticas prohibidas? Luego, contra el anexo III más el filtro de importancia del artículo 6: ¿cae bajo un epígrafe de alto riesgo? Luego, contra los desencadenantes de transparencia del artículo 50. El campo de mapeo al anexo III decide qué vía del artículo 6 aplica: el artículo 6(1) cubre la IA que es, o es un componente de seguridad de, un producto cubierto por la legislación de armonización del anexo I; el artículo 6(2) cubre los casos de uso autónomos que caen bajo un epígrafe del anexo III. El campo del anexo III del registro es lo que encamina una fila por una vía o la otra.
La exclusión del artículo 6(3) permite que ciertos casos de uso del anexo III escapen del estatus de alto riesgo cuando no plantean un riesgo significativo —tareas procedimentales acotadas, por ejemplo—. Pero la elaboración de perfiles de personas físicas siempre permanece como alto riesgo, sin exención disponible. Registra la justificación de cualquier reclamación del artículo 6(3) en la fila del registro, porque esa justificación es el artefacto que entregas a una autoridad si se cuestiona el nivel.
Los casos de transparencia que no debes olvidar
Los casos de uso de riesgo limitado son los que las organizaciones archivan por error bajo «nada que hacer». Un chatbot, o una funcionalidad que genera contenido sintético, sigue arrastrando deberes de transparencia del artículo 50: divulgar que una persona está interactuando con una IA, o marcar el contenido generado por IA. El registro los señala explícitamente para que un veredicto de «no es de alto riesgo» no se confunda con «sin obligaciones». Ten en cuenta que los deberes de marcado de contenido y marca de agua del artículo 50 llevan su propio plazo del 2 de diciembre de 2026.
El traspaso al registro de riesgos y al registro en la base de datos
Las filas de alto riesgo se gradúan. Pasan al registro de riesgos de IA del artículo 9 —el sistema de gestión de riesgos que recorre todo el ciclo de vida del sistema— y, en última instancia, al registro en la base de datos de la UE del artículo 49 que los proveedores deben completar antes de introducir un sistema de alto riesgo en el mercado. El registro de casos de uso es el alimentador de ambos. Deja limpios los campos del caso de uso y los artefactos de aguas abajo costarán mucho menos rehacer.
Ejemplo práctico: Meridian Logistics, un transitario de 120 personas
Un registro es abstracto hasta que se puebla. Toma Meridian Logistics, una empresa de tránsito de mercancías de 120 personas en Róterdam. Su dirección dice «usamos IA», una afirmación indiferenciada que no le dice nada a un regulador. Construir el registro convierte tres palabras en cuatro filas.
| Caso de uso | Sistema que lo entrega | Rol | Mapeo al anexo III | Nivel de riesgo |
|---|---|---|---|---|
| Motor de optimización de rutas (logística interna) | Herramienta SaaS de planificación | Responsable del despliegue | Ninguno — sin efecto sobre personas | Mínimo |
| Asistente de criba de currículums (equipo de RR. HH. de 6 personas) | SaaS de terceros | Responsable del despliegue (art. 26) | Punto 4 (empleo) | Alto riesgo |
| Chatbot de seguimiento de clientes | Chatbot de proveedor | Responsable del despliegue | Ninguno | Limitado (art. 50) |
| Modelo de previsión de demanda (ajustado internamente) | Modelo modificado internamente | Proveedor (art. 25) | Ninguno | Mínimo, pero con deberes de proveedor |
Clasificando cada fila
Caso de uso 1: optimización de rutas. Programa camiones; no afecta a personas físicas. Cribado contra el artículo 5 (claro), el anexo III (no aplica ningún epígrafe), el artículo 50 (sin desencadenante de transparencia). Nivel: mínimo. Meridian es el responsable del despliegue. El registro anota «ningún epígrafe del anexo III» con la razón, para que el veredicto de mínimo quede documentado en lugar de asumido.
Caso de uso 2: asistente de criba de currículums, usado por el equipo de RR. HH. de seis personas. Esto cae de lleno bajo el anexo III, punto 4 (empleo, selección de personal). Nivel: alto riesgo. Meridian es el responsable del despliegue; el proveedor SaaS es el proveedor. Esta única fila dispara las obligaciones del responsable del despliegue del artículo 26 y es el único caso de uso que se gradúa al registro de riesgos del artículo 9.
Caso de uso 3: chatbot de seguimiento de cara al cliente. Riesgo limitado, pero no nada: el artículo 50 exige que Meridian divulgue que los clientes están interactuando con una IA. El registro señala el deber de transparencia para que no se pierda.
Caso de uso 4: modelo de previsión de demanda, que Meridian ajustó internamente y ahora etiqueta como su propio producto interno. Esta es la trampa del artículo 25: al modificar sustancialmente el modelo y presentarlo bajo su propio nombre, el rol de Meridian pasa de responsable del despliegue a proveedor, arrastrando obligaciones mucho más pesadas de las que esperaba de una herramienta interna de previsión. El registro es exactamente el artefacto que saca a la luz este cambio antes de que lo haga un auditor.
Qué revela el registro poblado
De cuatro casos de uso de IA, solo uno es de alto riesgo, y un caso distinto convierte calladamente a Meridian en proveedor. Sin el registro, Meridian habría tratado los cuatro como de alto riesgo (desperdiciando esfuerzo) o, peor, habría omitido por completo el caso de uso de selección de personal y el cambio de rol. El registro convirtió «usamos IA» en una carga de trabajo precisa, priorizada y defendible. Punto.
Mantener el registro vivo y qué cuesta el incumplimiento
Desencadenantes de cambio y cadencia de revisión
El registro es un documento vivo, no un ejercicio puntual. Cada uno de estos dispara una clasificación nueva de la fila afectada: la aparición de un nuevo caso de uso; un cambio de proveedor o herramienta; una modificación sustancial que cambia un rol bajo el artículo 25; y cualquier cambio en la finalidad prevista. Por encima de los desencadenantes por evento, fija una revisión periódica fija —trimestral es el mínimo práctico— y sella cada fila con una fecha de última revisión. Una fecha de revisión vencida sin actualización es una brecha documentada, peor que no tener fecha, porque demuestra que lo sabías.
Los niveles de sanción detrás de hacerlo mal
| Nivel | Multa máxima | Qué cubre |
|---|---|---|
| Artículo 99(3) | 35 M€ o el 7 % del volumen de negocio anual total a escala mundial, lo que sea mayor | Incumplimientos de prácticas prohibidas del artículo 5 |
| Artículo 99(4) | 15 M€ o el 3 % del volumen de negocio anual total a escala mundial, lo que sea mayor | Incumplimiento de la mayoría de obligaciones de alto riesgo y otras |
| Artículo 99(5) | 7,5 M€ o el 1 % del volumen de negocio anual total a escala mundial, lo que sea mayor | Facilitar información incorrecta o engañosa a las autoridades |
El nivel más bajo es el 1 %, nunca el 1,5 %. Y bajo el artículo 99(6), las multas para pymes y empresas emergentes se limitan al menor entre el porcentaje o el importe fijo —no el mayor—, así que las empresas más pequeñas no deberían leer las cifras de titular sin matices. Donde el registro muerde: un registro inexacto o ausente es precisamente el tipo de información incorrecta que activa el nivel del artículo 99(5) cuando se comparte con una autoridad, además de minar la base de evidencia detrás de la mayor exposición del artículo 99(4).
El calendario de alto riesgo a junio de 2026
No todo está en el mismo reloj, y no todo se aplaza. Las prohibiciones del artículo 5 y la alfabetización en IA del artículo 4 se aplican desde el 2 de febrero de 2025. Las obligaciones de GPAI bajo los artículos 51 a 55 se aplican desde el 2 de agosto de 2025. Un nuevo plazo fijo del 2 de diciembre de 2026 suma la prohibición de material de abuso sexual infantil (CSAM) / «desnudadores» y los deberes de marcado de contenido del artículo 50.
Para los casos de uso de alto riesgo autónomos del anexo III (artículo 6(2)), el texto vigente fija legalmente el 2 de agosto de 2026. El Digital Omnibus alcanzó un acuerdo político provisional el 6 y 7 de mayo de 2026 (el COREPER confirmó el texto en torno al 13 de mayo de 2026) para aplazar esa fecha al 2 de diciembre de 2027, y para aplazar la vía de productos del anexo I (artículo 6(1)) del 2 de agosto de 2027 al 2 de agosto de 2028. Pero a junio de 2026 esto aún no es ley: todavía necesita un voto en el 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 autónomo del anexo III. Planifica frente al 2 de agosto de 2026 hasta que el aplazamiento se promulgue. Son fechas de calendario fijas; la variante de «parar el reloj» condicionada a normas técnicas fue rechazada.
Cómo ayuda Confir
Confir construye y mantiene tu registro de casos de uso de IA a medida que describes lo que tu organización hace con la IA. Respondes escenarios en lenguaje llano sobre cada uso —qué hace, a quién, en nombre de quién— y el motor determinista y basado en reglas de Confir deriva el rol (proveedor bajo el artículo 25 / responsable del despliegue bajo el artículo 26) y el nivel de riesgo (prohibido / alto / limitado / mínimo), con el mapeo al anexo III y una justificación citada registrada en cada fila.
La lógica es reproducible: las mismas entradas producen siempre el mismo nivel y el mismo razonamiento citado —sin inferencia de modelo, sin alucinación—. Esa reproducibilidad es lo que hace defendible un registro cuando una autoridad competente pregunta cómo se clasificó un uso. Las filas de alto riesgo luego alimentan directamente el registro de riesgos de IA del artículo 9 y los datos de registro del artículo 49, mantenidos en una sola fuente para que no se desvíen, con cada cambio de campo escrito en una pista de auditoría con marca temporal.
Preguntas frecuentes
¿Qué es un registro de casos de uso de IA?
Un registro de casos de uso de IA es un libro mayor de gobernanza que enumera cada uso de negocio distinto que una organización hace de la IA, una fila por finalidad prevista en lugar de una fila por herramienta. Cada entrada registra el caso de uso, el sistema que lo entrega, si actúas como proveedor o responsable del despliegue, su mapeo al anexo III y su nivel de riesgo resultante bajo la Ley de IA. Existe para dirigir la clasificación y es deliberadamente más ligero que un expediente completo de documentación técnica.
¿En qué se diferencia un registro de casos de uso de un inventario de IA?
Un inventario de IA en el sentido de stock de almacén cuenta lo que has desplegado: modelos, licencias SaaS y claves de API. Un registro de casos de uso pregunta qué estás usando la IA para hacer y a quién aplica. La distinción importa porque la clasificación de la Ley de IA se adhiere a la finalidad prevista bajo el artículo 3(12), no al modelo subyacente. Un solo modelo fundacional puede dar soporte a varios casos de uso que clasifican de manera diferente, así que el caso de uso, no la herramienta, es la unidad de análisis.
¿Por qué el registro de casos de uso es el paso uno del cumplimiento de la Ley de IA?
Porque toda obligación aguas abajo lo presupone. No puedes clasificar bajo el artículo 6, construir el sistema de gestión de riesgos del artículo 9, redactar la documentación del artículo 11 ni registrar bajo el artículo 49 hasta que hayas enumerado tus casos de uso. El registro también dimensiona el problema, diciéndote cuántos casos de uso tocan el anexo III antes de invertir en controles. Un registro mantenido es en sí mismo evidencia de diligencia si una autoridad de vigilancia del mercado pregunta de qué IA eres responsable.
¿Qué campos debe contener un registro de casos de uso de IA?
Como mínimo: un ID y una descripción del caso de uso, el sistema que lo entrega y el proveedor, la función de negocio y un responsable nominal con nombre. Los campos de clasificación son los que dirigen todo lo demás: tu rol (proveedor o responsable del despliegue), la finalidad prevista, el mapeo al anexo III, el nivel de riesgo resultante y una justificación breve de la clasificación. Añade campos de estado y de fecha de revisión para que el registro siga siendo un documento vivo, más un puntero a artefactos más profundos en lugar de duplicarlos.
¿Un registro de casos de uso solo cubre la IA de alto riesgo?
No. Debería cubrir cada caso de uso, porque no puedes saber cuáles son de alto riesgo hasta que los has clasificado todos. Los usos de riesgo mínimo también pertenecen al registro para que su clasificación quede documentada y se revise si cambia la finalidad. Los usos de riesgo limitado, como los chatbots, arrastran deberes de transparencia del artículo 50 y deben señalarse, no ignorarse. El registro es el lugar donde cada caso de uso se criba contra el artículo 5, el artículo 6 y el artículo 50 por turnos.
¿Cuándo se aplican las obligaciones de alto riesgo de la Ley de IA?
Las prohibiciones del artículo 5 y la alfabetización en IA del artículo 4 se aplican desde el 2 de febrero de 2025, y las obligaciones de GPAI bajo los artículos 51 a 55 desde el 2 de agosto de 2025. Para los sistemas de alto riesgo autónomos del anexo III, el texto vigente fija legalmente el 2 de agosto de 2026. Un aplazamiento al 2 de diciembre de 2027 alcanzó un acuerdo político provisional vía el Digital Omnibus en mayo de 2026, pero a junio de 2026 aún no es ley y todavía necesita un voto del Parlamento, la adopción del Consejo y la publicación. Planifica frente al 2 de agosto de 2026 hasta que se promulgue.
¿Cuáles son las sanciones por no gestionar los casos de uso de IA bajo la Ley de IA?
Las multas escalan con la infracción. Las prácticas prohibidas bajo el artículo 5 pueden alcanzar 35 M€ o el 7 % del volumen de negocio anual a escala mundial (artículo 99(3)). La mayoría de los incumplimientos de alto riesgo y de obligaciones alcanzan 15 M€ o el 3 % (artículo 99(4)). Facilitar información incorrecta o engañosa a las autoridades alcanza 7,5 M€ o el 1 % (artículo 99(5)). Para pymes y empresas emergentes, el artículo 99(6) fija cada límite en el menor entre el importe fijo o el porcentaje, no el mayor.
Guías relacionadas
- el inventario de IA que cuenta tus sistemas desplegados
- una plantilla de registro de sistemas de IA lista para copiar y pegar
- cómo el artículo 6 clasifica los sistemas de IA de alto riesgo
- construir un registro de riesgos de IA del artículo 9
- el modelo operativo más amplio de gobernanza de la Ley de IA
Última revisión: junio de 2026. Cita el Reglamento (UE) 2024/1689 (Ley de IA).
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 →