Sobhan Daliry, CPO & lider strategii AI w Pipefy – seria wywiadów

Sobhan Daliry, CPO & lider strategii AI w Pipefy, jest doświadczonym menedżerem produktu i technologii, który od 2023 roku kieruje strategią AI firmy, pomagając przekształcać tradycyjne procesy biznesowe w coraz bardziej inteligentne i autonomiczne. W trakcie swojej kariery Daliry łączył strategię produktu, transformację organizacyjną i przywództwo technologiczne w startupach i ugruntowanych przedsiębiorstwach. Przed dołączeniem do Pipefy założył i pełnił funkcję CEO w Polen.me oraz spędził ponad pięć lat jako CEO/CPO w NZN, gdzie prowadził odwrócenie sytuacji firmy i strategię produktu. Wcześniejsze stanowiska obejmowały dyrektora zarządzania produktem w PSafe, menedżera produktu w Peixe Urbano oraz role w usługach cyfrowych, telekomunikacji, konsultingu i rozwoju biznesu w Oi/Telemar, Claro, AIRCOM International i Planeta Tecnologia.

Pipefy jest globalną platformą do zarządzania procesami i AI, zaprojektowaną, aby pomagać organizacjom automatyzować i koordynować przepływy pracy. Założona w 2015 roku, firma przekształciła się z platformy do automatyzacji procesów bez kodu w środowisko orkiestracji skoncentrowane na AI, które łączy AI Agents, przepływy pracy, formularze, portale, aplikacje, dane, analitykę, wiadomości i integracje. Jej platforma umożliwia zespołom tworzenie i zarządzanie AI Agents przy użyciu języka naturalnego i narzędzi bez kodu, zachowując przy tym korporacyjne zarządzanie, bezpieczeństwo i widoczność. Możliwości AI Pipefy obejmują agenty, które potrafią interpretować dokumenty, wykonywać zadania w przepływie pracy, wspierać podejmowanie decyzji, współdziałać z systemami zewnętrznymi i orkiestrację procesów w obszarach takich jak finanse, zasoby ludzkie, zamówienia, operacje obsługi klienta i zgodność.

Twoja kariera przeniosła Cię z inżynierii telekomunikacyjnej w firmach takich jak Claro i Oi do przywództwa produktowego w Peixe Urbano i PSafe, pełniąc funkcję CEO/CPO w NZN, zakładając Polen.me, a obecnie prowadząc strategię produktu i AI w Pipefy. Jak ten rozwój ukształtował Twoje podejście do budowania produktów AI, które rozwiązują rzeczywiste problemy operacyjne, a nie tylko demonstrują nową technologię?

Telekomunikacja nauczyła mnie, że infrastruktura musi działać za każdym razem, w ogromnej skali, bez miejsca na „działa w większości”. Przerwane połączenie nie jest porażką demonstracji, to klient odchodzący. Ta mentalność — niezawodność ponad nowość — nigdy mnie nie opuściła. W Peixe Urbano i PSafe nauczyłem się odwrotnej lekcji: jak szybko produkty konsumenckie żyją lub giną w zależności od tego, czy rozwiązują rzeczywisty, odczuwany problem dziś, a nie teoretyczny. Prowadzenie NZN jako CEO/CPO zmusiło mnie do jednoczesnego trzymania obu prawd — nie można przewyższyć wykonania słabej tezy, i nie można przewyższyć tezy przy słabym wykonaniu. Założenie Polen.me dało mi najdroższą lekcję ze wszystkich: kapitał i czas są ograniczone, więc każda funkcja, którą budujesz, jest funkcją, której nie zbudowałeś, a koszt podążania za imponującą demonstracją zamiast prawdziwym przepływem pracy pojawia się miesiące później, a nie na scenie. Kiedy dotarłem do Pipefy, pytanie, które zadaję o każdą funkcję AI, jest tym samym, które zadałbym o wieżę komórkową: czy wytrzyma w produkcji, przy rzeczywistym obciążeniu, gdy nikt nie patrzy? Jeśli agent AI działa tylko w starannie przygotowanym środowisku demonstracyjnym, nie jest produktem — jest jedynie zwiastunem.

Prowadziłeś opracowywanie i wdrażanie strategii AI Pipefy od 2023 roku. Jakie założenia dotyczące AI w przedsiębiorstwach miałeś na początku, które najbardziej zmieniły się wraz z dojrzewaniem generatywnej AI i agentów AI?

Największym założeniem, które musiałem odrzucić, było przekonanie, że wąskim gardłem będzie model. W 2023 roku wszyscy — w tym ja — optymalizowali się pod kątem „który LLM jest najinteligentniejszy”. Okazało się, że wąskim gardłem jest kontekst: czy agent wie, czym naprawdę jest proces, jakie są ograniczenia, jak wygląda „ukończenie” w konkretnej wersji rozliczeń dostawcy tego klienta. Jakość modelu nadal rosła według przewidywalnej krzywej; kontekst procesu nie poprawiał się sam, ponieważ nikt go nie ustrukturyzował. Drugim odwróconym założeniem była autonomia. Zakładałem, że rynek chce agentów działających całkowicie niezależnie i jak najszybciej. To, czego przedsiębiorstwa naprawdę chcą — i nadal chcą — to ograniczona autonomia: agenci podejmujący rzeczywiste decyzje w ramach reguł, których nie mogą złamać, z zapisem, który to potwierdza później. Pełna autonomia bez nadzoru nie jest ambicją, to po prostu ryzyko z lepszym interfejsem użytkownika. Rynek szybciej dojrzewał pod względem wymagań dotyczących zaufania niż pod względem surowych wymagań funkcjonalnych, a to przestawienie priorytetów jest najważniejszą rzeczą, którą na początku popełniłem.

Pipefy rozróżnia stosunkowo prostą automatyzację AI od agentów AI, które potrafią rozumować w sytuacjach niejednoznacznych, planować wiele kroków i wykonywać działania w ramach przepływu pracy. Jak przedsiębiorstwa powinny określić, kiedy zadanie naprawdę wymaga agenta AI, a kiedy deterministyczna automatyzacja pozostaje lepszym rozwiązaniem?

Test, którego używam, jest prosty: jeśli potrafisz napisać regułę, napisz regułę. Deterministyczna automatyzacja wciąż jest właściwą odpowiedzią dla wszystkiego, co ma znane z góry drzewo decyzyjne i nie zmienia się — skieruj tę fakturę do tego zatwierdzającego, jeśli jej wartość jest poniżej określonej kwoty. To nie jest zadanie dla agenta, a udawanie, że tak jest, tylko zwiększa opóźnienia i nieprzewidywalność czegoś, co już zostało rozwiązane. Agent zasługuje na miejsce w momencie, gdy sytuacja ma niejasność, której nie może rozwiązać stała reguła — faktura nie pasuje dokładnie do zamówienia, brakuje pola, żądanie klienta nie wpisuje się w żadne z istniejących kategorii. To właśnie wtedy rozumowanie ma rzeczywistą wartość: decydowanie, co zrobić dalej, gdy „następny krok” nie jest jeszcze zapisany. Błąd, który widzę, że przedsiębiorstwa popełniają nieustannie, to budowanie agenta dla 80 % przypadków, które już były deterministyczne, ponieważ wygląda to efektowniej, i pozostawianie niejasnych 20 % — prawdziwej trudnej części — człowiekowi do ręcznego rozwiązania. Odwróć ten stosunek, a zbudujesz coś realnego.

Obserwujemy rosnące przejście od samodzielnych copilotów do „agentowej orkiestracji”, w której AI może koordynować procesy obejmujące wiele systemów. Co odróżnia prawdziwą agentową orkiestrację od po prostu dodania dużego modelu językowego do istniejącej platformy automatyzacji?

Umieszczenie węzła LLM w istniejącym przepływie automatyzacji daje inteligentniejszy pojedynczy krok. Prawdziwa orkiestracja oznacza, że AI ma trwały, ustrukturyzowany widok całego procesu — nie tylko tego zadania, ale także tego, gdzie znajduje się w sekwencji, co już wydarzyło się wcześniej, co musi być prawdziwe później, aby uznać to za zakończone. Różnica polega na tym, czy inteligencja ma pamięć procesu, czy tylko pamięć promptu. Copilot odpowiada na zadane mu pytanie. Orkiestracja koordynuje działania między systemami, które nie komunikują się ze sobą natywnie — twoim ERP, CRM, API partnera — zachowując te same reguły, uprawnienia i ścieżkę audytu, na których opiera się reszta procesu. Jeśli musisz budować oddzielną warstwę zarządzania wokół funkcji AI, ponieważ platforma automatyzacji pod nią nie posiada takiej warstwy, nie masz agentowej orkiestracji — masz chatbot z dostępem do API, a ich profil ryzyka jest zupełnie inny.

Agenci AI bez kodu mogą potencjalnie pozwolić zespołom biznesowym automatyzować coraz bardziej złożone procesy bez oczekiwania na zasoby inżynieryjne. Jak demokratyzować tę zdolność, nie tworząc nowej generacji cienia AI, źle zaprojektowanych agentów lub zagrożeń bezpieczeństwa?

Bezpiecznej demokratyzacji nie osiągniesz, prosząc użytkowników biznesowych o większą ostrożność — osiągniesz ją,

tworząc zabezpieczenia jako integralną część nawierzchni, a nie oddzielny pas, którym ludzie muszą się poruszać. Każdy agent, którego buduje użytkownik biznesowy, dziedziczy te same uprawnienia oparte na rolach, tę samą ścieżkę audytu i te same reguły biznesowe, które już rządzą procesem, w którym jest tworzony — nie są to opcjonalne konfiguracje, lecz strukturalne elementy. To właściwa odpowiedź na cień AI: nie jest to problem polityki, lecz problem architektury. Cień AI pojawia się, gdy zatwierdzone narzędzie jest trudniejsze w użyciu niż niezatwierdzone, więc ludzie budują swojego agenta w osobistym koncie ChatGPT lub w losowym narzędziu automatyzacji, które nie jest widoczne dla IT. Jeśli doświadczenie bez kodu jest naprawdę szybkie, a zarządzanie niewidoczne, ponieważ jest automatyczne, nie ma powodu, by zespół biznesowy je omijał. W momencie, gdy uczynisz zarządzanie ręcznym krokiem, który ktoś musi zapamiętać, już straciłeś.

Ponieważ agenci AI zyskują zdolność podejmowania decyzji i wykonywania działań, a nie tylko ich rekomendowania, jak organizacje powinny decydować, gdzie pełna autonomia jest odpowiednia, a gdzie ludzie powinni pozostać w pętli?

Oś, której używam, nie jest „jak inteligentny jest agent”, lecz odwracalność i promień rażenia. Jeśli błędna decyzja jest tania do wykrycia i tania do cofnięcia — routing, kategoryzacja, tworzenie szkiców — pozwól agentowi działać i przeglądać w agregacie. Jeśli błędna decyzja jest kosztowna, trudna do odwrócenia lub bezpośrednio dotyka pieniędzy, zgodności lub relacji z klientem, zachowaj człowieka w pętli dla tego konkretnego kroku, nawet jeśli agent podjął ostatnie tysiąc decyzji prawidłowo. Błąd polega na traktowaniu autonomii jako jednego pokrętła, które podnosi się dla całego przepływu pracy. Rzeczywiste procesy to sekwencja kroków o bardzo różnych profilach ryzyka, a właściwy projekt umieszcza człowieka dokładnie w miejscu, gdzie błąd jest kosztowny — nie wszędzie i nie nigdzie. To także powód, dla którego human-in-the-loop, właściwie wdrożony, nie jest podatkiem na szybkość — jest to sposób budowania pewności, aby ostatecznie usunąć go z niskiego ryzyka kroków, ponieważ masz dowody potwierdzające, które decyzje agent konsekwentnie podejmuje prawidłowo.

Pipefy podkreśla zarządzanie poprzez mechanizmy takie jak ścieżki audytu, kontrola dostępu oparta na rolach, reguły biznesowe i możliwość śledzenia w samym przepływie pracy. Czy wbudowanie zarządzania bezpośrednio w warstwę orkiestracji staje się niezbędne, gdy firmy przenoszą agenty AI z eksperymentów do produkcji?

To nie staje się niezbędne — już jest, a firmy, które odkryły to w trudny sposób, to te, które jako pierwsze wprowadziły agenty do produkcji i teraz budują ścieżkę audytu po fakcie. To jest odwrotne i kosztowne do naprawienia retrospektywnie. Jeśli ścieżki audytu, kontrola dostępu oparta na rolach i możliwość śledzenia nie są natywne dla warstwy orkiestracji, każdy nowy agent, którego wdrażasz, jest nowym miejscem, w którym zarządzanie może cicho zawieść — i nie dowiesz się o tym, dopóki audytor, regulator lub incydent nie postawi pytania. Osadzenie zarządzania w warstwie orkiestracji oznacza, że każda akcja agenta automatycznie dziedziczy te same zasady i pozostawia te same dowody, co działanie człowieka, bez konieczności osobnego konfigurowania. Przedsiębiorstwa przechodzące od eksperymentów AI do AI w produkcji odkrywają, że kryteria sukcesu pilota i kryteria sukcesu produkcji są różne: pilot musi działać, produkcja musi być obronna. Zarządzanie jest różnicą między tymi dwoma progami.

Wiele firm może wykazać imponujący pilotaż AI, ale ma trudności z przetłumaczeniem go na wymierną wartość biznesową. Na jakie metryki powinni się skupiać liderzy, określając, czy inicjatywa automatyzacji AI rzeczywiście przynosi ROI, i jakie są najczęstsze przyczyny, dla których obiecujące pilotaże nie skalują się?

Nie ufam żadnej dyskusji o ROI AI, która zaczyna się od „zaoszczędzonych godzin”, ponieważ pytanie brzmi: kto zaoszczędził te godziny i jak to zweryfikować? Metryki, które naprawdę wytrzymują kontrolę CFO, to te, które audytorzy mogą potwierdzić niezależnie: czas cyklu konkretnego procesu, przed i po; wskaźnik błędów lub poprawek; procent przepływu pracy, który teraz kończy się bez interwencji człowieka; oraz zakres ścieżki audytu — czy możesz pokazać, dla każdej decyzji agenta, dlaczego została podjęta. Jeśli nie możesz przedstawić tej ścieżki, nie masz liczby ROI, masz jedynie anegdotę. Pilotaże prawie zawsze nie skalują się z tego samego powodu: zostały zbudowane, aby udowodnić, że model działa, a nie aby udowodnić, że proces działa end‑to‑end, w produkcji, zintegrowany z systemami, od których zależy reszta firmy. Pilotaż, który istnieje w piaskownicy, odłączony od rzeczywistego systemu źródłowego, zawsze będzie wyglądał lepiej niż faktycznie działa, gdy zostanie podłączony do wszystkiego, co już działa. Skalowanie to problem integracji systemów w przebraniu AI.

Prowadziłeś również inicjatywy zmian organizacyjnych w Pipefy, wprowadzając nowe możliwości AI. Z twojego doświadczenia, ile z udanej adopcji AI w przedsiębiorstwie to naprawdę wyzwanie technologiczne, a ile wyzwanie procesowe, kulturowe i zarządzania zmianą?

Szczerze mówiąc, udana adopcja AI w przedsiębiorstwie to w 20 % technologia i w 80 % wszystko inne. Technologia działa w większości już teraz — to nie jest to, co mnie niepokoi. To, co naprawdę decyduje o tym, czy inicjatywa AI się utrzyma, to czy ludzie, których praca się zmienia, ufają systemowi na tyle, aby zrezygnować z ręcznej kontroli, którą wykonywali przez dziesięć lat, oraz czy przywództwo jest gotowe przeprojektować proces zamiast po prostu nakładać AI na istniejący. Przeszliśmy przez to wewnętrznie, budując własne narzędzia inżynieryjne — technologia automatyzacji części naszego procesu tworzenia oprogramowania istniała na długo przed tym, jak zespół naprawdę zaufał jej na tyle, by przestać ręcznie weryfikować wszystko. Przełom nie był lepszym modelem, lecz widocznym dowodem, powtarzanym wystarczająco wiele razy, że ocena systemu pokrywa się z ich własną. Zarządzanie zmianą w AI nie jest ćwiczeniem komunikacyjnym, to ćwiczenie gromadzenia dowodów — zdobywasz zaufanie w małych, weryfikowalnych partiach, a nie ogłaszasz go na zebraniach całej firmy.

Patrząc w przyszłość, czy spodziewasz się, że tradycyjne oprogramowanie do przepływów pracy i procesów biznesowych przekształci się w warstwy orkiestracji, w których ludzie, agenci AI i systemy przedsiębiorstwa będą współpracować nieustannie? Jeśli tak, co zasadniczo zmieni się w sposobie, w jaki firmy projektują i zarządzają swoimi operacjami?

Tak, i uważam, że zmiana jest większa, niż większość ludzi zakłada. Oprogramowanie do przepływów pracy kiedyś służyło do dokumentowania, jak praca powinna przebiegać. Staje się miejscem, w którym praca rzeczywiście się odbywa — żywym środowiskiem uruchomieniowym, w którym ludzie, agenci i systemy przedsiębiorstwa działają jednocześnie w tym samym zarządzanym procesie, zamiast człowieka używającego oprogramowania jako pasywnego rejestratora po fakcie. To, co zmienia się zasadniczo, to miejsce, w którym „system rejestru” faktycznie istnieje. Rejestr kiedyś był bazą danych, aktualizowaną po tym, jak coś już wydarzyło się poza nią. W warstwie orkiestracji rejestr i wykonanie to to samo — sam proces staje się interfejsem, dostępnym nie tylko przez ekran, ale także przez API, serwer MCP, CLI, tak że każdy agent, wewnętrzny lub partnera, może działać w nim na tych samych zasadach, co człowiek. Firmy, które traktują tę zmianę jako „dodaj AI do istniejących narzędzi”, będą wciąż napotykać na barierę, którą opisałem wcześniej. Te, które potraktują warstwę procesu jako rzeczywisty produkt — to, w co warto inwestować, aby prawidłowo go ustrukturyzować — będą czerpały przewagę, której nikt nie skopiuje, po prostu kupując ten sam model AI.

Dziękujemy za wspaniały wywiad, czytelnicy, którzy chcą dowiedzieć się więcej, powinni odwiedzić Pipefy.