Sick Leave Processing Agent

Każdego ranka w systemie pojawiają się nowe e-ZLA. W poniedziałki po fali grypy bywają ich dziesiątki. Każde pojedyncze zwolnienie uruchamia kaskadę: przypisanie do pracownika, sprawdzenie czy to pierwsze zwolnienie czy kontynuacja, obliczenie okresu wynagrodzenia chorobowego od pracodawcy, analiza historii nieobecności pod kątem wcześniejszych zwolnień, powiadomienie ZUS, korekta payroll, informacja do przełożonego - bez diagnozy. A przy przypadkach długoterminowych: monitorowanie progu nieobecności.

To nie jest sytuacja wyjątkowa. To normalność. Przeciętnie od 14 do 18 dni chorobowych na pracownika rocznie w Polsce, trend stabilny na podwyższonym poziomie. W organizacji z 2 000 pracowników oznacza to 28 000 do 36 000 dni chorobowych rocznie - każdy z nich akt administracyjny z ustawowymi terminami i konsekwencjami przy zaniedbaniu. Same koszty wynagrodzenia chorobowego od pracodawcy (art. 92 Kodeksu Pracy: 33 dni, potem zasiłek ZUS) stanowią ogromne obciążenie budżetowe. Problem nie tkwi w złożoności pojedynczego zwolnienia. Problem tkwi w wolumenie przy zerowej tolerancji na błąd.

Gdzie powstają błędy

Agent działa zgodnie z zasadą Decision Layer: każda decyzja jest oparta na regułach, wspierana przez AI lub przypisana człowiekowi.

Obliczenie okresu wynagrodzenia chorobowego na podstawie art. 92 Kodeksu Pracy brzmi prosto: 33 dni wynagrodzenia od pracodawcy (14 dni dla osób powyżej 50. roku życia), potem zasiłek chorobowy z ZUS. W praktyce jest to jedno z najczęstszych źródeł błędów w naliczeniu wynagrodzeń. Trzy konstelacje powodują najwięcej problemów:

Sumowanie nieobecności. Gdy pracownik w ciągu roku kalendarzowego choruje wielokrotnie, dni wynagrodzenia chorobowego od pracodawcy kumulują się. W praktyce regularnie zawodzi to na ręcznym śledzeniu sumy dni. Rezultat: pracodawca płaci wynagrodzenie chorobowe, choć uprawnienie już się wyczerpało - albo przechodzi na zasiłek ZUS zbyt wcześnie.

Ciągłość i kontynuacja. Gdy wpływa e-ZLA, trzeba natychmiast ustalić: czy to nowa niezdolność do pracy, czy przedłużenie istniejącej? Od tego zależy, czy 33-dniowy limit biegnie dalej, czy od nowa. Przy ręcznym przetwarzaniu wystarczy jedno błędne porównanie dat, by cała kalkulacja się posypała.

Podstawa wymiaru wynagrodzenia chorobowego. Obliczenie podstawy z 12 lub 6 miesięcy wstecz, z uwzględnieniem składników stałych i zmiennych, premii i dodatków - to algorytm o wielu zmiennych. Ręczna kalkulacja przy złożonych strukturach wynagrodzenia jest podatna na błędy przy każdym drugim przypadku.

Cztery terminy, cztery odbiorcy, zero marginesu

Pojedyncze zwolnienie lekarskie dotyczy równolegle kilku procesów i systemów:

Wpływ e-ZLA
    |
    +-- Payroll: wynagrodzenie chorobowe czy zasiłek ZUS?
    |
    +-- ZUS: powiadomienie (termin ustawowy)
    |
    +-- Przełożony: informacja bez diagnozy
    |
    +-- Monitor nieobecności: kumulacja dni, kontrola progu

Każdy z tych czterech wątków ma własne terminy, własnych odbiorców, własne reguły ochrony danych. Powiadomienie do ZUS musi wyjść terminowo. Przełożony może się dowiedzieć, że ktoś jest chory - ale nie na co. Payroll musi wiedzieć, czy obowiązuje wynagrodzenie chorobowe, czy zasiłek. A monitor nieobecności musi w tle sumować dni - przez miesiące, przez przerwy.

Ręcznie oznacza to: cztery różne systemy, cztery różne kroki przetwarzania, przy każdym pojedynczym zwolnieniu. Przy stu zwolnieniach miesięcznie beherrschowalny proces zamienia się w kruchy konstrukt z przypomnień, arkuszy Excel i zasady nadziei.

Silnik reguł zamiast zgadywania

Sick Leave Processing Agent rozkłada ten proces na poszczególne kroki i dla każdego przypisuje decydenta: silnik reguł, analiza AI lub człowiek.

Zdecydowana większość tych kroków jest deterministyczna. Przypisanie e-ZLA na podstawie numeru pracownika: silnik reguł. Porównanie dat - pierwsze zwolnienie czy kontynuacja: silnik reguł. Obliczenie wynagrodzenia chorobowego wg art. 92 KP: silnik reguł. Powiadomienie ZUS: silnik reguł. Informacja do przełożonego bez danych diagnostycznych: silnik reguł.

Tylko w jednym miejscu proces wymaga analizy: przy kumulacji i nakładaniu się nieobecności. Tu trzeba zbadać historię zwolnień pod kątem powiązań i ciągłości. To nie jest prosta odpowiedź tak/nie, lecz rozpoznawanie wzorców w złożonej historii nieobecności. Wspomagane AI, ale z transparentnym protokołem decyzyjnym - bo każda kalkulacja musi wytrzymać weryfikację przed sądem pracy.

Próg długoterminowej nieobecności: gdzie automatyzacja się kończy

Przy długotrwałych chorobach agent monitoruje kumulatywną długość nieobecności. Gdy pracownik zbliża się do 182 dni zasiłku chorobowego (lub 270 dni przy gruźlicy), zmienia się traktowanie prawne i finansowe. Agent rozpoznaje ten próg niezawodnie - nawet gdy dni składają się z kilku krótszych nieobecności, rozłożonych na miesiące, z przerwami.

Ale: samej decyzji o dalszym postępowaniu agent nie podejmuje. Zgłasza przekroczenie progu do HR. Człowiek decyduje o formie i czasie działania. To nie jest ograniczenie techniczne - to świadoma decyzja architektoniczna. Kwestie związane z rentą, rehabilitacją zawodową czy dalszym zatrudnieniem to rozmowy między ludźmi o przyszłości stosunku pracy. Żaden algorytm nie decyduje, kiedy jest odpowiedni moment na taką rozmowę.

To rozgraniczenie jest symptomatyczne dla całego procesu: agent przejmuje wolumen, terminy i obowiązki meldunkowe. Człowiek zachowuje decyzje wymagające osądu.

Dane zdrowotne wymagają własnej architektury ochrony

Zwolnienia lekarskie zawierają szczególne kategorie danych osobowych wg art. 9 RODO. To wymaga czegoś więcej niż uprawnień dostępu i szyfrowania. Wymaga architektury wymuszającej minimalizację danych.

Agent przetwarza okresy niezdolności i typy zwolnień - ale tylko tam, gdzie jest to absolutnie konieczne do kalkulacji. Konkretne diagnozy nie są przekazywane przełożonym, nie są zapisywane w treści powiadomień, nie są protokołowane w Decision Log. Każda reguła przetwarzania jest udokumentowana w porozumieniu z radą zakładową i dostępna do wglądu.

Brzmi jak oczywistość. W praktyce procesów ręcznych tak nie jest. Kto przesyła zwolnienia lekarskie jako PDF mailem do przełożonego, ma problem z ochroną danych - nawet jeśli nikt nie wywołał go celowo. Agent regułowy strukturalnie tego problemu nie ma, ponieważ architektura informacyjna określa, które dane trafiają do którego odbiorcy.