flowchart LR
r["Obligación"] --> t1["Registro de eventos"]
r --> t2["Supervisión humana"]
r --> t3["Documentación técnica"]
r --> t4["Gobierno del dato"]
t1 -.-> o["Observabilidad"]
t2 -.-> a["Aprobación en el bucle"]
t3 -.-> e["Evaluación y fichas"]
t4 -.-> p["Permisos y linaje"]
classDef control fill:#d7eddc,stroke:#4a9463,stroke-width:1.5px,color:#1c4a2e
classDef contexto fill:#d5e6f5,stroke:#3d7cb0,stroke-width:1.5px,color:#12354e
class r,t1,t2,t3,t4 control
class o,a,e,p contexto
22 Normativa
Es el apartado que todo el mundo se salta y el que decide si un sistema puede existir. Este capítulo no sustituye a un abogado: pretende que sepáis qué preguntas hacerle y, sobre todo, que reconozcáis en qué momento del proyecto hay que hacerlas, que es antes de construir.
AdvertenciaTerreno movedizo
Todo lo que sigue está fechado en 2026 y la regulación de IA se está moviendo con inusitada rapidez, incluidos los propios plazos de aplicación. Tomad las fechas concretas como orientación y contrastadlas antes de tomar una decisión con dinero detrás.
22.1 El Reglamento europeo de IA
El AI Act es el primer marco general de IA con fuerza de ley y su enfoque es de producto y de riesgo: no regula la tecnología sino los usos, y la obligación depende de para qué se emplea y del daño que pueda causar.
Cuatro niveles:
| Nivel | Ejemplos | Régimen |
|---|---|---|
| Riesgo inaceptable | Puntuación social, manipulación subliminal, ciertos usos biométricos | Prohibido |
| Alto riesgo | Selección de personal, crédito, educación, servicios esenciales | Obligaciones fuertes |
| Riesgo de transparencia | Chatbots, contenido generado, deepfakes | Hay que informar |
| Riesgo mínimo | El resto | Sin obligaciones específicas |
A esa clasificación por uso se le superpone un régimen aparte para los modelos de propósito general (GPAI), que recae sobre quien los proporciona: documentación técnica, resumen de los datos de entrenamiento, política de derechos de autor y, para los modelos con riesgo sistémico, evaluación y notificación de incidentes.
El calendario, tal como está a día de hoy: las prohibiciones se aplican desde febrero de 2025, las obligaciones de los modelos de propósito general desde agosto de 2025, y las de transparencia desde agosto de 2026. La parte de alto riesgo, en cambio, se ha retrasado: la revisión conocida como digital omnibus desplazó los sistemas del Anexo III a finales de 2027 y los integrados en productos a 2028.
Las sanciones llegan a decenas de millones de euros o a un porcentaje del volumen de negocio mundial, con topes superiores a los del RGPD. Es la cifra que suele terminar la discusión sobre si esto va en serio.
ImportanteLa pregunta que hay que hacerse el primer día
¿Nuestro caso de uso es de alto riesgo?
Casi siempre depende del dominio, no de la técnica. El mismo agente de búsqueda documental es riesgo mínimo si busca en el manual de la cafetera y alto riesgo si criba currículums o valora solvencia. La lista del Anexo III es concreta: empleo, educación, crédito, servicios esenciales, biometría, justicia, migración.
Responderla al principio cuesta una reunión. Responderla cuando el sistema lleva seis meses en producción cuesta un proyecto entero, porque las obligaciones de alto riesgo (gestión del riesgo, gobierno de datos, registro de eventos, supervisión humana, documentación técnica) condicionan la arquitectura.
22.2 Proveedor o responsable del despliegue
Una distinción que cambia por completo la lista de obligaciones y que en la práctica se malinterpreta a menudo. Proveedor es quien desarrolla y pone en el mercado el sistema; responsable del despliegue (deployer) es quien lo utiliza bajo su autoridad.
Si integráis un modelo de un tercero en vuestro producto y lo ponéis en el mercado con vuestra marca, sois proveedores de ese sistema aunque el modelo sea de otro. Y hay algo más que conviene saber: modificar sustancialmente un sistema de alto riesgo de otro, o cambiarle la finalidad prevista, puede convertiros en proveedores de pleno derecho con todo lo que ello arrastra.
22.3 Transparencia, que aplica a casi todos
Aunque vuestro caso no sea de alto riesgo, las obligaciones de transparencia sí os alcanzan y son de aplicación inmediata:
- Si una persona interactúa con un sistema de IA, tiene que saberlo. Se acabó el asistente que finge ser Marta de atención al cliente.
- El contenido generado o manipulado por IA debe estar marcado como tal en formato legible por máquina.
- Los deepfakes y el contenido que informa sobre asuntos de interés público deben llevar su etiqueta.
Son requisitos baratos si se piensan al diseñar la interfaz y muy molestos si hay que añadirlos después de que el producto tenga usuarios acostumbrados a otra cosa.
22.4 Lo que ya aplicaba
El AI Act no sustituye a nada, se suma. Y en la práctica, la mayoría de los problemas legales de un proyecto de IA generativa no vienen de él:
Protección de datos. El RGPD sigue en pie con todo su peso. Base jurídica para el tratamiento, minimización, información a los interesados y una obligación que aquí importa mucho: el derecho a no ser objeto de decisiones automatizadas con efectos significativos. Si el agente decide y nadie revisa, ahí hay un problema anterior a cualquier reglamento de IA.
Propiedad intelectual. Con qué se entrenó el modelo, de quién es lo que genera, qué pasa si reproduce material protegido. Terreno en litigio en varias jurisdicciones y sin respuesta cerrada.
Confidencialidad y secreto profesional. Enviar a un tercero información sujeta a deber de secreto puede infringir un contrato o una norma sectorial aunque el proveedor cumpla escrupulosamente el RGPD.
Normativa sectorial. Banca, seguros, sanidad y sector público tienen sus propios requisitos de trazabilidad, explicabilidad y conservación, que suelen ser más exigentes y llegar antes.
22.5 En España
España fue de los primeros países en montar una autoridad específica, la AESIA, y en poner en marcha un entorno controlado de pruebas (sandbox) para que las empresas ensayen sistemas de alto riesgo con acompañamiento del regulador. La ley nacional que articula el régimen sancionador ha ido más despacio y conviene comprobar su estado actual.
Para una empresa española, el orden práctico de las conversaciones suele ser: delegado de protección de datos primero (el RGPD aplica hoy, sin plazos que esperar), clasificación según el AI Act después, y normativa sectorial en paralelo si estáis en un sector regulado.
22.6 Los marcos voluntarios
Junto a la obligación legal hay dos referencias que se usan como andamiaje y que conviene no confundir con ella:
| Marco | Qué es | Para qué sirve |
|---|---|---|
| ISO/IEC 42001 | Sistema de gestión de IA certificable | Demostrar gobierno a clientes y auditores |
| NIST AI RMF | Metodología de gestión de riesgo | Estructurar el análisis, sin certificación |
| AI Act | Ley | No es opcional |
La estrategia razonable es construir un solo cuerpo documental que sirva a los tres: el AI Act como obligación, ISO 42001 como sistema de gestión auditable y NIST AI RMF como método de análisis. Hacer tres ejercicios separados es el camino más rápido a tener tres carpetas que nadie lee.
22.7 Lo que se traduce en ingeniería
Buena parte de esto acaba siendo trabajo técnico que ya hemos visto en otros capítulos, y ese es el argumento para no dejarlo para el final:
El registro de eventos es observabilidad. La supervisión humana es la aprobación de acciones irreversibles. La documentación técnica se apoya en el conjunto de evaluación. El gobierno del dato es el filtrado por permisos y la trazabilidad de las fuentes.
Es decir: un sistema bien construido ya tiene hecha la mayor parte del trabajo de cumplimiento. Y uno mal construido descubre que cumplir exige rehacerlo. Esa es, en el fondo, la tesis de este manual y una razón bastante buena para no dejar este capítulo para el final.