Asystent AI w dużej firmie: dostęp do systemów, bazy wiedzy i tickety

Często to integracja z systemami, które już istnieją w organizacji, w tym ze starszymi.

Niekoniecznie. Liczy się to, czy ktoś jest na rynku IT od dawna.

Pętla zwrotna jest krótsza, bo custom API przekazuje agentowi zmieniony opis reguły w locie.

Poza automatycznymi testami trzeba ustalić, jak agenta monitorować i jak prowadzić tracing.

Marek Grabarz: Na koniec dnia okazuje się, że 90% problemów, albo raczej pracy, polega na tym, żeby przebić się przez te wszystkie bariery i zrobić integrację od początku do końca. W łatwy sposób jesteśmy w stanie przekonać AI: daj mi dane, na przykład, prezesa firmy. I nagle nikt nie wie, bo nikt nigdy tego pytania nie zadawał. Ten asystent nie jest w stanie wyjść poza te ramki, poza te bariery.

Szymon Warda: Cześć, witajcie w kolejnym odcinku Powered by Protopia. Dzisiaj rozmawiam z Markiem Grabarzem. Temat jest kontynuacją naszej serii. W poprzednim odcinku rozmawiałeś z Mikołajem o tym, jak to wygląda biznesowo, dzisiaj powiemy sobie technicznie. Co ważne, to nie jest nasza pierwsza rozmowa o agentach AI i o tym, jak wprowadzić AI w organizacji. Zachęcamy do wcześniejszych rozmów, między innymi o APIM-ie, i do success story. Dzisiaj porozmawiamy mocno technicznie. Jak już mówiliśmy, nie będzie o samej architekturze. Powiemy sobie raczej, co spotka osobę, która będzie chciała wdrożyć agenta AI w organizacji: jakie problemy, jakie kruczki i na co warto uważać.

Marek Grabarz: Dokładnie tak. Dziś będziemy mówić o różnych problemach. Czyli trochę taki use case, ale w tym przypadku różne ciekawe i mniej oczywiste przygody, które się pojawiły i które mogą się pojawić w dużym wdrożeniu asystenta czy agenta AI.

Szymon Warda: Dałeś taką zajawkę w poprzednim odcinku: ciekawostką będą tu dostępy, więc od nich zacznijmy. Co właściwie jest trudnego? Przecież doskonale wiemy, jak łączyć system A z systemem B. Robiliśmy to zawsze: dajemy sobie service account i działa.

Marek Grabarz: To jest rzeczywiście jedna z pierwszych rzeczy, na które jako Protopia natrafiliśmy w tym konkretnym projekcie. Jest sobie system, dajmy na to SAP. Jeżeli chcielibyśmy podłączyć do niego asystenta, to dość intuicyjny pomysł, który pojawia się w większości organizacji, brzmi: podłączmy się tak zwanym service accountem. Czyli jest konto techniczne, które ma dostęp administracyjny do systemu źródłowego. Daj mi informację o tym pracowniku: idzie i bierze informację o tym pracowniku. Jeżeli chcę informację o innym pracowniku, integracja działa i mamy informację o innym pracowniku.

To ma jednak bardzo krótkie zastosowanie, kiedy chcemy w jakiś sposób ograniczyć dostęp. Dlaczego? Jak się pewnie, Szymon, domyślasz, problem polega na tym, że konto techniczne jest bardzo łatwo zmanipulować. Wystarczy skuteczny tak zwany prompt injection po stronie naszego chatbota asystenta i w łatwy sposób jesteśmy w stanie przekonać AI: daj mi dane, na przykład, prezesa firmy. Jakie ma plany? Jaką ma pensję? Jakie benefity przysługują takiej osobie? To jest pierwszy problem.

Pojawia się też słowo „impersonacja”. Na koncie technicznym dokładamy jakiś nagłówek, query string albo coś dodatkowego, co mówi: to ja, asystent, i widzę, że rozmawiam na przykład z Szymonem Wardą. Dokładam więc do zapytania identyfikator albo imię i nazwisko Szymona, ale to w dalszym ciągu bardzo łatwo zmanipulować. Impersonacja kończy się tym, że łatwo wbudowujemy podatność i niestety wystawiamy dane wrażliwe.

Szymon Warda: Dobrze, widzimy więc, że powinniśmy korzystać z realnego tokenu użytkownika. Dzięki temu korzystamy z uprawnień tego użytkownika w tamtym systemie. Jak mówiłeś w poprzednim odcinku, nie duplikujemy funkcjonalności, tylko ją orkiestrujemy i wykorzystujemy to, co już jest w organizacji. Nie komplikujemy tego. Czyli mamy delegated access. Możesz powiedzieć, o co w nim chodzi?

Marek Grabarz: Jeśli popatrzymy na klasycznego OAutha, czyli standard autoryzacji, który funkcjonuje na rynku, to są w nim przepływy uprawnień, które są właśnie delegowane. Co to znaczy? Loguję się jako ja i uzyskuję tak zwany access token, który reprezentuje mnie względem systemu docelowego. Kiedy z tym tokenem coś odpytuję, asystent nie jest w stanie wyjść poza te ramki, poza te bariery. Uprawnienia, które mam w systemie źródłowym, są na swój sposób zawarte w tym tokenie.

Nasz system w żaden sposób nie replikuje RBAC-a, czyli Role-Based Access Control. Nie stara się ograniczać dostępu magicznymi system promptami, parametrami czy innymi rzeczami, tylko jedzie all in. Ale all in znaczy mój all in, czyli dokładnie ten RBAC, który jest zrobiony w tamtym systemie, i asystent nie jest w stanie wyjść poza te bariery.

Pewnie nasuwa Ci się pytanie o kolejny problem. Tu wchodzi w grę wiedza ekspercka, multidyscyplinarna. Jak wszyscy się domyślają, SAP, SuccessFactors czy jakakolwiek inna duża platforma wdrożona w organizacji ma swoją tożsamość i trzeba zrobić tak zwaną federację tożsamości.

Szymon Warda: Tak, po to, żeby użytkownik, który korzysta z agenta, nie dostawał nagle pop-upa: zaloguj się do systemu, z którego będziesz teraz korzystał.

Marek Grabarz: Tak, albo SAP może oczekiwać zupełnie innej tożsamości. Między Entrą, w której rozpoznajemy, kim jestem, a systemem źródłowym musi być przelotka, czyli federacja po SAML-u. Konfiguracja takiej federacji w dużych organizacjach nie zawsze jest prosta. Trzeba przez to przejść i to jest pierwsze duże wyzwanie, które musimy mieć z tyłu głowy.

Szymon Warda: Pytanie, czy to jest pierwsze wyzwanie. Żeby się zintegrować, nie korzystamy z UI, tylko z API, więc musimy to API odnaleźć i dowiedzieć się, co wspiera. Tu też masz ciekawą historię, którą spotykamy szczególnie przy integracji starszych systemów. Nie oszukujmy się, nie wszystko jest greenfieldem. Często to integracja z systemami, które już istnieją w organizacji. Jak wygląda tu rola eksperta przy odkrywaniu API?

Marek Grabarz: Często w organizacji system jest już wdrożony. Jest zespół, może platformowy, jest zespół utrzymaniowy, są właściciele biznesowi. Ale ten system jest zwykle utrzymywany od strony funkcjonalności frontendowej. Przypuśćmy, że mamy ServiceNow i bazę wiedzy. ServiceNow ma działać, baza wiedzy ma być aktualizowana, a sposób jej tworzenia jest opisany. Kiedy jednak pojawia się pytanie: chciałbym dostać się do tej bazy wiedzy od tyłu, od strony API, to nagle nikt nie wie, bo nikt nigdy tego pytania nie zadawał.

Ci ludzie są rozproszeni geograficznie, zespoły utrzymaniowe są w różnych krajach, także azjatyckich, amerykańskich i europejskich, i po prostu tego nie wiedzą. Tu pojawia się rola ekspercka i my w Protopii staramy się być dokładnie w tym miejscu. Doświadczeni konsultanci, wszechstronni, którzy wiedzą, jak działa uwierzytelnianie i autoryzacja, jak działają te API, na czym polega ich wywoływanie, jak działa sieć i jak sieciowo się do tych API dostać.

Szymon Warda: Protokoły.

Marek Grabarz: Poszczególne protokoły i to, jak ogarnąć to wszystko pod kątem bezpieczeństwa, bo to też jest niezwykle ważne. Będę to powtarzał jak mantrę: na koniec dnia okazuje się, że 90% problemów, albo raczej pracy, polega na tym, żeby przebić się przez te wszystkie bariery i zrobić integrację od początku do końca. To jest jeden aspekt.

Te systemy często mają API wdrożone wybiórczo. W zależności od tego, jakie moduły są wdrożone i jakie są plany licencyjne, API może być albo go nie być. Jedno API może być kompletnie inne od drugiego, nawet między modułami potrafią być kompletnie rozjechane, więc tę integrację warto dobrze przemyśleć. Myślę, że jeszcze do tego wrócimy. I ostatnia rzecz: może się okazać, że API nie ma w ogóle albo wspiera tylko service account lub impersonację. Jak to ogarniemy? Na te pytania musimy znać odpowiedź, zanim zaczniemy implementację.

Szymon Warda: Chciałbym, żeby to mocno wybrzmiało: dużo pracy w takich wdrożeniach to ogarnięcie całej organizacji i dostanie się do systemów, do których chcemy się dostać. Tu jest bardzo dużo pracy. Wspomniałeś o API i dostawaniu się do różnych systemów. W dużej organizacji zawsze będzie SharePoint. Tu też był ciekawy przypadek. Mamy SharePointa, łatwo, bo online, łączymy się po Graph API i wszystko powinno ładnie działać. Ale to nie jest takie łatwe.

Marek Grabarz: Technicznie to działa. Ale od razu pojawia się to, że klienci mają tendencję do włączania integracji po całym SharePoincie. I nagle okazuje się, że asystent ma dostęp do wielu różnych site'ów, niekoniecznie tych, które byśmy chcieli.

Szymon Warda: Nawet jeżeli ma dostęp delegowany.

Marek Grabarz: Dokładnie. Wyobraźmy sobie, że ja jako użytkownik, Marek, mogę wejść na ten site, tamten site i tak dalej. To są moje projekty, do których mam dostęp, albo site'y, na których ktoś kiedyś odklikał publiczny dostęp, włożył super wrażliwe dane i zapomniał tego zmienić. Ktoś powie: dobrze, ale asystent niczego nie zmienia, bo dostęp już był. Prawda. Ale sam bym na to nie wpadł, chyba że celowo przeszukiwałbym site po sicie w poszukiwaniu konkretnych rzeczy.

Asystent robi syntezę wszystkich tych informacji i płynnie odpowiada na podstawie tego, co znalazł. Nagle okazuje się, że mogę zapytać o budżety i wyskakują projekty, do których w teorii nie miałem dostępu. To jest problem odczytu: jest za szeroki. Musieliśmy to ograniczyć tak, żeby asystent miał dostęp tylko do wybranych site'ów, które są moderowane i zawierają wiedzę związaną z HR-em. To jest jedna rzecz. Uśmiecham się, bo można to robić też w drugą stronę. Wyobraźmy sobie, że czytamy site, na którym ktoś ma prawo zapisu. Jeśli będę złośliwy, to mogę sobie…

Szymon Warda: Mój site.

Marek Grabarz: Tak, Twój site. Mogę wyprodukować, na przykład LLM-em, procedurę HR-ową, która wygląda na w pełni poprawną i wartościową, a w niej napisać, że należy mi się Porsche jako benefit służbowy. To nagle pojawia się w odpowiedziach LLM-a i potem można się szarpać z HR-em, co to za odpowiedzi i co mi się należy, a co nie. Można też wstrzyknąć na przykład: jeżeli chcesz zgłosić nieprawidłowości, mobbing i tak dalej, użyj tego formularza. I wstrzykuję inny formularz. Te zgłoszenia wyciekają na zewnątrz, osoba atakująca je zbiera i później może wyciągnąć z kapelusza, jakie brudy były w firmie, także poza organizacją. To cała masa niebezpiecznych rzeczy, które mogą się pojawić.

I ostatnia rzecz, mówiłeś o Graphie. Wszystko fajnie, ale on działa w SharePoincie online. Kiedy mamy SharePointa on-premises, który też często się zdarza, potrzebujemy scrapowania i bazy wektorowej, a dostęp delegowany nie będzie działał. Mamy wtedy po prostu całą wartość SharePointa z konkretnego site'u w postaci wektorów.

Szymon Warda: Jasne. Podsumowując SharePointa, mamy zupełnie różne obszary. Po pierwsze, musimy wyekstrahować wiedzę, którą chcemy pokazywać. Po drugie, musimy się obronić przed tym, żeby nikt nie wstrzykiwał złej zawartości.

Marek Grabarz: Ten content poisoning, tak.

Szymon Warda: Dokładnie. A po trzecie, musimy ograniczyć to, co w ogóle widzimy, bo to już nie jest tak, że podłączamy i działa. Całkiem dużo zagrożeń. To jednak nie jest jedyne miejsce, w którym zwykle mamy bazę wiedzy. Jest jeszcze jedno, które już poruszyłeś: ServiceNow Knowledge Base.

Marek Grabarz: Tak jest. W tym konkretnym projekcie większość wiedzy była w bazach wiedzy budowanych przez działy HR w ServiceNow. Pierwsze pytanie, które się nasuwa: jak jest zbudowana treść tej bazy wiedzy? Czy to plain text, markup, czy może coś innego? Odpowiedź pewnie łatwo zgadnąć. To kontrolka, w której, jak kiedyś w Pajączku, można było wyklikać stronę. Tu też treść powstaje w kontrolce WYSIWYG, w HTML-u.

Kiedy próbujemy od kuchni, przez API, ściągnąć zawartość takiego artykułu KB, okazuje się, że jest w HTML-u z inline stylami, najróżniejszymi divami, zagnieżdżonymi tabelkami i tak dalej. Zauważyliśmy, że próba zaciągnięcia czegoś takiego bez wyekstrahowania tekstu sprawia, że tokeny lecą razy 5. Już pomijam, że na koniec może z tego wyjść gruba halucynacja.

Szymon Warda: Ale to nie jest pierwsza taka sytuacja. Mamy różne modele i różne systemy, które potrafią wyekstrahować HTML nawet do Markdowna albo wyciągnąć sam tekst. Można by pomyśleć, że to problem rozwiązany. Chyba że…

Marek Grabarz: Chyba że mamy problemy z multimodalnością. Takie artykuły często zawierają obrazy, diagramy, załączniki i linki na przykład do zewnętrznych artykułów w SharePoincie. Nasz agent musi to wszystko odpowiednio zorkiestrować. Przykład obrazka: mamy procedurę, która składa się z kilku kroków, a szczegółowy przepływ tego, co trzeba zrobić, jest pokazany na załączonym obrazku. Agent, który ściąga tylko treść, nie ma prawa wiedzieć, co jest na tym obrazku. Musi też zrozumieć wartość tego obrazka.

Dlatego kluczowe jest, po pierwsze, żeby model był multimodalny: umiał w obrazki, w tekst, w załączniki, PDF-y, Wordy i tego typu rzeczy. Ale jednocześnie my musimy to zorkiestrować. Ktoś powie: dobra, zaciągajmy obrazki jako załączniki do kontekstu i budujmy to łącznie. Fajnie, ale tu widzimy inne problemy. Na przykład ktoś w zespole redakcyjnym miał ochotę zamiast myślników czy punktorów wstawić ikonkę z zielonym checkboxem albo z czerwonym krzyżykiem.

Kiedy ściągamy taki artykuł, okazuje się, że mamy 20 załączników graficznych, z których 19, a może nawet wszystkie, nie wnoszą niczego. Są ikonką albo paskiem z logo firmy na samym dole. Musimy być tego świadomi i modelować listy wyjątków: na poziomie API, integracji albo instrukcji agenta, żeby pewnych załączników nie ściągać.

Szymon Warda: Bo tokeny będą leciały.

Marek Grabarz: Trzecia rzecz z bazami wiedzy jest bardziej biznesowa i to też musimy orkiestrować. Mamy procedury lokalne i procedury globalne. Jeżeli jako Polak pytam, ile przysługuje mi urlopu, to chcę wiedzieć, ile przysługuje mi według polskiego prawa, a nie według globalnych polityk. Musi się więc zdarzyć pewna priorytetyzacja wyszukiwania.

To też jest problem, bo ServiceNow wyszukuje przez API po słowach kluczowych. Jeśli wpiszę „company car”, nie znajdzie polskiej procedury, bo w polskiej procedurze jest „samochód służbowy”. Musimy mieć tego świadomość i odpowiednio to opisywać. I ostatnie, jeszcze bardziej zagnieżdżone przypadki: co, jeżeli szuka osoba z HR-u, która ma dostęp do wszystkiego? Co, jeżeli jestem przełożonym, który ma ludzi w pięciu lokalizacjach, i pytam, ile urlopu ma mój pracownik z Francji? Mimo wszystko muszą zadziałać odpowiednie dostępy, odpowiednie zapytanie i odpowiednia orkiestracja.

Szymon Warda: To bardziej rozumienie tekstu. Samo wyszukiwanie nie daje stuprocentowej pewności, że to zadziała.

Marek Grabarz: Musimy mieć to opisane…

Szymon Warda: Trzeba umieć odpowiednio szukać.

Marek Grabarz: …przez odpowiednie user stories, opisane przez biznes i analityków: jak chcemy tę bazę eksplorować i streszczać.

Szymon Warda: Dobrze, jeszcze jeden temat, który poruszyłeś z Mikołajem: zakładanie ticketów. Wydawałoby się, że to proste. Mamy bazę wiedzy, zebraliśmy wszystkie procedury i zostało nam proste założenie ticketu w ServiceNow.

Marek Grabarz: Z ticketami jest tak, że celem projektu jest ograniczenie ich liczby. Staramy się więc raczej odpowiadać na pytania na podstawie baz wiedzy. W którymś momencie dochodzimy jednak do punktu, w którym asystent rozkłada ręce i wtedy robi fallback do ticketu. Chyba że użytkownik od początku mówi: jestem chory i chcę zgłosić ticket. Wtedy nie przeprowadzamy go przez całą bazę wiedzy, tylko idziemy prosto, straight to the point.

Szymon Warda: Dokładnie. To brzmi prosto. Mamy access.

Marek Grabarz: Brzmi prosto, ale ci, którzy widzieli ServiceNow, wiedzą, że ticket to zwykle formularz z dropdownami i listami. Jeżeli zaznaczę A, wyświetla się pięć innych pól, a jeśli nie zaznaczę, to się nie wyświetlają, i tak dalej. Powtarzałem to już: orchestrate, do not replicate. Staramy się zorkiestrować przeprowadzenie ticketu, a niekoniecznie odtworzyć każdy typ ticketu. A uwierzcie mi lub nie, jest ich…

Szymon Warda: Dużo.

Marek Grabarz: Dużo typów ticketów. Chcemy obsługiwać je w generyczny sposób. Ściągamy kategorie, staramy się dopasować kategorię do tego, czego oczekuje użytkownik, ściągamy typy ticketów w ramach tej kategorii, a potem szablon ticketu. Dowiadujemy się, jakie są pola, czy są opcjonalne, czy wymagane, jakiego są typu i tak dalej. Ale to nie wystarcza. Nie wystarcza, bo cała masa logiki została zakodowana w formularzu ticketu w ServiceNow. Wcale nie po stronie backendu, żeby była jasność, tylko właśnie w formularzu. Walidatory, lookupy do tabelek, na przykład City ID, czy inne rzeczy. To wszystko nagle jest we frontendzie.

Szymon Warda: Co więcej, mamy tam lookupy i zależności między polami. Nawet gdybyśmy mieli to w API, agent nie zrozumie tych zależności, bo nie są nigdzie zapisane.

Marek Grabarz: W ServiceNow jest takie magiczne SYS_ID. Mamy SYS_ID tabelki country, SYS_ID tabelki user, SYS_ID tabelki czegokolwiek. To duży problem, bo na koniec dnia dowiadujemy się, że nie ma dokumentacji, bo dziesięć lat temu przyszła jakaś firma i wyklikała te frontendy ticketów w ServiceNow. Oczywiście wiedza plemienna istnieje: osoby z HR-u i osoby, które za to odpowiadają, wiedzą mniej więcej, co tu się dzieje.

Potem odkrywamy takie historie: ticket z prośbą o szkolenie. Data szkolenia, którą podaję, nie może być wcześniejsza niż za dwa tygodnie. Tego nie ma na poziomie encji w API, to zostało zakodowane w logice formularza. Trafiliśmy na ścianę, której nie dało się łatwo pokonać. Co mogliśmy wnieść? Własne API pośrodku, które w locie dokłada do poszczególnych pól ticketu, szczególnie tych dynamicznych, nowe właściwości: reguły walidacyjne, opisy, zależności i tego typu rzeczy.

Asystent ma od początku powiedziane: ściągnij szablon ticketu, sprawdź, czy pole jest opcjonalne, czy wymagane, ale patrz też na reguły opisowe i walidacyjne. Te reguły nie są zapisane w JSON Logic ani w niczym podobnym, tylko po prostu semantycznie, zwykłym językiem. Jeżeli w polu A jest zaznaczona taka wartość, to to pole jest wymagane. Albo: to pole nie może być wcześniejsze niż za dwa tygodnie od teraz. Tyle. Kropka.

Szymon Warda: To daje podwójną wartość. Po pierwsze, agent to rozumie. Agent rozumie tekst.

Marek Grabarz: LLM doskonale się w tym odnajduje. To nie jest techniczny żargon ani „if this, then that”, tylko opis, który model interpretuje w naturalny sposób.

Szymon Warda: Tak, ale jest jeszcze druga duża wartość. Ten opis może edytować właściciel tematu, na przykład dział HR.

Marek Grabarz: Dokładnie. Możemy mieć załącznik albo zestaw informacji, który podciągamy jako źródło do naszego własnego API, i w locie aplikujemy konkretne pola, walidacje i opisy jako elementy tekstowe.

Szymon Warda: Czyli skracamy pętlę zwrotną tego, jak coś ma działać.

Marek Grabarz: Tak. Nie próbujemy pisać tego frontendu od nowa ani opisywać w prompcie krok po kroku, jak to ma być zrobione. Staramy się dynamicznie wstrzyknąć asystentowi informację, jak ma to ogarniać.

Szymon Warda: Jasne. Powoli podsumujmy tę rozmowę. Jakie są główne wnioski, które chciałbyś, żeby wybrzmiały w tego typu projektach?

Marek Grabarz: Myślę, że kluczowe są etapy discovery. Po pierwsze, musimy wiedzieć, z jakimi systemami będziemy się integrować, czy mają API, co to za API i jaki zakres wiedzy dostarczają. To chyba pierwsza i najważniejsza rzecz. Druga to to, o czym wspomniałem: uwierzytelnianie i autoryzacja. Musimy naprawdę mocno pilnować, żeby był to dostęp delegowany albo impersonowany, ale wtedy potrzebujemy API Gatewaya, który będzie pewne rzeczy tłumaczył.

Dlaczego? Bo do API Gatewaya możemy dojść z dostępem delegowanym, a on wyciągnie z tokena, że mówi Szymon Warda, i tej ścieżki nie da się oszukać. Wyciągnie to i dopiero w swojej deterministycznej logice dołoży impersonację wewnątrz systemu. Ale to już bardziej aspekt techniczny.

Szymon Warda: Kto chce się dowiedzieć, o co dokładnie chodzi, tego zapraszamy do poprzedniego odcinka o API.

Marek Grabarz: I tu znowu podkreślę, dlaczego warto mieć doświadczonych konsultantów. Niekoniecznie takich, którzy są od AI, bo wpisali to sobie do CV jakiś czas temu, tylko osoby, które są na rynku IT od dawna. Wyzwania są nie tylko w AI, ale przede wszystkim w integracjach, bezpieczeństwie, uwierzytelnianiu i typowych rzeczach, które konsultant musi widzieć i rozumieć od samego początku.

Szymon Warda: Wydaje mi się, że chodzi o umiejętność rozmawiania z bardzo wieloma interesariuszami, osobami z różnych projektów, tłumaczenia potrzeb na bardzo różne języki i adresowania wielu bolączek.

Marek Grabarz: To prawda. Myślę też, że ważne jest to, kto nagle wyląduje w projekcie. Jestem w stanie wyobrazić sobie sytuację, w której ściągamy osobę, która nie do końca potrafi się komunikować. Ma dobrą wiedzę techniczną, ale cały proces uzyskania integracji polega na spotkaniach z różnymi interesariuszami: z osobami od sieci, z właścicielami platform. Czasem trzeba pocisnąć ludzi od supportu, żeby wyciągnęli pewne informacje, a czasem eskalować do dostawcy systemu. To wszystko wymaga leadershipu.

Szymon Warda: Czyli umiejętności miękkie są ważne.

Marek Grabarz: Istotne. Warto też patrzeć na względy licencyjne. Coś mi się przypomniało, to świeża rzecz, dlatego do niej nawiążę. Nagrywamy ten odcinek na samym początku maja 2026. Jedna z naszych integracji to integracja z SAP-em. I niespodzianka! SAP ogłosił, że użycie jego API przez agentów AI będzie teraz rozliczane albo zabronione. Analizy trwają, co to znaczy. Być może to próba wymuszenia na wszystkich użycia własnego asystenta SAP-a, Joule. To ciekawe rzeczy, które też musimy znać: kwestie licencyjne, dostępowe, rate limity. Na koniec dnia chodzi o to, jak to wszystko ograć systemowo.

Szymon Warda: Jasne. Jeszcze jedna rzecz. Rozmawialiśmy przed odcinkiem, że mamy już temat na kolejny odcinek. Możemy zrobić zajawkę, bo jest ciekawy?

Marek Grabarz: To ciekawa rzecz, nad którą teraz pracujemy, więc do nagrania jeszcze chwila: testowanie agenta. Ktoś zapyta, co znaczy testowanie takiego agenta. W AI jest cały obszar, który chyba nie jest jeszcze mocno popularny na LinkedInie i w internecie, czyli tak zwana eval strategy. Co to oznacza? Mamy asystenta, który powinien odpowiedzieć na pytanie. Mamy przygotowaną spodziewaną odpowiedź na podstawie business case'ów, customer stories i tak dalej. A asystent daje inną odpowiedź. Jak to ewaluować?

Mamy najróżniejsze mechanizmy, oparte na LLM-ach i nie tylko, które automatycznie wykonują cały zestaw use case'ów i mówią, czy agent odpowiedział z sensem czy bez sensu, rzetelnie czy nierzetelnie, czy był proaktywny i miły, czy szorstki i niepomocny. Wszystkie te rzeczy możemy mierzyć i myślę, że o tym nagramy kolejny odcinek.

Szymon Warda: O dobrych praktykach, żeby agenta nie tylko wdrożyć, ale też utrzymywać w dłuższej perspektywie.

Marek Grabarz: Jak go monitorować, jak go śledzić i jak go automatycznie testować.

Szymon Warda: No dobrze, to zapraszamy na kolejny odcinek.

Marek Grabarz: Zapraszamy.

Szymon Warda: Dziękuję pięknie.

Marek Grabarz: Dzięki, Szymon. Dzięki Wam wszystkim.