“¿Qué procesos de RRHH son aptos para IA?” es la pregunta equivocada
Una directora de RRHH se sienta en el comité de dirección de su programa de IA. En la diapositiva: “Fase 1 - automatizar el procesamiento de bajas médicas”. Seis semanas después el piloto está detenido. La razón: “No funciona con suficiente fiabilidad”. ¿Qué pasó? El proyecto trató el proceso como una única unidad. Pero el procesamiento de bajas médicas no es una unidad. Es una secuencia de doce puntos de decisión - y dos de ellos deberían haber permanecido con el humano.
No es una anécdota. Es el patrón. Los proyectos de IA en RRHH raramente fracasan por la calidad del modelo y casi siempre por la granularidad de la pregunta. Quien pregunta “¿Qué procesos automatizamos?” obtiene respuestas inutilizables. Quien pregunta “¿En qué puntos de decisión dentro del proceso?” obtiene una arquitectura ejecutable.
Esta metodología describe cómo hacer la pregunta correcta. Es independiente de la tecnología - sin preferencia de modelo, proveedor ni stack. De una sola auditoría produce cuatro artefactos: un diseño de agente, una plantilla de acuerdo de empresa, una especificación del Decision Layer y la documentación que el EU AI Act exige para alto riesgo (plazo vigente: 2 de agosto de 2026; aplazamiento a diciembre de 2027 acordado provisionalmente).
McKinsey estima que el 60 - 70 % de las actividades administrativas de RRHH son automatizables con tecnología existente. La adopción está en el 3 %. La brecha no nace del escepticismo. Nace de la falta de un método que descomponga el nivel de proceso al nivel de punto de decisión.
De un vistazo
- "Automatizar el proceso" fracasa. Clasificar puntos de decisión individuales construye una arquitectura auditable.
- Un proceso típico de RRHH tiene 10 - 30 puntos de decisión. El personal experimentado toma la mayoría inconscientemente - por eso faltan en el pliego de requisitos.
- Cada punto de decisión es humano, regla o IA - con tres pruebas claras, no con intuición. La ambigüedad es la trampa de auditoría más frecuente.
- El resultado de la auditoría es a la vez diseño de agente, plantilla de acuerdo de empresa, especificación del Decision Layer y documentación EU AI Act. Cuatro interesados, un documento.
- La impugnabilidad es arquitectura, no anexo de compliance. Quien la atornilla después no tiene IA auditable - independientemente de la calidad del modelo.
Un proceso típico de RRHH tiene doce puntos de decisión, no uno
El mapeo precede a la clasificación. Falla por una peculiaridad del personal experimentado: toman muchas decisiones inconscientemente. “Comprobar si la baja tiene fecha de inicio” no lo perciben como decisión. Simplemente lo hacen. Para un agente, cada comprobación de ese tipo es una decisión explícita que debe especificarse.
El método que saca a la luz esas decisiones implícitas es la técnica del “qué podría salir mal”: para cada paso, preguntar qué podría fallar o requerir otra acción. Cada respuesta revela un punto de decisión.
Antes del mapeo, traza el límite del proceso. Un proceso tiene un disparador, una secuencia de pasos de procesamiento y uno o varios puntos finales. Error frecuente: trazar el límite demasiado amplio. “Onboarding” no es un proceso - es una colección de cinco a ocho sub-procesos (contrato, IT-provisioning, documentación compliance, puesto de trabajo, alta en formaciones, asignación de buddy, seguimiento del periodo de prueba). Auditar cada sub-proceso por separado.
Con el ejemplo del procesamiento de bajas médicas - disparador: el empleado presenta una baja. Puntos finales: registro SAP actualizado, mando informado, nómina ajustada, acción de retorno al trabajo planificada si se supera el umbral. Lo que la mayoría de las organizaciones describen como un paso es una cadena de doce:
| # | Punto de decisión | Pregunta que el proceso responde |
|---|---|---|
| 1 | Recepción del documento | ¿Es baja, parte médico, certificado de rehabilitación u otro? |
| 2 | Comprobación de completitud | ¿Están nombre del empleado, periodo, médico, firma? |
| 3 | Identificación del empleado | ¿A qué empleado pertenece este documento? |
| 4 | Asignación de entidad | ¿En qué entidad legal está el empleado? |
| 5 | Lookup de convenio | ¿Qué convenio colectivo aplica? |
| 6 | Derecho a continuación del salario | ¿Periodo de 6 semanas (§ 3 EFZG, DE) cumplido? ¿Periodo de carencia? |
| 7 | Evaluación de duración | ¿Día único, ausencia corta o larga? |
| 8 | Detección de patrones | ¿Umbral de BEM (DE) superado? |
| 9 | Impacto en nómina | ¿Cancelación de horas extra, plus de turno, prorrateo de bonus? |
| 10 | Actualización del sistema | ¿Qué cambia en SAP/SuccessFactors? |
| 11 | Routing de notificaciones | ¿A quién se informa (mando, HRBP, nómina, comité de empresa)? |
| 12 | Planificación de seguimiento | ¿Fecha de retorno, invitación BEM, derivación a medicina del trabajo? |
Doce puntos de decisión en un proceso que la mayoría describe como “el empleado presenta la baja, nosotros la procesamos”. La brecha entre simplicidad percibida y complejidad real es típica - y es la razón por la que “automatizamos las bajas” como objetivo no produce arquitectura.
Tres tipos de decisión, tres pruebas, una clasificación
Cada punto de decisión pertenece a exactamente uno de tres tipos. La clasificación es binaria. La ambigüedad apunta a un error de auditoría, no a un caso especial.
Tipo H - decide el humano. Empatía, juicio individual, riesgo legal si se automatiza, mandato de codeterminación del Comité de Empresa o sensibilidad ética. Pregunta de prueba: “¿Llegarían dos profesionales experimentados al mismo resultado en el mismo caso?” Si no - Tipo H. El humano permanece donde la ley lo exige. No porque lo haga mejor.
Tipo R - basado en reglas, determinista. La regla existe por escrito (ley, convenio colectivo, acuerdo de empresa, procedimiento documentado). Los inputs son estructurados. El resultado es determinista. Las excepciones son a su vez basadas en reglas - o son puntos Tipo H separados. Pregunta de prueba: “¿Podría escribir esta decisión como fórmula de hoja de cálculo?” Si sí - Tipo R.
Tipo A - elegible para IA, probabilístico con límites. La tarea es clasificación, extracción o comparación - no creación, juicio o evaluación. El conjunto de resultados es conocido y finito. El resultado es verificable. Se puede fijar un umbral de confianza; los casos inciertos escalan. Pregunta de prueba: “¿Estoy interpretando información contra categorías conocidas o juzgando una situación única?” Si categorías - Tipo A.
La tabla de bajas tras la clasificación:
| # | Punto de decisión | Tipo | Razonamiento |
|---|---|---|---|
| 1 | Clasificación del documento | A | Input no estructurado, clasificado en categorías conocidas, evaluable |
| 2 | Comprobación de completitud | A | Extracción de campos con campos obligatorios conocidos, verificable |
| 3 | Identificación del empleado | A | Coincidencia de nombre con fuzzy matching, evaluable |
| 4 | Asignación de entidad | R | ID de empleado → entidad, lookup determinista |
| 5 | Lookup de convenio | R | Entidad + categoría → convenio, determinista |
| 6 | Derecho a continuación del salario | R | Fecha + historial + § 3 EFZG, cálculo puro |
| 7 | Evaluación de duración | R | Aritmética de calendario |
| 8 | Detección de patrones | R | Cálculo de umbral (la respuesta al umbral es punto H separado) |
| 9 | Impacto en nómina | R | Tipo de ausencia + reglas de retribución |
| 10 | Actualización del sistema | R | Paso de ejecución de 4 - 9 |
| 11 | Routing de notificaciones | R | Reglas de routing de entidad, tipo, umbral |
| 12 | Planificación de seguimiento | R | Basado en reglas (la conversación en sí es H, proceso separado) |
Ocho Tipo R, tres Tipo A, ningún Tipo H. Las acciones de seguimiento que requieren juicio humano (la conversación BEM, la entrevista de retorno) son procesos separados con su propia clasificación - están fuera del procesamiento de bajas.
El Score no dice “sí”, dice “dónde permanece el humano”
De la clasificación sale una proporción simple: (Tipo R + Tipo A) ÷ total × 100. Las bajas alcanzan el 91,7 %. Es alto. No significa “menos humano”. Significa que el 91,7 % de las decisiones individuales pueden tomarse arquitectónicamente - mientras la supervisión humana se concentra en lo que la ley y la empatía realmente exigen.
Los umbrales de Score son lógica de despliegue, no escala:
| Score | Lo que dice | Qué hacer |
|---|---|---|
| > 80 % | Alta Agent Readiness | Implementar ahora. Governance se centra en los pocos handoffs H. |
| 60 - 80 % | Moderada | Por fases. R y A primero, H queda manual. Carga relevante de human-in-the-loop. |
| 40 - 60 % | Mixta | Automatizar solo los sub-procesos basados en reglas. Un agente completo aún no se justifica. |
| < 40 % | Baja | No recomendado. Documentación de procesos y estandarización primero. |
Scores típicos por dominio de RRHH: nómina y compensación 85 - 95 %, control horario 80 - 90 %, gestión de gastos 75 - 85 %, administración de onboarding 60 - 75 %, beneficios 65 - 80 %, screening de reclutamiento 40 - 55 %, gestión del desempeño 20 - 35 %, relaciones laborales 15 - 30 %. Reclutamiento y desempeño bajan no por imposibilidad técnica, sino porque son sistemas de alto riesgo según el Anexo III del EU AI Act y la supervisión humana pesa más.
Un resultado de auditoría, cuatro interesados
Por punto de decisión se produce un registro estructurado: ID y descripción, clasificación con razonamiento, fuente de la regla (para R) con versión y periodo de validez, umbral de confianza (para A), ruta de escalado con plazo, especificación del audit-trail y ruta de impugnación. Ese registro tiene cuatro destinatarios:
El equipo de ingeniería lee la clasificación como spec de arquitectura. Donde R - rules engine; donde A - llamada al modelo con confidence-capture; donde H - tarea en cola humana. El registro especifica directamente el Decision Layer - la capa entre agente y sistema destino que orquesta decisiones basadas en reglas y de IA, genera el audit-trail y enruta los escalados.
El Comité de Empresa lee los mismos datos como plantilla de codeterminación. Ve qué decisiones se automatizan, con qué razonamiento, con qué escalado. Un acuerdo de empresa marco puede derivarse directamente de la auditoría, a menudo más rápido que negociar acuerdos específicos por dominio.
El auditor lee versiones de regla y especificaciones del audit-trail como integridad de prueba. Qué regla aplicó cuándo, sobre qué datos, quién decidió. La respuesta está en el registro, no en un documento separado de compliance.
La autoridad de protección de datos lee los mismos datos como documentación EU AI Act y RGPD. Art. 11 (documentación técnica), Art. 12 (registro), Art. 86 (derecho a explicación) y Art. 22 RGPD requieren exactamente esa información.
Cuatro funciones de un solo documento. La auditoría no las produce como subproducto - está construida para ello.
La impugnabilidad es arquitectura, no anexo de compliance
Una decisión automatizada sobre una persona es admisible bajo el EU AI Act y el RGPD solo si la persona afectada puede impugnarla. La impugnabilidad no es un deber atornillado a posteriori - es un requisito arquitectónico planificado desde la primera auditoría.
Por punto de decisión la auditoría aporta cuatro respuestas que en conjunto hacen posible la impugnación. ¿Qué regla o qué modelo decidió en qué versión? Sin versionado la reproducción posterior es imposible. ¿Qué datos sirvieron de base a la decisión - los inputs exactos en el momento de la decisión, no los actuales? ¿Quién decidió - humano, regla o IA - y con qué confianza? ¿Cómo puede la persona presentar recurso - con dirección concreta, plazo e instancia siguiente?
Una consecuencia de la arquitectura: el agente mismo no toma “decisiones” en sentido jurídico. Ejecuta operaciones que el Decision Layer ha autorizado. No es preciosismo semántico. Es la base que mantiene las decisiones auditables cuando se sustituye el modelo de IA, se cambia el proveedor o se descubre un fallo en el modelo.
La clasificación de alto riesgo del EU AI Act afecta directamente a muchos workflows de RRHH: screening de reclutamiento, gestión del desempeño, decisiones de promoción y traslado, asignación de turnos cuando incide en beneficios de personal (Anexo III núm. 4 lit. a y b). Art. 26 ap. 7 obliga adicionalmente a informar a la representación de los trabajadores y a los trabajadores afectados antes del despliegue - no después. La auditoría debe responder por tanto adicionalmente por workflow: ¿este workflow cae bajo el Anexo III? Si sí - se añaden las obligaciones de los art. 11, art. 14, art. 15 y art. 26, y la información previa es condición para entrar en producción.
Para organizaciones fuera de la UE: los requisitos que el EU AI Act enumera explícitamente ya son exigibles en casi cualquier sistema jurídico como interpretación de los deberes generales de diligencia - solo que sin lista clara de obligaciones. Quien construye el Decision Layer conforme al EU AI Act cumple con ello también lo que las autoridades de protección de datos californianas, brasileñas y británicas exigirán en caso de inspección.
Cuatro errores de clasificación distorsionan cualquier auditoría
Una regla con excepciones que requieren juicio se clasifica como Tipo R. “Horas extra al 150 %” suena basado en reglas. Pero: ¿festivo al 200 %? ¿Turno que cruza medianoche en festivo? ¿Contrato individual que sobrescribe el convenio? Cuando las excepciones requieren juicio, la ruta de excepción es Tipo H - aunque el caso estándar sea Tipo R. Solución limpia: caso estándar como R, punto separado para gestión de excepciones como H o A.
Un resultado de IA no verificable se clasifica como Tipo A. “La IA evalúa si el candidato encaja culturalmente.” No es Tipo A - no hay respuesta correcta verificable. El encaje cultural es subjetivo. Tipo A exige verificabilidad: “la IA clasificó este documento como baja médica” puede ser validado por dos humanos sobre el mismo documento. Las evaluaciones subjetivas son Tipo H - siempre.
La decisión disparadora se confunde con la acción posterior. “La detección de patrones dispara un proceso BEM” - la detección es Tipo R (umbral), pero el BEM contiene decisiones Tipo H (planificación del retorno). La auditoría debe separar el disparador del workflow disparado.
Las decisiones implícitas se ignoran. “Comprobamos la baja” suena a un paso. Contiene al menos tres decisiones: documento válido, completo, corresponde al empleado. La auditoría debe descomponer hasta que cada punto tenga exactamente una pregunta y una clasificación.
Qué no resuelve esta metodología
La auditoría entrega Agent Readiness a nivel de punto de decisión y la especificación del Decision Layer. No entrega: secuenciación entre workflows (depende del volumen de transacciones, complejidad de governance, apetito organizativo; ver la lógica H1-H4 en el catálogo de agentes RRHH), selección de tecnología, cambio organizativo ni la estrategia de negociación con el comité de empresa. La implementación concreta del Decision Layer - rules engine, confidence capture, endpoint de impugnación - es tema aparte.
La auditoría proporciona la base fáctica. Estrategia e implementación construyen sobre ella. Quien empieza por la estrategia y mira la base fáctica después, construye la pirámide sobre la punta.
Artículos relacionados
- El EU AI Act se aplica en todo el mundo - por qué el deber de impugnabilidad no nace solo con el plazo de agosto de 2026
- Tres tipos de decisiones: Cuándo el humano, cuándo la IA - la base conceptual de la clasificación H/R/A
- El Decision Layer como patrón arquitectónico - cómo la clasificación se transfiere a una capa ejecutable
- EU AI Act y RRHH: clasificación de alto riesgo - qué workflows de RRHH caen bajo el Anexo III
Bert Gogolin
Director General, Gosign
AI Governance Briefing
IA empresarial, regulación e infraestructura - una vez al mes, directamente de mi parte.