Onboarding i offboarding z AI — od listy pracowników do sprawnego zarządzania dostępami

W firmie mamy plik z pracownikami i listę narzędzi. Jest Google Workspace: poczta, kalendarz, dokumenty i arkusze. Do tego komputer, telefon, Google Cloud, GitHub, Jira oraz inne aplikacje. Gdy ktoś dołącza, trzeba przygotować mu stanowisko i nadać odpowiednie dostępy. Gdy odchodzi, trzeba te dostępy odebrać, odzyskać sprzęt i zadbać o pozostawione materiały.

Każda z tych czynności jest do wykonania. Trudność polega na dopilnowaniu całości: kto ma co zrobić, w którym systemie, do kiedy i skąd będziemy wiedzieć, że faktycznie to zrobił.

Z AI, czyli sztuczną inteligencją, wykonałem już mały fragment takiej pracy. W jednej z rozmów poprosiłem o uporządkowanie listy kont. Następnie wskazałem, które pozycje mają zostać wypisane do dalszego przekazania. Wybór należał do mnie, a czat pomagał przygotować czytelną listę. Samo jej przygotowanie nie było usunięciem kont.

Chcę rozwinąć ten sposób pracy: połączyć informację o pracowniku z katalogiem narzędzi, zasadami dostępu i potwierdzeniami wykonania. Poniżej opisuję pomysł na taki proces, a nie relację z wdrożenia całej automatyzacji w mojej firmie. W materiale o przygotowaniu firmy do bezpiecznej współpracy opisuję, jak taki podział na właściciela, dowód i kolejny krok pomaga uporządkować zadania.

Przejdźmy go na przykładzie Anny. Anna, jej stanowiska i wszystkie poniższe wyniki są fikcyjnym przykładem, przygotowanym do pokazania procesu bez ujawniania danych pracowników.

Dwie listy to początek. Potrzebujemy jeszcze zasad

Onboarding oznacza tutaj przygotowanie osoby do pracy: od sprzętu po dostęp do potrzebnych informacji. Offboarding to uporządkowanie jej odejścia, w tym odebranie dostępów i przekazanie zasobów.

Sama informacja „Anna pracuje w operacjach” nie mówi jeszcze, do jakich projektów w Jirze powinna mieć dostęp. Lista aplikacji też tego nie rozstrzyga. Potrzebny jest zatwierdzony profil stanowiska: zestaw narzędzi i uprawnień wynikający z obowiązków. AI może pomóc go opisać, ale nie powinno wymyślać firmowych zasad przy każdym nowym pracowniku.

Na początek uporządkowałbym cztery rzeczy w istniejącym arkuszu lub systemie:

Stały identyfikator pomaga połączyć wpis pracownika z jego kontami, nawet gdy zmieni się nazwisko lub adres. Przy niejednoznacznym dopasowaniu AI powinno zgłosić problem. Podobnie brzmiące nazwisko nie wystarcza do wyłączenia konta.

Brak osoby w przypadkowym eksporcie także nie może sam uruchamiać offboardingu. Potrzebujemy potwierdzonej informacji o zmianie, jej terminu i właściwej osoby zatwierdzającej. Pusty wiersz może oznaczać błąd danych.

Anna dołącza do zespołu

W naszym przykładzie Anna zaczyna jako specjalistka ds. operacji. Jej przełożony potwierdza stanowisko i dzień rozpoczęcia pracy. AI zestawia te dane z zatwierdzonym profilem i przygotowuje plan:

„Nie dotyczy” jest tu pełnoprawnym wynikiem. Proces powinien ocenić każdą pozycję katalogu, ale nie zakładać kont we wszystkich narzędziach. Kopiowanie uprawnień kolegi mogłoby przenieść również jego stare wyjątki.

Plan trafia do zatwierdzenia. Przełożony potwierdza potrzebę biznesową, a administrator lub właściciel systemu sprawdza zakres i sposób wykonania. Zgoda powinna dotyczyć konkretnej osoby, organizacji, zasobów i uprawnień. Można zatwierdzić cały jasno opisany pakiet; nie trzeba robić z każdego kliknięcia osobnej decyzji.

Po zatwierdzeniu dostępne integracje wykonują wskazane operacje. Tam, gdzie integracji nie ma albo nie obsługuje danej czynności, powstaje zadanie dla administratora. Wydanie laptopa pozostaje czynnością fizyczną, nawet jeśli AI świetnie przygotuje zgłoszenie.

Co robi AI, co integracja, a co człowiek

Ten podział chciałbym zachować przez cały proces:

AI może korzystać z integracji, ale samo zdanie „konto zostało założone” nie jest dowodem. Raport powinien wskazywać konto, wynik operacji oraz ponowne sprawdzenie stanu w systemie. Przy pracy ręcznej potrzebne jest potwierdzenie administratora, a przy sprzęcie — odbioru lub zwrotu.

Wdrożenie musi też respektować istniejące zarządzanie kontami. Jeśli firma ma już centralny katalog tożsamości i synchronizację, nowy proces powinien z nich korzystać. Równoległe, ręczne zmienianie tych samych kont może prowadzić do sprzecznych stanów. Dostępność automatyzacji trzeba sprawdzić dla używanych usług, konfiguracji i uprawnień integracji.

Anna zmienia rolę. Co trzeba odebrać?

Po pewnym czasie Anna przechodzi do zespołu analiz i automatyzacji. Ma już konto, komputer i telefon. Nie zaczynamy onboardingu od zera. Porównujemy obecny dostęp z potrzebami nowej roli.

W przykładzie plan wygląda tak:

• zachować konto Google Workspace oraz przypisany sprzęt;
• dodać dostęp do materiałów nowego zespołu i właściwego projektu w Jirze;
• odebrać członkostwa i uprawnienia związane wyłącznie ze starymi obowiązkami;
• nadać zatwierdzony dostęp do wskazanego repozytorium GitHub i potrzebnych zasobów GCP;
• ustalić datę wygaśnięcia ewentualnego dostępu przejściowego, potrzebnego do przekazania spraw.

GCP nie powinno być opisane jednym polem „ma dostęp”. Trzeba wiedzieć, do jakich zasobów i z jakimi uprawnieniami. W Google Cloud prawa mogą być dziedziczone z wyższych poziomów: organizacji, folderu lub projektu. Sprawdzenie jednego miejsca nie wystarcza więc do ustalenia całości dostępu. Wyjaśnia to dokumentacja hierarchii uprawnień Google Cloud.

AI może przygotować różnicę: zachowaj, dodaj, odbierz, wyjaśnij. Przy wyjątkach podaje przyczynę i termin ponownego przeglądu. Administrator potwierdza, że nowy zakres działa, a niepotrzebny stary zakres rzeczywiście został odebrany.

Taki przegląd przy zmianie roli pomaga uniknąć sytuacji, w której ktoś przez lata zbiera dostęp do kolejnych zespołów, a żaden wcześniejszy dostęp nie znika.

Anna odchodzi. Dostępy i zasoby to dwie listy zadań

Przy odejściu potrzebujemy potwierdzonego terminu, łącznie z godziną i strefą czasową, oraz aktualnej listy kont. AI porównuje ewidencję z dostępnymi odczytami systemów i wskazuje rozbieżności. System, którego nie sprawdzono, otrzymuje status „brak potwierdzenia”.

W przykładzie Anna jest właścicielką roboczych dokumentów i opiekuje się automatyzacją raportu. Samo wyłączenie jej logowania nie odpowiada na pytanie, kto przejmie te obowiązki.

Dlatego plan rozdziela dwie rzeczy. Pierwsza to odebranie dostępu osobie: konta, członkostwa, aktywne sesje oraz związane z nią poświadczenia, czyli dane pozwalające się uwierzytelnić. Druga to zachowanie potrzebnych zasobów: dokumentów, raportów, zadań i automatyzacji, z wyznaczonym nowym opiekunem.

Przy planowanym odejściu przekazanie przygotowujemy wcześniej. Nie może ono jednak opóźniać odebrania dostępu w zatwierdzonym terminie. Jeśli sprawa wymaga natychmiastowego wyłączenia, dalsze porządkowanie wykonują uprawnieni administratorzy.

Kilka różnic między narzędziami ma tu praktyczne znaczenie:

• Google Workspace: zawieszenie konta służy do zablokowania dostępu do usług z zachowaniem danych. Nie oznacza jednak zakończenia każdej trwającej sesji: Google wskazuje wyjątek dotyczący rozpoczętej rozmowy w Google Chat. Sesje i poświadczenia wymagają więc osobnego sprawdzenia. Usunięcie konta ma inne skutki i wymaga wcześniejszego ustalenia, co przenieść lub zachować. Transfer danych nie jest jedną operacją obejmującą dowolny zasób. Zobacz zasady zawieszenia i usunięcia użytkownika.
• GitHub: odebranie członkostwa w firmowej organizacji jest czymś innym niż usunięcie osobistego konta pracownika. Nie usuwa także jego lokalnych kopii repozytoriów. Opisuje to instrukcja usuwania członka organizacji.
• Jira i Atlassian: odebranie dostępu do firmowego środowiska nie musi oznaczać wyłączenia całego konta Atlassian. Sposób działania zależy m.in. od tego, czy firma zarządza kontem. Rozróżnienie opisują instrukcje odebrania dostępu i dezaktywacji konta zarządzanego.

Nie zakładałbym, że wyłączenie poczty automatycznie zamyka wszystkie pozostałe drogi dostępu. Plan powinien objąć każdy używany system oraz poświadczenia związane z pracownikiem, w tym ewentualne dodatkowe konto administracyjne. Ich unieważnienie i skutek sprawdza administrator zgodnie z konfiguracją narzędzia.

Osobnej uwagi wymaga raport Anny. Na czyim koncie działa automatyzacja? Kto będzie ją utrzymywał? Czy trzeba zmienić sposób uwierzytelnienia i wykonać próbne uruchomienie? Konta techniczne, używane przez programy, należy odróżnić od kont pracowników. Sam fakt, że Anna przygotowała proces, nie oznacza, że trzeba usunąć jego konto techniczne. Trzeba natomiast odebrać jej możliwość korzystania z niego i rozstrzygnąć los poświadczeń, do których miała dostęp.

Do tego dochodzą telefon i komputer: potwierdzenie zwrotu, rozliczenie numeru oraz zabezpieczenie firmowych danych według ustalonej procedury. Przekazanie urządzenia, numeru czy zawartości poczty kolejnej osobie nie powinno następować automatycznie. Wymaga wskazania odbiorcy i zatwierdzonego zakresu; prywatnych danych nie przenosimy razem z firmowymi materiałami.

Raport ma pokazywać stan, a nie dobre intencje

Przykładowy raport z offboardingu Anny mógłby wyglądać tak. To nadal ilustracja procesu, nie wyniki operacji w mojej firmie:

W rzeczywistym raporcie każda pozycja powinna mieć właściciela, termin, identyfikator operacji lub zgłoszenia oraz dowód sprawdzenia. Dane dostępowe i hasła nie są takim dowodem i nie powinny trafiać do raportu.

Rozróżniłbym statusy: proponowane, zatwierdzone, w trakcie, wykonane, potwierdzone, błąd, brak danych. Nieudane działanie pozostaje widoczne. Ponowienie po błędzie powinno najpierw sprawdzić obecny stan, żeby nie zakładać drugiego konta ani nie powtarzać zakończonej operacji.

Komplet zielonych wierszy ma znaczenie tylko dla sprawdzonego zakresu. Jeśli katalog nie zawiera jednego narzędzia albo jego odczyt się nie udał, raport musi zaznaczyć tę lukę. Offboarding zamyka odpowiedzialna osoba po sprawdzeniu zakresu i rozstrzygnięciu wyjątków, nie samo AI po wysłaniu ostatniego zgłoszenia.

Od czego zacząłbym u siebie

Pierwszą wersję ograniczyłbym do przygotowania planu i porównania go z pracą administratora. Jedna rola, jedna fikcyjna osoba, kilka narzędzi. W ten sposób można sprawdzić brakujące dane i błędne założenia przed podłączeniem operacji zmieniających uprawnienia.

Do próby przygotuj zatwierdzony profil roli i zanonimizowane dane. Rzeczywiste dane pracowników przetwarzaj wyłącznie w środowisku dopuszczonym przez firmę, w zakresie potrzebnym do zadania. Nie wklejaj do promptu haseł, kluczy ani tokenów.

Pomóż przygotować plan zarządzania dostępami jednej osoby.
Na tym etapie niczego nie wykonuj i nie wysyłaj zgłoszeń.

Zdarzenie: [dołączenie / zmiana roli / odejście].
Osoba: [identyfikator testowy].
Termin zmiany: [data, godzina, strefa czasowa].
Dane wejściowe: [zatwierdzony profil roli, katalog narzędzi,
obecne konta, uprawnienia i sprzęt oraz data ich sprawdzenia].

Porównaj stan obecny z docelowym. Wskaż: zachowaj, dodaj,
odbierz, przekaż albo wymaga wyjaśnienia.
Nie wymyślaj brakujących uprawnień ani dopasowań kont.

Dla każdej pozycji podaj:
- osobę i właściwy system, organizację, projekt lub urządzenie;
- dokładną czynność oraz jej uzasadnienie;
- kto zatwierdza, kto wykonuje i w jakim terminie;
- czy może wykonać ją dostępna integracja, czy administrator;
- jak sprawdzimy efekt i gdzie zapiszemy potwierdzenie.

Oddziel odebranie dostępu od usunięcia konta oraz zachowania danych.
Uwzględnij dokumenty, automatyzacje i konta techniczne do sprawdzenia.
Wymień wszystkie braki, niejednoznaczności i niesprawdzone systemy.
Wyniki proponowane wyraźnie odróżnij od wykonanych i potwierdzonych.

Dopiero po takiej próbie wybrałbym jedną dobrze opisaną operację do automatyzacji, z zatwierdzeniem zakresu i sprawdzeniem wyniku. Kolejne systemy dołączałbym wtedy, gdy wiadomo, co dana integracja wykonuje i czego nie potrafi potwierdzić.

Dziś mam konkretny punkt wyjścia: wykorzystanie AI do uporządkowania listy kont wskazanych przeze mnie. Następny krok to doprowadzenie tej listy do stanu, w którym przy każdej pozycji widzę odpowiedzialną osobę, wykonaną czynność i potwierdzenie. Wtedy pytanie „czy odebraliśmy wszystkie dostępy?” ma odpowiedź opartą na sprawdzeniu, z jasno pokazanymi wyjątkami.