Człowiek w pętli AI w urzędzie

Przed opisaniem funkcji AI należy rozrysować cały proces i zaznaczyć punkty, w których powstaje skutek dla mieszkańca. Inny ciężar ma podsumowanie rozmowy, inny rekomendacja kolejki, a jeszcze inny zmiana priorytetu, odmowa albo zamknięcie sprawy. Dla każdego punktu warto zapisać właściciela, podstawę działania, wymagane informacje, możliwość odwołania oraz koszt opóźnienia lub błędu. Dopiero ta mapa pozwala rozstrzygnąć, czy automatyzacja może działać samodzielnie, jako podpowiedź, czy wcale.

W proponowanym wzorcu Rozeta wspiera porządkowanie informacji i rekomendowanie następnego kroku, natomiast nie zastępuje uprawnionej osoby w decyzji administracyjnej ani ocenie praw mieszkańca. Granica musi być egzekwowana technicznie: konto integracyjne powinno mieć minimalne uprawnienia, a system źródłowy zachować kontrolę nad statusem sprawy. Sama instrukcja w dokumentacji nie wystarczy, jeżeli interfejs lub API pozwala narzędziu wykonać operację, której nie przewiduje uzgodniony zakres.

Progi należy projektować osobno dla typów rekomendacji i grup spraw. Niska pewność jest oczywistym sygnałem eskalacji, ale nie jedynym. Sprzeczne dane, nowy temat, treść wielowątkowa, problem z transkrypcją, kategoria wrażliwa lub możliwy wysoki skutek powinny prowadzić do kontroli nawet przy wysokim wyniku modelu. Reguły muszą być wersjonowane i możliwe do wyłączenia bez zatrzymania podstawowego kanału obsługi.

Eskalacja potrzebuje adresata, czasu reakcji i zachowania kontekstu. Kolejka bez właściciela tworzy tylko nowe opóźnienie. Operator powinien widzieć oryginalną treść, rekomendację, przyczynę skierowania i pola niepewne, a po decyzji pozostawić krótki ślad. Jeśli wymagany czas i liczba kompetentnych osób nie są zapewnione, deklarowany nadzór jest pozorny. Wtedy zakres automatyzacji należy zmniejszyć albo zatrzymać, zamiast obniżać próg wyłącznie po to, by zmieścić się w przepustowości zespołu.

Możliwość korekty powinna istnieć zarówno podczas obsługi, jak i po wykryciu pomyłki. Operator potrzebuje czytelnego sposobu zmiany rekomendacji bez obchodzenia systemu, a organizacja — ścieżki wyjaśnienia, co stało się z konkretną sprawą. Informacja dla mieszkańca musi odpowiadać rzeczywistej roli narzędzia i kanału. Nie należy twierdzić, że człowiek podjął decyzję, jeżeli w praktyce zatwierdzał automatyczny wynik bez czasu i danych do jego oceny.

Kontestowalność nie wymaga ujawniania danych innych osób, tajemnic technicznych ani budowania pozornego, stuprocentowego wyjaśnienia modelu. Wymaga natomiast odtworzenia wersji reguł, istotnych wejść, wyniku, korekt i dalszych działań w zakresie potrzebnym do sprawdzenia procesu. Należy też ustalić, kto odpowiada na zgłoszenie dotyczące błędnej rekomendacji i jak korekta propaguje się do systemów, które zdążyły wykorzystać poprzednią wartość.

Minimalny zapis powinien pozwolić ustalić, jaka wersja rozwiązania i taksonomii działała, jaki typ rekomendacji powstał, czy uruchomiła się reguła eskalacji, kto dokonał weryfikacji i jaki był dalszy krok. Zakres nie powinien automatycznie obejmować pełnej treści każdej rozmowy przez nieograniczony czas. Dla poszczególnych elementów należy ustalić cel, dostęp, retencję i sposób usunięcia, uwzględniając system źródłowy oraz obowiązki organizacji.

Dziennik powinien być chroniony przed nieuprawnioną zmianą i czytelny dla roli kontrolnej, lecz nie może stać się dodatkowym profilem mieszkańca ani ukrytym źródłem danych szkoleniowych. Wskaźniki zbiorcze pomagają obserwować wzrost eskalacji, różnice między kategoriami i zmiany po aktualizacji, ale nie zastępują analizy przypadków. Jeżeli zespół nie potrafi odtworzyć błędnej rekomendacji, powinien ograniczyć zastosowanie do czasu poprawy obserwowalności.

Właściciel usługi odpowiada za cel i akceptowalny sposób obsługi. Właściciel procesu zatwierdza reguły, kategorie i granice decyzji. Role ochrony danych, bezpieczeństwa, dostępności i prawne oceniają właściwe im ryzyka, a dostawca techniczny odpowiada za uzgodnione właściwości rozwiązania, dokumentację zmian i obsługę incydentów. Lista ról musi wskazywać nazwane funkcje organizacyjne oraz ścieżkę eskalacji, nie abstrakcyjne hasło „człowiek”.

Przegląd powinien odbywać się przed zmianą modelu, źródła danych, integracji, celu lub zakresu użytkowników, a także cyklicznie na podstawie błędów i sygnałów operacyjnych. Przepisy, w tym RODO i AI Act, wymagają kwalifikacji konkretnego zastosowania przez właściwe osoby; ten przewodnik nie stanowi opinii prawnej. Jego celem jest stworzenie sprawdzalnej struktury decyzji, dzięki której organizacja potrafi powiedzieć, kto może zatrzymać system i na podstawie jakich dowodów.