El artículo 4 bis del AI Act permite tratar categorías especiales de datos personales (origen racial o étnico, convicciones religiosas, datos de salud, orientación sexual) cuando sea estrictamente necesario para detectar y corregir los sesgos de un sistema de IA, y solo si se cumplen sus seis condiciones, que son acumulativas. Es un artículo nuevo: lo inserta el Reglamento (UE) 2026/1744, en vigor desde el 27 de julio de 2026, y antes de esa fecha no existía en el texto del Reglamento (UE) 2024/1689.
Para comprobar si un sistema discrimina por religión o por estado de salud hay que mirar la religión y el estado de salud de las personas que hay en los datos, y esos datos son categorías especiales del artículo 9 del Reglamento (UE) 2016/679, sujetas a prohibición general de tratamiento. La paradoja es conocida: no puedes medir el sesgo sin tratar el dato que quieres proteger. El artículo 4 bis abre una vía tasada para salir de ese bucle, con la puerta muy estrecha.
Respuesta corta. Si eres proveedor de un sistema de IA de alto riesgo, el artículo 4 bis, apartado 1, te habilita a tratar excepcionalmente categorías especiales de datos personales para detectar y corregir sesgos, siempre que se cumplan todas las condiciones de sus letras a) a f). El apartado 2 extiende esa posibilidad a proveedores y responsables del despliegue de otros sistemas y modelos de IA, y a responsables del despliegue de sistemas de alto riesgo, con las mismas condiciones. Y deja escrito que no obliga a medir el sesgo: es una habilitación, no un mandato, y se suma al RGPD sin sustituirlo.
Qué habilita el apartado 1 y a quién
El apartado 1 se dirige a los proveedores de sistemas de IA de alto riesgo. Pueden tratar excepcionalmente categorías especiales de datos personales «en la medida en que sea estrictamente necesario para garantizar la detección y corrección de los sesgos asociados a los sistemas de IA de alto riesgo de conformidad con lo dispuesto en el artículo 10, apartado 2, letras f) y g)», siempre que ofrezcan garantías adecuadas.
Fíjate en dónde empieza la frase de las condiciones: «Además de las disposiciones establecidas en los Reglamentos (UE) 2016/679 y (UE) 2018/1725 y la Directiva (UE) 2016/680». Ese «además» ordena la lectura de todo el artículo. El 4 bis no es una excepción que te saque del RGPD ni una autorización que sustituya a la que ya necesitas: se apila sobre ella. Añade seis requisitos, no te quita ninguno.
El «estrictamente necesario» no es retórica: hay que poder defenderlo por escrito para este sesgo, en este sistema y con estos datos. Mejorar el modelo no vale como finalidad; comprobar si la tasa de rechazo varía según el origen étnico de la persona solicitante sí.
Las seis condiciones, una por una
El artículo exige que «para que se produzca dicho tratamiento deberán cumplirse todas las condiciones siguientes». No es un menú: si falla una, el tratamiento no está amparado.
a) Subsidiariedad: primero, lo que no identifica
Literal: «que el tratamiento de otros datos, como los sintéticos o los anonimizados, no permita efectuar de forma efectiva la detección y corrección de sesgos».
Es una condición de subsidiariedad: el dato real sensible es el último recurso. Tienes que haber intentado antes la vía de los datos sintéticos o anonimizados y poder demostrar que no funcionó, con un informe técnico fechado. Un correo diciendo no nos servía no acredita nada.
b) Limitaciones técnicas y medidas punteras
Literal: «que las categorías especiales de datos personales estén sujetas a limitaciones técnicas relativas a la reutilización de los datos personales y a medidas punteras en materia de seguridad y protección de la intimidad, incluida la pseudonimización».
Dos cosas en la misma letra: impedir que el dato se reutilice para otra cosa, que se resuelve en el diseño del entorno y no con una política, y un estándar de seguridad situado en el estado del arte, con la pseudonimización como mínimo expreso. Se acredita con la configuración: cómo se pseudonimiza y qué impide que ese conjunto alimente un entrenamiento posterior.
c) Control estricto y documentado del acceso
Literal: «que las categorías especiales de datos personales estén sujetas a medidas para garantizar que los datos personales tratados estén asegurados, protegidos y sujetos a garantías adecuadas, incluidos controles estrictos y documentación del acceso, a fin de evitar el uso indebido y garantizar que solo las personas autorizadas tengan acceso a dichos datos personales con obligaciones de confidencialidad adecuadas».
Traducido a entregables: lista nominal de autorizados, registro de accesos que se conserve y confidencialidad firmada. La palabra «documentación» está en el texto, así que el control tiene que dejar rastro: un acceso por grupo genérico del directorio incumple esta letra.
d) Nada sale a terceros
Literal: «que las categorías especiales de datos personales no se transmitan ni transfieran a terceros y que estos no puedan acceder de ningún otro modo a ellos».
Esta puede tumbar el proyecto por una decisión de arquitectura. La prohibición cubre la transmisión, la transferencia y el acceso «de ningún otro modo», lo que alcanza al soporte del proveedor de la plataforma, a los subencargados y a cualquier servicio que pueda leer el conjunto. Si la medición se piensa hacer en un servicio externo, resuelve esta letra antes de escribir código. Cómo se aísla el entorno lo trata la capa técnica del cumplimiento del AI Act.
e) El dato se borra cuando el sesgo se corrige
Literal: «que las categorías especiales de datos personales se eliminen una vez que se haya corregido el sesgo o los datos personales hayan llegado al final de su período de conservación, si esta fecha es anterior».
Es un límite de conservación con dos relojes y manda el que salta antes. El proyecto necesita una condición de cierre definida desde el principio: qué significa corregido, quién lo declara y quién ejecuta el borrado. Si el plazo general de conservación vence antes, no puedes estirarlo.
f) La motivación, por escrito, en el registro
Literal: «que los registros de las actividades de tratamiento en virtud de los Reglamentos (UE) 2016/679 y (UE) 2018/1725 y la Directiva (UE) 2016/680 incluyan las razones por las que el tratamiento de categorías especiales de datos personales era estrictamente necesario para detectar y corregir sesgos, y por las que ese objetivo no podía alcanzarse mediante el tratamiento de otros datos».
El reglamento te dice dónde tiene que estar el papel: en el registro de actividades de tratamiento que ya llevas por el RGPD, no en un anexo del proyecto. Y con dos razonamientos separados: por qué era estrictamente necesario y por qué no se podía lograr con otros datos. Esa segunda mitad es el reverso de la letra a): sin la prueba previa, no tienes qué escribir aquí.
Las seis condiciones en una tabla
| Condición | Qué exige | Cómo se acredita |
|---|---|---|
| a) Subsidiariedad | Que los datos sintéticos o anonimizados no permitan detectar y corregir el sesgo de forma efectiva | Informe técnico fechado de la prueba previa |
| b) Límites técnicos y seguridad | Limitaciones a la reutilización y medidas punteras de seguridad e intimidad, incluida la pseudonimización | Configuración del entorno y esquema de pseudonimización |
| c) Acceso | Controles estrictos, documentación del acceso y confidencialidad de las personas autorizadas | Lista nominal, registro de accesos y confidencialidad firmada |
| d) Sin terceros | Ni transmisión, ni transferencia, ni acceso por ninguna otra vía | Mapa de flujos, aislamiento del entorno y contratos que excluyan el acceso |
| e) Supresión | Borrado al corregir el sesgo o al vencer el plazo de conservación, el que ocurra antes | Criterio de cierre, responsable del borrado y evidencia de que se ejecutó |
| f) Motivación | Razones de la necesidad estricta y de por qué no bastaban otros datos | Entrada específica en el registro de actividades de tratamiento |
Fuente: artículo 4 bis, apartado 1, letras a) a f), del Reglamento (UE) 2024/1689, en la redacción del Reglamento (UE) 2026/1744. La columna cómo se acredita es criterio profesional de Summum Consultoría, no texto del reglamento.
El apartado 2 amplía mucho el círculo de afectados
Si te has quedado tranquilo porque no eres proveedor de alto riesgo, lee el apartado 2. Extiende la posibilidad a «los proveedores y responsables del despliegue de otros sistemas y modelos de IA y los responsables del despliegue de sistemas de IA de alto riesgo». Es decir: también quien solo usa una IA ajena y quien trabaja con sistemas que no son de alto riesgo.
La condición de entrada por esta vía es distinta. El tratamiento tiene que ser estrictamente necesario para la detección y corrección de sesgos, «atendiendo a posibles sesgos que afecten probablemente a la salud y la seguridad de las personas, tengan consecuencias negativas para los derechos fundamentales o den lugar a una discriminación prohibida por el Derecho de la Unión, especialmente cuando las salidas de datos influyan en las informaciones de entrada de futuras operaciones». Y hay que aplicar «todas las condiciones y garantías previstas en el apartado 1»: las seis letras vuelven íntegras.
Esa última frase merece pararse: habla de sistemas cuyas salidas se convierten en entradas de operaciones futuras, esto es, de bucles de retroalimentación. Un sistema que aprende de sus propias decisiones amplifica lo que ya hacía: si cribó menos candidaturas de un grupo, verá menos personas de ese grupo entre las contratadas y confirmará el criterio con el que empezó. El reglamento señala ese escenario como el caso en que medir importa más. Si eres responsable del despliegue, el resto de tus deberes están en la pieza sobre el artículo 26 y las obligaciones del responsable del despliegue.
Habilitación, no mandato: la frase que hay que leer entera
El apartado 2 cierra así, literal: «El presente apartado no crea obligación alguna de llevar a cabo dicha detección y corrección de sesgos.»
La consecuencia jurídica es precisa. El artículo 4 bis te da base para tratar el dato sensible si decides medir el sesgo, pero no te obliga a medirlo: es una llave, no una orden.
Lo que sí puede obligarte viene por otra puerta. Para los sistemas de alto riesgo, el propio artículo 4 bis remite en materia de sesgos al artículo 10, apartado 2, letras f) y g), del AI Act. Ahí es donde hay que mirar si el deber existe en tu caso, no en el 4 bis. Y sigue vivo todo el Derecho que no es el AI Act, que se aplica con independencia de que decidas o no medir.
La costura con el RGPD: el artículo 2, apartado 7
El Ómnibus digital sobre IA no se limitó a insertar el 4 bis. También sustituyó el artículo 2, apartado 7, del AI Act, que ahora dice: «El Derecho de la Unión en materia de protección de los datos personales, la intimidad y la confidencialidad de las comunicaciones se aplicará a los datos personales tratados en relación con los derechos y obligaciones establecidos en el presente Reglamento. Sin perjuicio de sus artículos 4 bis y 59, el presente Reglamento no afectará a los Reglamentos (UE) 2016/679 o (UE) 2018/1725 ni a las Directivas 2002/58/CE o (UE) 2016/680.»
Ese «Sin perjuicio de sus artículos 4 bis y 59» es la costura jurídica de la reforma. La regla general del AI Act es que no toca el RGPD, y si se hubiera quedado tal cual, el 4 bis habría chocado con ella: una habilitación de tratamiento metida en el AI Act sería, precisamente, afectar al RGPD. La salvedad evita el choque. El resto de lo que cambió el Reglamento (UE) 2026/1744, el Ómnibus digital sobre IA, incluidas las fechas de aplicación del AI Act, está en su propia pieza. Y cuidado con la distinción de siempre: el AI Act está en vigor desde el 1 de agosto de 2024 y se aplica por tramos; el Ómnibus está en vigor desde el 27 de julio de 2026.
Lo que el artículo 4 bis no te ahorra
Aquí es donde se pierden los proyectos: una habilitación en el AI Act no resuelve el lado del RGPD.
- Base jurídica y excepción al artículo 9. El «además» del apartado 1 obliga a identificarlas y a dejarlas escritas, igual que en cualquier otro tratamiento de categorías especiales.
- Minimización. Cuántas personas, qué categorías y durante cuánto tiempo. El «estrictamente necesario» del 4 bis y la minimización del RGPD apuntan al mismo sitio, y se acreditan con números, no con adjetivos.
- Evaluación de impacto. Hay que valorar si el tratamiento exige una evaluación de impacto relativa a la protección de datos del artículo 35 del Reglamento (UE) 2016/679. No damos por hecho que sea obligatoria en todo caso: lo que no es opcional es hacer la valoración y documentarla, también cuando el resultado sea que no procede. Aquí tienes cómo se monta una evaluación de impacto en protección de datos. Y cuando el sistema es de alto riesgo, el artículo 26, apartado 9, del AI Act manda usar la información que el proveedor facilita conforme al artículo 13 para cumplir esa obligación del artículo 35.
- Información a los interesados. Auditar un modelo con datos de una persona es un tratamiento, y hay que informarlo.
Las dos normas miden cosas distintas y se solapan solo en parte: esa frontera está desarrollada en AI Act y RGPD, qué mide cada uno y qué evaluación toca. Y el 4 bis, con su letra f), su control de accesos y su borrado condicionado, es en el fondo un problema de gobierno del dato: sin inventario, sin trazabilidad y sin dueño del conjunto, ninguna de las seis condiciones se puede demostrar.
Quién firma esta decisión
Esta decisión no la puede tomar sola el equipo técnico: las letras a) y f) son razonamientos jurídicos que hay que sostener ante una autoridad. Tampoco la persona que lleva la protección de datos: la letra a) exige un juicio técnico sobre si los datos sintéticos o anonimizados dan resultado, y la letra d) depende de cómo esté montada la infraestructura. Es una decisión conjunta, con autorización expresa. El reparto de papeles está en responsable de IA en la empresa frente al delegado de protección de datos.
Lista de comprobación antes de autorizar el tratamiento
- Identifica tu vía: apartado 1 como proveedor de alto riesgo, o apartado 2.
- Describe el sesgo que vas a medir, en qué sistema y sobre qué decisión.
- Ejecuta y documenta la prueba previa con datos sintéticos o anonimizados.
- Escribe por qué es estrictamente necesario, en términos que entienda alguien de fuera.
- Fija el alcance con cifras: categorías, número de personas y plazo.
- Deja identificadas la base jurídica y la excepción al artículo 9 del RGPD.
- Configura la pseudonimización y los límites de reutilización antes de cargar un registro.
- Nombra a las personas autorizadas, fírmales la confidencialidad y activa el registro de accesos.
- Comprueba que ningún tercero puede acceder, tampoco por soporte ni por subencargado.
- Define qué significa sesgo corregido, quién lo declara y quién ejecuta el borrado.
- Valora si procede evaluación de impacto del artículo 35 del RGPD y documenta la valoración.
- Anota en el registro de actividades las dos razones de la letra f).
- Guarda la autorización firmada y fechada de quien tiene autoridad para decidir.
Si te falta la primera casilla o la tercera, el resto no te salva.
En Summum Consultoría montamos este expediente completo, del juicio de necesidad estricta al criterio de borrado, dentro de nuestro servicio de cumplimiento del AI Act. Si vas a medir sesgos con datos reales, el trabajo empieza por poder explicar por escrito por qué no había otra manera de hacerlo.
Preguntas frecuentes
¿Puedo tratar datos de salud u origen racial para comprobar si mi IA discrimina?
Sí, pero por una vía muy estrecha. El artículo 4 bis del Reglamento (UE) 2024/1689, insertado por el Reglamento (UE) 2026/1744, permite tratar excepcionalmente categorías especiales de datos personales cuando sea estrictamente necesario para detectar y corregir sesgos de un sistema de IA. Se exigen las seis condiciones de su apartado 1, y todas a la vez: que los datos sintéticos o anonimizados no sirvan, pseudonimización y medidas punteras de seguridad, control documentado del acceso, prohibición de que accedan terceros, borrado al corregir el sesgo y motivación escrita en el registro de actividades de tratamiento. La habilitación se suma al RGPD, no lo sustituye.
¿El artículo 4 bis obliga a medir los sesgos de mi sistema de IA?
No. Su apartado 2 lo dice con estas palabras: «El presente apartado no crea obligación alguna de llevar a cabo dicha detección y corrección de sesgos.» Es una habilitación para tratar datos sensibles si decides medir, no un mandato de medir. La obligación, cuando existe, viene por otra vía: para los sistemas de IA de alto riesgo, el propio artículo 4 bis remite en materia de sesgos al artículo 10, apartado 2, letras f) y g), del AI Act. Ahí es donde hay que comprobar si el deber te alcanza, no en el artículo 4 bis.
¿Qué tengo que anotar en el registro de actividades de tratamiento?
Dos razonamientos distintos, y los dos por escrito. La letra f) del artículo 4 bis, apartado 1, exige que el registro de actividades de tratamiento incluya las razones por las que el tratamiento de categorías especiales era estrictamente necesario para detectar y corregir sesgos, y las razones por las que ese objetivo no podía alcanzarse con otros datos. La segunda parte es el reverso documental de la letra a): si no hiciste la prueba previa con datos sintéticos o anonimizados, no tienes con qué rellenarla. La anotación va en el registro que ya llevas por el RGPD, no en un anexo aparte del proyecto.
Solo uso una IA de un proveedor externo. ¿Me sirve el artículo 4 bis?
Puede servirte, por el apartado 2. Ese apartado extiende la posibilidad a los proveedores y responsables del despliegue de otros sistemas y modelos de IA y a los responsables del despliegue de sistemas de IA de alto riesgo. La entrada exige que el tratamiento sea estrictamente necesario para detectar y corregir sesgos que afecten probablemente a la salud y la seguridad, tengan consecuencias negativas para los derechos fundamentales o den lugar a una discriminación prohibida por el Derecho de la Unión, con mención expresa al caso en que las salidas influyan en las entradas de operaciones futuras. Y hay que aplicar todas las condiciones y garantías del apartado 1.
¿Necesito una evaluación de impacto en protección de datos para medir sesgos?
Hay que valorarlo caso por caso, y la valoración se documenta aunque el resultado sea que no procede. El artículo 4 bis no dice nada sobre esto, porque no sustituye al RGPD: se aplica «además de» sus disposiciones. Por tanto sigue en pie la pregunta del artículo 35 del Reglamento (UE) 2016/679 sobre si el tratamiento exige una evaluación de impacto. Cuando el sistema es de alto riesgo, el artículo 26, apartado 9, del AI Act añade que el responsable del despliegue usará la información facilitada conforme al artículo 13 para cumplir esa obligación del artículo 35.
¿Desde cuándo existe el artículo 4 bis del AI Act?
Desde el 27 de julio de 2026. Lo inserta el Reglamento (UE) 2026/1744, de 8 de julio de 2026, conocido como Ómnibus digital sobre IA, publicado en el Diario Oficial L, 2026/1744, de 24 de julio de 2026. Su artículo 4 dispone que entrará en vigor a los tres días de su publicación, de modo que el texto del AI Act incluye el artículo 4 bis desde el 27 de julio de 2026. Antes de esa fecha el artículo no existía, así que cualquier documento interno anterior que hable de tratar datos sensibles para medir sesgos se escribió sin esta base.