Dobre AI zaczyna się na długo przed AI

Klient zgłasza pobyt w szpitalu i prosi o wypłatę świadczenia. W załączniku przesyła zdjęcie z wakacji.

Albo kartę z zupełnie innego leczenia. Albo nieczytelny wypis z łacińskim opisem zabiegu, którego nie rozszyfrowałby nikt poza lekarzem.

System tego nie zauważy, bo opiera się na tym, co klient wpisał we wniosku. Można go obudować, jak to ujęła Anna Sędek, „milionem sztywnych reguł”, a i tak nie będzie wiadomo, co naprawdę jest w załączniku.

Od tego problemu Beata Brzosko i Anna Sędek z Nationale-Nederlanden zaczęły swoje wystąpienie na konferencji „Analityk & Architekt w erze AI” organizowanej przez Andrzej Sobczak i Jan Maria Kowalski, MBA
Uprzedziły, że nie będą mówić o modelach ani o technologii. Opowiedziały, jak przejść od problemu biznesowego do pierwszych testów. I dlaczego ta droga zaczyna się długo przed AI.

Na początku nie było AI

Projekt wcale nie zaczął się od pomysłu „wdróżmy sztuczną inteligencję”. Zaczął się od transformacji obsługi roszczeń i czterech celów: uporządkować procesy, skrócić czas obsługi klienta, uwolnić ekspertów od prostych spraw, żeby mogli zająć się trudnymi, oraz przygotować obszar na rosnącą skalę.

„Jak ktoś mnie śledzi, to wie, że bywam nudna. Zaczęłyśmy od nudnej standaryzacji”. — Anna Sędek

Przez cały kwartał zespół rozkładał proces na części, bez krztyny AI. Szukał szybkich usprawnień i miejsc, które blokowały pełną automatyzację. Wyszły z tego dwa zupełnie klasyczne artefakty: procesy w BPMN (od stanu obecnego do docelowego, z opisanymi problemami) i tabela wymagań do systemów w Confluence.

Dopiero na uporządkowanym procesie było widać, gdzie AI naprawdę może pomóc.

W sesji pytań zapytałem, jak przekonać zarząd do takiego kwartału, kiedy wszyscy chcą AI na wczoraj. Anna odpowiedziała szczerze, że miały szczęście do świadomej Product Ownerki, ale i tak była to długa i trudna dyskusja. Zespół pokazał decydentom, że rzucenie się na AI bez uporządkowania procesu skończy się katastrofą i dużymi kosztami. Ten kwartał trzeba było po prostu wywalczyć.

AI jako zabezpieczenie, a nie gadżet

Proces wyglądał tak: klient przesyła wniosek, system sprawdza dane, rejestruje sprawę, weryfikuje dokumenty i podejmuje decyzję o wypłacie albo odmowie. Część prostych spraw obsługiwały reguły, resztę ludzie.

Słabym punktem była dokumentacja medyczna. Nikt nie miał pewności, czy to, co jest w załączniku, zgadza się z tym, co klient zadeklarował.

Dlatego zespół potraktował AI jak zabezpieczenie przed ryzykiem. Model ma czytać dokumentację medyczną i przekazywać z niej uporządkowane dane do reguł, które już działają. Dzięki temu można wprowadzić automatyzację, która wcześniej była zbyt ryzykowna.

Na diagramie procesu wygląda to niewinnie: dwa nowe klocki, „Przekaż dane i dokument do AI” i „Odbierz dane z AI”. W praktyce kryła się za nimi ogromna praca analityczna.

Smutny Word i Smutny Excel

Zespół wziął 50 kart szpitalnych i razem z ekspertami zaznaczał na skanach fragmenty, które decydują o wypłacie. Tak powstał „Smutny Word”: skany z zakreśleniami i komentarzami likwidatorów.

Potem zamieniono go w „Smutnego Excela”, który stał się podstawą całego projektu. W pierwszej kolumnie była polska nazwa pola, w drugiej angielska nazwa techniczna do JSON-a, a w kolejnych reguły, komentarze i przykładowe wartości.

Jeden plik służył dwóm grupom. Biznes na warsztatach sprawdzał w nim założenia, a programiści i dostawca AI mieli w nim specyfikację promptów i tego, co model ma zwracać.

Zespół wyróżnił trzy rodzaje danych:

proste dane biznesowe, takie jak z formularza, dane, które AI musi zinterpretować, na przykład rodzaj operacji z opisu medycznego, dane formalne: jakość skanu, czytelność, liczba stron.

Wymaganie staje się hipotezą

Według Anny najtrudniejsza zmiana dla analityka dzieje się w głowie.

„W projektach AI nie ma klasycznych, sztywnych wymagań. Są hipotezy i założenia”.

W tradycyjnym systemie pytasz: jaka jest reguła? Na przykład: jeśli operacja dotyczy woreczka żółciowego, sprawa idzie do ręcznej weryfikacji. System sprawdza kod i decyzja jest jednoznaczna.

Przy AI pytasz: co model ma wyczytać z opisu zabiegu, który każdy szpital pisze inaczej? Każdy nowy szablon dokumentu może zmienić zachowanie modelu. Model może nie rozpoznać łacińskiej nazwy, OCR może się pomylić, podpis lekarza może być nieczytelny. A wszystkich możliwych dokumentów nie da się opisać.

Dlatego zespół ustalił próg pewności modelu. Jeśli model jest mniej pewny swojej odpowiedzi niż ustalony poziom (na przykład 50%), sprawa trafia do człowieka. Analityk musi też pogodzić się z tym, że ta analiza nigdy nie jest do końca zamknięta.

Narkotyk na sali operacyjnej

Na warsztaty z biznesem zespół przychodził z sześcioma pytaniami. Czy brak tej danej zatrzymuje proces? Jak dokładnie ją pozyskać? Czy tę samą informację można zapisać na różne sposoby? Czy wystarczy sama informacja, czy potrzebny jest kontekst? Gdzie kończy się jednoznaczność i co zrobić, gdy model nie wie? I wreszcie: jak naprawdę pracują likwidatorzy? To ostatnie zespół sprawdzał, obserwując ich przy pracy.

Najlepiej pokazuje to przykład z wystąpienia. W karcie szpitalnej pojawia się nazwa silnego opioidu. Czy to znaczy, że klient jest uzależniony, co mogłoby wykluczać wypłatę? Nie. Lek został legalnie podany na sali operacyjnej jako znieczulenie.

Wyszukanie słowa w tekście to zadanie na prosty skrypt. Rolą analityka jest takie przygotowanie modelu, żeby rozumiał kontekst.

80% to wystarczająco dobrze

Z gotową specyfikacją zespół poszedł do programistów i zewnętrznego dostawcy AI. W testach znów przydał się Excel: zielone wiersze oznaczały poprawny odczyt, czerwone błąd, halucynację albo brak odczytu.

Testy AI nie polegają na tym, że wszystko przechodzi w 100%. Patrzy się na statystykę i rodzaje błędów. Biznes przyjął próg 80% skuteczności i po jego osiągnięciu rozwiązanie trafiło na produkcję. Na razie działa w trybie ochronnym (hypercare): na prawdziwych danych korzysta z niego wewnętrzny zespół projektowy, zanim dostaną je wszyscy.

Andrzej Sobczak zapytał, jak przekonać ubezpieczyciela, w którym wszystko zawsze musiało działać w 100%, do skuteczności na poziomie 80%. Odpowiedź miała trzy części:

Edukacja. Eksperci biznesowi sami na co dzień korzystają z AI i rozumieją, że model trzeba dopracowywać. Twarde granice. Są obszary, na przykład interpretacja wyłączeń medycznych, w których model nie może nic zdecydować bez człowieka. Zaufanie. Jak podkreśliła Beata, transformacja trwa już piąty rok. Biznes ufa IT, a IT rozumie biznes. Bez tego takie wdrożenie byłoby niemożliwe.

Jan Maria Kowalski, MBA zapytał też o bezpieczeństwo, bo chodzi o dane medyczne. Na etapie rozwoju i testów zespół pracował wyłącznie na danych zanonimizowanych. Prawdziwe dokumenty przetwarza dopiero zabezpieczona infrastruktura produkcyjna.

A czy przy całej tej pracy analitycznej korzystały z AI? Tak, z Copilota: do szukania synonimów medycznych, alternatywnych nazw procedur i testowania pierwszych wersji promptów. Ale ostateczna specyfikacja i tak powstała w Excelu, bo z niego korzystają i likwidatorzy, i programiści.

Eksperyment, który się nie kończy

Na koniec Anna zostawiła salę z myślą, która dobrze podsumowuje całe wystąpienie:

„Iterujemy nie zakres oprogramowania, lecz wiedzę, kontekst i prompty”.

Projekt AI nie kończy się po wdrożeniu. To ciągły eksperyment. Udaje się dzięki temu, co zespół zrobił, zanim w ogóle zaczął mówić o modelach: dzięki nudnemu kwartałowi standaryzacji, Smutnemu Excelowi i zaufaniu budowanemu przez pięć lat.