A finales de septiembre, la Agencia Española de Protección de Datos (AEPD) publicó una advertencia a una empresa que estaba preparando una herramienta para evaluar candidaturas. La idea era bastante sencilla: analizar currículums, darles una puntuación y utilizarla para priorizar personas en procesos de selección y movilidad interna.
La herramienta todavía no se había puesto en marcha. La empresa había informado a su plantilla de que pensaba utilizarla y la AEPD intervino antes de que lo hiciera.
Me parece un caso interesante porque permite observar dos problemas distintos que aparecen en una misma aplicación. Por un lado, el tratamiento de los datos personales de quienes buscan trabajo. Por otro, las responsabilidades que asumes cuando decides para qué va a utilizarse un sistema de IA.
Y hay una pregunta que merece la pena hacerse desde el principio: ¿qué pasa si esa herramienta la construye tu propio equipo utilizando la API de un tercero?
No hace falta entrenar un modelo para acabar siendo proveedor de un sistema de alto riesgo. En determinados casos, basta con desarrollar una aplicación, darle una finalidad concreta y ponerla en servicio bajo tu nombre. El artículo 25 del AI Act añade otros supuestos para quienes parten de sistemas que ya existían.
Qué le ha dicho la AEPD a la empresa
La advertencia publicada el 23 de septiembre de 2026 insiste en cuatro cuestiones que deberían estar resueltas antes de implantar una herramienta así:
- Protección de datos desde el diseño. Hay que tenerla en cuenta cuando se plantea el proyecto, no cuando ya está funcionando.
- Evaluación de riesgos y, cuando corresponda, evaluación de impacto en protección de datos (EIPD). Si el tratamiento puede entrañar un alto riesgo para las personas, debe evaluarse antes de empezar.
- Transparencia. Las personas candidatas y trabajadoras tienen que entender que se está utilizando una herramienta para evaluarlas y qué papel tiene su puntuación.
- Supervisión humana efectiva. La empresa había explicado que la decisión final sería humana. La AEPD recordó que esa persona debe poder cuestionar el resultado y decidir con criterio propio. Firmar automáticamente la recomendación de la máquina no sirve.
Conviene aclarar algo: una advertencia no es una sanción. Es una actuación preventiva. La Agencia está señalando riesgos antes de que se produzca el tratamiento previsto.
Aquí también aparecen dos evaluaciones con nombres parecidos que es fácil confundir. La EIPD viene del RGPD y analiza los riesgos del tratamiento de datos personales. La FRIA, prevista en el artículo 27 del AI Act, estudia el impacto sobre derechos fundamentales de determinados usos de sistemas de alto riesgo.
La FRIA no se exige a cualquier empresa por utilizar uno de esos sistemas. Su ámbito se limita, con los matices del artículo 27, a ciertos responsables del despliegue, como organismos públicos, entidades privadas que prestan servicios públicos y determinados usos en solvencia y seguros. Una empresa privada que criba currículums para sus propias contrataciones no está obligada a hacer una FRIA solo por ese motivo. Eso no elimina sus obligaciones bajo el RGPD.
El currículum también viaja dentro del prompt
Cuando pensamos en una evaluación de impacto, es fácil quedarse en lo que hace la aplicación. Pero hay otra parte igual de importante: qué ocurre con la información que enviamos al modelo.
Imagina que la herramienta manda el currículum completo en cada petición. Ahí pueden viajar el nombre, la fecha de nacimiento, la fotografía, la trayectoria profesional y otros datos personales. Si la aplicación se utiliza para movilidad interna, también puede incorporar información de empleados que ya trabajan en la compañía.
Entonces empiezan las preguntas que debería hacerse cualquier equipo técnico antes de desplegarla. ¿Qué datos necesita realmente el modelo? ¿Quién procesa las peticiones? ¿Dónde se ejecuta la inferencia? ¿Hay proveedores adicionales? ¿Se guardan los prompts y las respuestas? ¿Durante cuánto tiempo?
La arquitectura importa mucho en estas respuestas. Puedes ejecutar un modelo en infraestructura europea con condiciones contractuales que excluyan la retención del contenido, o llamar a una API que procese datos en otros países y conserve parte de las solicitudes. Cada configuración exige revisar sus garantías, los encargados del tratamiento y, cuando proceda, las transferencias internacionales.
Pero el control de la infraestructura tampoco resuelve todas las decisiones de diseño. Si mandas una fotografía o una fecha de nacimiento que no necesitas para evaluar una candidatura, el problema comienza antes de que se haga la llamada a la API.
Reducir esos datos ayuda a limitar la exposición de información personal y puede eliminar algunas señales que introducirían sesgos en la evaluación. No garantiza, por sí mismo, que el sistema deje de discriminar: el modelo puede inferir características sensibles a partir de otros datos.
Lo que no necesita la evaluación se queda fuera de la petición. La minimización reduce la exposición, pero no elimina el riesgo de sesgo.
Además, hay que distinguir la retención del proveedor de inferencia de la trazabilidad de tu propia aplicación. Que la API no conserve el contenido de las peticiones puede ser una buena garantía. Tu sistema seguirá necesitando los registros y evidencias adecuados, con acceso limitado y plazos de conservación justificados, para explicar cómo funcionó y qué decisiones se tomaron.
Cómo un prompt puede cambiar tus obligaciones
Volvamos al ejemplo de los currículums.
Imagina que el equipo técnico monta una aplicación sobre un modelo de propósito general. Entre las instrucciones del sistema escribe algo parecido a esto:
Eres un asistente de selección de personal. Lee el currículum adjunto, puntúa de 1 a 10 su encaje con la oferta y descarta las candidaturas por debajo de 5.
No has entrenado ningún modelo ni modificado sus pesos. Quizá apenas has escrito unas cuantas líneas de código.
Ahora bien, has creado una aplicación que evalúa y filtra candidaturas. El Anexo III del AI Act incluye expresamente esos usos relacionados con el empleo entre los sistemas de alto riesgo, sin perjuicio de las excepciones y condiciones del artículo 6.
El modelo es de un tercero; la finalidad la fija tu prompt. Si la aplicación evalúa y filtra candidaturas, entra en el Anexo III y tú eres su proveedor.
El detalle interesante es que buena parte de la finalidad del sistema puede quedar recogida en instrucciones escritas en lenguaje natural. En aplicaciones tradicionales, esa lógica estaba repartida entre el código, los datos y las reglas de negocio. Con los modelos de propósito general, un archivo de texto puede cambiar considerablemente el comportamiento de una aplicación.
Por eso conviene tratar los prompts que gobiernan funciones sensibles con el mismo cuidado que el resto del software: revisarlos, versionarlos, probarlos y documentar sus cambios.
Si desarrollas esa aplicación y la pones en el mercado o en servicio bajo tu nombre, puedes ser su proveedor desde el principio, conforme a la definición general del AI Act. Si partes de una herramienta que ya existía y cambias su uso, entra en juego además el artículo 25.
Las tres situaciones del artículo 25
El artículo 25 explica cuándo un distribuidor, importador, responsable del despliegue o tercero pasa a considerarse proveedor de un sistema de IA de alto riesgo. Contempla tres situaciones.
Los tres supuestos del artículo 25 en los que pasas a ser proveedor de un sistema de alto riesgo.
1. Pones tu nombre o tu marca en un sistema de alto riesgo
Partes de un sistema de alto riesgo que ya se ha comercializado o puesto en servicio y lo presentas bajo tu marca. El reglamento contempla que puedas asumir la condición de proveedor incluso aunque no hayas cambiado su funcionamiento, sin perjuicio de los acuerdos contractuales previstos.
2. Modificas sustancialmente un sistema de alto riesgo
Haces cambios relevantes en un sistema que ya era de alto riesgo y sigue siéndolo después de la modificación.
Puede haber cambios de arquitectura, lógica de decisión o entrenamiento. Pero hacer fine-tuning o modificar un prompt no constituye automáticamente una modificación sustancial. Hay que estudiar el alcance del cambio, lo que estaba previsto en la evaluación original y sus efectos sobre el cumplimiento o la finalidad del sistema.
3. Cambias la finalidad de un sistema y lo conviertes en uno de alto riesgo
Esta es probablemente la situación más fácil de pasar por alto.
Coges una herramienta que no estaba considerada de alto riesgo, incluido un sistema de IA de uso general ya comercializado o puesto en servicio, y modificas su finalidad para utilizarlo en una actividad que sí entra en esa categoría.
Una aplicación que responde preguntas sobre documentos puede acabar utilizándose para clasificar candidatos o evaluar la solvencia de personas. En ese momento conviene revisar si el nuevo uso cambia su clasificación y quién asume las obligaciones de proveedor.
Hay un matiz importante: utilizar un modelo de propósito general como componente de una aplicación nueva no equivale automáticamente al supuesto de cambio de finalidad del artículo 25. Primero hay que identificar qué sistema se ha desarrollado, quién lo ofrece o pone en servicio y cuál es su uso previsto.
¿Entonces cualquier aplicación con IA es de alto riesgo?
Por supuesto que no.
Resumir documentación interna, preparar borradores de correos, ayudar a programar o responder preguntas sobre una base de conocimiento no convierte automáticamente una aplicación en un sistema de alto riesgo. Hay que analizar su finalidad y el funcionamiento real.
Tampoco eres necesariamente proveedor porque tu empresa compre una herramienta de cribado y la utilice conforme a las instrucciones de su fabricante. En principio actuarías como responsable del despliegue, con las obligaciones que correspondan a ese papel. La situación cambia si transformas la herramienta o se da alguno de los supuestos del artículo 25.
El artículo 6.3 contempla además ciertas excepciones para sistemas incluidos inicialmente en el Anexo III. Por ejemplo, tareas procedimentales limitadas, determinadas tareas preparatorias o sistemas que detectan patrones sin sustituir ni influir materialmente en la evaluación humana, siempre que se cumplan las condiciones del reglamento.
Piensa en dos instrucciones:
Resume este currículum para que una persona pueda revisarlo.
Puntúa el currículum y descarta a quienes tengan menos de cinco.
El primer caso podría encajar en una excepción si realmente se limita a una tarea preparatoria y cumple el resto de requisitos. El segundo interviene directamente en la evaluación y el descarte de personas, así que no puede tratarse como un simple resumen administrativo.
Además, cuando un sistema realiza elaboración de perfiles de personas físicas en los términos relevantes del reglamento, el artículo 6.3 no permite acogerse a esas excepciones. Si un proveedor considera que su sistema está exento, tiene que justificarlo y documentarlo antes de comercializarlo o ponerlo en servicio, además de cumplir las obligaciones de registro aplicables.
El nombre que le pongas a la herramienta importa bastante menos que lo que hace cuando alguien la utiliza.
Qué pasa con el proveedor original
El artículo 25 también aborda la relación entre el proveedor inicial y quien asume ese papel después de transformar el sistema.
Cuando se cumple alguno de sus supuestos, el proveedor original deja de ser considerado proveedor de ese sistema concreto a los efectos establecidos en el artículo. Eso no hace desaparecer otras obligaciones que pueda tener, por ejemplo, respecto a un modelo de propósito general.
El reglamento prevé que coopere con el nuevo proveedor y facilite determinada información, documentación técnica y acceso para pruebas, con las condiciones y excepciones correspondientes.
Hay una excepción especialmente relevante: si el proveedor original había dejado claro que su sistema no debía transformarse en uno de alto riesgo, puede quedar excluido de esa obligación de cooperación.
Esto cambia bastante la conversación con un proveedor. Si vas a construir una aplicación regulada sobre una tecnología ajena, deberías comprobar desde el principio qué usos permite, qué garantías ofrece y qué documentación puede facilitarte.
Descubrir que necesitas esos materiales cuando ya tienes el producto funcionando es una mala manera de empezar.
Qué obligaciones asumes como proveedor
Cuando se aplica el régimen de alto riesgo, las exigencias van bastante más allá de publicar una política de privacidad.
El artículo 16 del AI Act , junto con el resto de disposiciones aplicables, establece obligaciones sobre gestión de riesgos, gobernanza de datos, documentación técnica, registros, instrucciones de uso, supervisión humana, exactitud, robustez, ciberseguridad, gestión de la calidad y evaluación de conformidad. Según el caso, también corresponden el marcado CE y los registros exigidos por el reglamento.
Buena parte de ese trabajo consiste en poder explicar cómo se comporta el sistema, qué riesgos se han identificado y qué mecanismos existen para detectarlos y corregirlos.
En muchos sistemas del Anexo III, la evaluación de conformidad se realiza mediante control interno, sin que una entidad externa tenga que certificar cada aplicación. Eso tampoco significa que baste con declarar que todo está bien: hay que cumplir y documentar los requisitos aplicables.
En octubre de 2026 se publicó en el Diario Oficial de la UE la referencia a la norma armonizada EN 18286:2026, centrada en los sistemas de gestión de la calidad exigidos por el artículo 17. Aplicarla puede otorgar presunción de conformidad respecto de los requisitos que cubre, pero no equivale a una certificación general de cumplimiento de todo el AI Act.
Las fechas han cambiado, pero hay obligaciones que ya se aplican
El Reglamento (UE) 2026/1744, conocido como Ómnibus digital sobre IA, retrasó la aplicación de determinadas obligaciones de alto riesgo:
- 2 de diciembre de 2027: sistemas clasificados conforme al artículo 6.2 y al Anexo III, como muchos de los usos en empleo.
- 2 de agosto de 2028: sistemas clasificados conforme al artículo 6.1 y al Anexo I.
Son las fechas previstas para las secciones correspondientes del capítulo III. No significan que hasta entonces se pueda utilizar cualquier aplicación sin controles.
En selección de personal ya se aplica el RGPD, incluidas sus obligaciones de transparencia, protección de datos desde el diseño, evaluación de impacto cuando proceda y las garantías frente a determinadas decisiones exclusivamente automatizadas.
También existen obligaciones laborales. El artículo 64.4.d del Estatuto de los Trabajadores reconoce derechos de información de la representación legal sobre parámetros, reglas e instrucciones de algoritmos que afectan a decisiones laborales. Y desde el 5 de octubre de 2026, el Real Decreto 723/2026 contempla nuevas obligaciones de información escrita a las personas trabajadoras sobre la existencia de sistemas algorítmicos o automatizados de toma de decisiones y, en los supuestos previstos, sobre sus criterios y reglas de funcionamiento.
Las obligaciones de alto riesgo llegan en 2027 y 2028. Las de protección de datos e información laboral ya se aplican.
Así que esperar a 2027 para empezar a documentar estas herramientas sería un error.
Pensemos en algo muy concreto. Dentro de un año, alguien te pregunta por qué se descartó una candidatura. ¿Puedes recuperar qué versión del modelo se utilizó? ¿Qué instrucciones tenía la aplicación? ¿Qué datos recibió y qué intervención humana hubo?
Si trabajas con un modelo de pesos abiertos, puedes fijar y documentar una versión concreta de los pesos y de la configuración desplegada. Eso facilita el control, aunque reproducir exactamente una salida también depende del entorno de ejecución y los parámetros de inferencia. Con una API de terceros, tendrás que revisar qué garantías de versionado ofrece el proveedor y cómo comunica los cambios.
En ambos casos, el registro y la justificación de las decisiones siguen siendo responsabilidad de quien opera el sistema, dentro de los límites y obligaciones que le correspondan.
Cinco cosas que revisaría antes de desplegar una aplicación así
- Documentar la finalidad. Escribir con claridad para qué se va a utilizar cada sistema y qué decisiones puede influir. Si alguien propone un uso nuevo, volver a evaluarlo.
- Versionar el modelo y las instrucciones. Guardar las versiones relevantes de prompts, modelos, configuraciones y cambios. Tratar las modificaciones sensibles como cambios de software que necesitan revisión.
- Revisar qué datos se envían. Minimizar la información, comprobar quién procesa las solicitudes, dónde se ejecutan y cuáles son las condiciones de retención y seguridad.
- Comprobar los términos del proveedor. Revisar los usos permitidos y qué documentación, soporte técnico y garantías pueden proporcionar cuando el sistema está sujeto a obligaciones adicionales.
- Dejar constancia de la clasificación y de las decisiones. Si crees que una tarea de resumen es preparatoria y puede acogerse al artículo 6.3, documentar por qué, verificar que el comportamiento real coincide con esa descripción y revisar si hay elaboración de perfiles.
Estas preguntas deberían formar parte del diseño del producto. Resolverlas cuando ya hay personas afectadas y decisiones tomadas suele salir bastante más caro.
El caso de la AEPD me parece una buena advertencia para cualquiera que esté construyendo aplicaciones sobre modelos de terceros. La facilidad con la que hoy podemos añadir una función de IA a un producto hace que resulte tentador saltarse algunas preguntas incómodas. Conviene hacérselas antes: qué datos utiliza, qué decisiones influye, quién responde por su funcionamiento y qué podremos demostrar si algo sale mal.
La infraestructura puede ayudarte a controlar el procesamiento, la retención y las versiones de los modelos. La finalidad que le das a la aplicación, y las consecuencias que tiene para las personas, necesitan el mismo nivel de atención.
Fuentes y lecturas recomendadas
- AEPD: notas de prensa, incluida la advertencia sobre análisis de currículums del 23 de septiembre de 2026 .
- AI Act: texto consolidado del Reglamento (UE) 2024/1689 , especialmente artículos 3, 6, 16, 17, 25 y 27 y Anexos III y IV.
- Reglamento (UE) 2026/1744: cambios en los plazos del AI Act .
- Comisión Europea: primera norma armonizada de apoyo al AI Act (EN 18286:2026) .
- Real Decreto 723/2026 sobre información laboral .
- RGPD , especialmente artículos 22, 25 y 35.
Este artículo tiene carácter divulgativo y no constituye asesoramiento jurídico.
