Workflow Audit para Agent Readiness: Metodologia paso a paso
Como descomponer un proceso de RRHH en puntos de decision y clasificar cada uno para humano, regla o IA. Con ejemplo completo y calculo de Score.
Que aporta esta metodologia
Este articulo describe un metodo repetible para evaluar si un proceso de RRHH - o partes especificas de el - puede ser gestionado por un agente de IA. El metodo produce tres resultados: un mapa de decisiones con cada punto de decision del workflow, una clasificacion de cada punto por tipo y un Agent-Readiness-Score que cuantifica cuanto del proceso es automatizable.
La metodologia es independiente de la tecnologia. No presupone ninguna plataforma de IA, proveedor o stack tecnologico especifico. Funciona igual para organizaciones que evaluan su primer despliegue de agentes que para las que amplian uno existente a nuevos dominios.
Paso 1: Definir el limite del workflow
Antes de analizar puntos de decision, hay que definir que incluye y que excluye el workflow.
Un workflow tiene un disparador (que lo inicia), un conjunto de pasos de procesamiento y uno o mas puntos finales (que constituye su finalizacion). Tambien tiene un limite de alcance: donde interactua con otros workflows.
Ejemplo: Procesamiento de bajas medicas
- Disparador: El empleado presenta un parte de baja medica (papel, email, upload al portal o notificacion del responsable)
- Puntos finales: Registro en SAP actualizado, responsable notificado, nomina ajustada si procede, accion de reincorporacion programada si se supera el umbral
- Limite de alcance: Este workflow NO incluye la entrevista de reincorporacion en si (es un workflow separado). NO incluye el proceso de reintegracion laboral: este se desencadena desde aqui pero se gestiona por separado.
Error frecuente: definir el limite demasiado amplio. “Onboarding” no es un workflow, es una coleccion de 5-8 sub-workflows (generacion de contrato, aprovisionamiento IT, documentacion de compliance, configuracion del puesto, matriculacion en formacion, asignacion de buddy, seguimiento del periodo de prueba). Auditar cada sub-workflow por separado.
Paso 2: Mapear cada punto de decision
Recorrer el workflow desde el disparador hasta el punto final e identificar cada punto donde se toma una decision. Un punto de decision es cualquier momento en que el proceso requiere elegir entre dos o mas caminos basandose en datos de entrada.
La mayoria de las organizaciones subestiman el numero de puntos de decision en sus procesos. La razon: los empleados experimentados toman muchas decisiones de forma inconsciente. No perciben “comprobar si el parte de baja tiene fecha de inicio” como una decision - simplemente lo hacen. Pero para un agente, cada comprobacion de este tipo es una decision explicita que debe especificarse.
Metodo: La tecnica “que podria salir mal”
Para cada paso del workflow, preguntar: “¿Que podria salir mal aqui? ¿Que causaria que este paso fallara o requiriera una accion diferente?” Cada respuesta revela un punto de decision.
Procesamiento de bajas medicas - mapa de decisiones:
| # | Punto de decision | Pregunta que responde el proceso |
|---|---|---|
| 1 | Recepcion del documento | ¿Es un parte de baja, un certificado medico, un informe de rehabilitacion u otra cosa? |
| 2 | Comprobacion de completitud | ¿Contiene el documento: nombre del empleado, inicio del periodo de diagnostico, fin del periodo de diagnostico, nombre del medico, firma del medico? |
| 3 | Identificacion del empleado | ¿A que empleado pertenece este documento? (Coincidencia de nombre, numero de empleado, departamento) |
| 4 | Asignacion de entidad | ¿En que entidad juridica esta este empleado? (Determina las reglas aplicables) |
| 5 | Consulta de convenio colectivo | ¿Que convenio colectivo aplica a este empleado? |
| 6 | Derecho a prestacion por baja | ¿Esta el empleado dentro del periodo de prestacion de IT (segun el Estatuto de los Trabajadores y convenio colectivo aplicable)? |
| 7 | Evaluacion de duracion | ¿Es un solo dia, una ausencia corta (3 dias o menos) o una ausencia prolongada? |
| 8 | Deteccion de patrones | ¿Esta ausencia, combinada con anteriores, activa algun umbral? (p.ej., mas de 20 dias en 12 meses -> revision especifica) |
| 9 | Impacto en nomina | ¿Afecta esta ausencia a la nomina? (Cancelacion de horas extra, complemento de turno, prorrateo de bonus) |
| 10 | Actualizacion del sistema | ¿Que debe actualizarse en SAP/SuccessFactors? (Registro de ausencia, cuenta de tiempo, flag de nomina) |
| 11 | Enrutamiento de notificaciones | ¿Quien debe ser informado? (Responsable directo, HR Business Partner, nominas, comite de empresa si se activa procedimiento de reintegracion) |
| 12 | Programacion de seguimiento | ¿Se requiere una accion de seguimiento? (Fecha de reincorporacion, convocatoria de reunion, derivacion a vigilancia de la salud) |
Doce puntos de decision en un proceso que la mayoria de las organizaciones describen como “el empleado presenta la baja, nosotros la procesamos”. La brecha entre la simplicidad percibida y la complejidad real es tipica.
Paso 3: Clasificar cada punto de decision
Para cada punto de decision, determinar a cual de los tres tipos pertenece. Los criterios de clasificacion deben aplicarse de forma estricta: el error mas comun es clasificar una decision como “basada en reglas” cuando en realidad requiere interpretacion.
Tipo H: Decision humana
La decision requiere una o mas de las siguientes caracteristicas:
- Empatia o juicio individual - el resultado depende de comprender la situacion especifica de una persona, no de aplicar una regla general
- Riesgo legal por automatizacion - una decision automatizada erronea generaria un riesgo legal, financiero o reputacional significativo
- Mandato de consulta del comite - el comite de empresa ha exigido expresamente participacion humana para este tipo de decision conforme al Art. 64 del Estatuto de los Trabajadores
- Sensibilidad etica - la decision implica ponderar intereses en conflicto donde personas razonables discreparian
Pregunta de prueba: “Si dos profesionales experimentados diferentes analizaran el mismo caso, ¿llegarian de forma fiable a la misma conclusion?” Si no - Tipo H.
Tipo R: Basada en reglas (determinista)
La decision sigue logica explicita que puede formularse como una instruccion condicional inequivoca. Todas las siguientes condiciones deben cumplirse:
- La regla existe por escrito - en una ley, convenio colectivo, acuerdo de empresa o procedimiento documentado
- Los datos de entrada son estructurados - nombres, fechas, numeros, codigos, categorias - no texto libre que requiera interpretacion
- El resultado es determinista - ante la misma entrada, la regla siempre produce el mismo resultado
- No hay excepciones que requieran juicio - o las excepciones son ellas mismas basadas en reglas (“si excepcion X, aplicar regla Y”)
Pregunta de prueba: “¿Podria escribir esta decision como una formula en una hoja de calculo, sin interpretacion humana?” Si si - Tipo R.
Tipo A: Elegible para IA (probabilistico con limites)
La decision implica procesar informacion no estructurada o semi-estructurada, pero dentro de limites definidos y con resultados verificables. Todas las siguientes condiciones deben cumplirse:
- La tarea es clasificacion, extraccion o coincidencia - no creacion, juicio ni evaluacion
- Los limites estan definidos - el conjunto de posibles resultados es conocido y finito
- El resultado es verificable - existe una forma de comprobar si la decision de la IA fue correcta
- Se puede establecer un umbral de confianza - el sistema puede expresar certeza, y los casos de baja certeza pueden escalarse a un humano
Pregunta de prueba: “¿Esto interpreta informacion contra categorias conocidas, o juzga una situacion unica?” Si interpreta contra categorias - Tipo A. Si juzga una situacion unica - Tipo H.
Aplicado a nuestro ejemplo de bajas medicas:
| # | Punto de decision | Tipo | Razonamiento |
|---|---|---|---|
| 1 | Clasificacion de documento | A | Entrada no estructurada (documento escaneado), pero clasificacion en categorias conocidas. Puntuable por confianza. |
| 2 | Comprobacion de completitud | A | Extraccion de campos de documento no estructurado. Campos obligatorios conocidos. Verificable. |
| 3 | Identificacion del empleado | A | Coincidencia de nombre contra base de empleados. Puede requerir coincidencia aproximada. Puntuable por confianza. |
| 4 | Asignacion de entidad | R | ID de empleado -> mapeo a entidad es determinista. Tabla de consulta. |
| 5 | Consulta de convenio colectivo | R | Entidad + categoria de empleado -> convenio. Determinista. |
| 6 | Derecho a prestacion por baja | R | Fecha de inicio + historial de ausencias + reglas del Estatuto de los Trabajadores. Calculo puro. |
| 7 | Evaluacion de duracion | R | Calculo de calendario. Determinista. |
| 8 | Deteccion de patrones | R | Historial de ausencias + reglas de umbral. Determinista (aunque la respuesta a un umbral activado puede ser Tipo H). |
| 9 | Impacto en nomina | R | Tipo de ausencia + duracion + reglas retributivas. Determinista. |
| 10 | Actualizacion del sistema | R | Determinada por las decisiones 4-9. Paso de ejecucion. |
| 11 | Enrutamiento de notificaciones | R | Reglas de enrutamiento basadas en entidad, tipo de ausencia, activadores de umbral. Determinista. |
| 12 | Programacion de seguimiento | R | Basada en duracion, umbral y politica. Determinista - aunque la accion de seguimiento en si (p.ej., la reunion de reintegracion) es Tipo H. |
Resultado: 0 humanas, 8 basadas en reglas, 3 elegibles para IA, 1 condicional (R para la programacion, H para la accion de seguimiento en si).
Paso 4: Calcular el Agent-Readiness-Score
El Score es un ratio simple que cuantifica cuanto del workflow es automatizable.
Formula:
Agent Readiness Score = (Cantidad Tipo R + Cantidad Tipo A) / Total puntos de decision x 100
Para nuestro ejemplo de bajas medicas: (8 + 3) / 12 = 91,7%
Es un Score alto. Indica que casi todo el workflow puede ser gestionado por un agente, con participacion humana solo para acciones posteriores (la reunion de reintegracion, la entrevista de reincorporacion) que son workflows separados.
Interpretacion del Score:
| Score | Interpretacion | Recomendacion de despliegue |
|---|---|---|
| >80% | Alta Agent Readiness | Candidato fuerte para despliegue inmediato. La mayoria de los puntos de decision pueden automatizarse. Enfocar el diseno de governance en los pocos traspasos Tipo H. |
| 60-80% | Moderada Agent Readiness | Buen candidato para despliegue por fases. Automatizar primero las decisiones Tipo R y A, mantener Tipo H manual. Esperar carga significativa de Human-in-the-Loop. |
| 40-60% | Readiness mixta | Considerar automatizar solo los sub-procesos basados en reglas. El workflow puede no justificar un despliegue completo de agente, pero se beneficia de automatizacion dirigida de decisiones Tipo R de alto volumen. |
| <40% | Baja Agent Readiness | No recomendado para despliegue de agente a corto plazo. Este workflow depende fuertemente del juicio experto. Invertir primero en documentacion de procesos y estandarizacion. |
Scores tipicos por dominio de RRHH (basado en experiencia practica):
| Dominio | Score tipico | Razon |
|---|---|---|
| Nominas y retribucion | 85-95% | Casi enteramente basado en reglas |
| Control de presencia | 80-90% | Alta densidad de reglas, pocas decisiones discrecionales |
| Procesamiento de gastos | 75-85% | Basado en reglas con algo de clasificacion de documentos |
| Administracion de onboarding | 60-75% | Mix de basado en reglas y semi-estructurado |
| Inscripcion en beneficios | 65-80% | Intensivo en reglas, pero con casos limite de elegibilidad |
| Cribado de candidatos | 40-55% | Juicio significativo en la evaluacion |
| Gestion del desempeno | 20-35% | Fuertemente basado en juicio |
| Relaciones laborales | 15-30% | Casi exclusivamente empatia y juicio |
Paso 5: Documentar el resultado de la auditoria
La auditoria produce un resultado estructurado que sirve a tres propositos: guiar el diseno del agente (¿que decisiones asume el agente?), informar el acuerdo de empresa (¿que decisiones permanecen con el humano?) y cumplir el requisito de documentacion del EU AI Act (¿por que se clasifico esta decision como automatizada?).
Documentacion minima por punto de decision:
- ID del punto de decision y descripcion
- Clasificacion (H, R o A) con razonamiento
- Fuente de la regla (para Tipo R): ¿Que ley, convenio colectivo o politica define esta regla? ¿Que version?
- Umbral de confianza (para Tipo A): ¿A que nivel de confianza la IA decide de forma autonoma vs. escala?
- Ruta de escalado (para Tipo A y casos limite de Tipo R): ¿Quien gestiona el caso cuando el agente no puede decidir?
- Requisito de Audit Trail: ¿Que debe registrarse para esta decision? (Datos de entrada, regla aplicada, resultado, marca de tiempo, agente o humano)
Esta documentacion se convierte en la especificacion para la configuracion del agente. Es tambien el artefacto que revisa el comite de empresa y que examina el auditor.
Errores de clasificacion frecuentes
Error 1: Clasificar como R cuando la regla tiene excepciones que requieren juicio
“Las horas extra se pagan al 150%.” Suena basado en reglas. Pero: ¿Las horas extra en dia festivo se pagan al 200%? ¿Y las horas extra en un turno que cruza la medianoche y entra en dia festivo? ¿Y si el empleado tiene un contrato individual que anula el convenio colectivo?
Si las excepciones requieren juicio humano para resolverse, el punto de decision es Tipo H para la ruta de excepcion - aunque el caso estandar sea Tipo R. El enfoque correcto: clasificar el caso estandar como R y anadir un punto de decision separado para la gestion de excepciones, clasificado como H o A.
Error 2: Clasificar como A cuando el resultado de la IA no es verificable
“La IA evalua si el candidato encaja culturalmente.” Esto no es Tipo A - no hay una respuesta correcta verificable. El encaje cultural es inherentemente subjetivo. Tipo A requiere que el resultado pueda comprobarse: “La IA clasifico este documento como un parte de baja” puede ser verificado por un humano que mire el mismo documento.
Error 3: Confundir la decision con la accion posterior
“La deteccion de patrones desencadena un proceso de reintegracion” - la deteccion es Tipo R (calculo de umbral), pero el proceso de reintegracion contiene decisiones Tipo H (planificacion de la reincorporacion). La auditoria debe separar la decision disparadora del workflow disparado.
Error 4: Ignorar decisiones implicitas
“Comprobamos el parte de baja.” Suena como un paso. Pero contiene al menos tres decisiones: ¿Es un documento valido? ¿Esta completo? ¿Corresponde al empleado? Cada una debe clasificarse por separado. La auditoria debe descomponer hasta que cada punto de decision tenga exactamente una pregunta y una clasificacion.
Que no cubre esta metodologia
Esta auditoria determina la Agent Readiness a nivel de puntos de decision. No determina:
- Secuenciacion y priorizacion - que workflows automatizar primero (depende de criterios estrategicos mas alla de la readiness: volumen de transacciones, complejidad de governance, apetito organizativo)
- Seleccion de tecnologia - que plataforma de IA, modelo o proveedor usar
- Cambio organizativo - como gestionar la transicion para empleados cuyas funciones cambian
- Estrategia de negociacion con el comite de empresa - como estructurar el proceso de informacion y consulta
Estas son cuestiones estrategicas que estan por encima del Workflow Audit. La auditoria proporciona la base factual para esas decisiones.