«El DPO siempre dice no». Esta queja es muy común entre los Directores de Recursos Humanos (DRH) ante la respuesta que obtienen de los Delegados de Protección de Datos cuando les plantean casos de uso de Inteligencia Artificial. No la expresan con resentimiento, sino con el cansancio de quien ha presentado tres proyectos distintos y ha recibido tres veces la misma negativa. Lo que no se habían preguntado —y lo que este artículo intenta responder— es por qué el «no» suele ser la primera respuesta del DPO.
- El DPO no dice no a la tecnología. Dice no a los proyectos que llegan sin la información que necesita para decir sí. El problema es estructural: el proceso estándar de compra de software no está diseñado para el nuevo ecosistema regulatorio de la IA.
- Cuando el DPO entra tardío, las decisiones críticas ya están tomadas. El proveedor está elegido, el calendario no tiene margen y el diseño del sistema está cerrado. En ese momento el DPO no tiene buenas opciones.
- El flujo correcto es sincrónico. El DPO debe incorporarse cuando RR. HH. identifica una necesidad y empieza a explorar el mercado, no cuando ya ha elegido. Cinco datos de negocio concretos son suficientes para que la primera reunión sea productiva.
- Tres condiciones de gobernanza hacen que el modelo funcione. Protocolo de notificación obligatoria, acceso del DPO a la fase estratégica y umbral de activación claro. Sin las tres, la colaboración depende de que alguien se acuerde.
La relación entre el director de RR. HH. y el DPO no debería ser un duelo de argumentos. Más bien debe parecerse a la de dos arquitectos que, desde perspectivas complementarias, diseñan un edificio para que su estructura sea tanto funcional (qué problema operativo resuelve, cómo encaja en los procesos) como segura y conforme a la normativa (qué datos se tratan, qué obligaciones se activan, qué garantías reales ofrece el proveedor). Cuando la arquitectura se diseña junta, el DPO ya no necesita decir «no»; se limita a coordinar el «cómo».
Por qué el proceso de compra tradicional ya no sirve
Cuando un equipo de RR. HH. evalúa un ATS con cribado algorítmico, un sistema de evaluación del desempeño o una plataforma de people analytics, suele seguir el mismo flujo que para cualquier otro software: demo, referencias, comparativa de funcionalidades y negociación de precio. Pero con la IA, el tablero regulatorio ha cambiado por completo.
El Reglamento de IA clasifica como de alto riesgo prácticamente toda la categoría de herramientas utilizadas para la selección, evaluación, asignación de tareas y gestión del comportamiento de los trabajadores. Esto significa que existen obligaciones legales específicas que van mucho más allá del RGPD: evaluaciones de conformidad que el proveedor debe acreditar, documentación técnica detallada que la organización debe auditar y evaluaciones de impacto que deben ejecutarse obligatoriamente antes del despliegue. Hasta ahora, ninguna de estas variables formaba parte del proceso comercial ordinario. Hoy, ignorarlas es un riesgo inasumible.
Lo que ocurre cuando los planos llegan terminados
Cuando el DPO entra en el proyecto con el proveedor ya elegido y el contrato en fase de negociación, las decisiones críticas ya han cristalizado en tres puntos ciegos:
| Punto ciego | Qué ha ocurrido ya | Consecuencia para el DPO |
|---|---|---|
| El proveedor | Seleccionado bajo criterios exclusivamente funcionales o económicos. Nadie preguntó si el sistema usa los datos de la plantilla para entrenar sus modelos, qué subencargados intervienen o cómo acredita su conformidad con el Reglamento de IA. La organización negocia el contrato desde una posición débil: ya ha elegido. |
No puede influir en la selección. Solo puede intentar mitigar en el contrato lo que no se eligió bien. |
| El calendario | Realizar una EIPD requiere, en proyectos de complejidad media, entre 6 y 8 semanas. Si el cronograma no contempla ese margen, la evaluación nace muerta. Una EIPD mal hecha es peor que no hacerla: genera falsa sensación de cumplimiento. |
O hace una revisión superficial o pide parar el proyecto. Ninguna opción es buena. |
| El diseño | Nadie ha definido cómo informar a los candidatos, qué datos tienen prohibido introducir en los prompts ni cómo articular supervisión humana real. Modificar el software después exige reconfigurar, renegociar o renunciar al proyecto. |
Las decisiones de diseño que más afectan al riesgo ya están cerradas. |
En este escenario tardío, el DPO se queda sin opciones: o asume una revisión superficial que camufla riesgos reales, o señala problemas que el proyecto ya no puede financiar, o pide detenerlo, consolidando su injusta fama de bloqueador. Las tres opciones son la consecuencia directa de haber implicado al DPO demasiado tarde.
El orden que funciona: el flujo sincrónico
El DPO debe incorporarse cuando RR. HH. identifica una necesidad y empieza a explorar el mercado, no cuando ya ha elegido la herramienta. No se trata de que el DPO dirija la compra ni de que tenga poder de veto; se trata de trabajar en paralelo sobre los mismos planos desde el primer día.
| RR. HH. | DPO | |
|---|---|---|
| 1 |
Definición
Describe el problema, no la herramienta
«Tardamos 45 días en cerrar un proceso y el cribado consume el 70% del tiempo», no «queremos un ATS con IA».
|
Encuadre
Evalúa el nivel de riesgo del caso de uso
Determina qué evaluaciones serán necesarias antes de elegir proveedor y qué preguntas hay que hacer al mercado.
|
| 2 |
Evaluación
Califica usabilidad y coste
Solicita al proveedor la información que el DPO necesita valorar junto con la funcional.
|
Garantías
Valora la conformidad del proveedor
Clasificación de riesgo, localización de datos, subencargados, política de entrenamiento. Un proveedor que esquiva estas preguntas no mejorará tras la firma.
|
| 3 |
Información
Aporta el contexto de uso
Universo de afectados, decisiones que alimentará el sistema, nivel de autonomía del algoritmo.
|
EIPD y FRIA
Ejecuta las evaluaciones obligatorias
Evaluación de Impacto (EIPD) y, si aplica el Reglamento de IA, la FRIA. El calendario debe absorber este tiempo. Si hay consulta a la AEPD: hasta 14 semanas adicionales.
|
| 4 |
Negociación
Negocia funcionalidades y precio
Con el proveedor seleccionado y evaluado, cierra condiciones comerciales y SLA.
|
Contrato
Revisa los anexos jurídicos
Prohibición de uso de datos para entrenamiento, retención de logs, régimen de responsabilidad y derecho efectivo de auditoría.
|
| 5 |
Despliegue
Forma al equipo y activa protocolos
Uso correcto de prompts e información a trabajadores sobre la existencia del sistema.
|
Revisión continua
Calendariza revisiones por hitos
Actualizaciones del modelo, cambio de proveedor, reajustes del proceso interno, incidentes de seguridad.
|
Qué necesita el DPO de RR. HH. para poder decir «sí»
El DPO que entra en el momento correcto no espera que el equipo de personas le traiga la solución jurídica; para eso está él. Lo que precisa son cinco datos de negocio claros para que la primera reunión sea productiva:
- El objetivo de negocio, no el nombre del software. Cuál es el cuello de botella. «Queremos mejorar la selección» es un dato estéril; «Tardamos 45 días en cerrar un proceso y el cribado de CV consume el 70% del tiempo» permite al DPO buscar el encaje legal óptimo.
- El universo de afectados y la tipología de datos. Volumen estimado de personas, su condición jurídica (candidatos, empleados, contratas) y si la herramienta procesará datos de alto impacto (biométricos, voz, textos de bajas médicas).
- El nivel de autonomía del algoritmo. Si el sistema decide por sí mismo, recomienda un score o es meramente informativo. Si el responsable de RR. HH. puede revertir la propuesta y si esa corrección humana queda registrada (art. 22 RGPD).
- La madurez declarada del proveedor. Qué documentación ha facilitado el comercial: declaración de conformidad, certificados ISO, modelo de contrato de encargado (art. 28). Que el proveedor no disponga de esto ya es, en sí mismo, un indicador de riesgo.
- El calendario real de implantación. Cuándo se estima la salida a producción. Si el margen es insuficiente para evaluar los riesgos, la prioridad de la mesa de trabajo no será recortar el análisis, sino reajustar la fecha de lanzamiento.
Seis situaciones reales que ilustran la diferencia
La distancia entre implicar al DPO en la fase de diseño o en la de firma se evidencia en situaciones que cualquier departamento de RR. HH. reconoce de inmediato:
El ATS que llega por la vía comercial
El proveedor enamora al equipo de selección con una demo espectacular. Al entrar tarde, el DPO actúa como el «aguafiestas» que frena el entusiasmo con exigencias de cumplimiento. Si el DPO participa desde el inicio, los requisitos de transparencia algorítmica se incluyen en el pliego de condiciones de la licitación, forzando al proveedor a competir también en seguridad.
La videoentrevista con análisis de emociones
El módulo de IA viene activado por defecto y se vende como un valor añadido. El DPO advierte, al revisar el contrato, que el análisis sistemático de expresiones faciales y tono de voz constituye un tratamiento de datos de categoría especial (biométricos) que carece de habilitación legal en el ámbito laboral. De haber estado implicado en la fase de necesidades, esa funcionalidad se habría descartado de inmediato, ahorrando semanas de negociación inútil.
El modelo predictivo de absentismo o fuga de talento
RR. HH. introduce datos históricos de la última década para entrenar un modelo predictivo. Nadie advierte que los datos de partida arrastran los sesgos de género o edad de la cultura corporativa pasada; el algoritmo simplemente automatiza y amplifica la discriminación. Además, pretender fundamentar este tratamiento en el consentimiento de la plantilla es inviable por el desequilibrio de la relación laboral. Una intervención temprana del DPO habría reorientado el proyecto hacia análisis puramente agregados y anonimizados, sin impacto individualizado.
El chatbot interno implantado como piloto
Se lanza un piloto rápido que registra conversaciones de empleados donde se mencionan de forma espontánea bajas médicas, conflictos sindicales y problemas familiares. Nadie ha acotado el acceso a esos contenidos ni el borrado de los registros de actividad. El DPO lo detecta meses después cuando se solicita su inclusión en el Registro de Actividades de Tratamiento (RAT). En un flujo sincrónico, la gobernanza de los datos y los perfiles de acceso habrían quedado blindados por diseño antes de abrir la primera ventana de chat.
La supervisión humana puramente formal
El evaluador recibe una puntuación automática del desempeño de un empleado y la valida sistemáticamente por inercia o falta de tiempo. Ante una demanda laboral o una inspección, la empresa es incapaz de demostrar una «intervención humana significativa», confundiendo tener la última palabra con ejercer un control crítico. El DPO, incorporado desde el inicio, diseña el flujo operativo para obligar al evaluador a justificar y registrar los motivos cuando decide apartarse —o seguir ciegamente— el criterio del algoritmo.
El proveedor que firma como «encargado» pero actúa como «responsable»
El contrato estipula formalmente que el proveedor es un mero encargado del tratamiento (art. 28 RGPD). Sin embargo, la letra pequeña desvela que el proveedor decide de forma autónoma qué variables pondera el algoritmo o se reserva el derecho de anonimizar los datos para mejorar su propio software comercial. La naturaleza jurídica de una figura no depende del título del contrato, sino de quién define los fines y los medios del tratamiento. El DPO detecta esta discrepancia antes de que la firma convalide una cesión ilegal de datos.
Tres condiciones de gobernanza para que el proceso funcione
Para que este modelo deje de ser una declaración de buenas intenciones y se convierta en una sistemática corporativa, se requieren tres pilares mínimos:
- Un protocolo de notificación obligatoria. Un procedimiento interno automatizado que obligue a RR. HH. a comunicar al DPO la apertura de cualquier proceso de prospección de mercado para herramientas que traten datos de personas. En entornos de alta presión, si la colaboración depende de la memoria, nunca ocurre.
- Acceso directo a la fase estratégica. Cuando RR. HH. eleva al Comité de Dirección un proyecto estratégico que incorpora IA, el DPO debe tener asiento en esa mesa para evaluar el impacto regulatorio en la toma de decisiones inicial. El artículo 38 del RGPD exige explícitamente que el DPO tenga los recursos y el acceso directo a la alta dirección; no es una recomendación, es un mandato legal.
- Un umbral de activación claro. Para evitar la parálisis por análisis y no saturar la función del DPO, se debe definir por escrito qué proyectos requieren su intervención. La regla es clara: cualquier sistema que procese datos de candidatos o empleados para generar perfiles, predicciones o decisiones automatizadas que afecten a sus derechos laborales se notifica desde el minuto cero.
