Asystent AI dla ponad 60 tys. pracowników: HR, integracje i wdrożenie etapami

Od warsztatów z biznesem. Pomagają zrozumieć, na czym stoi firma, i znaleźć kilka use case'ów spoza IT.

Dojrzałe działy IT znają procesy DevOps i chmurę, ale w systemach agentowych nikt nie ma wieloletniego doświadczenia. Dlatego klient uznał, że warto wesprzeć się kimś z zewnątrz, kto pokaże, jak to się robi.

Feedback pokazuje, czego potrzebują użytkownicy. Ich głos i głos biznesu muszą się wzajemnie uzupełniać.

Marek Grabarz: 90% wdrożeń tematów AI kończy się porażką, bo nie przynoszą żadnej wartości.

Mikołaj Szczerbicki: Firmy oczekują, że pojawi się superagent, który od pierwszego dnia na produkcji rozwiąże im wszystkie problemy.

Marek Grabarz: A na koniec dnia asystent to tylko klej, crème de la crème, który w efektywny sposób łączy te systemy ze sobą. Większość wyzwań w realizacji takich projektów to wyzwania związane z integracją.

Mikołaj Szczerbicki: Cześć! Witajcie w Powered by Protopia. Nazywam się Mikołaj Szczerbicki, a dziś w studio jest ze mną Marek Grabarz.

Marek Grabarz: Cześć wszystkim!

Mikołaj Szczerbicki: Marek, dzisiaj konkretny projekt, konkretna firma, konkretne wyzwanie. Porozmawiamy o tym, jak zespół Protopii pod Twoim przewodnictwem bierze udział we wdrożeniu agenta AI w dużej globalnej firmie farmaceutycznej. Mówimy o kilkudziesięciu krajach i ponad 60 tysiącach pracowników. Chciałbym, żebyśmy porozmawiali dziś o aspektach biznesowych, koncepcyjnych i decyzyjnych. Kwestie techniczne omówisz z Szymonem w następnym odcinku.

Marek Grabarz: Zostawiamy je na później.

Mikołaj Szczerbicki: Tak jest. Zacznijmy jak zwykle od początku, czyli od genezy problemu. Co takiego pojawiło się u klienta, że postanowili pomyśleć o wdrożeniu procesu agentowego u siebie?

Marek Grabarz: Cały projekt, o którym dziś mówimy, to inicjatywa, która powstała w obszarze HR. Ten agent AI działa właśnie w obszarze HR. Jak to w dużych organizacjach bywa, mają masę rozproszonych systemów HR: systemy z bazami wiedzy, systemy związane z wypłatami, rzeczy związane z benefitami. Wszystko to jest rozproszone w wielu systemach, co skutkowało pewnym niezrozumieniem: do którego systemu się odwołać, co w którym systemie można znaleźć i co można w nim zrobić. Na pewnym etapie HR, czy też HR i IT, doszli do wniosku, że trzeba zrobić agenta, a właściwie nie tyle agenta, co asystenta. Na koniec dnia to frontend z chatbotem, który ułatwi te procesy. Inicjatywa wyszła z takiego poziomu, że HR mówi: hej, potrzebujemy rozwiązać ten problem, potrzebujemy ograniczyć złożoność tego całego ekosystemu.

Jeżeli nie zrobicie tego dla nas, to jakoś znajdziemy sposób i rozwiążemy ten problem samodzielnie.

Mikołaj Szczerbicki: Czyli inicjatywa wyszła od biznesu. To biznes poszedł do IT i zgłosił zapotrzebowanie, a nie było tak, że dział IT dostał zadanie budowania agentów AI i drapał się po głowie, do czego ci agenci mogliby się w organizacji przydać.

Marek Grabarz: Tak. Schemat, który opisujesz, widzimy dość często: pojawia się polecenie zarządu albo potrzeba dyrektorska, że potrzebujemy AI. IT drapie się po głowie i myśli: dobra, ale co my tu możemy zrobić? Zwykle IT próbuje wtedy ogarniać swoje bazy wiedzy i swoje tematy, zamiast zrobić discovery, jakieś warsztaty i zrozumieć, na czym stoi biznes tej konkretnej firmy. A potrzeby często powstają właśnie na poziomie biznesu. To chyba klucz, który staramy się realizować w Protopii: spotkać się z biznesem, zrobić warsztaty i znaleźć kilka przypadków użycia spoza IT. Oczywiście IT będzie je realizować, ale problemy są tak naprawdę w innym miejscu.

Mikołaj Szczerbicki: Na szczęście ten przypadek to nie ten scenariusz. Dobrze, wiemy już, jaki był problem u tego klienta. Powiedz mi, w którym momencie projektu pojawiła się Protopia jako zespół?

Marek Grabarz: Dobre pytanie. W tym konkretnym przypadku nie byliśmy tam od samego początku. Inicjatywa i potrzeba już powstały. Projekt został dość dobrze rozpisany: co oni będą próbowali rozwiązać. Była też wdrożona platforma AI. Projekt wystartował, miał sponsora i odpowiednich opiekunów biznesowych. Pojawiliśmy się w miarę na początku, kiedy pierwszy szpadel został wbity w ziemię, a oni doszli do wniosku, że potrzebują kogoś z zewnątrz, kto już widział te procesy i zgłębił implementacje agentowe i obszary AI. Potrzebowali zastrzyku wiedzy eksperckiej.

Mikołaj Szczerbicki: Tu nasuwa mi się pytanie. Zewnętrzna firma ekspercka w organizacji o olbrzymiej skali, w globalnej firmie. Na pewno mają rozbudowany dział IT i wewnętrzne kompetencje, a jednak byli świadomi, że potrzebują zewnętrznego eksperta.

Marek Grabarz: Temat AI, choć jest na tapecie od dwóch, trzech lat, nadal wygląda tak, że ustabilizowane działy IT wiedzą, jak działają procesy DevOps, chmura i tego typu rzeczy. Natomiast wiedzy eksperckiej nie wniesie tu człowiek z dziesięcioletnim doświadczeniem, bo w systemach agentowych doświadczenie można mieć rok, dwa lata. Uznali, że warto wesprzeć się kimś z zewnątrz, kto pokaże, jak to się robi, i pomoże uniknąć problemów, które prędzej czy później wyjdą: problemów z kontekstem, halucynacji i tego typu rzeczy. Warto, żeby był ktoś, kto już widział te problemy i wie, jak je adresować.

Mikołaj Szczerbicki: I wtedy ten klient zgłosił się do…

Marek Grabarz: Zgłosił się do nas.

Mikołaj Szczerbicki: Jak najbardziej. W takim razie przejdźmy do najważniejszej części naszej rozmowy. Opowiedz, co tam budujecie.

Marek Grabarz: Budujemy, jak już wspomniałem, asystenta. Staram się używać słowa „asystent”, żeby odciąć się od słowa „agent”. Dla mnie agent to autonomiczny element, który w tle łączy procesy i je automatyzuje. W tym przypadku mówimy o czymś, co nazwałbym chatbotem. I znowu odgradzam się od klasycznego chatbota, który działa bez kontekstu, choć oczywiście ma podłączone różne rzeczy. Ten asystent przede wszystkim wie, kim jest użytkownik, z którym rozmawia. Wiemy, że rozmawiamy z Mikołajem, który pracuje w konkretnym kraju, w konkretnej roli, a jego kontrakt to umowa o pracę albo B2B. To przekłada się na to, co może, a czego nie może zrobić w organizacji z punktu widzenia HR. Z drugiej strony integrujemy się z najróżniejszymi systemami, które w tym korporacyjnym świecie istnieją od lat, na przykład z systemem do obsługi ticketów HR.

Marek Grabarz: Co mam na myśli? Na przykład zgłoszenie urlopu macierzyńskiego albo zwolnienia chorobowego, prośbę o szkolenie, zmianę roli, przeniesienie osoby. Różne rzeczy obsługuje się przez zgłoszenia, czyli tickety. Wokół tego istnieje ogromna baza wiedzy, w skrócie KB, czyli knowledge base. Bazy są rozproszone: niektóre dotyczą procedur lokalnych, inne globalnych. Pojawiają się zagadnienia w stylu: jestem menedżerem i mam pracowników w trzech różnych miejscach, więc czy mam dostęp do wszystkich tych baz, czy do części? To problemy, które asystent będzie rozwiązywał albo już dziś rozwiązuje. Do tego obszar rozwoju pracowników. Konkretnie wzięliśmy do implementacji plany roczne. Ktoś ma plan, realizuje go, ma cele SMART, które chciałby osiągnąć. Razem z menedżerem i asystentem może formułować te plany i odpowiednio je weryfikować.

Mikołaj Szczerbicki: Powiedziałeś w liczbie mnogiej, bo zakładam, że tych systemów jest mnóstwo. O integracji mówiłeś już w poprzednich odcinkach. Wiemy, że agent bez integracji niewiele zdziała, nie jest pełnowartościowym agentem. Musi mieć dostęp, a integracje muszą być zrobione poprawnie, żeby mógł pobierać i przetwarzać dane. Ale tych systemów jest u klienta na pewno wiele. Prawdopodobnie musieliście coś wybrać, żeby od czegoś zacząć, zawęzić zakres.

Marek Grabarz: Dokładnie tak.

Mikołaj Szczerbicki: Co wybraliście?

Marek Grabarz: Trochę wyprzedziłem odpowiedź na to pytanie. Kluczem jest moim zdaniem dobranie roadmapy produktu tak, żeby nie próbować wrzucić wszystkiego jednocześnie. Pierwsza i najbardziej paląca rzecz to integracja z bazami wiedzy, tak żeby w kontekście użytkownika uzyskiwać konkretne odpowiedzi. Ile mam dni urlopu, czy przysługuje mi taki a taki benefit, czy mogę dostać samochód służbowy i co się z tym wiąże: najróżniejsze pytania, na które odpowiedzi wylądowały w tych bazach. Zamiast zmuszać użytkownika, żeby ręcznie przeszukiwał bazy i próbował coś znaleźć, asystent dostaje się do tych systemów i robi syntezę, która odpowiada natywnie, w języku zadanego pytania. To pierwszy filar. Drugi filar to tickety. Staramy się rozwiązywać problemy użytkowników właśnie w oparciu o bazy wiedzy.

Jeżeli jednak użytkownik dochodzi do ściany i mówi: nadal nie wiem, jak to zrobić, albo już wiem i muszę zgłosić ticket, to drugi krok jest propozycją, żeby wspólnie z nim wypełnić odpowiedni ticket i wiedzieć dokładnie, gdzie on jest. A typów ticketów jest dużo.

Mikołaj Szczerbicki: Czyli żeby szybko i sprawnie przeprowadzić go przez ten proces.

Marek Grabarz: Tak. Trzecia rzecz to wspomniane plany roczne. Chęci i roadmapa produktu są jednak szerokie. Mówimy o nauce, o rekrutacjach, o wewnętrznym rozwoju pracownika, gdzie może znaleźć szansę, żeby się odnaleźć i awansować w organizacji, pionowo albo w poprzek. Możliwości jest dużo.

Mikołaj Szczerbicki: Pomysł jest taki, żeby to rozwiązanie pokryło wiele obszarów HR w tej korporacji.

Marek Grabarz: Żeby stało się centralnym punktem wejścia, który de facto integruje te systemy w całość. Istotna rzecz, którą powtarzamy cały czas: staramy się, żeby asystent nie replikował wartości tych systemów, tylko był punktem dostępu do nich.

Mikołaj Szczerbicki: Możesz zdradzić, na jakim etapie jesteście z tym projektem i z trzema przypadkami, o których opowiedziałeś?

Marek Grabarz: Wdrożenie tego asystenta nie jest „all in”. Pierwszy etap, który nazwaliśmy pierwszym rejsem pilotażowym, czyli pierwsza produkcja, ma ograniczony zasięg. Na tę chwilę aktywnych, unikalnych użytkowników jest już ponad 1000. To pierwszy element.

Mikołaj Szczerbicki: Myślę, że wiele firm chciałoby w ogóle mieć tylu pracowników, a to na razie mała część tego projektu.

Marek Grabarz: Dosłownie. Bodajże wczoraj dostaliśmy zgodę, żeby wejść na produkcję z pełnym zakresem, który opisuję. Ale to znowu nie jest pełny rollout: mówimy o 10% pracowników, czyli już o tysiącach osób. Docelowo, prawdopodobnie na początku lipca, nie widzę wielkich przeszkód, żeby asystent wyszedł na całą organizację. Wtedy mówimy już o pełnym zakresie: wszystkie kraje i wszyscy pracownicy będą mieli dostęp do asystenta.

Mikołaj Szczerbicki: Muszę Ci powiedzieć, że widzę pewien schemat, który często pojawia się u naszych klientów. W tym przypadku widzę, że część rzeczy przemyślano w odpowiednim momencie. Pierwsza sprawa: firmy oczekują, że pojawi się superagent, który od pierwszego dnia na produkcji rozwiąże im wszystkie problemy. Wiemy z doświadczenia, że to nie działa. Tutaj, na szczęście, podejście koncepcyjne…

Marek Grabarz: …jest oparte na roadmapie.

Mikołaj Szczerbicki: Dokładnie, jest zupełnie inne. Jest iteracyjne, rozbite na poszczególne zadania i poszczególnych agentów. Nie powstał jeden duży agent, który ma się zająć wszystkim i nagle rozwiązać wszystkie problemy. Druga kwestia: w tym przypadku to HR, czyli biznes, wyszedł z konkretną potrzebą. Przyszli do działu IT i powiedzieli: słuchajcie, mamy takie wyzwanie i musimy znaleźć sposób, żeby je rozwiązać, pomóżcie nam. Wspomniałeś na początku, że dziś każdy chce mieć AI u siebie, siada i myśli: dobra, zróbmy AI i zastanówmy się, do czego je przypiąć.

Marek Grabarz: Wtrącę się. Później kończy się to tym, że słyszymy na rynku, że 90% wdrożeń tematów AI kończy się porażką, bo nie przynoszą żadnej wartości.

Mikołaj Szczerbicki: Dokładnie tak. I trzecia rzecz, której nie powinniśmy się bać, a widzę u klientów taką obawę: mówić o tym, co konkretnie agent umie, a czego nie umie. Chodzi o transparentność agenta i o to, żeby już na początku komunikacji, w interfejsie, który widzi użytkownik docelowy, przedstawić, do czego ten agent faktycznie służy. Jak to wygląda w tym projekcie?

Marek Grabarz: W tym przypadku, kiedy pojawiają się kolejne edycje, wydania MVP, organizacja robi duże spotkania, korporacyjnie mówiąc town halle. Pierwszym użytkownikom, a docelowo pewnie wszystkim, ogłasza się, że pojawił się asystent i że umie to, to i tamto. Kiedy po raz pierwszy wchodzę z nim w interakcję, od razu widzę deklarację, co jest możliwe, a co nie. Dodatkowo, nawet wewnątrz procesów: wspieramy tworzenie ticketów, OK. Doszliśmy jednak do etapu, w którym uznaliśmy, że pewne typy ticketów są tak złożone, z dynamicznymi, rozwijanymi i zwijanymi menu, że nie chcemy implementować ich przez agenta. Dla użytkownika efektywniej będzie, gdy asystent powie: w tym przypadku Ci nie pomogę, tu jest link, wypełnij ten ticket osobiście, bo jest tam za dużo zależności.

Marek Grabarz: Dzięki temu unikamy halucynacji i problemów, trochę zgodnie z zasadą Pareto. W przypadku ticketów to nie było 80/20, tylko raczej 90/10: 90% funkcjonalności jesteśmy w stanie ogarnąć w 10% wysiłku i odwrotnie. Pozostałe 10% to tak trudny orzech do zgryzienia, że wolimy nie poświęcać 90% czasu, żeby wdrożyć je na siłę. Po prostu ogłaszamy, że ten ticket niestety nie będzie obsługiwany przez asystenta.

Mikołaj Szczerbicki: To też wymaga wiedzy i doświadczenia w pracy z agentami i asystentami, żeby znać ich prawdziwe możliwości, a nie pchać ich wszędzie.

Marek Grabarz: Tak, i przekłada się na jeszcze jedną regułę, którą wzięliśmy pod rozwagę. Ten agent służy temu, żeby orkiestrować procesy, a niekoniecznie je replikować. Jeżeli dojdziemy do wniosku, że jakiś proces jest niezwykle skomplikowany i zamknięty w systemie źródłowym, nie chcemy mikrozarządzać agentem, dając mu instrukcje krok po kroku, co ma robić, jak i dlaczego. Staramy się ogarniać to generycznie i orkiestrować proces, a całe procesowe mięso zostawiamy po stronie systemu. Orkiestrujemy, łączymy kropki, a niekoniecznie zastępujemy te systemy.

Mikołaj Szczerbicki: Dobrze. Wiemy już, co budujecie i na jakim etapie jest projekt. Mnie osobiście bardzo ciekawi, co mierzycie i co sprawdzacie. W poprzednich odcinkach rozmawiałem z Łukaszem o mierzeniu sukcesu. Jak mierzyć sukces?

Marek Grabarz: Jak zmierzyć sukces? W tym przypadku można wyjść od różnych elementów, na przykład od głównego problemu, który asystent miał rozwiązać. Tu jest to liczba zgłoszeń, czyli ticketów, w szczególności tak zwanych user requestów, które są po prostu pytaniem do HR, jak zrobić to czy tamto. Chodzi o to, żeby osoby z HR nie były męczone na czatach i w requestach. Mierzymy więc liczbę ticketów, które rzeczywiście powstają. Staramy się, żeby asystent rozwiązał problem już na etapie bazy wiedzy, a niekoniecznie żeby kończyło się to ticketem. Różnice w liczbie ticketów i konkretnych typów ticketów to jedna z miar, które zdecydowanie mierzymy. Druga istotna miara to to, czy użytkownicy chętnie wracają do asystenta i czy widzimy z tego wartość. Trzecia rzecz: czy asystent rzeczywiście rozwiązuje problemy. Tu mamy mocno zaangażowany element feedbacku w ramach platformy i tego agenta.

Feedback możemy mierzyć w dwóch wymiarach: biznesowym i technicznym. W biznesowym prosimy: hej, tu kawałek feedbacku. Czy ta sesja z asystentem rozwiązała Twój problem? Czy rozwiązała go szybko, czy wymagała wielu iteracji, pytań i kroków? Dostajemy konkretny feedback: tak, rozwiązała, albo nie, bo pojawiły się rzeczy niezwiązane z tym, czego szukałem. Dzięki temu identyfikujemy, czy była to kwestia agenta, niezrozumienia, jak działa, czy braków w bazach wiedzy. Jest tam zespół, który cały czas naprawia bazy wiedzy, bo czasem trafia się stara albo niepoprawna wersja. Czasem oczywiście pojawiają się błędy, ale jest też dużo feedbacku w stylu: super, ale chciałbym albo chciałabym, żeby były tu jeszcze dodatkowe rzeczy.

Oczywiście zbieramy te informacje, bo dzięki nim wiemy, gdzie jest zapotrzebowanie użytkowników. To, co mówi biznes, i to, co mówią użytkownicy, to dwa elementy, które muszą się wzajemnie uzupełniać. Kiedy mamy błędy, pod spodem działa platforma monitoringowa, wręcz z tracingiem. Na produkcji nie będziemy chcieli mieć tego w takim zakresie, bo mamy tu wrażliwe dane HR, czasem związane z payrollem, czasem z problemami zdrowotnymi, więc nie zawsze chcemy wszystko śledzić. Na etapie pilotażowym jesteśmy jednak w stanie wydobyć całą treść rozmowy, kontekst wywołań i poszczególne funkcje, jak zostały wywołane. Dzięki temu wiemy dokładnie, co się wydarzyło, a co nie. Identyfikator sesji nadal gdzieś tam jest.

Mikołaj Szczerbicki: Muszę tu wtrącić jedną rzecz. Słuchając o tych procesach, widzę, że bardzo często nie da się ich zmierzyć miarą pieniądza. Patrzę z perspektywy biznesowej i zarządczej, kogoś, kto miałby za to płacić. Jest wiele procesów, których nie da się zmierzyć tak, żeby spojrzeć z jednej strony, ile będzie mnie kosztowało rozwiązanie agentowe i ile zje tokenów, bo to suma wielu kosztów, a z drugiej strony, co będzie korzyścią, i to zważyć. W tym przypadku nie da się tego zrobić, tak?

Marek Grabarz: Poza typowymi aspektami finansowymi: ile kosztowała realizacja projektu i ile, w dużym uproszczeniu, kosztuje w tokenach cały system. Oczywiście możemy próbować mierzyć efektywność organizacji: jak powstają tickety, ile ich powstaje, czy użytkownicy są zadowoleni. Ale jest też aspekt niemierzalny. Załóżmy, że pracuję w organizacji i potrzebuję rozwiązać jakiś problem. Zwykle albo zagaduję do kogoś, albo próbuję znaleźć magiczny sposób: przetrząsam bazę wiedzy, przetrząsam tickety, próbuję coś stworzyć. Kto pracował w dużej organizacji, ten wie, że nie zawsze wiadomo, gdzie jest ticket i jaki konkretnie ticket trzeba podnieść.

Mikołaj Szczerbicki: To tak zwana wiedza plemienna, jak mówi Łukasz.

Marek Grabarz: I wtedy nie odrywam się od swojej pracy. Załóżmy, że jestem analitykiem finansowym i mam jakiś problem HR. Zamiast czekać dniami, wysyłać maile i zagadywać kogoś na Teamsach, mogę z asystentem bardzo szybko ogarnąć problem i wrócić do pracy. Taką efektywność, mierzoną nieprzerwanym czasem pracy zamiast odrywania się, odpisywania na maile i czekania na skrzynce, trudno zmierzyć, ale moim zdaniem to też ogromna wartość.

Mikołaj Szczerbicki: Kto to przeżył, ten wie. Marek, zmierzając powoli do końca, mam prośbę. Podejrzewam, że wśród osób, które nas oglądają, są takie, które stoją przed podobnym wyzwaniem i zastanawiają się, jak podejść do takiego rozwiązania u siebie. Wymieniłbyś w paru krokach trzy najważniejsze rzeczy, które trzeba przemyśleć, zanim podejmie się takiego wyzwania?

Marek Grabarz: Myślę, że to dobre podsumowanie tego, co już powiedzieliśmy. Myśląc o takim agencie, warto podejść do tego iteracyjnie i procesowo. Zidentyfikować potrzeby, zrozumieć je i nie próbować zrobić wszystkiego naraz. Po prostu powiedzieć: hej, róbmy to krok po kroku. Integrujemy ten system, tamten system, rozszerzamy możliwości asystenta o taką a taką funkcję. To jedna rzecz. Do tego, jak mówiłem, nie próbujmy zastępować elementów, które identyfikujemy, tylko je orkiestrujmy. Starajmy się być punktem wejścia do tych systemów, a niekoniecznie replikować logikę, uprawnienia i wszystko, co da się zrobić w tych systemach. Druga rzecz, którą podkreślaliśmy wielokrotnie i podkreślę po raz kolejny: większość wyzwań w realizacji takich projektów to wyzwania związane z integracją. Okazuje się, że gdy mamy systemy, które już są, jakieś SAP-y, jakieś serwisy, SharePoint czy tego typu rzeczy, to nie jest oczywiste.

Oczywiście porozmawiamy o tym jeszcze z Szymonem w kolejnym odcinku: jakie wyzwania i problemy techniczne mogą się pojawić. Zdradzimy tam kilka smaczków. Musimy jednak zidentyfikować, jak się będziemy integrować, gdzie są zespoły utrzymaniowe i gdzie w organizacji jest wiedza o systemach docelowych, bo bardzo ważne jest, żeby mieć to upilnowane. I na koniec: kiedy budujemy asystenta, warto być w pętli, czyli angażować coraz więcej użytkowników i mierzyć, na ile agent jest efektywny w swojej pracy. Czy rzeczywiście przynosi wartość? Bo ostateczną korzyść z uruchomienia tego procesu da się zmierzyć tylko w ten sposób: czy asystent przynosi wartość, czy nie.

Mikołaj Szczerbicki: Czy robi swoją robotę?

Marek Grabarz: Czy robi robotę.

Mikołaj Szczerbicki: Dobrze, Marek. Na sam koniec poproszę Cię o małą zajawkę następnego odcinka, Twojej rozmowy z Szymonem o technicznych aspektach tego projektu. Powiedz nam proszę o jednym, największym wyzwaniu, z którym spotkałeś się podczas realizacji.

Marek Grabarz: W następnym odcinku nie będę dokładnie omawiał architektury tego rozwiązania, bo pewne szczegóły techniczne staram się trzymać poza wiedzą publiczną. Porozmawiamy za to o niskopoziomowych problemach, których pojawia się co niemiara. Przykładem jest dostęp delegowany. Mamy już asystenta i mamy system, dajmy na to SAP. W SAP jako użytkownik mam dostęp do tego czy tamtego, mogę dotknąć swoich celów rocznych, swoich e-learningów i swoich spraw. Jako przełożony mogę mieć dostęp do moich pracowników i ich deklaracji. Jak to technicznie upilnować? Jak sprawić, żeby asystent miał dostęp tylko do tych danych, czyli de facto replikował RBAC, role i uprawnienia z systemu źródłowego? To nie jest rzecz trywialna. To pierwsza ściana, na którą trafimy, i pierwsza ściana, którą musieliśmy z klientem pokonać.

I znowu gwiazdka, wielkie albo niewielkie zaskoczenie: większość pracy dotyczy tożsamości, integracji i identyfikacji tych API. A na koniec dnia asystent to tylko klej, crème de la crème, który łączy te systemy ze sobą i w efektywny sposób je wywołuje.

Mikołaj Szczerbicki: Dobrze, Marek, ja osobiście nie mogę się doczekać tego odcinka i tych wszystkich smaczków. A na dziś dziękujemy wszystkim bardzo i do zobaczenia w następnych odcinkach.

Marek Grabarz: Cześć, cześć!