AI odpowiada na e-mail: dobry tekst może trafić do złej rozmowy

Dwie wiadomości mają temat „Termin montażu”. W obu klient pisze uprzejmie i prosi o potwierdzenie piątku. Jedna dotyczy małej wystawy w Gdyni, druga stoiska we Wrocławiu. Asystent przygotowuje zgrabną odpowiedź, wybiera właściwą datę i kończy „Do zobaczenia na miejscu”. Niestety w tej rozmowie „na miejscu” oznacza drugie miasto.

To fikcyjny przykład błędu, którego nie wykryje korekta samego akapitu. Jakość odpowiedzi e-mail zależy także od tego, do której wiadomości została przypisana, z której skrzynki ma wyjść i kto ją otrzyma. Tekst może być bez zarzutu, a cała operacja nadal błędna.

Przyjmijmy, że zespół Most chce używać AI do przygotowywania szkiców odpowiedzi na pytania organizatorów. Wysyłkę zatwierdza pracownik. Odbiór funkcji odbywa się na kontach i materiałach testowych, bez wiadomości do rzeczywistych klientów. Zespół sprawdza zarówno treść szkicu, jak i jego powiązanie z rozmową oraz adresatami. Poniższe przypadki tworzą plan takiego odbioru; wyniki własnego rozwiązania trzeba dopiero zebrać.

Temat pomaga znaleźć rozmowę, ale jej nie identyfikuje

Zadanie „odpowiedz na mail o terminie” pozostawia zbyt wiele miejsca na wybór. W próbce Mostu obie rozmowy mają ten sam temat, podobną datę i podobny początek. Asystent powinien dostać jednoznaczne wskazanie wiadomości, która jest podstawą odpowiedzi. Weryfikator zachowuje jej identyfikator i powiązanie z wątkiem, czyli łańcuchem wiadomości w tej samej rozmowie.

Nie należy zastępować tego powiązania nazwą projektu odgadniętą z treści. Numer sprawy w systemie firmy może pomóc człowiekowi, ale integracja musi jeszcze wskazać właściwą wiadomość w używanej usłudze pocztowej. Przy odbiorze porównaj obie wartości: sprawę biznesową oraz techniczny cel operacji. Jeden poprawny identyfikator nie naprawia drugiego.

Gdy wskazana wiadomość jest niedostępna, narzędzie powinno pokazać ten brak i poprosić o ponowne wskazanie materiału. Samodzielne wybranie kolejnej rozmowy o podobnym temacie zmienia zadanie. W próbce usuń dostęp do jednej fikcyjnej wiadomości i sprawdź, czy proces kończy się na tej granicy, zamiast przygotować wiarygodnie wyglądającą odpowiedź w innej sprawie.

Dokumentacja wątków Gmail API wymienia warunki dołączenia szkicu lub wiadomości do wątku: wskazanie threadId, odpowiednie nagłówki References i In-Reply-To oraz zgodny temat. Samo dopasowanie tematu nie zastępuje tych warunków. To opis mechanizmu Gmail API, a nie uniwersalna instrukcja dla wszystkich systemów poczty.

W raporcie Mostu powinno więc znaleźć się oznaczenie źródłowej wiadomości i docelowej rozmowy. Do zwykłego podglądu dla pracownika można dobrać czytelny skrót: projekt, data ostatniej wiadomości i nadawca. W razie wątpliwości użytkownik otwiera pełny kontekst. Nie musi odczytywać ciągu technicznych znaków, żeby rozpoznać, czy odpowiada organizatorowi z Gdyni.

Próba z podobnymi tematami powinna wymagać dwóch różnych, z góry ustalonych odpowiedzi. Jeśli oba szkice brzmią „potwierdzamy”, pomyłka może pozostać niewidoczna. Niech w jednej fikcyjnej rozmowie potwierdzenie dotyczy godziny dziewiątej, a w drugiej pracownik ma poprosić o uzupełnienie miejsca rozładunku. Wtedy widać, czy materiał z jednej sprawy przeniknął do drugiej.

„Odpowiedz” i „odpowiedz wszystkim” to dwa zadania

W pierwszym przypadku Most odpowiada tylko osobie prowadzącej sprawę. W drugim dołącza wskazanego koordynatora. W trzecim oryginalna wiadomość została przekazana wewnętrznie z pytaniem: „Jak to rozwiązać?”. Odpowiedź na taką wiadomość może być przeznaczona dla współpracownika, choć w cytowanej treści znajduje się adres klienta.

Niech zespół jawnie wybierze zamierzoną operację. „Przygotuj propozycję dla mnie”, „utwórz odpowiedź do nadawcy” i „utwórz odpowiedź wszystkim uczestnikom” muszą dawać rozróżnialne wyniki. Słowo „odpisz” nie rozstrzyga, czy adresy z pola DW mają wrócić do kopii. Model nie powinien samodzielnie rozszerzać grona odbiorców tylko dlatego, że ktoś został wspomniany w treści.

W przypadku przekazanej korespondencji sprawdź również cytowany fragment. Wewnętrzna uwaga pracownika nie powinna trafić do zewnętrznego szkicu tylko dlatego, że leży obok wiadomości klienta. Przygotuj próbkę z wyraźnie oznaczoną, sztuczną notatką wewnętrzną i osobnym pytaniem organizatora. Oceń treść odpowiedzi oraz dołączony cytat, nie wyłącznie nowo wygenerowane zdania.

Microsoft Graph opisuje createReplyAll jako utworzenie szkicu odpowiedzi, który jest wysyłany osobną operacją. Dokumentacja zwraca też uwagę na pole replyTo, gdy oryginalna wiadomość wskazuje inny adres do odpowiedzi. Własna integracja musi poprawnie wykorzystać ten mechanizm; nazwa widocznego nadawcy nie wystarcza do oceny adresatów.

W próbce uwzględnij więc różnicę między nazwą wyświetlaną a właściwym adresem. Dwie osoby mogą występować jako „Koordynator”, choć reprezentują inne organizacje. Podgląd powinien pozwalać sprawdzić adresy oraz role pól Do i DW. Jeśli narzędzie używa także UDW, czyli ukrytej kopii, ten zakres wymaga osobnego sprawdzenia przed dopuszczeniem funkcji. Nie wnioskuj o nim ze zwykłej listy uczestników rozmowy.

Pracownik powinien zobaczyć odbiorców zapisanych w przygotowanym szkicu. Lista, którą asystent dopisał w wyjaśnieniu pod odpowiedzią, może opisywać inny zestaw. Zdanie „odpowiedź przygotowana tylko dla organizatora” jest deklaracją; sprawdzony zbiór adresów w operacji pokazuje rzeczywisty zamiar wysyłki. Przy odbiorze porównaj je ze sobą.

Dodaj próbę ze wspólną skrzynką zespołu oraz osobistym kontem pracownika, jeśli oba występują w planowanym obiegu. Ten sam tekst i zestaw adresatów nie rozstrzygają, z którego konta ma wyjść odpowiedź. W podglądzie wskaż rzeczywistą tożsamość nadawczą, a w kluczu zapisz oczekiwaną. Zmiana konta powinna być widoczna przed oceną operacji.

Szkic ma swoją wersję

Załóżmy, że pracownik sprawdził treść i adresatów, lecz zanim zatwierdził szkic, zmienił się jego odbiorca. Dawna zgoda nie powinna bez śladu obejmować nowej operacji. Zatwierdzenie trzeba związać z konkretną wersją: treścią, wiadomością źródłową, kontem nadawczym i kompletem adresów.

To szczególny przypadek zatwierdzania działań AI przez człowieka. Podgląd musi pokazywać to, co zostanie wykonane. Przycisk akceptacji obok ładnego tekstu nie daje pracownikowi kontroli nad niewidocznym celem operacji.

Dla Mostu dobry przebieg testowy wygląda tak: utwórz szkic odpowiedzi w jednej rozmowie, odczytaj go z używanego systemu, porównaj pola z kluczem próby, a następnie zmień jeden istotny element. Sprawdź, czy aplikacja rozpoznaje zmianę i ponownie przedstawia aktualny stan do oceny. Odbiorcą testowym pozostaje kontrolowane konto zespołu, a nie klient.

Jeśli szkic zawiera załącznik, oznacz go numerem sprawy i porównaj z przygotowaną próbką. Dwie fikcyjne wyceny mogą mieć taką samą nazwę pliku, lecz inną zawartość. Ustal też, czy narzędzie ma dołączyć dokument, udostępnić link czy pozostawić sam tekst. Wybór innego sposobu przekazania wymaga sprawdzenia dostępu odbiorcy, a nie tylko poprawnego brzmienia zdania „w załączeniu”.

Osobno sprawdź ręczną edycję treści. Pracownik może usunąć niepewną obietnicę terminu, a asystent przy kolejnym przygotowaniu szkicu przywrócić wcześniejsze zdanie. Podgląd powinien wyraźnie odróżniać propozycję asystenta od ręcznie poprawionej wersji. Ten problem łączy się z równoczesną zmianą rekordu przez AI i człowieka: trzeba rozstrzygnąć, który stan był podstawą pracy i który ma zostać zachowany.

W ofercie Aeneia Audit takim punktem wyjścia może być konkretny obieg wiadomości: od wyboru sprawy przez przygotowanie szkicu do odpowiedzialności za wysyłkę. Pozwala to rozmawiać o sprawdzalnej czynności, a nie tylko o tym, czy model pisze przyjemnym tonem.

Nowa wiadomość może unieważnić dobrą odpowiedź

Most otrzymał rano pytanie o możliwość montażu w piątek. Szkic jest gotowy, lecz przed zatwierdzeniem klient dopisuje: „Zmiana planu, proszę wstrzymać potwierdzenie”. Odpowiedź na poprzedni stan rozmowy może być poprawna językowo i nieaktualna w chwili wykonania.

W próbie sprawdź, czy narzędzie ponownie rozpoznaje stan wątku przed kolejnym krokiem. Jeśli integracja nie potrafi wykryć takiej zmiany, ustal ograniczenie pracy i obowiązek ręcznej kontroli. Nie pokazuj pracownikowi dawnego szkicu jako odpowiedzi na najnowszą wiadomość. Etykieta „gotowe” powinna odnosić się do wskazanego materiału, z którego powstała propozycja.

W kolejnym przebiegu nowa wiadomość zmienia wyłącznie zestaw odbiorców DW. To pozwala odróżnić kontrolę treści od kontroli całej operacji: propozycja zdania może nadal pasować, lecz dotychczasowy zestaw adresów już nie. Zespół powinien świadomie określić, na którą wiadomość odpowiada oraz kto ma uczestniczyć w tej odpowiedzi. Sam wybór ostatniego tekstu w rozmowie nie rozstrzyga obu kwestii.

Zdarzenie o nowym e-mailu może też dotrzeć do automatyzacji z opóźnieniem. Automatyzacja może wtedy rozpocząć pracę na dawnym impulsie, choć w skrzynce czeka już dalsza część rozmowy. Kontrola spóźnionych zdarzeń pomaga oddzielić dawny impuls do pracy od aktualnego stanu sprawy. Przy poczcie ta różnica może decydować o sensie całej odpowiedzi.

Warto przetestować również przekazanie sprawy do innego pracownika. Nowa osoba powinna rozpoznać, czy szkic czeka na ocenę, został zmieniony, czy wiadomość już wysłano. Oznaczenie zgłoszenia jako „obsłużone” po samym wygenerowaniu tekstu może ukryć brak odpowiedzi. Przy klasyfikacji wiadomości przez AI kategoria i dalszy stan obsługi wymagają odrębnej kontroli.

Odbiór kończy się na wyniku operacji

Przy wdrożeniu obejmującym wysyłkę próbę prowadzi upoważniona osoba w kontrolowanym środowisku. Zapisanie szkicu nie jest dowodem wysłania, a potwierdzenie przyjęcia operacji nie oznacza jeszcze, że wszystkie zamierzone konta zobaczyły właściwą wiadomość. Ustal z wykonawcą, jaki dowód jest dostępny na każdym etapie i jak obsługuje się niepewny wynik. W próbie na kontrolowanych kontach porównaj wiadomość po stronie nadawczej i odbiorczej, wraz z powiązaniem rozmowy. Nie wystarczy zrzut ekranu szkicu wykonany przed operacją.

Nie uruchamiaj ponownie wysyłki tylko dlatego, że ekran długo nie pokazuje odpowiedzi. Najpierw trzeba rozstrzygnąć stan poprzedniej operacji. W raporcie zachowaj identyfikator sprawy, szkicu i wykonania oraz rzeczywistego nadawcę. Szczegółowość zapisu dobierz do potrzeby kontroli; kopiowanie całej korespondencji do kolejnego raportu nie jest domyślnie konieczne.

Jeśli próbka ujawni skierowanie materiału do niezamierzonego adresata, zanotuj dokładny mechanizm pomyłki i zatrzymaj dany sposób pracy do wyjaśnienia. W rzeczywistym zdarzeniu potrzebna jest także uzgodniona obsługa incydentu danych w narzędziu AI. Zmiana polecenia dla modelu nie zastępuje ustalenia, co faktycznie przekazano i komu.

Końcowy protokół Mostu powinien rozdzielać cztery wyniki: wybrano właściwą rozmowę, przygotowano poprawną treść, ustalono właściwych odbiorców i wykonano uzgodniony krok. Dzięki temu zespół może zaakceptować samą pomoc przy pisaniu, nawet jeśli nie dopuszcza jeszcze automatycznej wysyłki. Każda z tych decyzji ma własny zakres. Żadnej nie da się wyczytać z grzecznego „pozdrawiam” na końcu szkicu.