Dział Audytu Grant Thornton Polska potrzebował szybszego sposobu na obsługę eksperckich zapytań. Stworzyliśmy Asystenta AI, który czerpie odpowiedzi z przepisów prawa, wewnętrznych polityk oraz wcześniejszych przypadków, skracając czas reakcji i odciążając specjalistów. Opisujemy, jak podeszliśmy do tego zadania i co to oznacza dla zespołów, które chcą realnie wdrożyć użyteczną technologie w firmowych procesach, stawiając na Automatyzacje i AI.
Dowiedz się więcej o naszym projekcie:
- Klient: Grant Thornton Polska – jedna z wiodących organizacji audytorsko-doradczych na świecie, w Polsce od 1993 roku, zatrudnia ponad 1000 osób, rocznie obsługuje ponad 2,4 tys. Klientów; na świecie – rozpoznawalna w 147 krajach, z ponad 100-letnią historią, zatrudnia ponad 68 tys. pracowników.
- Typ klienta: międzynarodowa korporacja
- Branża: consulting, finanse, fintech
- Typ projektu: Transformacja cyfrowa, Corporate Innovation, AI Agent, UX Design,
- Obszar prac: Aplikacja AI, komunikacja, baza wiedzy
- Metodologia: Human Centric AI Design
- Cel projektu: Stworzenie narzędzia AI, którego zadaniem jest udzielanie odpowiedzi na pytania pracowników audytu. Asystent AI ma wykorzystywać dane z przepisów prawnych, wewnętrznych regulacji firmy i historii wcześniej rozwiązanych spraw.
- Główny rezultat: Ogólnodostępny Asystent AI mający dostęp do wybranych danych firmy (sharepoint, poczta email, strony www) w oparciu o architektury RAG (Retrieval-Augmented Generation). Przyspieszenie udzielania odpowiedzi i wyszukiwania dokumentów.
Język projektu: polski - Partnerzy: 10senses (partner technologiczny), Grant Thornton Polska
- Rok realizacji: 2024-2025
- Skład zespołu: Mateusz Jędraszczyk – AI & Automation design Lead, Marek Zielinski – AI Backend Developer, Mateusz Biesiadowski – AI & Fullstack Developer, Łukasz Borowiecki – Data Scientist, Irina Jackiewicz – Project Manager
Dlaczego klient się do nas zgłosił, czyli problemy, wyzwania i wskaźniki wejściowe
Zespół techniczny Departamentu Audytu Grant Thornton Polska zmagał się z rosnącą liczbą pytań eksperckich, które były trudne do obsłużenia przy ograniczonej liczbie pracowników. Ustaliliśmy, że celem będzie stworzenie narzędzia, które umożliwi sprawniejsze odpowiadanie na specyficzne pytania audytorów, ograniczając czas poświęcany na szukanie informacji.
Jakie były efekty współpracy, czyli co świadczy o sukcesie projektu
Nasz projekt przyniósł konkretne rezultaty, mające rzeczywiste znaczenie dla biznesu:
- Ogólnodostępny Asystent AI mający dostęp do wybranych danych firmy (sharepoint, poczta email, strony www) w oparciu o architektury RAG (Retrieval-Augmented Generation).
- Zadowalający poziom poprawnego wyszukiwania źródeł wiedzy na etapie Proof of Concept.
- Poprawne rozwiązywanie spraw przez AI na poziomie Juniora.
- Zredukowanie czasu udzielania odpowiedzi na pytania audytorów poprzez:
– przyspieszanie wyszukiwania dokumentów w rozproszonych źródłach danych,
– inteligentne wnioskowanie i samodzielne udzielanie odpowiedzi przez Asystenta AI,
– użyteczny i spersonalizowany interfejs użytkownika wspierający pracę
z pytaniami oraz kontrolę odpowiedzi udzielanych przez Asystenta AI.
Czym różni się Agent AI od Asystenta AI?
Asystent AI – wspiera użytkownika, odpowiada na pytania, działa na żądanie. Agent AI – wykonuje autonomiczne zadania, podejmuje decyzje samodzielnie
Jak wyglądała współpraca, czyli etapy, metody i wnioski
Przeszliśmy przez cztery pierwsze kluczowe kroki.
Etap 1: Zrozumienie problemu
Zaczęliśmy od Process Discovery Workshops, czyli spotkania, podczas którego przyjrzeliśmy się wybranemu procesowi krok po kroku. Sprawdziliśmy, jak długo trwają poszczególne zadania i co może być przeszkodą. To pozwoliło nam lepiej zrozumieć, gdzie warto wprowadzić automatyzację.
Każdy element procesu oceniliśmy według kryteriów:
- ile osób skorzysta z nowego rozwiązania? (czyli jak duży będzie wpływ),
- użyteczności rozwiązania (w skali 1–10),
- możliwości technologicznych do wytworzenia rozwiązania (w skali 1–10),
- wartości dla użytkownika (w skali 1–10).
Na koniec wybraliśmy te pomysły, które zdobyły najwięcej punktów. To one stały się fundamentem naszego rozwiązania.
Czym dokładnie jest Process Discovery Workshops?
To nasz autorski sposób na analizowanie procesów. Podobnie jak w data miningu, szukamy ukrytych wzorców w danych. Następnie idziemy dalej, patrzymy na to, co robią ludzie, a nie tylko na dane w systemie. Czasem problemem jest coś tak prostego jak zapisywanie informacji na kartce zamiast w systemie. Nasz proces pozwala to zauważyć i znaleźć sposób na usprawnienie.
Co więcej, ocena pozwoliła metodycznie i bardziej obiektywnie spojrzeć na cały proces. Odrzuciliśmy te pomysły, które:
- mogły wykraczać poza obecne możliwości dostępnych narzędzi AI
- dawały niepewne rezultaty,
- mogły zostać rozwiązane prostszymi i tańszymi metodami.
Na przykład: zamiast tworzyć skomplikowany model AI, część trudniejszych zapytań skierowaliśmy automatycznie do systemu ticketowego, gdzie przejmowali je odpowiedni specjaliści.
Etap 2: Jak nie budować AI dla samego AI
Wiele firm wierzy, że wystarczy dodać AI do procesu, a problemy same się rozwiążą. To kusząca wizja, ale daleka od rzeczywistości. AI jest tylko narzędziem, to ludzie będą z niego korzystać na co dzień. Jeśli nie uwzględnimy ich potrzeb, stworzymy system, który nie odpowiada na realne wyzwania i szybko zostanie porzucony.
Dlatego w ramach Process Discovery Workshops zaczęliśmy od kluczowego pytania: dla kogo tworzymy to rozwiązanie? Kim są użytkownicy?
Wyłoniliśmy dwie główne grupy, które będą pracować z Asystentem AI:
- Specjalista działu technicznego – dziś to on odpowiada na pytania audytorów, analizując dane i dostarczając im potrzebne informacje.
- Specjalista wykonujący audyt – to osoba, która zadaje pytania i podejmuje decyzje na podstawie uzyskanych odpowiedzi.
Te dwie persony różnią się doświadczeniem, potrzebami i oczekiwaniami wobec narzędzia. Musieliśmy więc zadbać, by Asystent AI rzeczywiście im pomagał, zamiast dokładać komplikacji.
Tu pojawiło się inne ważne pytanie: czy mamy dobre dane?
AI potrzebuje solidnych fundamentów, czyli wysokiej jakości danych. Jeśli system będzie się uczyć na błędnych lub niepełnych informacjach, stanie się bezużyteczny.
Przeanalizowaliśmy więc dostępne źródła wiedzy, takie jak:
- e-maile zespołu,
- wewnętrzne strony internetowe,
- zewnętrzne strony z regulacjami,
- dokumenty PDF, np. przepisy prawne i wytyczne.
Szczególnie ciekawym przypadkiem były e-maile. Wiedzieliśmy, że to tam znajduje się wiele wartościowych odpowiedzi na pytania audytorów. Ale jak oddzielić istotne wiadomości od reszty?
Poprosiliśmy ekspertów naszego klienta (SME), aby wyselekcjonowali kluczowe materiały.
Z ponad 2000 wiadomości udało się wybrać 217, które zawierały najbardziej wartościowe informacje. To one miały stać się jednym z fundamentów dla Asystenta AI.
To trudny, ale konieczny krok. Dzięki niemu nie tylko uporządkowaliśmy wiedzę, ale też upewniliśmy się, że AI będzie korzystać z rzetelnych źródeł.
Kim jest Subject Matter Expert?
To osoba z dużym doświadczeniem w swojej dziedzinie wiedzy. Może to być profesor prawa lub doświadczona programistka.
Aby zamknąć zakres prac, opisaliśmy zadania w rejestrze zadań (backlogu). Wykorzystaliśmy do tego metodę pisania User Stories. Wynikiem prac była lista zadań, stworzona przez specjalistę Prouduct Design wspieranego Sztuczną Inteligencją. To pozwoliło nam błyskawicznie opisać najważniejsze kryteria akceptacji, czyli punkty kontrolne, które następnie były użyte do testów manualnych.
Czym jest backlog?
To inaczej spis zadań wykonany z podziałem na istotność zadań i konkretne daty ich wykonania.
Czym jest User Stories?
To krótki opis (w formie zdania) mówiący o tym co użytkownik chce osiągnąć i dlaczego. Spisywany w określonym formacie zdania: „Jako [kto], chcę [cel], aby [motywacja]”. User Story pomaga lepiej zrozumieć, co wspólnie chcemy stworzyć bez potrzeby posiadania specjalistycznej wiedzy programistycznej. Często User Stories są traktowane jako sposób komunikacji z osobami nietechnicznymi.
Przykładowe User Story widoczne jest poniżej.
Etap 3: Projektowanie – czyli inteligentne interfejsy w praktyce
Po zdefiniowaniu person i weryfikacji dostępnych źródeł danych, przyszedł czas na kolejny krok, projektowanie interfejsu i doświadczenia użytkownika.
W ramach testowania pomysłu postawiliśmy sobie dwa główne cele:
- Doświadczenie użytkownika:
- Czy interfejs czatu będzie intuicyjny i spójny z wizerunkiem marki?
- Czy posiadamy wszystkie niezbędne funkcjonalności wymagane przez użytkownika w tym konkretnym przypadku wykorzystania AI?
- Czy wiemy, jakimi kanałami najlepiej porozumiewać się z asystentem AI? (Microsoft Teams, oddzielny interfejs itd.)
- Jakie są możliwości i ograniczenia technologiczne związane z wyborem konkretnego rozwiązania (np. wykorzystanie Microsoft Copilot Studio vs. w pełni dostosowane narzędzie – na które ostatecznie się zdecydowaliśmy)
- Doświadczenie z rozmowy z AI:
- Jaki powinien być ton wypowiedzi AI?
- Jaka powinna być struktura wypowiedzi AI? (Wdrożyliśmy m.in. opcje dodatkowych pytań sugerowanych przez AI)
- Jak zwiększyć zaufanie w odpowiedzi w realny sposób – wdrożyliśmy m.in. opcję podglądu kroków wykonanych przez AI, zanim użytkownik uzyskał odpowiedź.
- Jakie opcje powinny być dostępne w podglądzie źródeł wiedzy i jaki powinien być kontekst fragmentów tekstów wykorzystywanych przez AI?
Zdecydowaliśmy się na prototyp wizualny, interaktywną makietę, która umożliwiała użytkownikom „rozmowę” z imitacją działającego AI. Nie był to jeszcze w pełni funkcjonalny asystent, ale pozwolił przetestować kluczowe elementy interfejsu.
Równolegle z testami UX rozpoczęliśmy analizę technologiczną. Kluczowe pytania dotyczyły m.in.:
- Jakie rozwiązanie najlepiej sprawdzi się w naszych warunkach?
- Jakie standardy bezpieczeństwa musimy spełnić?
- Jakie środowisko developerskie będzie optymalne?
W ramach Proof of Concept (PoC) postawiliśmy na szybkie testowanie podstawowej wersji systemu. Aby maksymalnie skrócić czas wdrożenia, skorzystaliśmy z gotowych komponentów UI. Pozwoliło to skupić się na najważniejszym elemencie. Działaniu AI.
Już pierwsze testy pokazały, że interfejs jest dobrze odbierany, a użytkownicy czują się w nim komfortowo. To dało nam zielone światło do dalszych prac nad końcowym rozwiązaniem.
Etap 4: Testy Asystenta AI – zamknięte testy beta
Po zakończeniu etapu projektowania przyszedł czas na praktyczne testy działania asystenta AI. W tej fazie naszym celem było sprawdzenie, jak dobrze AI radzi sobie z wyszukiwaniem i przetwarzaniem informacji, a także jak użytkownicy oceniają jakość jego odpowiedzi.
Podzieliliśmy testy na trzy kluczowe obszary:
- Testy automatyczne
- Testy pół-automatyczne
- Testy jakościowe ze specjalistami (SME – Subject Matter Experts)
Testy automatyczne
Pierwszy etap polegał na automatycznej analizie źródeł danych. AI oceniał każde źródło pod względem przydatności i jakości, przypisując mu ocenę w skali 1–5.
- Źródła z oceną powyżej 2,5 zostały automatycznie dołączone do bazy wiedzy asystenta.
- Źródła z oceną poniżej 2,5 były odrzucane lub wymagały dalszej analizy.
- Każda ocena była poparta uzasadnieniem, co pozwalało na lepsze zrozumienie decyzji AI i ewentualne korekty.
Taki system filtrowania pozwolił nam wyeliminować słabej jakości dane jeszcze przed rozpoczęciem testów z użytkownikami.
Testy pół-automatyczne
Na tym etapie skupiliśmy się na dwóch aspektach:
- Czy AI prawidłowo pozyskuje informacje z bazy wiedzy?
- Czy udzielane odpowiedzi są zgodne z oczekiwaniami?
Aby to zweryfikować, nie angażowaliśmy jeszcze ekspertów, lecz posłużyliśmy się metodą testowania pół-automatycznego:
- Zespół projektowy zadawał AI pytania, bazując na wyselekcjonowanych dokumentach.
- Do generowania pytań i wzorcowych odpowiedzi wykorzystaliśmy najnowsze modele AI (np. Claude), co pozwoliło nam ocenić zgodność odpowiedzi asystenta z oczekiwanym rezultatem.
- W przypadku błędnych odpowiedzi AI oznaczaliśmy je jako wymagające poprawy, aby dostosować model do specyficznych potrzeb użytkowników.
To podejście umożliwiło wczesne wychwycenie błędów, zanim asystent trafił do testów z użytkownikami końcowymi.
Testy jakościowe ze specjalistami (SME)
W kolejnym etapie udostępniliśmy AI w kontrolowanym środowisku testowym (tzw. „piaskownicy”). Tutaj specjaliści z danej dziedziny mogli swobodnie zadawać pytania i oceniać jakość odpowiedzi.
Eksperci sprawdzali AI pod kątem:
- Czy odpowiedź była merytorycznie poprawna?
- Czy AI poprawnie wyszukiwał informacje w bazie wiedzy?
- Czy AI potrafił odpowiedzieć na pytania rzeczywiście zadawane przez klientów (np. na podstawie historycznych maili)?
Czym są testy Alfa i Beta?
Są to częste określenia kolejnych faz testowania produktu. Testy Alfa oznaczają najczęściej zamknięte testy wewnętrzne (np. wśród pracowników firmy lub konkretnego departamentu). Testy Beta to zazwyczaj testy, podczas których rozszerzamy dostęp na klienta docelowego.
Co dalej? Przed nami kolejna faza 2 projektu
Druga faza projektu zakłada rozszerzenie testów na około 200 użytkowników, co pozwoli nam dokładniej ocenić skuteczność Asystenta AI w zależności od poziomu trudności pytań i stanowisk użytkowników.
W ramach tego etapu skupimy się na:
- Nowych formatach dokumentów: Asystent AI będzie w stanie analizować m.in. umowy.
- Dłuższym kontekście rozmowy: umożliwienie AI odniesienia się do wcześniejszych fragmentów rozmowy.
- Poprawie trafności odpowiedzi: optymalizacja modelu i dostosowanie algorytmów.
- Automatycznej aktualizacji źródeł wiedzy: integracja z zewnętrznymi stronami.
- Udoskonaleniu interfejsu: nowe funkcje, jak możliwość zapisywania pytań i ich ponownego wykorzystania.
Kluczowe wnioski
- Skuteczność AI zależy od realnych potrzeb użytkowników. Warto je dokładnie analizować przed wdrożeniem.
- AI nie jest uniwersalnym rozwiązaniem. Wymaga starannego projektowania, podobnie jak tradycyjne systemy.
- Dedykowane rozwiązania są kluczowe. Nie wystarczy powielić popularnych interfejsów czatu.
- Świadomość możliwości i ograniczeń AI wśród zespołu ułatwia współpracę i optymalizację.
- Weryfikacja odpowiedzi przez ekspertów (SME) jest niezbędna dla utrzymania jakości i zaufania użytkowników.
Kluczowym elementem procesu było zebranie zwinnego zespołu, który miał doświadczenie z projektowaniem i tworzeniem AI. Pozwoliło to pominąć żmudny proces nauki tego, jakie są możliwości i ograniczenia AI, a także ograniczyć czas na zarządzanie projektem. Cała współpraca opierała się na interdyscyplinarnym zespole specjalistów związanych z projektami AI, same role można jednak uznać za „klasyczne”.
- Subject matter experts (SMEs) – osoby dobrze znające temat projektu – specjaliści w swojej dziedzinie, którzy wspierają zespół projektowy testami asystenta AI.
- Chief Design Officer – dbający przede wszystkim o kontakt z klientem, a także dostarczanie niezbędnych zasobów.
- Lead AI Product Designer – projektant tworzący rozwiązania AI z uwzględnieniem potrzeb użytkowników.
- AI Backend Developer – osoba odpowiedzialna za wybranie odpowiedniego modelu AI do zadania, stworzenie odpowiedniego repozytorium, bazy wektorowej i wirtualnej maszyny, a także za bezpieczeństwo przetwarzanych danych.
- AI & Fullstack Developer – osoba odpowiedzialna za prompty, instrukcje i kroki (które są przez AI wykonywane zanim przekaże końcową odpowiedź), a także za frontend.
- Data Scientist – osoba odpowiedzialna za wstępną analizę przesyłanych danych, ich strukturę oraz format, a także testy manualne oparte o prompty i instrukcje.
- Project Manager – osoba odpowiedzialna za sprawny przepływ pracy wewnętrznej, a także rozwijanie projektu i ustalanie bieżących postępów w celu raportowania do klienta.
