AI Agent
Projektujemy automatyzację procesów z jasno określoną rolą aplikacji, wybranych zadań AI i osób odpowiedzialnych za decyzje.
Przed automatyzacją ustalamy uczestników procesu, źródła danych, miejsca opóźnień, wyjątki i możliwe awarie oraz oczekiwany wynik. Jeśli zadanie ma jednoznaczne reguły, logika aplikacji może być prostsza, szybsza i bardziej przewidywalna niż AI.
| Uczestnik | Przykładowa odpowiedzialność | |---|---| | Aplikacja | tożsamość, uprawnienia, walidacja, obliczenia, stan procesu i dozwolone działania | | AI | proponowane kategorie i wartości z dokumentów, podsumowania, szkice odpowiedzi | | Upoważniona osoba | ocena wyjątków, korekty i decyzje wymagające zatwierdzenia |
To przykład podziału ról, nie obowiązkowa architektura. Zakres automatyzacji zależy od danych, skutków błędu i wymagań firmy. Wygenerowanie propozycji nie zmienia danych sprawy.
Rozważmy hipotetyczną obsługę zgłoszeń klientów. Aplikacja zapisuje wiadomość i przypisuje ją według swoich reguł. AI przygotowuje streszczenie i szkic odpowiedzi, a pracownik porównuje je z oryginałem i w razie potrzeby poprawia.
Przy fakturze AI może proponować odczytane pola. Aplikacja sprawdza formaty, kwoty, zgodność z regułami firmy i możliwe duplikaty. Upoważniona osoba weryfikuje dane w dotychczasowym obiegu zatwierdzania.
Inne hipotetyczne zastosowania to uporządkowanie zapytań sprzedażowych przed aktualizacją CRM oraz lista zadań dla nowego pracownika przygotowana z zatwierdzonych informacji. AI nie nadaje tu samodzielnie dostępu, nie zatwierdza płatności ani nie podejmuje wiążących decyzji.
Aplikacja: zapis zgłoszenia i kontrola dostępu
|
+-- AI: propozycja -> aplikacja sprawdza wynik
|
+-- poprawny -> pracownik ocenia / koryguje
| -> kontrola i zapis propozycji oraz oceny
|
+-- błąd / brak -> ustalona obsługa wyjątków
(np. praca ręczna)
Dalsza akcja, np. wysłanie odpowiedzi:
zatwierdzona propozycja + uprawnienia + reguły
-> wykonanie przez istniejącą aplikacjęPo korekcie aplikacja ponownie sprawdza propozycję. Zapisanie jej wraz z oceną nie oznacza wysłania odpowiedzi; odrzucona propozycja nie jest stosowana.
Oryginalny dokument lub zgłoszenie, propozycję AI oraz sprawdzony lub zatwierdzony wynik przechowujemy oddzielnie. Status zadania pokazuje pracę oczekującą, zakończoną i błędy. Dłuższe zadania mogą trafić do kolejki, by nie blokować formularza. Sama kolejka nie zapewnia jednak niezawodnego wykonania.
Przekroczenie czasu, niedostępność dostawcy i błędna odpowiedź nie są sukcesem. Ponowienia mają limit i dotyczą błędów przejściowych, nie każdego niepowodzenia.
Idempotencja oznacza, że ponowienie tej samej operacji nie powiela jej skutków. Numer sprawy nie wystarcza: potrzebny jest klucz operacji, np. sprawa, zadanie i wersja danych, oraz trwały zapis wykonania. Ograniczenie unikalności w bazie i niepodzielny zapis chronią przed równoczesnym utworzeniem zduplikowanych rekordów wykonania. Nie gwarantują jednak pojedynczego wywołania dostawcy; jego obsługę duplikatów trzeba sprawdzić osobno.
Ścieżkę ręczną projektujemy i testujemy dla konkretnego procesu, ustalając, co można dokończyć bez AI i co musi poczekać.
Do AI trafiają tylko potrzebne dane. Aplikacja kontroluje dostęp użytkowników i organizacji, sprawdza wyniki oraz zapisuje istotne decyzje w historii audytu. Wysoka ocena pewności modelu nie dowodzi poprawności danych i nie nadaje uprawnień. Przegląd przez człowieka uzupełnia te zabezpieczenia, ale ich nie zastępuje.
W GiSoft zaczynamy od ograniczonego zakresu. Mierzymy czas obsługi, poprawki pracowników, zaakceptowane propozycje, błędy i koszt ukończonej sprawy. Porównanie z dotychczasową obsługą pozwala zdecydować, czy rozszerzyć automatyzację, zmienić jej zasady, czy zrezygnować z AI w danym kroku.