Sick Leave Processing Agent

Cada mañana llegan nuevos partes de incapacidad temporal al sistema. Los lunes tras una oleada gripal pueden ser decenas. Cada uno desencadena una cascada: asignación al empleado, verificación de si es parte de baja inicial o de confirmación, cálculo de la prestación por IT, comunicación a la Seguridad Social y la Mutua, ajuste en nómina, información al responsable directo - sin datos de diagnóstico. Y en los casos de larga duración: seguimiento de umbrales para la gestión de la reincorporación.

No es una situación excepcional. Es el estado normal. En España, la tasa media de absentismo por IT se sitúa en torno al 7%, con una duración media por proceso que supera los 35 días en contingencias comunes. En una empresa con 2.000 empleados, eso representa miles de días de IT al año - cada uno un acto administrativo con plazos legales y consecuencias económicas por incumplimiento. Solo la prestación por IT y el complemento a cargo de la empresa suponen un coste directo que las organizaciones necesitan gestionar con precisión. El problema no es la complejidad de cada parte individual. El problema es el volumen con tolerancia cero a errores.

Donde se producen los errores

Este agente sigue el principio del Decision Layer: cada decisión está basada en reglas, asistida por IA o asignada explícitamente a una persona.

El cálculo de la prestación por IT parece sencillo: los tres primeros días sin prestación (a cargo de la empresa en función del convenio), del cuarto al vigésimo día el 60% de la base reguladora, a partir del vigésimo primero el 75%. En la práctica, es una de las fuentes de error más frecuentes en la gestión de nóminas. Tres situaciones causan la mayoría de los problemas:

Recaídas y procesos previos. Si un empleado causa baja por la misma patología dentro de los 180 días siguientes al alta anterior, no se inicia un nuevo proceso con su correspondiente período de carencia. Los días previos se acumulan. En la práctica, esto falla regularmente porque nadie cruza el historial de IT de forma sistemática contra grupos de diagnóstico. Resultado: la empresa calcula mal la prestación - paga de más o aplica el recorte antes de tiempo.

Partes de baja y confirmación. Cuando llega un parte de IT, debe decidirse de inmediato: es una baja nueva o la confirmación de una existente? De ello depende si los contadores de días se reinician o continúan. Con procesamiento manual, basta un cruce de fechas incorrecto para desajustar todo el cálculo de prestaciones.

Festivos y modelos de turno. En empresas con jornadas variables, el cálculo de la base reguladora durante la IT es una de las partidas más propensas a error en la nómina. Los festivos dentro de un período de IT se clasifican mal, los complementos de turno no se consideran correctamente.

Cada uno de estos errores genera reprocesamiento: nóminas correctivas, regularizaciones con la Seguridad Social, en el peor de los casos actas de liquidación en una inspección.

Cuatro plazos, cuatro destinatarios, cero margen

Un solo parte de baja afecta simultáneamente a varios procesos y sistemas:

Recepción del parte de IT
    |
    +-- Nómina: Prestación por IT o complemento de empresa?
    |
    +-- Seguridad Social/Mutua: Comunicación dentro de plazo legal
    |
    +-- Responsable directo: Información sin diagnóstico
    |
    +-- Monitor de larga duración: Acumular días, vigilar umbrales

Cada uno de estos cuatro hilos tiene sus propios plazos, sus propios destinatarios, sus propias reglas de protección de datos. La comunicación a la Seguridad Social a través del Sistema RED debe salir dentro del plazo reglamentario. El responsable directo puede saber que alguien está de baja - pero no el motivo. La nómina necesita saber si corresponde prestación o complemento de empresa. Y el monitor de larga duración debe acumular días de IT en segundo plano, durante meses, incluyendo interrupciones.

Manualmente, eso significa: cuatro sistemas distintos, cuatro pasos de tramitación diferentes, con cada parte de baja. Con cien partes al mes, un proceso controlable se convierte en una construcción frágil hecha de recordatorios, hojas de cálculo y confianza en que nada se pierda.

Reglamento en lugar de suposiciones

El agente de procesamiento de IT descompone este proceso en pasos individuales y asigna a cada uno un responsable: regla, análisis de IA o persona.

La gran mayoría de estos pasos es determinista. Asignación del parte por número de empleado y número de afiliación: regla. Cruce de fechas para distinguir baja nueva de confirmación: regla. Cálculo de prestación según normativa de Seguridad Social: regla. Comunicación a la Seguridad Social: regla. Notificación al responsable sin datos de diagnóstico: regla.

Solo en un punto el proceso necesita análisis real: en la valoración de recaídas y procesos previos. Aquí debe cruzarse el historial de IT contra grupos de diagnóstico dentro del período de 180 días. No es una comprobación de sí o no, sino un reconocimiento de patrones sobre categorías médicas. Asistido por IA, pero con un protocolo de decisión transparente - porque cada imputación debe resistir ante una inspección de trabajo.

El umbral de larga duración: donde la automatización se detiene

En los procesos de IT de larga duración, el agente monitoriza la duración acumulada. Cuando un empleado alcanza determinados umbrales - los 365 días de duración máxima de la prestación por IT, o antes si el convenio establece obligaciones de seguimiento - el agente lo detecta con fiabilidad, incluso cuando los días se componen de múltiples bajas cortas repartidas a lo largo de meses.

Pero la gestión de la reincorporación no la inicia el agente. Comunica la superación del umbral a RRHH. La persona decide sobre el momento, la forma y la coordinación del proceso. Esa no es una limitación técnica - es una decisión de arquitectura deliberada. La reincorporación tras una baja de larga duración es una conversación entre personas sobre el futuro de una relación laboral. Ningún algoritmo decide cuándo es el momento adecuado para esa conversación.

Esta delimitación es representativa de todo el proceso: el agente asume volumen, plazos y obligaciones de comunicación. La persona conserva las decisiones que requieren criterio. En muchas organizaciones, los umbrales de larga duración simplemente se pasan por alto en procesos manuales - no porque la empresa ignore su obligación, sino porque el seguimiento acumulado se pierde entre las tareas diarias. Un agente que cuenta los días de forma fiable no resuelve ningún problema de gestión de personas. Pero garantiza que RRHH conozca cada caso.

Los datos de salud exigen una arquitectura de protección propia

Los partes de IT contienen categorías especiales de datos personales según el artículo 9 del RGPD. Eso exige más que permisos de acceso y cifrado. Exige una arquitectura que imponga la minimización de datos.

El agente procesa períodos de IT y grupos de diagnóstico - pero solo donde es estrictamente necesario para el cálculo de prestaciones. Los diagnósticos concretos no se transmiten a los responsables directos, no se almacenan en el texto de notificación, no se registran en el Decision Log. Cada regla de tratamiento está documentada y es consultable por el Comité de Empresa, en el marco de sus derechos de información conforme al artículo 64 del Estatuto de los Trabajadores.

Parece una obviedad. En la práctica de los procesos manuales, no lo es. Quien reenvía partes de IT como PDF por correo electrónico al responsable directo tiene un problema de protección de datos - aunque nadie lo haya provocado intencionadamente. Un agente basado en reglas no tiene este problema de forma estructural, porque la arquitectura de información define qué datos fluyen a qué destinatario.