El Reglamento Europeo de IA (AI Act) en un departamento de IT: niveles de riesgo, roles, calendario, registro de casos de uso y una herramienta no aprobada

Qué vas a conseguir

Saber qué parte del Reglamento (UE) 2024/1689, el AI Act, afecta a tu organización cuando no fabrica modelos de IA pero los usa todos los días: Copilot en Microsoft 365, un chatbot en la web, una herramienta de selección de RR. HH., un asistente de código. Y montar lo mínimo que IT tiene que tener: un registro de casos de uso, un circuito de aprobación y una respuesta para cuando alguien usa una herramienta que nadie ha aprobado.

Esta guía es un mapa práctico para IT, no asesoramiento jurídico: las decisiones de clasificación se toman con el área legal y el delegado de protección de datos (DPO).

Antes de empezar

• Un patrocinador en dirección y un grupo pequeño con legal, DPO, seguridad, RR. HH. y IT. La IA entra por todas las áreas, no solo por IT.
• El inventario de lo que ya se usa: licencias de Copilot, funciones de IA activadas en el SaaS que ya tienes (CRM, ITSM, RR. HH.), desarrollos propios con APIs de modelos y lo que la gente usa sin pedir permiso (los registros del proxy o de Defender for Cloud Apps lo enseñan).
• La política de uso aceptable de IT, para añadirle la parte de IA en vez de crear otra.

1. Las cuatro categorías de riesgo

El reglamento no regula "la IA" en bloque: regula usos, según el riesgo.

En una empresa típica, casi todo cae en mínimo o limitado. Lo que hay que vigilar son los usos de RR. HH. y de evaluación de clientes: ahí está el alto riesgo, aunque la herramienta la venda un tercero.

2. Proveedor o responsable del despliegue

• Proveedor (provider): quien desarrolla un sistema de IA y lo comercializa o lo pone en servicio con su nombre. Microsoft, para Copilot.
• Responsable del despliegue (deployer): quien usa un sistema de IA bajo su autoridad en una actividad profesional. Tu empresa, cuando activa Copilot.
• Ojo con los desarrollos propios: si tu equipo monta un chatbot para clientes sobre la API de un modelo y lo publica con vuestra marca, sois el proveedor de ese sistema, con las obligaciones de transparencia del proveedor.
• Si modificas de forma sustancial un sistema de alto riesgo o le cambias la finalidad para convertirlo en uno, pasas a tener las obligaciones del proveedor.

3. Lo que aplica a una empresa que usa Copilot o un chatbot

Alfabetización en IA (artículo 4), aplicable desde el 2 de febrero de 2025. Tras el Ómnibus Digital, la obligación es adoptar medidas para apoyar la alfabetización del personal y de quien use los sistemas en nombre de la empresa, sin exigir un nivel concreto a cada persona. En la práctica:

• Una formación corta por perfil: qué puede y qué no puede hacer la herramienta, alucinaciones, qué datos no se meten y cómo revisar lo que produce.
• Formación más profunda para quien configura o aprueba casos de uso.
• Registro de quién la ha hecho: es lo que podrás enseñar.

Transparencia (artículo 50), aplicable desde el 2 de agosto de 2026:

• Un chatbot que habla con clientes tiene que dejar claro que es una IA, salvo que sea evidente.
• Si publicas imágenes, audio o vídeo generados o manipulados que parecen reales, hay que indicarlo.
• Si usas reconocimiento de emociones o categorización biométrica (en los casos permitidos), hay que informar a las personas expuestas.

Si un caso de uso es de alto riesgo, quien lo despliega tiene que, entre otras cosas, usarlo según las instrucciones del proveedor, asignar supervisión humana a personas con formación y autoridad, vigilar su funcionamiento, conservar los registros que genera durante al menos seis meses e informar a los representantes de los trabajadores antes de usarlo en el trabajo.

4. El calendario

Las dos últimas fechas son las del Ómnibus Digital sobre IA, el Reglamento (UE) 2026/1744, publicado en julio de 2026, que retrasó el alto riesgo (antes 2 de agosto de 2026 y 2027), suavizó la redacción de la alfabetización y añadió nuevas prohibiciones sobre imágenes íntimas no consentidas y material de abuso infantil desde el 2 de diciembre de 2026. Las obligaciones de alto riesgo son las mismas: solo se ha movido la fecha.

En España, la autoridad de supervisión es la AESIA (Agencia Española de Supervisión de la Inteligencia Artificial). Los modelos de propósito general obligan a sus proveedores, no a quien usa Copilot.

5. El registro de casos de uso

Una tabla en la herramienta de GRC, en SharePoint o en la CMDB, con una fila por caso de uso (no por herramienta: Copilot para resumir reuniones y Copilot para evaluar candidatos son dos casos distintos):

Lo que se revisa cada trimestre: casos nuevos, cambios de finalidad, herramientas que han añadido IA por su cuenta en una actualización y casos que han dejado de usarse.

6. Aprobación y su relación con el RGPD

Un circuito sencillo para cada caso de uso nuevo:

1. Solicitud con la finalidad, los datos y quién lo va a usar.
2. Clasificación de riesgo con legal. Si cae en prohibido, se para aquí.
3. Protección de datos: si trata datos personales, el DPO decide si hace falta una evaluación de impacto (EIPD) según el artículo 35 del RGPD. Para un sistema de alto riesgo, la información que da el proveedor sirve para hacerla. Revisa también el contrato: dónde se procesan los datos, si se usan para entrenar y cuánto tiempo se guardan.
4. Seguridad: acceso con la identidad corporativa, registro de actividad, etiquetas de confidencialidad y qué ve la herramienta (Copilot ve lo que el usuario puede abrir: un SharePoint con permisos de más es un problema antes de Copilot y más visible después).
5. Aprobación, alta en el registro y formación de los usuarios antes de dar licencias.

7. El caso: un empleado ha pegado datos de clientes en una herramienta de IA no aprobada

Un analista ha pegado una exportación con nombres, correos y saldos de 300 clientes en un chatbot público con su cuenta personal para "ordenar la tabla". Lo detecta la alerta de DLP del navegador o lo cuenta él mismo.

1. Contener: que deje de usarla, borre la conversación y, si la herramienta lo permite, desactive el uso de sus conversaciones para entrenar. Guarda capturas como evidencia antes de borrar.
2. Evaluar qué datos han salido: hay datos personales de clientes, así que se avisa al DPO de inmediato. El DPO decide si es una violación de seguridad que hay que notificar a la AEPD en un máximo de 72 horas desde que se tiene conocimiento (artículo 33 del RGPD). Se notifique o no, queda en el registro de violaciones de seguridad.
3. Revisar las condiciones de la herramienta: dónde guarda los datos, durante cuánto tiempo y si los usa para entrenar. Eso cambia la valoración del riesgo.
4. Bloquear: en Defender for Cloud Apps, marcar la aplicación como no autorizada (Unsanctioned); con la integración con Defender for Endpoint, el acceso queda bloqueado en los equipos gestionados. Lo mismo en el proxy si lo usas.
5. Dar la alternativa: si la necesidad es real, una herramienta aprobada con la cuenta corporativa (Copilot con protección de datos empresariales, por ejemplo). Prohibir sin ofrecer nada aumenta el uso escondido.
6. Cerrar: formación para la persona y su equipo, una línea en el registro de casos de uso si la necesidad se aprueba, y revisar qué otras herramientas de IA salen en los registros.

Lo que falla en este caso es la protección de datos y la confidencialidad, no el AI Act. Por eso la respuesta va por el proceso de incidentes de seguridad y el DPO, no por un comité de IA aparte.

Siguientes pasos

• La guía de ISO 27001, NIS2 y RGPD en IT cubre la gestión de incidentes de seguridad y las notificaciones en las que se apoya el último apartado.
• La guía de Microsoft Purview explica las etiquetas de confidencialidad y la DLP que limitan lo que Copilot puede ver y lo que sale de la empresa.
• El repositorio 25-security-controls-evidence de mi GitHub reúne en un registro la evidencia de controles que pide una auditoría; el registro de casos de uso de IA y la formación encajan como una línea más.

¿Falta algo o en tu entorno es distinto? Escríbeme y lo corrijo.