Cada pocos meses circula la misma pregunta en los equipos que han metido un modelo de lenguaje en producción: ¿nos afecta ya el Reglamento europeo de IA, o todavía nos queda tiempo? La respuesta correcta depende de qué parte del Reglamento preguntes, y ha cambiado dos veces en los últimos dos años: primero con el calendario original de 2024, después con una reforma publicada el 24 de julio de 2026 que aplaza algunas fechas, adelanta otras y reescribe el propio artículo sobre alfabetización en materia de IA. Un equipo que cita de memoria una fecha que aprendió hace un año tiene bastantes números de estar citando una fecha que ya no es la vigente.
Este módulo cierra el curso con lo que un desarrollador o un arquitecto necesita saber de verdad sobre el marco legal: qué aplica hoy, qué se ha aplazado y hasta cuándo, qué exige literalmente el artículo sobre alfabetización en IA, en qué categoría de riesgo cae la aplicación corporativa típica con un modelo de lenguaje, y qué documentación puedes exigirle a tu proveedor de modelo sin necesidad de leerte el Reglamento entero. Termina con el ejercicio que cierra el curso completo: el modelo de amenazas de una aplicación con recuperación de contexto y agentes, con los diez riesgos del Top 10 de OWASP, sus controles y quién es responsable de cada uno.
Qué aprenderás
- El calendario real de aplicación del Reglamento (UE) 2024/1689 tras la reforma del Reglamento (UE) 2026/1744, con las fechas que ya rigen y las que se han aplazado, verificadas contra el texto de EUR-Lex.
- Qué obliga literalmente el artículo 4 sobre alfabetización en materia de IA, a quién y desde cuándo, incluido el cambio de redacción que entró en vigor el 27 de julio de 2026.
- Cómo se clasifica una aplicación de IA en las cuatro categorías de riesgo del Reglamento, y por qué una aplicación corporativa típica con un modelo de lenguaje casi nunca cae en alto riesgo.
- Qué exige el artículo 50 sobre informar al usuario y marcar contenido generado, con sus fechas reales de aplicación y la excepción para contenido con revisión humana.
- Qué obligaciones tienen los proveedores de modelos de uso general y qué documentación puedes exigirles antes de integrar su modelo en tu aplicación.
- Cómo se articula el Reglamento con el RGPD cuando tu aplicación trata datos personales: evaluación de impacto, base legal y decisiones automatizadas.
- Para qué sirve certificarse en ISO/IEC 42001 y qué no resuelve esa certificación por sí sola.
- Cómo montar un gobierno interno mínimo viable: inventario de sistemas, política de uso, responsable, proceso de aprobación de casos de uso y registro de decisiones.
- A construir el modelo de amenazas completo de una aplicación con RAG y agentes, cruzando los diez riesgos del Top 10 de OWASP con sus controles y una matriz de responsabilidad.
El calendario real del Reglamento (UE) 2024/1689
El Reglamento (UE) 2024/1689, la Ley de IA, se publicó en el Diario Oficial el 12 de julio de 2024 y entró en vigor el 1 de agosto de 2024, a los veinte días de su publicación. Pero entrar en vigor no significa que todas sus obligaciones fueran exigibles ese mismo día: el propio Reglamento, en su artículo 113, escalona la aplicación de sus distintos capítulos en varias fechas distintas repartidas entre 2025 y 2027. Ese escalonamiento es precisamente lo que ha cambiado con la reforma de 2026, así que conviene separar con cuidado qué fecha corresponde a qué bloque de obligaciones.
El 8 de julio de 2026 el Parlamento Europeo y el Consejo adoptaron el Reglamento (UE) 2026/1744, conocido como el «Digital Omnibus on AI», que modifica el propio Reglamento (UE) 2024/1689 y, a la vez, otros dos reglamentos sectoriales (aviación civil y maquinaria). Se publicó en el Diario Oficial el 24 de julio de 2026 y, según su artículo 4, entró en vigor y resultó directamente aplicable el 27 de julio de 2026, a los tres días de su publicación. Los considerandos de la propia reforma explican el motivo con una franqueza poco habitual en un texto legal: la preparación de las normas técnicas armonizadas y el establecimiento de los marcos de gobernanza y evaluación de la conformidad a nivel nacional se habían retrasado, y eso había generado una carga de cumplimiento más pesada de lo previsto para quienes tenían que aplicar el capítulo de alto riesgo en las fechas originales.
Con las dos normas leídas juntas, este es el calendario que rige hoy, ordenado por fecha:
| Bloque de obligaciones | Referencia | Fecha de aplicación | Situación |
|---|---|---|---|
| Disposiciones generales y prácticas prohibidas (capítulos I y II) | Artículos 1 a 5 | 2 de febrero de 2025 | Aplicable |
| Gobernanza a nivel de la Unión, sanciones, obligaciones de modelos de uso general y disposiciones finales (capítulo III sección 4, capítulos V, VII y XII, artículo 78) | Sin cambios en la reforma | 2 de agosto de 2025 | Aplicable |
| Infraestructura de evaluación de la conformidad (organismos notificados) | Artículos 102 a 110, añadido por la reforma de 2026 | 27 de julio de 2026 | Aplicable |
| Aplicación general del Reglamento, incluidas las obligaciones de transparencia del artículo 50 | Sin cambios en la reforma | 2 de agosto de 2026 | Aplicable |
| Dos prácticas prohibidas nuevas, añadidas por la reforma: desnudos sintéticos sin consentimiento y material dentro del artículo 2 de la Directiva 2011/93/UE | Artículo 5(1), letras b bis) y b ter), añadidas por la reforma de 2026 | 2 de diciembre de 2026 | Aplicable a partir de esa fecha |
| Periodo transitorio para marcar contenido sintético de sistemas ya comercializados antes del 2 de agosto de 2026 | Artículo 111(4), añadido por la reforma de 2026 | 2 de diciembre de 2026 | Plazo límite |
| Alto riesgo «independiente»: sistemas del anexo III (biometría, empleo, educación, servicios públicos y privados regulados, aplicación de la ley, migración, justicia) | Artículo 6(2) y anexo III; fecha reemplazada por la reforma (antes 2 de agosto de 2026) | 2 de diciembre de 2027 | Aplazado |
| Alto riesgo insertado como componente de seguridad de un producto regulado (anexo I) | Artículo 6(1) y anexo I; fecha reemplazada por la reforma (antes 2 de agosto de 2027) | 2 de agosto de 2028 | Aplazado |
| Sistemas de alto riesgo ya en uso por autoridades públicas: plazo límite para adaptarse | Artículo 111(2), reescrito por la reforma de 2026 | 2 de agosto de 2030 | Plazo límite |
Tres lecturas de esta tabla que conviene no pasar por alto. La primera es que la aplicación general del Reglamento, la que cubre entre otras cosas las obligaciones de transparencia del artículo 50 y la vigilancia poscomercialización, no se ha movido: sigue en 2 de agosto de 2026, tal como decía el texto de 2024. Lo que se ha aplazado es específicamente el capítulo de requisitos para sistemas de alto riesgo, y con dos fechas distintas según si el sistema entra por el anexo III o por el anexo I. La segunda es que el aplazamiento del anexo III son dieciséis meses (de agosto de 2026 a diciembre de 2027) y el del anexo I es exactamente doce meses (de agosto de 2027 a agosto de 2028); si ves citada una cifra distinta de meses de aplazamiento en algún resumen de terceros, vuelve a contarla tú con las dos fechas de esta tabla, porque varias fuentes que circulan mezclan ambos plazos. La tercera es que la reforma no toca ni una coma de las prácticas prohibidas que ya llevan aplicándose desde febrero de 2025: solo añade dos prácticas nuevas, con su propia fecha de aplicación separada.
Sobre esas dos prácticas nuevas: el Reglamento original ya prohibía, entre otras cosas, la manipulación subliminal, la explotación de vulnerabilidades y el scoring social. La reforma de 2026 añade la generación o manipulación, sin el consentimiento libre, específico, informado e inequívoco de la persona, de imágenes, vídeos o audios realistas de las partes íntimas de una persona identificable o de una persona identificable en una actividad sexualmente explícita, y la generación de material dentro del ámbito del artículo 2 de la Directiva 2011/93/UE sobre explotación sexual de menores. Ambas entran en vigor legal el 27 de julio de 2026, pero su fecha de aplicación como prohibición exigible es el 2 de diciembre de 2026, no antes.
El artículo 4: alfabetización en materia de IA
El artículo 4 lleva aplicándose desde el 2 de febrero de 2025, dentro del capítulo I. Lo que cambió no fue esa fecha, sino el propio texto del artículo, sustituido por la reforma con aplicación directa desde el 27 de julio de 2026. Antes de esa fecha, el artículo decía esto, en su traducción oficial al español:
Los proveedores y responsables del despliegue de sistemas de IA adoptarán medidas para garantizar que, en la mayor medida posible, su personal y demás personas que se encarguen en su nombre del funcionamiento y la utilización de sistemas de IA tengan un nivel suficiente de alfabetización en materia de IA, teniendo en cuenta sus conocimientos técnicos, su experiencia, su educación y su formación, así como el contexto previsto de uso de los sistemas de IA y las personas o los colectivos de personas en que se van a utilizar dichos sistemas.
Desde el 27 de julio de 2026, el artículo 4 dice esto:
1. Los proveedores y responsables del despliegue de sistemas de IA adoptarán medidas para apoyar la promoción de la alfabetización en materia de IA de su personal y demás personas que se encarguen en su nombre del funcionamiento y la utilización de sistemas de IA, teniendo en cuenta sus conocimientos técnicos, su experiencia, su educación y su formación, así como el contexto previsto de uso de los sistemas de IA y las personas o los colectivos de personas en que se van a utilizar dichos sistemas. Esta obligación no exige que los proveedores o los responsables del despliegue garanticen un nivel específico de alfabetización en materia de IA de ninguna persona en particular.
2. La Comisión y los Estados miembros apoyarán y facilitarán los esfuerzos de los proveedores y responsables del despliegue de sistemas de IA, en particular de las pymes, en el cumplimiento de su obligación en virtud del apartado 1 del presente artículo. A tal fin, la Comisión publicará ejemplos prácticos de cómo cumplir dicha obligación en la plataforma única de información a que se refiere el artículo 62, apartado 3, letra b).
3. El Consejo de IA adoptará recomendaciones, teniendo en cuenta los marcos europeos de competencias, con vistas a apoyar a la Comisión y a los Estados miembros en la promoción de la alfabetización en materia de IA exigida en virtud del apartado 1, incluido mediante el establecimiento de objetivos comunes.
La diferencia entre «garantizar… un nivel suficiente» y «adoptar medidas para apoyar la promoción» no es cosmética. El texto original imponía una obligación de resultado difícil de auditar: ¿cómo demuestra una empresa que su personal alcanzó un «nivel suficiente» de alfabetización, y quién lo mide? El texto vigente convierte eso en una obligación de medios, y añade una frase que evita explícitamente la lectura más agresiva: no hace falta certificar el nivel de ningún individuo. En la práctica, para un equipo que usa modelos de lenguaje en producción, cumplir el artículo 4 hoy significa tres cosas concretas y demostrables: que exista formación o documentación accesible sobre qué hace y qué no hace el sistema con el que trabajan (no un curso genérico de «qué es la IA»), que esa formación tenga en cuenta el puesto de cada persona (no es lo mismo quien revisa las respuestas del modelo que quien solo las consume), y que quede constancia de que la medida se adoptó, aunque sea un registro simple de quién recibió qué formación y cuándo. Nada de esto exige un examen ni una certificación individual, y el propio artículo lo dice ahora de forma explícita.
Quien construya la formación no tiene que partir de cero: el apartado 2 obliga a la Comisión a publicar ejemplos prácticos de cumplimiento en la plataforma única de información, y el apartado 3 obliga al Consejo de IA a adoptar recomendaciones con objetivos comunes. Comprueba en el sitio de la Oficina de IA qué hay publicado en el momento en que leas esto: es contenido que se actualiza con el tiempo, y una cifra o un enlace concreto que diera aquí podría quedar obsoleto antes de que termines el módulo.
La clasificación por riesgo
El Reglamento organiza sus obligaciones en cuatro niveles de riesgo, y entender en cuál cae tu aplicación es lo primero que hay que resolver antes de diseñar cualquier control de cumplimiento.
| Nivel | Qué incluye | Ejemplo típico | Obligación principal |
|---|---|---|---|
| Riesgo inaceptable (prohibido) | Manipulación subliminal, explotación de vulnerabilidades, scoring social, biometría remota en tiempo real en espacios públicos para aplicación de la ley (con excepciones tasadas), deepfakes sexuales sin consentimiento | No aplica a desarrollo corporativo legítimo | No se puede comercializar ni usar |
| Alto riesgo | Sistemas del anexo III que no caen en la excepción del artículo 6(3), y sistemas del anexo I insertados en un producto regulado | Cribado automático de currículums, scoring de crédito, sistema de admisión educativa | Gestión de riesgos, documentación técnica, supervisión humana, registro en la base de datos de la UE |
| Riesgo de transparencia | Sistemas que interactúan con personas o generan contenido sintético, sin ser de alto riesgo | Chatbot de atención al cliente, generador de imágenes, asistente de redacción | Informar al usuario y marcar el contenido generado (artículo 50) |
| Riesgo mínimo | Todo lo demás | Copiloto interno de código, asistente de resumen de documentos internos sin exposición al público | Ninguna obligación específica más allá del artículo 4 y los códigos de conducta voluntarios |
El punto donde más equipos se equivocan, en los dos sentidos posibles, es la frontera entre alto riesgo y los niveles inferiores. El artículo 6, apartado 2, dice que los sistemas listados en el anexo III se consideran de alto riesgo, y ese anexo cubre ocho áreas: biometría, infraestructura crítica, educación y formación profesional, empleo y gestión de trabajadores, acceso a prestaciones y servicios públicos y privados, aplicación de la ley, migración y control fronterizo, y administración de justicia y procesos democráticos. Hasta aquí, es fácil asustarse: si tu aplicación toca recursos humanos o créditos, parece que ya estás dentro. Pero el apartado 3 del mismo artículo introduce una excepción que reduce mucho ese temor inicial: un sistema del anexo III no se considera de alto riesgo si no supone un riesgo significativo de daño a la salud, la seguridad o los derechos fundamentales, y esa condición se cumple cuando el sistema realiza una tarea procedimental limitada, mejora el resultado de una actividad humana ya completada, detecta patrones de decisión sin sustituir ni influir en la evaluación humana previa sin revisión adecuada, o realiza una tarea preparatoria a una evaluación relevante para los casos de uso del anexo III. Con una excepción a esa excepción que conviene memorizar: un sistema del anexo III siempre se considera de alto riesgo si hace perfilado de personas físicas, sin importar cuál de esas cuatro condiciones cumpla.
Aplicado a un caso real: un asistente que ayuda a un reclutador a redactar preguntas de entrevista o a resumir un currículum para que lo lea un humano cae, casi siempre, en alguna de esas cuatro condiciones de excepción, porque mejora un trabajo humano sin sustituir la decisión. Un sistema que puntúa automáticamente a los candidatos y descarta a los que quedan por debajo de un umbral, sin que nadie revise los descartados, hace perfilado de personas y es de alto riesgo sin excepción posible. La línea no la marca el sector (recursos humanos) ni la tecnología (un modelo de lenguaje), la marca si el sistema sustituye o condiciona de forma relevante una decisión sobre una persona sin supervisión humana real. El artículo 6, apartado 4, exige también que quien decida que su sistema no es de alto riesgo documente esa evaluación antes de comercializarlo, y que la entregue a la autoridad competente si se la pide, así que la conclusión de «esto no es de alto riesgo» no puede quedar solo en la cabeza de quien la tomó.
Esta es también la razón por la que, tal como decía el módulo 2 de este curso, mucha gente se asusta de más con este Reglamento: asocia «modelo de lenguaje en producción» con «alto riesgo» de forma automática, cuando la inmensa mayoría de aplicaciones corporativas con modelos (asistentes internos, buscadores semánticos, herramientas de redacción, copilotos de código) caen en riesgo mínimo o, como mucho, en la obligación de transparencia del artículo 50 si generan contenido que ve un usuario externo.
Las obligaciones de transparencia del artículo 50
El artículo 50 es, en la práctica, el que más aplicaciones corporativas con modelos de lenguaje van a tener que cumplir de verdad, porque no hace falta ser de alto riesgo para estar dentro de su alcance. Se aplica desde el 2 de agosto de 2026 y la reforma de 2026 no ha tocado su contenido sustantivo, solo el procedimiento interno por el que la Comisión aprueba los códigos de prácticas del apartado 7, sin relevancia para quien construye la aplicación. Estos son sus apartados 1, 2 y 4, en la traducción oficial:
1. Los proveedores garantizarán que los sistemas de IA destinados a interactuar directamente con personas físicas se diseñen y desarrollen de forma que las personas físicas de que se trate estén informadas de que están interactuando con un sistema de IA, excepto cuando resulte evidente desde el punto de vista de una persona física razonablemente informada, atenta y perspicaz, teniendo en cuenta las circunstancias y el contexto de utilización.
2. Los proveedores de sistemas de IA, entre los que se incluyen los sistemas de IA de uso general, que generen contenido sintético de audio, imagen, vídeo o texto, velarán por que los resultados de salida del sistema de IA estén marcados en un formato legible por máquina y que sea posible detectar que han sido generados o manipulados de manera artificial.
4. Los responsables del despliegue de un sistema de IA que genere o manipule imágenes o contenidos de audio o vídeo que constituyan una ultrasuplantación harán público que estos contenidos o imágenes han sido generados o manipulados de manera artificial. […] Los responsables del despliegue de un sistema de IA que genere o manipule texto que se publique con el fin de informar al público sobre asuntos de interés público divulgarán que el texto se ha generado o manipulado de manera artificial. Esta obligación no se aplicará […] cuando el contenido generado por IA haya sido sometido a un proceso de revisión humana o de control editorial y cuando una persona física o jurídica tenga la responsabilidad editorial por la publicación del contenido.
Tres obligaciones distintas conviene no confundir entre sí. La primera, del apartado 1, es informar de que se está hablando con una IA: aplica al proveedor del sistema conversacional y tiene una excepción amplia cuando ya es obvio para una persona razonable (un chatbot con nombre de robot en la esquina de la pantalla probablemente cumple esta parte sin esfuerzo adicional). La segunda, del apartado 2, es marcar técnicamente el contenido sintético en un formato legible por máquina, lo que en la práctica significa metadatos embebidos o watermarking, no solo un aviso visible al usuario. La tercera, del apartado 4, es distinta de las dos anteriores porque recae sobre el responsable del despliegue, no sobre el proveedor, y tiene la excepción que más eximirá a medios y equipos editoriales: si el contenido generado por IA pasó por revisión humana y alguien asume la responsabilidad editorial de publicarlo, no hace falta divulgar que se generó con IA. Esa excepción no cubre el marcado técnico del apartado 2, solo la divulgación pública del apartado 4.
Sobre las fechas: la obligación general del artículo 50 aplica desde el 2 de agosto de 2026 para cualquier sistema nuevo que se comercialice a partir de esa fecha. Pero la reforma de 2026 añadió un apartado 4 al artículo 111 que da un margen a quien ya tenía un sistema generador de contenido sintético en el mercado antes de esa fecha: esos proveedores tienen hasta el 2 de diciembre de 2026 para adaptar sus sistemas al marcado técnico del apartado 2. Es un periodo transitorio de cuatro meses, no una exención permanente, y solo cubre sistemas que ya estaban comercializados antes del 2 de agosto de 2026.
Modelos de uso general: qué exigir a tu proveedor
El capítulo V del Reglamento, el que regula los modelos de IA de uso general, lleva aplicándose desde el 2 de agosto de 2025 y la reforma de 2026 no ha cambiado esa fecha. Si tu aplicación construye sobre un modelo de este tipo (y casi todas lo hacen, tanto si el modelo es propio como si se consume por API), las obligaciones legales recaen sobre el proveedor del modelo, no sobre ti como desarrollador de la aplicación. Pero eso no significa que el tema no te concierna: tu aplicación hereda parte del riesgo de cumplimiento de su proveedor, y la documentación que ese proveedor está obligado a producir es exactamente la que necesitas para tus propias obligaciones de gestión de riesgos.
El artículo 53 obliga a todo proveedor de un modelo de uso general a mantener documentación técnica actualizada sobre el proceso de entrenamiento y evaluación del modelo, a poner a disposición de quien integre el modelo información suficiente para entender sus capacidades y limitaciones y cumplir sus propias obligaciones, a tener una política de cumplimiento del derecho de autor de la Unión (incluida la identificación de reservas de derechos expresadas conforme al artículo 4, apartado 3, de la Directiva (UE) 2019/790), y a publicar un resumen suficientemente detallado del contenido usado para entrenar el modelo, según una plantilla de la Oficina de IA. Los modelos publicados bajo una licencia libre y de código abierto, con pesos y arquitectura disponibles públicamente, quedan exentos de las dos primeras obligaciones, pero no de la política de derechos de autor ni del resumen de entrenamiento, y la exención completa desaparece si el modelo se clasifica con riesgo sistémico.
Esa clasificación de riesgo sistémico, definida en el artículo 51, se basa sobre todo en la potencia de cómputo usada en el entrenamiento: un modelo se presume de alto impacto cuando el cómputo acumulado supera 10^25 operaciones de coma flotante, aunque la Comisión puede clasificar un modelo como de riesgo sistémico por otros criterios sin llegar a ese umbral. Los proveedores de modelos con riesgo sistémico suman, a las obligaciones del artículo 53, las del artículo 55: evaluar el modelo con protocolos estandarizados, incluidas pruebas adversariales documentadas, evaluar y mitigar riesgos sistémicos a escala de la Unión, notificar sin demora indebida los incidentes graves a la Oficina de IA, y garantizar un nivel adecuado de ciberseguridad tanto del modelo como de su infraestructura física.
Lo que esto significa para ti como desarrollador de aplicación es una lista concreta de qué pedir antes de integrar un modelo de uso general en producción: la información del artículo 53(1)(b) sobre capacidades y limitaciones (necesaria para tu propia evaluación de riesgos), la política de derechos de autor (relevante si tu aplicación genera contenido que se publica), y, si trabajas en un sector regulado, comprobar si el proveedor adhiere a algún código de prácticas aprobado como forma de demostrar cumplimiento. Si un proveedor se niega a compartir esa documentación mínima, o no puedes localizarla en ningún sitio público, eso es una señal de cadena de suministro poco transparente que el módulo 7 de este curso ya trató desde el ángulo técnico y que aquí tiene también una base legal concreta para reclamarla.
Cómo se articula con el RGPD
El Reglamento de IA no sustituye al RGPD, lo complementa, y el propio texto lo deja explícito: sin perjuicio de los artículos 4 bis y 59, no afecta a los Reglamentos (UE) 2016/679 ni (UE) 2018/1725 ni a la Directiva (UE) 2016/680. Si tu aplicación con modelo de lenguaje procesa datos personales (y una aplicación con RAG sobre documentos internos casi siempre lo hace, aunque sea de forma indirecta a través del contexto recuperado), sigues necesitando una base legal para ese tratamiento igual que la necesitarías sin ningún modelo de por medio: el Reglamento de IA no crea una base legal nueva ni sustituye la que ya exige el artículo 6 del RGPD.
Donde los dos marcos se cruzan de forma más directa es en la evaluación de impacto. El artículo 26, apartado 9, del Reglamento de IA dice que el responsable del despliegue de un sistema de alto riesgo usará la información que le proporcionó el proveedor según el artículo 13 para cumplir su obligación de realizar una evaluación de impacto relativa a la protección de datos conforme al artículo 35 del RGPD. No son dos evaluaciones separadas que haya que hacer por duplicado: la documentación técnica que exige el Reglamento de IA alimenta directamente la evaluación de impacto que ya exige el RGPD cuando el tratamiento entraña alto riesgo para los derechos de las personas. Y si tu sistema de alto riesgo toma decisiones automatizadas con efectos jurídicos o significativos sobre una persona sin intervención humana significativa, entra también en el ámbito del artículo 22 del RGPD, con sus propias garantías (derecho a intervención humana, a expresar el punto de vista, a impugnar la decisión) que el Reglamento de IA no sustituye. El desarrollo completo de evaluaciones de impacto, bases legales y decisiones automatizadas, más allá de este cruce específico con la IA, lo tiene el curso de GRC de este mismo sitio.
ISO/IEC 42001: para qué sirve certificarse
El módulo 2 de este curso ya presentó ISO/IEC 42001 como uno de los marcos de referencia, con su estructura de cláusulas 4 a 10 heredada de otras normas de sistemas de gestión de ISO. Aquí solo hace falta añadir la pieza que le falta a ese repaso inicial: para qué sirve certificarse, ahora que ya conoces el calendario legal completo del Reglamento de IA. La certificación en ISO/IEC 42001 no es un requisito legal en ningún punto del Reglamento europeo de IA: es una decisión comercial, normalmente motivada por una exigencia contractual de un cliente grande o por un pliego de contratación pública que la pide como criterio de solvencia. Certificarse demuestra ante un auditor externo que existe un sistema de gestión de IA con procesos documentados, revisados y mejorados de forma continua, no que una aplicación concreta esté libre de los riesgos del Top 10 de OWASP ni que cumpla automáticamente el Reglamento de IA. Son dos cosas relacionadas pero distintas: puedes tener la certificación y seguir teniendo una aplicación mal diseñada frente a inyección de prompt, y puedes cumplir el Reglamento de IA al pie de la letra sin tener ni falta certificación alguna. Como la norma es de pago, este módulo no entra en el contenido de sus controles, solo en para qué sirve el papel que obtienes al final del proceso.
Gobierno interno realista
La parte del cumplimiento que de verdad depende de tu organización, y no de lo que diga Bruselas, es el gobierno interno: los procesos que hacen posible saber, en cualquier momento, qué sistemas de IA existen, quién los aprobó y bajo qué criterio. Cuatro piezas mínimas, en orden de dependencia.
La primera es un inventario de sistemas de IA, sin el cual ninguna de las otras piezas funciona: no puedes evaluar el riesgo de algo que no sabes que existe. Un registro mínimo por sistema necesita al menos estos campos:
sistema: asistente-soporte-nivel1
proveedor_modelo: [proveedor y modelo, por contrato]
responsable_negocio: [equipo o persona propietaria del caso de uso]
datos_personales: si
base_legal_rgpd: interes_legitimo
clasificacion_riesgo_ia_act: transparencia
justificacion_clasificacion: >
Interactua con clientes; no hace perfilado ni decision automatizada
con efectos juridicos; entra en el articulo 50, no en el anexo III.
fecha_evaluacion: 2026-07-15
proxima_revision: 2027-01-15
estado: produccionLa segunda es una política de uso aceptable, un documento corto que responda a lo que de verdad pregunta un empleado: qué herramientas de IA puede usar, con qué datos puede o no puede alimentarlas (aquí es donde se enlaza con la clasificación de datos que ya tenga la organización, no hace falta inventar una nueva), y a quién avisa si descubre un uso nuevo que nadie aprobó formalmente. Sin esta pieza, el inventario se queda desactualizado en cuanto alguien conecta una herramienta nueva sin pasar por el proceso, que es exactamente el problema de IA en la sombra que trató el módulo 13 de este curso.
La tercera es un responsable identificado, con nombre y no solo con cargo genérico, que reciba las solicitudes de casos de uso nuevos y tenga autoridad real para aprobarlos o rechazarlos. No hace falta un puesto a tiempo completo en la mayoría de organizaciones medianas: puede ser una responsabilidad añadida a quien ya lleva seguridad o cumplimiento, siempre que esté nombrada por escrito y no sea «el equipo» de forma difusa.
La cuarta es un registro de decisiones, que documenta no solo qué se aprobó sino por qué, con la clasificación de riesgo razonada en el momento de la decisión, no reconstruida después de un incidente:
decision_id: DEC-2026-014
fecha: 2026-07-20
solicitante: equipo-marketing
caso_uso: generador de descripciones de producto con modelo de lenguaje
clasificacion_propuesta: transparencia (articulo 50, marcado de salida)
alto_riesgo_descartado_porque: >
No hace evaluacion ni perfilado de personas; genera texto de producto
revisado por un editor antes de publicarse (excepcion del articulo 50.4).
aprobado_por: [responsable de IA]
condiciones: marcado tecnico activo antes de produccion; revision en 6 meses
resultado: aprobado con condicionesEste registro es, en la práctica, el documento que exige el artículo 6, apartado 4, cuando decides que un sistema del anexo III no es de alto riesgo: no basta con la conclusión, hace falta la justificación escrita en el momento, disponible si una autoridad la pide. Y para no depender de memoria ni de resúmenes de terceros sobre si ha cambiado algo más del calendario desde que escribiste este registro, conviene comprobar tú mismo el estado vigente del texto consolidado antes de cada revisión periódica:
curl -s "https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R1689"
-o reglamento-ia-vigente.html
# repite lo mismo con el CELEX del Reglamento 2026/1744 (32026R1744)
# si aparece un CELEX de una reforma posterior, esta tabla queda desfasadaEjercicio: modelo de amenazas completo de una aplicación con RAG y agentes
Este es el ejercicio que cierra el curso entero, no solo este módulo. El objetivo es construir, de principio a fin, el modelo de amenazas de una aplicación hipotética pero realista: un asistente interno que responde preguntas sobre políticas de la empresa recuperando documentos de una base vectorial (módulo 5), tiene una herramienta para abrir tickets en un sistema externo (módulo 6), corre sobre un modelo de uso general consumido por API (módulo 7) y expone su respuesta a empleados a través de un prompt de sistema con instrucciones de negocio (módulo 8). No hace falta software especial, solo un editor de texto o una hoja de cálculo libre como LibreOffice Calc.
Primero, dibuja o lista los componentes: el modelo, la base vectorial y su proceso de ingesta, la herramienta de tickets, el prompt de sistema, el canal de entrada (el empleado que escribe) y el canal de salida (la respuesta que ve el empleado, y cualquier acción que dispare la herramienta). Cada componente es una superficie de ataque distinta, tal como viste en el módulo 1.
Segundo, para cada uno de los diez riesgos del OWASP Top 10 for LLM Applications 2025 que repasó el módulo 2, escribe una fila con esta estructura, y complétala tú mismo para las diez entradas:
riesgo: LLM01:2025 Inyeccion de prompt
componente_afectado: canal de entrada + contenido recuperado del RAG
vector_concreto: documento envenenado en la base vectorial (indirecta)
control: saneamiento de contenido recuperado, instrucciones jerarquizadas
en el prompt de sistema (modulo 3), limite de privilegios de la
herramienta de tickets (modulo 6)
propietario_control: equipo de plataforma de IA
evidencia_de_cumplimiento: registro de prompts bloqueados (modulo 13)
relacion_reglamento_ia: articulo 4 (formacion del equipo que revisa
alertas), sin obligacion especifica de alto riesgo en este casoTercero, construye la matriz de responsabilidad completa, con las diez filas del Top 10, cruzando riesgo, control principal y quién responde de cada uno. Esta es la tabla que entregarías de verdad en una revisión de seguridad:
| Riesgo (OWASP LLM Top 10 2025) | Control principal | Propietario |
|---|---|---|
| LLM01:2025 Inyección de prompt | Saneamiento del contexto recuperado, jerarquía de instrucciones, límite de privilegios de herramientas | Equipo de plataforma de IA |
| LLM02:2025 Divulgación de información sensible | Control de acceso al conocimiento recuperado por identidad del usuario, no por la aplicación | Equipo de datos y seguridad |
| LLM03:2025 Cadena de suministro | Documentación del artículo 53 exigida al proveedor del modelo, inventario de dependencias | Compras y equipo de plataforma |
| LLM04 Envenenamiento de datos y modelo | Validación de fuentes antes de la ingesta en la base vectorial, control de versiones del índice | Equipo de datos |
| LLM05:2025 Manejo inadecuado de la salida | Tratar la salida del modelo como entrada no confiable antes de pasarla a la herramienta de tickets | Equipo de desarrollo de la aplicación |
| LLM06:2025 Agencia excesiva | Permisos mínimos por herramienta y por usuario, confirmación humana en acciones irreversibles | Equipo de plataforma de IA |
| LLM07:2025 Filtración de prompts de sistema | No incrustar secretos ni reglas de negocio sensibles en el prompt de sistema | Equipo de plataforma de IA |
| LLM08:2025 Debilidades de vector y representaciones vectoriales | Control de acceso a nivel de documento en el índice, no solo a nivel de aplicación | Equipo de datos y seguridad |
| LLM09:2025 Desinformación | Citas verificables de la fuente recuperada, revisión humana antes de publicar contenido externo | Equipo de negocio propietario del caso de uso |
| LLM10:2025 Consumo ilimitado | Límites de tasa y de coste por usuario e identidad delegada (módulo 10) | Equipo de plataforma de IA |
Cuarto, con la matriz ya construida, resuelve la última pregunta, la que en realidad es el objetivo de todo el ejercicio: clasifica el sistema completo según el capítulo de riesgo de este módulo (¿toca algún área del anexo III? ¿hace perfilado? ¿entra en la excepción del artículo 6, apartado 3?), decide si le aplica el artículo 50, y escribe la entrada de registro de decisiones, con el mismo formato que viste en la sección anterior, que documentaría esa clasificación ante una auditoría. Ese último paso es el que conecta los trece módulos técnicos anteriores con el marco legal de este, y es la habilidad concreta que se supone que tienes al terminar el curso: no memorizar artículos, sino saber convertir un sistema real en una clasificación de riesgo justificada y en una lista de controles con dueño.
Preguntas frecuentes
Mi aplicación usa un modelo de lenguaje para resumir documentos internos. ¿Es de alto riesgo?
Casi seguro que no. Para ser de alto riesgo tendría que caer en un área del anexo III (biometría, empleo, educación, servicios públicos y privados regulados, aplicación de la ley, migración, justicia) y no cumplir ninguna de las cuatro condiciones de excepción del artículo 6, apartado 3. Un resumen de documentos internos, sin decisión automatizada sobre personas ni perfilado, normalmente cae en riesgo mínimo. Si el resumen alimenta una decisión sobre una persona concreta sin revisión humana, la respuesta cambia.
¿Desde cuándo tengo que marcar el contenido sintético que genera mi aplicación?
Desde el 2 de agosto de 2026 para cualquier sistema nuevo. Si tu sistema ya generaba contenido sintético antes de esa fecha, tienes hasta el 2 de diciembre de 2026 para adaptar el marcado técnico, según el periodo transitorio que añadió la reforma de 2026 al artículo 111.
¿El artículo 4 me obliga a certificar a mi equipo en algo concreto?
No. Desde julio de 2026 el propio artículo dice de forma explícita que no exige garantizar un nivel específico de alfabetización de ninguna persona en particular. Lo que exige es adoptar medidas razonables para apoyar esa alfabetización, adaptadas al puesto de cada persona, y que quede constancia de que se adoptaron.
¿Qué hago si el proveedor de mi modelo de uso general no me da la documentación del artículo 53?
Depende de si el proveedor está sujeto al Reglamento de IA (si opera en la Unión o pone su modelo a disposición de usuarios en la Unión, lo está). Si lo está y no comparte ni la información sobre capacidades y limitaciones ni la política de derechos de autor, tienes una palanca contractual, y también una señal de riesgo de cadena de suministro, que conviene documentar en tu propio registro de decisiones, no solo asumir en silencio.
¿Necesito una evaluación de impacto de protección de datos aparte de cualquier evaluación que pida el Reglamento de IA?
Si tu sistema es de alto riesgo y trata datos personales, no son dos evaluaciones independientes: el artículo 26, apartado 9, del Reglamento de IA dice que uses la información que te dio el proveedor para cumplir tu obligación de evaluación de impacto del artículo 35 del RGPD. Si tu sistema no es de alto riesgo pero sí trata datos personales, la obligación de evaluación de impacto sigue las reglas normales del RGPD, sin que el Reglamento de IA añada nada encima.
Con el calendario aplazado hasta 2027 y 2028 para el alto riesgo, ¿tiene sentido empezar a aplicar todo esto ya?
Mi lectura, después de repasar el calendario completo, es que sí, y por una razón sencilla: lo que se ha aplazado es solo el capítulo de alto riesgo. El artículo 4 lleva aplicándose desde febrero de 2025, el artículo 50 se aplica desde agosto de 2026, y las obligaciones de los modelos de uso general desde agosto de 2025. Esperar a que llegue 2027 antes de montar el inventario de sistemas o el registro de decisiones significa llegar sin la base que ese mismo registro necesita para justificar, con fecha, por qué un sistema no era de alto riesgo cuando lo desplegaste. Con esto termina el curso: para gobierno de riesgo y cumplimiento más allá de la IA, el curso de GRC desarrolla el resto del terreno; para llevar la detección de los patrones que viste en el módulo 13 a un programa completo de monitorización, sigue con el curso de ingeniería de detección para SOC; y si quieres entender de primera mano las familias de vulnerabilidad web que aquí solo aparecieron como impacto de una inyección de prompt, el curso de hacking web las desarrolla desde cero.