Guía completa: agentes de IA en RRHH — RGPD, Reglamento de IA y el principio de diseño de Humano (humano.io)

Esta es la guía completa, con el detalle normativo artículo por artículo. Si prefieres antes la versión resumida y práctica, lee Agentes de IA en RRHH: qué pueden hacer solos y qué no, según la ley.

Un chatbot te contesta. Un agente de IA, además, puede leer tu ERP de RRHH, cruzar datos de la plantilla, redactar un comunicado y enviarlo a 300 personas sin que nadie lo revise antes. Esa diferencia —de «responder» a «actuar»— es la que de verdad le importa a la ley. Y es la que casi nadie se para a mirar antes de desplegar un agente.

En Humano (humano.io) trabajamos cada día con RRHH de empresas con plantillas operativas y distribuidas: fábrica, almacén, campo, tienda. Cada vez más nos preguntan lo mismo: «¿podemos meter un agente de IA para gestionar turnos, responder dudas de nómina o avisar de incidencias?». La respuesta corta es sí, pero con una condición: hay que diseñarlo sabiendo qué obligaciones legales activa.

Este artículo no es un tratado jurídico ni sustituye el asesoramiento de un abogado para tu caso concreto. Es una guía práctica para que, como responsable de RRHH, tecnología o cumplimiento, sepas qué preguntas hacerte antes de dar luz verde.

La ley no mira la etiqueta, mira la función

Da igual que lo llames «agente», «asistente» o «bot». Ni el RGPD ni el Reglamento europeo de IA (AI Act) regulan por el nombre del sistema. Regulan por tres cosas:

1. Qué hace: ¿informa, prepara un borrador para que lo revise una persona, o ejecuta directamente una acción con efectos reales (modifica un dato, envía una comunicación, activa un cambio en nómina)?
2. Qué datos utiliza: ¿maneja datos personales de empleados? ¿Datos de categoría especial (salud, afiliación sindical, origen étnico)? ¿Datos de menores, en el caso de becarios?
3. Qué consecuencias tiene: ¿la acción afecta a un derecho o una condición laboral de una persona (horario, salario, evaluación, continuidad del contrato)?

Cuanto más alto el marcador en estos tres ejes, mayor el riesgo jurídico y más obligaciones. Un sistema que solo lee y resume información pública de la empresa no es lo mismo, ante la ley, que uno que decide a quién se le renueva el contrato.

Quién responde: el proveedor de la tecnología y la empresa que la usa

Un error habitual es pensar que, si el agente falla, la culpa es «de la IA» o del proveedor que la construyó. La normativa europea reparte la responsabilidad entre dos papeles distintos, y casi siempre coexisten en el mismo proyecto:

• El proveedor de la tecnología (quien desarrolla el modelo o el agente, o lo comercializa): responde de que el sistema sea seguro, esté documentado y —si es de alto riesgo— cumpla los requisitos técnicos del Reglamento de IA. En términos de protección de datos, normalmente actúa como encargado del tratamiento.
• La empresa que lo usa con sus empleados (el «responsable del despliegue» en el Reglamento de IA, y el responsable del tratamiento en el RGPD): responde de cómo lo configura, para qué lo usa, qué datos le da de comer, quién lo supervisa y qué decisiones deja en sus manos. Esta responsabilidad no se transfiere ni se delega en el proveedor por contrato.

En la práctica: si compras o contratas un agente de IA para RRHH, tú sigues siendo responsable de cómo lo usas dentro de tu empresa, aunque el sistema lo haya construido un tercero. Conviene que el contrato con el proveedor deje claro quién hace qué (encargado del tratamiento, medidas de seguridad, subcontratación) —esto se llama contrato o cláusulas de encargo de tratamiento—, pero eso no te exime de tus propias obligaciones como empresa.

Cuatro niveles de autonomía, cuatro niveles de exigencia

Antes de entrar en el detalle normativo, conviene tener un mapa claro de qué tareas puede asumir un agente y con qué nivel de vigilancia. Es la primera pregunta que nos hacemos con cualquier cliente de Humano (humano.io) que se plantea automatizar un proceso de RRHH:

• Bajo. Buscar información, resumir documentos o conversaciones, responder preguntas frecuentes de empleados. No decide ni ejecuta nada sobre una persona.
• Medio. Preparar documentos o comunicaciones, modificar registros administrativos (por ejemplo, actualizar una fecha de vacaciones ya aprobada), redactar textos que un humano revisa antes de enviar. Requiere supervisión, pero el riesgo es moderado si esa supervisión es real.
• Alto. Recomendar contrataciones, evaluar el desempeño de trabajadores, calcular incentivos o variables, priorizar candidatos en un proceso de selección. Aquí entran en juego el artículo 22 del RGPD y, muy probablemente, la categoría de «alto riesgo» del Reglamento de IA. Exige supervisión humana reforzada, trazabilidad y, casi siempre, evaluación de impacto previa.
• No autorizado (sin intervención humana real). Sancionar, despedir o tomar cualquier decisión jurídicamente relevante sobre una persona sin que un humano la revise y decida de verdad. No es que esté prohibido usar IA para apoyar estas decisiones; es que la decisión final, la que produce efectos, no puede recaer únicamente en el sistema.

Esta escalera es útil como primer filtro: cuanto más alto subes, más obligaciones de las que siguen se activan a la vez.

RGPD aplicado a un agente: ocho preguntas que hay que resolver antes de encenderlo

El RGPD no es una casilla que se marca una vez. Para un agente que toca datos de empleados, hay que resolver, como mínimo, estos ocho puntos:

• Finalidad. ¿Para qué exactamente vas a usar el agente? «Mejorar RRHH» no es una finalidad válida; «resolver dudas de nómina de primer nivel» sí lo es. La finalidad concreta acota qué datos puede tocar y qué no.
• Base jurídica. ¿Qué te legitima a tratar esos datos con el agente? En el ámbito laboral, casi siempre será la ejecución del contrato de trabajo o el interés legítimo del empresario, y en algunos casos una obligación legal; el consentimiento del empleado es poco recomendable como base única, porque en una relación laboral rara vez es libre.
• Minimización. El agente debe ver solo los datos que necesita para su tarea, no todo el histórico del empleado «por si acaso». Si solo necesita el turno de esta semana, no le des acceso a diez años de expedientes.
• Accesos. ¿Quién puede ver lo que el agente produce, y quién puede revisar lo que consulta? Un agente conectado a datos de nómina o salud no debería ser accesible, ni siquiera indirectamente, a cualquier mando intermedio.
• Conservación. ¿Cuánto tiempo se guardan las conversaciones, los prompts y las salidas del agente? Necesitas un plazo definido y un criterio de borrado, igual que con cualquier otro dato de RRHH.
• Proveedores. Si el agente corre sobre un modelo de un tercero (OpenAI, Anthropic, Google, etc.), ese tercero es un encargado del tratamiento y necesitas un contrato de encargo (DPA) en regla, además de conocer dónde y cómo procesa los datos.
• Transferencias internacionales. Si ese proveedor procesa datos fuera del Espacio Económico Europeo (típicamente, EE. UU.), hace falta una garantía válida: adhesión al marco de adecuación UE-EE. UU. (Data Privacy Framework) o cláusulas contractuales tipo. No des por hecho que «está en la nube» significa que está en Europa.
• Entrenamiento de modelos. Hay que asegurarse contractualmente de que los datos de tus empleados no se usan para entrenar o mejorar el modelo del proveedor salvo que lo hayas decidido expresamente y tengas base jurídica para ello. La mayoría de proveedores serios ofrecen esta garantía para clientes empresariales, pero hay que comprobarla, no asumirla.

Decisiones automatizadas y el artículo 22 del RGPD

El artículo 22 del RGPD da a cualquier persona el derecho a no ser objeto de una decisión basada únicamente en tratamiento automatizado (sin intervención humana significativa) cuando esa decisión le produzca efectos jurídicos o le afecte de modo similarmente significativo. En RRHH, esto cubre selección de personal, evaluación de desempeño, promoción o despido.

Hay excepciones (que la decisión sea necesaria para el contrato, esté autorizada por una ley, o exista consentimiento explícito), pero incluso en esos casos el RGPD exige salvaguardas mínimas: derecho de la persona a obtener intervención humana, a expresar su punto de vista y a impugnar la decisión. Si tu agente puede, por ejemplo, descartar automáticamente candidaturas o marcar a alguien para no renovación sin que nadie revise ese resultado antes de comunicarlo, estás en el terreno exacto que este artículo regula.

Evaluación de impacto (DPIA) cuando exista alto riesgo

Cuando el tratamiento —por su naturaleza, alcance o finalidad— entrañe un alto riesgo para los derechos de las personas, el RGPD obliga a hacer una evaluación de impacto relativa a la protección de datos (DPIA) antes de poner en marcha el tratamiento, no después. Esto aplica típicamente cuando el agente hace evaluación sistemática de personas basada en tratamiento automatizado con efectos significativos, o cuando trata datos de categoría especial a gran escala.

En la práctica: si vas a usar un agente para evaluar desempeño, priorizar candidatos o tomar decisiones sobre condiciones de trabajo de forma sistemática, encarga la DPIA antes del despliegue, no la dejes como papeleo posterior. Es, además, tu mejor documento de defensa si alguien reclama.

IA de alto riesgo en selección, evaluación o gestión de trabajadores

El Reglamento europeo de IA clasifica explícitamente como sistemas de alto riesgo los usados para: reclutamiento y selección (incluida la publicación de ofertas dirigidas, el filtrado de candidaturas o su evaluación), y para decisiones sobre las condiciones de la relación laboral —promoción, extinción, asignación de tareas según comportamiento o rasgos personales, y evaluación del rendimiento—.

Si tu agente entra en esta categoría, las obligaciones incluyen: sistema de gestión de riesgos, gobernanza de los datos de entrenamiento, documentación técnica, registro de eventos (logs), supervisión humana efectiva, y niveles adecuados de precisión, robustez y ciberseguridad. Una obligación que se pasa por alto con frecuencia: el Reglamento exige informar a los trabajadores afectados y a sus representantes de que van a estar sujetos a un sistema de IA de alto riesgo, antes de ponerlo en marcha, no después.

Transparencia: que la persona sepa que interactúa con una IA, y sus límites

Si un empleado escribe a un agente pensando que habla con una persona de RRHH, hay un problema de transparencia. La normativa europea exige que, salvo que sea evidente por el contexto, se informe a la persona de que está interactuando con un sistema de IA. Y no basta con decir «esto es un bot»: conviene explicar, en lenguaje llano, qué puede hacer bien (responder dudas frecuentes) y qué no (tomar decisiones definitivas, sustituir a un responsable humano en casos complejos o sensibles).

Esto no es solo una obligación legal: es lo que evita que un empleado confíe una decisión importante —una baja médica, un conflicto con un compañero— a un sistema que no está diseñado para gestionarla.

Supervisión humana real: un botón de «aprobar» no basta

Aquí está uno de los puntos donde más empresas fallan sin darse cuenta. Poner un botón de «aprobar» delante de una decisión generada por IA no es supervisión humana si la persona que lo pulsa no tiene tiempo, información o criterio real para cuestionar el resultado. Si un responsable aprueba veinte evaluaciones de desempeño en tres minutos porque «el sistema ya lo ha analizado», esa firma no es una revisión: es un trámite.

Supervisión humana real significa que la persona que revisa: tiene acceso a la información en la que se basó el agente (no solo a su conclusión), tiene la competencia y el tiempo para cuestionarla, y tiene autoridad real para cambiar el resultado sin fricción ni presión. Diseñar el flujo de trabajo para que esto sea posible —y no solo teóricamente posible— es responsabilidad de la empresa, no del proveedor de la IA.

Permisos mínimos: separar lectura, escritura, envío, eliminación y ejecución

Un mismo agente no debería tener automáticamente permiso para todo solo porque tiene acceso a un sistema. El principio de mínimo privilegio, aplicado a un agente de IA, significa separar con claridad:

• Lectura: qué datos puede consultar.
• Escritura: qué registros puede crear o modificar.
• Envío: si puede comunicarse directamente con empleados, clientes o terceros.
• Eliminación: si puede borrar datos o registros.
• Ejecución: si puede activar acciones con efectos reales (aprobar, pagar, dar de baja, cambiar un turno en firme).

Un agente que solo necesita leer incidencias de fichaje para redactar un resumen no necesita permiso de envío masivo ni de escritura en nómina. Cuantos más de estos permisos acumule sin necesidad real, mayor la superficie de error y de riesgo si algo falla o si alguien lo manipula.

Registro y trazabilidad

Tienes que poder reconstruir, después de los hechos, qué datos consultó el agente, qué produjo y por qué, y quién lo aprobó. Sin este registro no hay forma de defenderte ante una reclamación de un empleado, una inspección de trabajo o una auditoría del RGPD, ni de detectar un fallo sistemático a tiempo. Para los sistemas de alto riesgo, el propio Reglamento de IA obliga a mantener este tipo de registros automáticos (logs) durante un periodo determinado.

Ciberseguridad: prompt injection, accesos indebidos, filtraciones y órdenes maliciosas

Un agente con capacidad de actuar es también, por definición, una nueva superficie de ataque:

• Prompt injection: instrucciones maliciosas escondidas en un documento, un correo o un mensaje que el agente procesa, diseñadas para hacer que actúe fuera de su cometido (por ejemplo, que filtre datos o envíe algo que no debía).
• Accesos indebidos: si las credenciales del agente están sobredimensionadas (más permisos de los necesarios) o mal protegidas, un fallo o una filtración se convierte en una puerta abierta a todo el sistema.
• Filtraciones: datos de empleados que salen de tu perímetro a través del propio proveedor de IA o de un tercero mal configurado.
• Órdenes maliciosas: alguien —dentro o fuera de la empresa— que intenta engañar al agente para que ejecute una acción dañina disfrazándola de instrucción legítima.

La defensa práctica combina lo ya dicho —permisos mínimos, supervisión humana en las acciones sensibles— con medidas técnicas: validación de las acciones antes de ejecutarlas, límites de velocidad y volumen, y revisión periódica de qué puede hacer realmente el agente frente a lo que necesita hacer.

Derechos laborales e información a los representantes de los trabajadores

Más allá de la protección de datos, el Estatuto de los Trabajadores reconoce a la representación legal de los trabajadores el derecho a ser informada sobre cuestiones que afectan a las condiciones de trabajo. Desde 2021, la normativa española añade expresamente el derecho a conocer los parámetros, reglas e instrucciones de los algoritmos que puedan afectar a la toma de decisiones que incidan en las condiciones de trabajo, el acceso y mantenimiento del empleo, y la elaboración de perfiles (la norma nacida a raíz de la llamada «Ley Rider», pero que no se limita al reparto).

Si tu agente reparte turnos, prioriza tareas, evalúa rendimiento o influye en la asignación de trabajo, esta obligación de informar a los representantes de los trabajadores se activa aunque el sistema nunca llegue a tomar una decisión de despido. Es un paso que muchas empresas se saltan simplemente porque no saben que existe.

Formación de usuarios y supervisores

Ningún agente es más seguro que la persona que lo usa o lo supervisa. Quien revisa las salidas de un agente necesita entender qué puede fallar (alucinaciones, sesgos, datos desactualizados), cuándo escalar una decisión, y qué implicaciones legales tiene aprobar sin más una recomendación automatizada. Esto no es un curso puntual: es formación que hay que mantener a medida que el agente cambia de capacidades.

Una prohibición que se pasa por alto: el reconocimiento de emociones en el trabajo

El Reglamento europeo de IA prohíbe, con carácter general, los sistemas de IA que infieran las emociones de una persona en el entorno laboral —por tono de voz, expresión facial o patrones de comportamiento—, con excepciones muy acotadas por razones médicas o de seguridad (por ejemplo, detectar fatiga en tareas de riesgo). Un agente que analice el «estado de ánimo» de los empleados a partir de sus mensajes o llamadas para uso general de gestión de personas entra directamente en esta prohibición, no en una zona gris.

Ejemplos aplicados a RRHH

• Un agente que resume las incidencias de fichaje de la semana para que el responsable de turno decida → nivel bajo, sigue siendo herramienta de apoyo.
• Un agente que redacta un comunicado interno que RRHH revisa y envía → nivel medio, con supervisión real es perfectamente asumible.
• Un agente que prioriza candidaturas en un proceso de selección a partir de datos del CV → nivel alto: sistema de alto riesgo bajo el AI Act, exige supervisión humana significativa, trazabilidad y aviso previo a la persona candidata.
• Un agente que decide y comunica directamente a un empleado que su contrato no se renueva, sin revisión humana → no autorizado: decisión automatizada del artículo 22 RGPD sin las salvaguardas exigidas.

El principio de diseño que aplicamos en Humano (humano.io)

El agente puede buscar, explicar, resumir, calcular y preparar borradores. No puede adoptar ni ejecutar autónomamente decisiones que produzcan efectos laborales, económicos o jurídicos relevantes sobre una persona. Estas actuaciones requieren revisión y confirmación expresa de un usuario autorizado.

Esta frase no está pensada para una política de privacidad que nadie lee. Es un principio de diseño: condiciona cómo construimos cada función de IA en Humano (humano.io), desde el primer boceto.

Y aquí está el punto que de verdad importa: el cumplimiento no se resuelve con un aviso. Escribir «la IA puede equivocarse» en letra pequeña no protege a nadie —ni a tu empresa, ni a tus empleados— si por debajo el sistema puede escribir, enviar o decidir sin que nadie lo frene a tiempo. La responsabilidad no se delega en un disclaimer: se construye en el producto. En la práctica, eso significa:

• Permisos por rol. No todo el mundo necesita que el agente pueda hacer lo mismo: un responsable de turno no tiene por qué poder darle acceso a nóminas; un administrador no tiene por qué delegarle una decisión de despido.
• Acceso a los datos estrictamente necesarios. El agente ve lo que necesita para la tarea concreta, no todo el histórico de la persona «por si acaso».
• Confirmaciones. Antes de cualquier acción con efecto real sobre una persona, alguien con autoridad y contexto tiene que decir «sí, adelante» de forma explícita, no como trámite.
• Acciones reversibles. Siempre que sea posible, lo que hace el agente se puede deshacer. Si no se puede deshacer, no se automatiza sin confirmación humana previa.
• Registros. Queda constancia de qué datos vio el agente, qué propuso y quién lo aprobó. Sin esto no hay forma de defenderse ante una reclamación ni de aprender de un error.
• Aislamiento entre empresas. Los datos y las acciones de cada cliente viven en su propio compartimento. Un fallo o una manipulación en una empresa no puede filtrarse ni afectar a otra.
• Supervisión humana efectiva. No un botón de aprobar por inercia: una persona con tiempo, información y autoridad real para cambiar el resultado.

Esto es, en esencia, lo que el RGPD llama «protección de datos desde el diseño» (artículo 25) y lo que el Reglamento de IA exige como supervisión humana efectiva en sistemas de alto riesgo: no algo que se añade al final, sino algo que se decide antes de escribir la primera línea de código.

La regla práctica que nos llevamos

Diseña la autonomía del agente de fuera hacia dentro: empieza por definir qué decisiones NUNCA debe tomar solo (las que afectan a derechos o condiciones laborales de una persona) y, a partir de ahí, decide qué puede automatizar sin supervisión. Es más fácil ampliar la autonomía de un agente que ha nacido prudente que recortarla después de un incidente.

No toda IA aplicada a RRHH es «de alto riesgo» por defecto: depende de su finalidad, de los datos que usa y de las consecuencias reales de lo que hace. Pero cuando sí lo es, la diferencia entre una empresa preparada y una expuesta no está en el marketing de su proveedor de IA, sino en si ese principio de diseño se puede comprobar, línea a línea, en el producto que usa.

En Humano (humano.io) construimos herramientas de comunicación interna y RRHH pensadas precisamente para que la persona siga en el centro del proceso: visibilidad de lo que se comunica, quién lo aprueba y qué queda registrado.

¿Quieres ver cómo aplicamos este principio en la gestión de turnos, la comunicación interna y los procesos de RRHH? Habla con nuestro equipo y te lo enseñamos con casos reales.

Este artículo es una guía práctica y divulgativa, no asesoramiento jurídico individualizado. Para tu caso concreto, reserva una DEMO personalizada. Fuentes: Reglamento de IA (UE) 2024/1689, RGPD (arts. 13, 14, 22, 25, 28, 32 y 35), guías de la Agencia Española de Protección de Datos (AEPD), Estatuto de los Trabajadores y documentación de la Comisión Europea.