EUROPE · RIGHTS · RESPONSIBILITY
Guía práctica del Reglamento europeo de IA: riesgos, RGPD, explicabilidad, autoridades, modelos avanzados y evidencias.
Guía divulgativa independiente, revisada el 26 de octubre de 2026. No es asesoramiento jurídico individual ni certificación. La clasificación y las obligaciones dependen de la finalidad y del contexto. Contrasta el texto consolidado y los cambios antes de desplegar.
Resumen del calendario de la Comisión que incorpora el Ómnibus de IA. Existen transiciones y excepciones: consulta el supuesto concreto.
No todas estas normas aplican a todos los proyectos. Esta tabla es un mapa de comprobación, no una lista exhaustiva de obligaciones.
| Marco / Framework | Cuándo revisarlo | Link |
|---|---|---|
| RGPD + LOPDGDD | Datos personales, base jurídica, derechos, EIPD, encargados y transferencias. | Fuente |
| AI Act | Sistema/modelo, rol, prohibiciones, riesgo, transparencia y conformidad. | Fuente |
| MDR / IVDR | Finalidad de producto sanitario: cualificación y obligaciones clínicas/sectoriales. | Fuente |
| NIS2 / CRA | Analiza entidad, producto y transposición nacional; no aplican por igual a toda IA. CRA: notificación desde septiembre de 2026; obligaciones principales desde diciembre de 2027. | Fuente |
| DORA / finanzas | Entidades financieras y resiliencia TIC; añade el régimen específico del servicio financiero. | Fuente |
| Propiedad intelectual | Derechos de autor, bases de datos, licencias y reservas de derechos; no todo dato accesible es reutilizable libremente. | Fuente |
| Data Act / DGA | Acceso y reutilización de datos en sus supuestos; no sustituyen el RGPD ni autorizan cualquier entrenamiento. | Fuente |
| Trabajo, consumo, igualdad y sector público | Revisa información laboral, no discriminación, accesibilidad, contratación y seguridad aplicables al contexto. En España, valorar ENS cuando corresponda al sistema público. | Fuente |
El AI Act regula sistemas y modelos de IA según funciones, riesgos y papel en la cadena de valor; no concede una autorización universal para usar datos. Identifica finalidad prevista, usuarios, personas afectadas, territorio, proveedor, responsable del despliegue y cambios del sistema. El mismo modelo puede tener obligaciones distintas según su uso. Un prototipo interno o un sistema gratuito no queda automáticamente fuera.
Un modelo es un componente; el sistema incluye interfaz, reglas, datos, integración y uso. Proveedor y responsable del despliegue tienen obligaciones diferentes. Reetiquetar, modificar sustancialmente o cambiar la finalidad de un sistema puede trasladar responsabilidades de proveedor. Un contrato con un tercero debe repartir tareas, acceso a evidencias y cooperación, pero no elimina deberes legales propios.
Revisa el artículo 5: determinadas manipulaciones dañinas, explotación de vulnerabilidades, puntuación social, predicción delictiva basada solo en perfiles, extracción indiscriminada de imágenes faciales y ciertos usos biométricos están prohibidos. La inferencia de emociones en trabajo y educación tiene una prohibición específica con excepciones médicas o de seguridad. No presentes biometría o vigilancia como usos ordinarios: sus condiciones y excepciones requieren lectura exacta.
Las vías principales son determinados productos o componentes de seguridad regulados por el anexo I y los usos enumerados en el anexo III. Este último abarca ámbitos como empleo, educación, servicios esenciales y ciertos usos públicos. La excepción del artículo 6.3 exige condiciones y justificación documental: no basta decir que la herramienta solo ayuda. Si un sistema del anexo III realiza perfilado de personas, la excepción no permite rebajarlo por ese motivo.
Un predictor industrial no encaja automáticamente en alto riesgo por utilizar redes neuronales. Sin embargo, puede estar sujeto a protección de datos, seguridad de producto, contratos o reglas sectoriales. Las obligaciones de transparencia del artículo 50 se activan por funciones específicas, no por una etiqueta comercial. Documenta por qué aplican o no las categorías; revisa la decisión si cambian finalidad o integración.
Para sistemas de alto riesgo, la gestión de riesgos debe ser continua: identificar peligros previsibles, evaluar impactos, aplicar controles y comprobar riesgo residual. Traduce cada riesgo a una evidencia verificable: prueba, responsable, umbral de aceptación y decisión de liberación. No reduzcas cumplimiento a una carpeta final; vuelve a evaluar al cambiar datos, modelo, usuarios o entorno.
Documenta procedencia, licencias, finalidad, representatividad, limpieza, etiquetado, separación de conjuntos y posibles sesgos. Examina las condiciones reales de uso y los colectivos afectados. Evita fugas entre entrenamiento y evaluación, incluidas fugas temporales. Datos sintéticos no garantizan anonimato ni ausencia de sesgo. Para categorías especiales, analiza la habilitación y salvaguardas específicas; no recopiles atributos sensibles por defecto para completar una auditoría.
Mantén descripción del sistema, finalidad, arquitectura, versiones, datos, métricas, validación, límites, riesgos y controles. Relaciona requisitos con evidencias y documenta cambios. Una ficha del modelo es útil, pero no sustituye el expediente técnico exigible. Debe poder reconstruirse qué versión se puso en servicio y con qué evaluación, sin conservar datos personales innecesarios.
Diseña registros que permitan investigar fallos y decisiones: versión del sistema, fecha, entrada o referencia mínima, resultado, intervención y evento relevante. La retención debe respetar las obligaciones aplicables, la finalidad y la seguridad. No guardes indiscriminadamente conversaciones, secretos, datos médicos o cadenas internas de razonamiento. Controla accesos y verifica integridad.
El artículo 13 exige transparencia suficiente para interpretar resultados y usarlos adecuadamente en alto riesgo, acompañada de instrucciones comprensibles sobre finalidad, rendimiento, límites y supervisión. Esto no equivale a publicar todo el código o todos los pesos. La explicación debe servir a una persona concreta y una tarea real, no limitarse a un gráfico atractivo.
El artículo 86 contempla explicaciones claras y significativas del papel de la IA y de los elementos principales de determinadas decisiones basadas en sistemas de alto riesgo del anexo III, con exclusión de su punto 2. Deben concurrir los efectos y condiciones del artículo; existen límites y coordinación con otros derechos europeos. No crea un derecho universal a una explicación técnica de cualquier predicción.
Como práctica técnica, compara modelos interpretables, importancia de variables, explicaciones locales y contrafactuales. SHAP y LIME pueden ayudar, pero no son métodos impuestos por el AI Act ni prueban causalidad o cumplimiento. Comprueba estabilidad, fidelidad y comprensión. Un texto generado por un LLM que suena convincente no demuestra por qué decidió otro modelo. No confundas explicación de un resultado con justificación de una decisión.
En alto riesgo, la persona supervisora necesita competencia, autoridad y medios para interpretar, detectar anomalías, intervenir o detener el uso. Una firma automática o una revisión sin tiempo no ofrecen supervisión sustantiva. Ensaya situaciones de desacuerdo con el sistema y controla el sesgo de automatización. Documenta cuándo se requiere escalado y quién asume la decisión.
Define métricas vinculadas al daño: falsos positivos y negativos, calibración, incertidumbre, desempeño por subgrupos, degradación y disponibilidad. Los umbrales no son universales. Prueba datos fuera de distribución, ataques, manipulación, envenenamiento y dependencias. Para modelos generativos añade evaluación de alucinaciones, fugas, prompt injection y abuso de herramientas. Una alta media de precisión puede ocultar fallos graves.
Quien despliega alto riesgo debe seguir instrucciones, asignar supervisión, controlar datos bajo su responsabilidad y atender seguimiento e incidencias según corresponda. El uso empresarial de una API no convierte automáticamente al cliente en proveedor del modelo base. Un cambio de finalidad o modificación sí puede cambiar el análisis. Pide al proveedor documentación suficiente y mecanismos para comunicar problemas.
La EIPD del RGPD y la evaluación del artículo 27 del AI Act no son el mismo documento ni tienen idéntico ámbito. El artículo 27 alcanza a determinados responsables del despliegue, incluidos supuestos públicos y ciertos servicios, no a cualquier modelo. Examina grupos afectados, impactos, mitigaciones y participación pertinente. Coordina evaluaciones para evitar duplicidades, sin borrar sus requisitos particulares.
Si tratas información sobre personas identificadas o identificables, determina base jurídica, finalidad, minimización, información, conservación, encargados y transferencias. El artículo 22 RGPD trata determinadas decisiones exclusivamente automatizadas con efectos jurídicos o similares: no toda predicción. Examina sus excepciones y salvaguardas. Una intervención humana decorativa no cambia la realidad del proceso. Pseudonimizar no equivale a anonimizar.
No supongas que los parámetros de un modelo dejan de contener información personal por ser parámetros. El CEPD pide analizar anonimato caso por caso y evaluar el interés legítimo cuando se invoque. Considera memorización, extracción, expectativas y mitigaciones; una fuente pública no elimina los derechos de las personas. La base del entrenamiento y la del uso posterior pueden requerir análisis separados.
Un modelo que estima demanda, solvencia o riesgos de una empresa no es automáticamente alto riesgo por hablar de una entidad. Pero sus datos pueden identificar autónomos, administradores, empleados o clientes. Revisa también secreto empresarial, licencias, exactitud y el uso sectorial: el análisis corporativo que termina decidiendo empleo o crédito personal cambia el contexto. En inversiones, comprueba la normativa financiera y el servicio concreto.
Antes de predecir desempeño, salud, conducta o vulnerabilidad de una persona, pregunta si la finalidad es legítima, necesaria y proporcionada y qué daños producirían los errores. No infieras rasgos sensibles por curiosidad ni reutilices puntuaciones fuera de su contexto. Diseña información comprensible, corrección de datos, revisión y reclamación. Los sistemas médicos o laborales requieren análisis sectorial especializado, no solo ajustar una red neuronal.
Distingue las obligaciones del proveedor del modelo GPAI de las del sistema que lo integra. El artículo 53 aborda documentación, información para integradores, política de derechos de autor y resumen público de contenido de entrenamiento, según sus condiciones. Las excepciones open source tienen límites; publicar pesos no convierte cualquier desarrollo en exento. Un ajuste fino exige analizar el papel real y las modificaciones.
Los modelos GPAI con riesgo sistémico tienen un régimen adicional, que contempla evaluación, pruebas adversarias, mitigación de riesgos, incidentes y ciberseguridad. No identifiques riesgo sistémico con cualquier modelo grande o con una única métrica aislada; revisa el procedimiento y los criterios vigentes. El integrador sigue teniendo que evaluar su caso de uso y no puede trasladar toda su responsabilidad al modelo base.
Analiza los avisos de interacción con IA y las obligaciones de marcado o divulgación que correspondan al proveedor o al responsable del despliegue, con sus excepciones. Distingue el marcado técnico de la comunicación al público. Un aviso genérico al pie no resuelve todas las situaciones. La transparencia no autoriza difamar, revelar datos personales o infringir derechos de autor.
En alto riesgo, determina la vía de evaluación de conformidad, la documentación, declaración UE, marcado y registro aplicables. No todos los sistemas requieren el mismo organismo externo. Un organismo notificado no es un auditor comercial cualquiera. Las normas armonizadas solo producen los efectos jurídicos previstos cuando se cumplen las condiciones pertinentes; un logotipo o una auditoría voluntaria no sustituyen la conformidad exigible.
ISO/IEC 42001 estructura un sistema de gestión de IA. La certificación es voluntaria y la realizan entidades certificadoras, no ISO. Puede aportar evidencia sobre procesos dentro de su alcance, pero no certifica que cada modelo, decisión o tratamiento cumpla toda la legislación. Revisa alcance, entidad emisora y vigencia; no la presentes como una autorización general de AESIA o de la ORGANIZATION-004.
Prepara un plan de vigilancia poscomercialización y un canal de incidentes. Mide deriva, quejas, abuso y daños reales, no solo precisión en laboratorio. Define quién investiga, qué versión puede retirarse y cómo se comunican medidas correctoras. Los plazos dependen del régimen y la gravedad: una alerta puede activar AI Act, RGPD y reglas sectoriales simultáneamente.
RAG no elimina la responsabilidad sobre fuentes, datos o resultados. Para agentes, limita herramientas y permisos, separa entornos, valida acciones irreversibles y registra autorizaciones sin almacenar secretos. Evalúa recuperación, citas, exposición de documentos y prompt injection. Estas son medidas técnicas propuestas: su suficiencia depende del sistema. Un agente con acceso a pagos, expedientes o infraestructura necesita límites especialmente claros.
Esquema editorial; cada obligación tiene su ámbito legal propio.
Ejemplos editoriales orientativos, no dictámenes de clasificación. Las garantías de la última columna combinan obligaciones potenciales y recomendaciones técnicas.
| Sistema | Análisis inicial | Evidencias y controles |
|---|---|---|
| Predicción de demanda energética | No necesariamente alto riesgo; cambia si actúa como componente de seguridad en infraestructura crítica. | Validación temporal, incertidumbre, límites de uso y modo de fallo seguro. |
| Ranking de candidaturas laborales | Caso típico del anexo III; revisar finalidad, clasificación y RGPD. | Datos pertinentes, pruebas de sesgo, supervisión real, información y vía de revisión. |
| Crédito de una persona física | Generalmente alto riesgo en el supuesto del anexo III; las excepciones son específicas. | Calibración, trazabilidad, motivos de decisión y revisión, además de normativa financiera. |
| Solvencia de una sociedad mercantil | No equivale por sí sola a evaluar crédito de una persona física. | Proveniencia, datos personales residuales, incertidumbre y límites del asesoramiento. |
| Asistente de documentación pública | Examinar interacción, fuentes, licencias y tratamiento de datos. | Aviso de IA cuando proceda, citas contrastables, evaluación de errores y controles de acceso. |
| Apoyo al diagnóstico clínico | Puede entrar en normativa de producto sanitario y alto riesgo; importa la finalidad médica. | Evidencia clínica, gestión de riesgos, evaluación sectorial y supervisión profesional. |
| Inferencia de emociones de empleados | Uso generalmente prohibido en el ámbito laboral, salvo excepciones concretas. | No desplegar basándose solo en consentimiento; comprobar prohibición y excepciones. |
| Moderación o detección de fraude | La etiqueta no determina el riesgo; examinar personas, efectos y el supuesto legal exacto. | Falsos positivos, intervención, apelación, seguridad y régimen sectorial aplicable. |
| Agente que gestiona facturas | No automáticamente alto riesgo; datos y acciones pueden activar otras obligaciones. | Permisos mínimos, aprobación de pagos, límites, auditoría y recuperación. |
Comprueba la lista vigente de autoridades y el reparto sectorial antes de presentar expedientes o reclamaciones. No toda autoridad certifica modelos.
| Comisión Europea / Oficina de IA | Supervisión y coordinación europea; papel específico en modelos GPAI. |
| Comité Europeo de IA | Coordinación entre Estados y asesoramiento; no una ventanilla que apruebe cada modelo. |
| AESIA | Referencia española para supervisión y recursos de IA. Verifica la competencia concreta y la designación vigente. |
| AEPD / autoridades de protección de datos | Protección de datos personales; no se sustituye por la intervención de una autoridad de IA. |
| Supervisores sectoriales | Finanzas, sanidad, seguridad de producto u otros ámbitos: dependen del sistema y del marco vigente. |
| Autoridades notificantes y organismos notificados | Las primeras designan y supervisan; los segundos evalúan conformidad en las vías que requieren su intervención. |
Checklist de preparación, no test de cumplimiento ni certificado. Marcar casillas no demuestra que la evidencia exista o sea suficiente. La selección se mantiene solo mientras está abierta esta página.
Descargar plantilla de evidencias · JSONEsta secuencia es una propuesta de implementación, no una vía legal alternativa ni una promesa de ausencia de riesgo.
No: clasifica el sistema integrado y tus propias obligaciones.
No: es una técnica de análisis; su utilidad debe validarse y no sustituye los requisitos legales.
No: debe poder comprender, discrepar e intervenir de verdad.
No necesariamente: puede utilizar datos de personas identificables.
No: ofrece un entorno regulado de experimentación, no inmunidad.
Reglamento / Regulation (EU) 2024/1689 · Regulation (EU) 2026/1744 · AI Act Service Desk · AESIA · AEPD · ORGANIZATION-009
Los enlaces de cada capítulo permiten profundizar. Las guías y códigos no sustituyen el texto legal. Revisa cambios, normas armonizadas publicadas y competencias nacionales antes de reutilizar la guía en un proyecto. Las fotografías son ilustraciones conceptuales generadas con IA, no imágenes de organismos ni sellos de conformidad.