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.
| Categoría | Qué es | Ejemplos | Qué implica |
|---|---|---|---|
| Prohibido | Prácticas no permitidas en la UE (artículo 5) | Puntuación social, manipulación que causa daño, reconocimiento de emociones en el trabajo o en la educación salvo por motivos médicos o de seguridad, recopilación indiscriminada de imágenes faciales | No se usa. Si aparece, se para |
| Alto riesgo | Sistemas del anexo III o componentes de seguridad de productos regulados (anexo I) | Cribado de CV y decisiones sobre empleados, evaluación de solvencia de personas físicas, precios de seguros de vida y salud | Obligaciones fuertes para el proveedor y para quien lo despliega |
| Riesgo limitado (transparencia) | Sistemas que interactúan con personas o generan contenido | Chatbots, contenido generado o manipulado (deepfakes) | Avisar a las personas |
| Riesgo mínimo | El resto | Filtros de spam, resúmenes de reuniones, asistentes de código | Sin obligaciones específicas más allá de la alfabetización |
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
| Fecha | Qué empieza a aplicar |
|---|---|
| 1 de agosto de 2024 | Entrada en vigor del reglamento |
| 2 de febrero de 2025 | Prácticas prohibidas y alfabetización en IA |
| 2 de agosto de 2025 | Obligaciones de los modelos de propósito general (GPAI) y régimen de gobernanza y sanciones |
| 2 de agosto de 2026 | Aplicación general, incluida la transparencia del artículo 50 |
| 2 de diciembre de 2027 | Alto riesgo del anexo III (empleo, solvencia, servicios esenciales…) |
| 2 de agosto de 2028 | Alto riesgo del anexo I (IA en productos regulados) |
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):
| Campo | Ejemplo |
|---|---|
| Caso de uso | Resumen de reuniones de Teams con Copilot |
| Herramienta y proveedor | Microsoft 365 Copilot · Microsoft |
| Dueño de negocio | Dirección de operaciones |
| Rol de la empresa | Responsable del despliegue |
| Datos que trata | Transcripciones internas; puede incluir datos personales |
| Categoría de riesgo | Mínimo |
| EIPD necesaria | Revisada por el DPO: cubierta por la de Microsoft 365 |
| Controles | Etiquetas de confidencialidad de Purview, licencias por grupo, formación hecha |
| Aprobado por / fecha | Comité de IA · 2026-09-15 · revisión anual |
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:
- Solicitud con la finalidad, los datos y quién lo va a usar.
- Clasificación de riesgo con legal. Si cae en prohibido, se para aquí.
- 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.
- 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).
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
What you'll get
Knowing which part of Regulation (EU) 2024/1689, the AI Act, affects your organisation when it doesn't build AI models but uses them every day: Copilot in Microsoft 365, a chatbot on the website, an HR screening tool, a coding assistant. And setting up the minimum IT needs to have: a use-case register, an approval flow and an answer for when someone uses a tool nobody has approved.
This guide is a practical map for IT, not legal advice: classification decisions are made with legal and the data protection officer (DPO).
Before you start
- A sponsor in management and a small group with legal, DPO, security, HR and IT. AI comes in through every department, not just IT.
- The inventory of what is already in use: Copilot licences, AI features switched on in the SaaS you already have (CRM, ITSM, HR), in-house builds on model APIs, and what people use without asking (the proxy or Defender for Cloud Apps logs show it).
- IT's acceptable use policy, to add the AI part to it rather than create another one.
1. The four risk categories
The regulation doesn't regulate "AI" as a whole: it regulates uses, according to risk.
| Category | What it is | Examples | What it implies |
|---|---|---|---|
| Prohibited | Practices not allowed in the EU (Article 5) | Social scoring, manipulation that causes harm, emotion recognition at work or in education except for medical or safety reasons, untargeted scraping of facial images | Not used. If it shows up, it stops |
| High risk | Annex III systems or safety components of regulated products (Annex I) | CV screening and decisions about employees, creditworthiness of natural persons, life and health insurance pricing | Heavy obligations for the provider and for whoever deploys it |
| Limited risk (transparency) | Systems that interact with people or generate content | Chatbots, generated or manipulated content (deepfakes) | Tell people |
| Minimal risk | Everything else | Spam filters, meeting summaries, coding assistants | No specific obligations beyond AI literacy |
In a typical company, almost everything falls into minimal or limited. What needs watching is HR and customer assessment uses: that is where high risk lives, even if a third party sells the tool.
2. Provider or deployer
- Provider: whoever develops an AI system and places it on the market or puts it into service under their own name. Microsoft, for Copilot.
- Deployer: whoever uses an AI system under their authority in a professional activity. Your company, when it switches on Copilot.
- Watch out for in-house builds: if your team builds a customer chatbot on a model's API and publishes it under your brand, you are the provider of that system, with the provider's transparency obligations.
- If you substantially modify a high-risk system, or change its purpose so that it becomes one, you take on the provider's obligations.
3. What applies to a company using Copilot or a chatbot
AI literacy (Article 4), applicable since 2 February 2025. After the Digital Omnibus, the obligation is to take measures to support the AI literacy of staff and of those using the systems on the company's behalf, without requiring a specific level from each person. In practice:
- A short training per profile: what the tool can and can't do, hallucinations, which data doesn't go in and how to review what it produces.
- Deeper training for those who configure or approve use cases.
- A record of who has completed it: that is what you will be able to show.
Transparency (Article 50), applicable since 2 August 2026:
- A chatbot talking to customers must make clear it is an AI, unless that is obvious.
- If you publish generated or manipulated images, audio or video that look real, it has to be disclosed.
- If you use emotion recognition or biometric categorisation (in the permitted cases), the people exposed must be informed.
If a use case is high risk, the deployer must, among other things, use it according to the provider's instructions, assign human oversight to people with training and authority, monitor its operation, keep the logs it generates for at least six months and inform workers' representatives before using it in the workplace.
4. The timeline
| Date | What starts to apply |
|---|---|
| 1 August 2024 | The regulation enters into force |
| 2 February 2025 | Prohibited practices and AI literacy |
| 2 August 2025 | Obligations for general-purpose AI models (GPAI) and the governance and penalties regime |
| 2 August 2026 | General application, including Article 50 transparency |
| 2 December 2027 | Annex III high risk (employment, creditworthiness, essential services…) |
| 2 August 2028 | Annex I high risk (AI in regulated products) |
The last two dates come from the Digital Omnibus on AI, Regulation (EU) 2026/1744, published in July 2026, which delayed high risk (previously 2 August 2026 and 2027), softened the wording of AI literacy and added new prohibitions on non-consensual intimate imagery and child sexual abuse material from 2 December 2026. The high-risk obligations are the same: only the date has moved.
In Spain, the supervisory authority is AESIA (the Spanish Agency for the Supervision of Artificial Intelligence). General-purpose model obligations fall on their providers, not on whoever uses Copilot.
5. The use-case register
A table in the GRC tool, in SharePoint or in the CMDB, with one row per use case (not per tool: Copilot to summarise meetings and Copilot to assess candidates are two different cases):
| Field | Example |
|---|---|
| Use case | Teams meeting summaries with Copilot |
| Tool and provider | Microsoft 365 Copilot · Microsoft |
| Business owner | Head of operations |
| Company's role | Deployer |
| Data processed | Internal transcripts; may include personal data |
| Risk category | Minimal |
| DPIA needed | Reviewed by the DPO: covered by the Microsoft 365 one |
| Controls | Purview sensitivity labels, licences by group, training completed |
| Approved by / date | AI committee · 2026-09-15 · annual review |
What gets reviewed every quarter: new cases, changes of purpose, tools that added AI on their own in an update, and cases no longer in use.
6. Approval and its link with GDPR
A simple flow for each new use case:
- Request with the purpose, the data and who will use it.
- Risk classification with legal. If it falls under prohibited, it stops here.
- Data protection: if it processes personal data, the DPO decides whether a data protection impact assessment (DPIA) is needed under Article 35 of the GDPR. For a high-risk system, the information the provider supplies is used to carry it out. Also review the contract: where the data is processed, whether it is used for training and how long it is kept.
- Security: access with the corporate identity, activity logging, sensitivity labels and what the tool can see (Copilot sees what the user can open: a SharePoint site with excessive permissions is a problem before Copilot and a more visible one after).
- Approval, entry in the register and user training before licences are assigned.
7. The case: an employee has pasted customer data into an unapproved AI tool
An analyst has pasted an export with names, emails and balances of 300 customers into a public chatbot with a personal account to "sort the table". The browser DLP alert catches it, or they report it themselves.
- Contain: they stop using it, delete the conversation and, if the tool allows it, switch off the use of their conversations for training. Keep screenshots as evidence before deleting.
- Assess what data has left: there is customer personal data, so the DPO is told immediately. The DPO decides whether it is a personal data breach to be notified to the supervisory authority (the AEPD in Spain) within 72 hours of becoming aware (Article 33 of the GDPR). Whether notified or not, it goes in the breach register.
- Review the tool's terms: where it stores data, for how long and whether it uses it for training. That changes the risk assessment.
- Block: in Defender for Cloud Apps, mark the app as Unsanctioned; with the Defender for Endpoint integration, access is blocked on managed devices. The same in the proxy if you use one.
- Offer the alternative: if the need is real, an approved tool with the corporate account (Copilot with enterprise data protection, for example). Banning without offering anything increases hidden use.
- Close: training for the person and their team, a line in the use-case register if the need is approved, and a check on which other AI tools show up in the logs.
What fails in this case is data protection and confidentiality, not the AI Act. That is why the response goes through the security incident process and the DPO, not through a separate AI committee.
Next steps
- The ISO 27001, NIS2 and GDPR in IT guide covers security incident management and the notifications the last section relies on.
- The Microsoft Purview guide explains the sensitivity labels and DLP that limit what Copilot can see and what leaves the company.
- The 25-security-controls-evidence repository on my GitHub brings the control evidence an audit asks for into one register; the AI use-case register and the training fit in as one more line.
Is something missing, or different in your environment? Get in touch and I'll fix it.
Tech Career Lab · newsletter
¿Te ha servido? Cada dos semanas envío una idea práctica para perfiles IT: LinkedIn, proyectos, networking y procesos de selección.Found this useful? Every two weeks I send one practical idea for IT professionals: LinkedIn, projects, networking and hiring processes.
Apúntate y llévate las 33 ideasSign up and get the 33 ideas →