Sobhan Daliry, CPO & AI Strategy Leader at Pipefy – Серія інтерв’ю

Sobhan Daliry, CPO & AI Strategy Leader at Pipefy, є досвідченим керівником у сфері продукту та технологій, який очолює AI‑стратегію компанії з 2023 року, допомагаючи перетворювати традиційні бізнес‑процеси на все більш інтелектуальні та автономні. Протягом своєї кар’єри Далірі поєднував продуктову стратегію, організаційну трансформацію та технологічне лідерство у стартапах і великих компаніях. Перш ніж приєднатися до Pipefy, він заснував і був CEO компанії Polen.me та понад п’ять років працював як CEO/CPO у NZN, де керував відновленням компанії та продуктовою стратегією. Раніше він займав посади директора з управління продуктом у PSafe, менеджера продукту у Peixe Urbano, а також працював у сферах цифрових сервісів, телекомунікацій, консалтингу та розвитку бізнесу в Oi/Telemar, Claro, AIRCOM International та Planeta Tecnologia.

Pipefy — це глобальна платформа управління процесами та AI, створена для допомоги організаціям автоматизувати та оркеструвати бізнес‑процеси. Заснована у 2015 році, компанія розвинулася від платформи безкодової автоматизації процесів до оркестраційного середовища, орієнтованого на AI, яке об’єднує AI‑агенти, робочі процеси, форми, портали, додатки, дані, аналітику, повідомлення та інтеграції. Платформа дозволяє командам створювати та керувати AI‑агентами за допомогою природної мови та безкодових інструментів, зберігаючи корпоративне управління, безпеку та видимість. AI‑можливості Pipefy включають агентів, які можуть інтерпретувати документи, виконувати завдання робочих процесів, підтримувати прийняття рішень, взаємодіяти із зовнішніми системами та оркеструвати процеси в таких сферах, як фінанси, управління персоналом, закупівлі, операції з клієнтами та комплаєнс.

Ваша кар’єра пройшла шляхом від інженерії телекомунікацій у компаніях, таких як Claro і Oi, до лідерства у продуктових підрозділах у Peixe Urbano і PSafe, виконання ролі CEO/CPO у NZN, заснування Polen.me і тепер керування продуктовою та AI‑стратегією у Pipefy. Як цей розвиток вплинув на ваш підхід до створення AI‑продуктів, які вирішують реальні операційні проблеми, а не лише демонструють нові технології?

Телеком навчив мене, що інфраструктура має працювати без винятків, у масштабах масивних навантажень, без жодного простору для «в більшості випадків працює». Втрачене з’єднання — це не провал демонстрації, а клієнт, який йде. Така ментальність — надійність понад новизну — ніколи мене не залишила. У Peixe Urbano і PSafe я засвоїв протилежний урок: наскільки швидко споживчі продукти живуть або вмирають залежно від того, чи вирішують вони реальну, відчутну проблему сьогодні, а не теоретичну. Керуючи NZN як CEO/CPO, я був змушений одночасно тримати обидві істини — не можна випередити погану тезу, і не можна випередити погане виконання. Заснування Polen.me дало найдорогіший урок: капітал і час обмежені, тому кожна функція, яку ви створюєте, — це функція, яку ви не створили, а вартість гонитви за вражаючою демонстрацією замість реального робочого процесу проявляється через кілька місяців, а не на сцені. Коли я прийшов до Pipefy, питання, яке я ставлю до кожної AI‑функції, таке ж, як і до вишки: чи витримає це у продакшн‑середовищі, під реальним навантаженням, коли ніхто не спостерігає? Якщо AI‑агент працює лише в підготовленому демонстраційному середовищі, це не продукт — це лише трейлер до нього.

Ви керували формулюванням та впровадженням AI‑стратегії Pipefy з 2023 року. Які припущення щодо корпоративного AI у вас були на початку, які найбільше змінилися з розвитком генеративного AI та AI‑агентів?

Найбільше припущення, яке мені довелося відкинути, полягало в тому, що вузьким місцем буде модель. У 2023 році всі — включаючи мене — оптимізувалися за критерієм «яка LLM найрозумніша». На практиці вузьким місцем виявився контекст: чи знає агент, який саме процес, які обмеження, як виглядає «завершено» для конкретної версії рахунків‑фактур у цього замовника. Якість моделі постійно покращувалася за передбачуваною кривою; контекст процесу не покращувався сам по собі, бо ніхто його не структурував. Друге припущення, яке змінилося, стосувалося автономії. Я вважав, що ринок хоче агентів, які діють повністю незалежно і якомога швидше. На практиці підприємства хочуть — і продовжують хотіти — обмеженої автономії: агентів, які приймають реальні рішення в межах правил, які вони не можуть порушити, залишаючи після цього слід, що це доводить їх дію. Повна автономія без управління — це не амбіція, а лише ризик з кращим інтерфейсом. Ринок швидше зростав у вимогах до довіри, ніж у вимогах до чистих можливостей, і це переосмислення стало найбільшим моїм помилковим уявленням на початку.

Pipefy розрізняє відносно просту AI‑автоматизацію та AI‑агентів, які можуть розмірковувати в неоднозначних ситуаціях, планувати кілька кроків і виконувати дії в межах робочого процесу. Як підприємствам визначити, коли завдання дійсно потребує AI‑агента, а коли детерміністична автоматизація залишається кращим рішенням?

Тест, який я використовую, простий: якщо ви можете написати правило, напишіть правило. Детермінована автоматизація все ще є правильним рішенням для будь‑якого випадку, коли дерево рішень відоме заздалегідь і не змінюється — наприклад, направити цей рахунок‑фактуру цьому затверджувачу, якщо сума нижча за вказану. Це не завдання для агента, а вдавання протилежного лише додає затримку та непередбачуваність до вже вирішеної проблеми. Агент заслуговує на місце в той момент, коли ситуація має неоднозначність, яку фіксоване правило не може розв’язати — рахунок‑фактура не відповідає замовленню точно, відсутнє поле, запит клієнта не підходить до жодної з ваших існуючих категорій. Ось де міркування мають реальну цінність: вирішувати, що робити далі, коли «далі» ще не прописано. Помилка, яку я постійно спостерігаю у підприємств, — це створення агента для 80 % випадків, які вже були детермінованими, бо це виглядає ефектніше, і залишення неоднозначних 20 % — справжньої складної частини — для людини, яка має розплутати їх вручну. Якщо змінити це співвідношення, ви отримаєте справжній продукт.

Спостерігається зростаючий перехід від окремих копілотів до «агентної оркестрації», коли ШІ може координувати процеси, що охоплюють кілька систем. Чим справжня агентна оркестрація відрізняється від простого додавання великої мовної моделі до існуючої платформи автоматизації?

Додавання вузла LLM до існуючого автоматизованого потоку дає вам розумніший окремий крок. Справжня оркестрація означає, що ШІ має постійний, структурований огляд усього процесу — не лише цього завдання, а й того, де воно розташоване в послідовності, що вже сталося вище по потоку, що має бути правдою нижче, щоб це вважалося завершеним. Різниця полягає в тому, чи має інтелект пам’ять про процес, чи лише пам’ять про підказку. Копілот відповідає на запитання, яке ви йому ставите. Оркестрація координує дії між системами, які не спілкуються між собою «з коробки» — вашим ERP, CRM, API партнера — при цьому успадковуючи ті ж правила, дозволи та журнал аудиту, на яких працює решта процесу. Якщо вам доводиться будувати окремий шар управління навколо вашої функції ШІ, бо платформа автоматизації під ним його не має, у вас немає агентної оркестрації — у вас чат‑бот з доступом до API, і це зовсім інший профіль ризику.

AI‑агенти без коду потенційно дозволяють бізнес‑командам автоматизувати все складніші процеси без очікування ресурсів інженерії. Як демократизувати цю можливість, не створюючи нове покоління «тіньового» ШІ, погано спроектованих агентів або безпекових ризиків?

Ви не досягнете безпечної демократизації, просячи бізнес‑користувачів бути обережнішими — ви досягнете її, коли

зробите захисні бар’єри частиною дорожнього покриття, а не окремою смугою, яку треба обирати для їзди. Кожен агент, який створює бізнес‑користувач, успадковує ті ж ролі доступу, той же журнал аудиту та ті ж бізнес‑правила, що вже керують процесом, у якому він створений — це не опціональна конфігурація, а структурна складова. Це справжня відповідь на «тіньовий» ШІ: це не проблема політики, а проблема архітектури. Тіньовий ШІ виникає, коли санкціонований інструмент важче використовувати, ніж несанкціонований, і люди створюють свого агента в особистому обліковому записі ChatGPT або випадковому інструменті автоматизації без видимості для ІТ. Якщо досвід без коду дійсно швидкий, а управління невидиме, бо автоматичне, немає підстави для бізнес‑команди обходити його. У той момент, коли ви робите управління ручним кроком, який треба пам’ятати, ви вже програли.

Коли AI‑агенти набувають здатності приймати рішення та виконувати дії, а не лише рекомендувати їх, як організаціям визначати, де доречна повна автономність, а де людина повинна залишатися в циклі?

Ось вісь, яку я використовую: це не «наскільки розумний агент», а зворотність та радіус впливу. Якщо помилкове рішення легко виявити і легко скасувати — маршрутизація, категоризація, чернетка — дозволяйте агенту діяти і переглядати результати в агрегаті. Якщо помилкове рішення дорого, важко повернути або безпосередньо зачіпає гроші, комплаєнс чи відносини з клієнтом, залишайте людину в циклі для цього конкретного кроку, навіть якщо агент правильно прийняв тисячі рішень поспіль. Помилка полягає в тому, що автономність розглядається як один єдиний регулятор, який підвищують для всього робочого процесу. Реальні процеси — це послідовність кроків з дуже різними профілями ризику, і правильний дизайн розміщує людину саме на тому кроці, де помилка дорого коштує — не скрізь і не ніде. Ось чому «людина в циклі», виконана правильно, не є податком на швидкість — це спосіб побудови довіри, щоб зрештою прибрати її з низькоризикових кроків, бо у вас є докази, які показують, які рішення агент стабільно приймає правильно.

Pipefy підкреслює управління через такі механізми, як журнали аудиту, контроль доступу за ролями, бізнес‑правила та простежуваність безпосередньо у робочому процесі. Чи стає вбудовування управління безпосередньо в шар оркестрації необхідністю, коли компанії переводять AI‑агенти з експериментів у виробництво?

Це не стає обов’язковим — це вже так, і компанії, які зрозуміли це на власному досвіді, — це ті, що першими запустили агентів у продакшн і тепер будують журнал аудиту після факту. Це навпаки, і виправляти це ретроспективно дорого. Якщо журнали аудиту, контроль доступу за ролями та простежуваність не є вбудованими в сам шар оркестрації, кожен новий агент, який ви розгортаєте, стає новим місцем, де управління може тихо провалитися — і ви дізнаєтеся про це лише коли аудитор, регулятор або інцидент поставить питання. Вбудовування управління в шар оркестрації означає, що кожна дія агента автоматично успадковує ті ж правила і залишає ті ж докази, що й людська дія, без необхідності комусь окремо пам’ятати про їх налаштування. Підприємства, які переходять від AI‑експериментів до AI у продакшн, виявляють, що критерії успішності пілоту та продакшну різні: пілот має працювати, продакшн має бути захищеним. Управління — це різниця між цими двома бар’єрами.

Багато компаній можуть продемонструвати вражаючий AI‑пілот, але стикаються з труднощами у перетворенні його на вимірювану бізнес‑цінність. На які метрики слід орієнтуватися лідерам, визначаючи, чи ініціатива AI‑автоматизації дійсно приносить ROI, і які найпоширеніші причини, чому обіцяючі пілоти не масштабуються?

Я не довіряю будь‑якій розмові про ROI AI, яка починається з «зекономлених годин», бо питання: години зекономлені ким, і як це підтвердити? Метрики, які дійсно витримують перевірку CFO, — це те, що аудитори можуть незалежно підтвердити: час циклу конкретного процесу до і після; рівень помилок або переробки; відсоток робочого процесу, який тепер завершується без людського втручання; і охоплення аудиторської лінійності — чи можете ви показати, для кожного агентного рішення, чому воно було прийняте. Якщо ви не можете надати цей журнал, у вас немає числа ROI, а лише анекдот. Пілоти майже завжди не масштабуються з однієї причини: їх будували, щоб довести, що модель працює, а не щоб довести, що процес працює від початку до кінця у продакшн, інтегрований із системами, від яких залежить решта компанії. Пілот, який живе у пісочниці, відокремлений від реальної системи запису, завжди виглядатиме краще, ніж він працює, коли його підключать до всього іншого, що вже працює. Масштабування — це проблема системної інтеграції, замаскована під AI.

Ви також керували ініціативами організаційних змін у Pipefy, впроваджуючи нові AI‑можливості. З вашого досвіду, якою мірою успішне впровадження AI у підприємствах є технологічним викликом, а якою — викликом процесу, культури та управління змінами?

Якщо бути чесним, успішне впровадження AI у підприємствах становить 20 % технологій і 80 % усього іншого. Технології зараз в основному працюють — це не те, що мене турбує. Те, що справді визначає, чи AI‑ініціатива закріпиться, — це чи люди, чиї робочі місця змінюються, довіряють системі настільки, щоб відмовитися від ручної перевірки, яку вони виконували протягом десяти років, і чи готове керівництво перепроектувати процес, а не просто накласти AI поверх старого. Ми пройшли це всередині, створюючи власні інженерні інструменти — технологія автоматизації частин нашого процесу розробки існувала задовго до того, як команда дійсно довірила їй і перестала все подвійно перевіряти вручну. Прорив полягав не в кращій моделі, а у видимому доказі, повтореному достатньо разів, що судження системи збігається з їхнім. Управління змінами для AI — це не лише комунікаційна вправа, а вправа накопичення доказів: ви заробляєте довіру маленькими, перевіреними партіями, а не оголошуєте її на загальних зборах.

Дивлячись у майбутнє, чи очікуєте ви, що традиційне програмне забезпечення для робочих процесів і бізнес‑процесів перетвориться на шари оркестрації, де люди, AI‑агенти та корпоративні системи постійно співпрацюватимуть? Якщо так, що фундаментально зміниться у способі, яким компанії проектують і керують своїми операціями?

Так, і я вважаю, що цей зсув більший, ніж більшість людей уявляє. Раніше програмне забезпечення для робочих процесів слугувало документуванню того, як має відбуватись робота. Тепер це місце, де робота фактично відбувається — живий час виконання, де люди, агенти та корпоративні системи діють у межах одного керованого процесу одночасно, а не людина, яка використовує програму лише як пасивний реєстратор після факту. Фундаментальна зміна — це місце, де «система запису» фактично існує. Раніше записом була база даних, яка оновлювалась після того, як щось вже сталося поза нею. В шарі оркестрації запис і виконання — це одне й те саме: процес сам стає інтерфейсом, доступним не лише через екран, а й через API, сервер MCP, CLI, так що будь‑який агент, внутрішній чи партнёрський, може діяти всередині нього за тими ж правилами, що й людина. Компанії, які розглядають цей зсув як «додати AI до існуючих інструментів», будуть стикаються з бар’єром, який я описав раніше. Ті, хто сприймає свій шар процесу як справжній продукт — те, у що варто інвестувати, правильно структуруючи, — отримають перевагу, яку ніхто не зможе скопіювати, просто купивши той самий AI‑модель.

Дякуємо за чудове інтерв’ю, читачі, які хочуть дізнатися більше, повинні відвідати Pipefy.