Віджай Раяпаті, генеральний директор та співзасновник Atomicwork – серія інтерв’ю

Vijay Rayapati є співзасновником і генеральним директором Atomicwork. До заснування компанії він працював старшим віце‑президентом і генеральним менеджером підрозділу хмарних мереж і безпеки в Nutanix, після того як Nutanix придбала Minjar, платформу управління хмарами, яку він заснував і розвивав як CEO. Раніше у своїй кар’єрі він займав інженерні та продуктові керівні посади в Kuliza та Trilogy, що дало йому глибокий досвід створення корпоративної інфраструктури та програмних застосувань. Його досвід охоплює хмарну інфраструктуру, корпоративне програмне забезпечення та технології AI‑робочої сили, що робить його відомим засновником у сфері корпоративних ІТ.

Atomicwork — це корпоративна AI‑компанія, яка створює агентну платформу управління ІТ‑сервісами, що допомагає співробітникам вирішувати технічні проблеми, автоматизувати рутинні завдання підтримки та отримувати доступ до корпоративних знань за допомогою ШІ. Платформа поєднує AI‑агентів із сучасними можливостями ITSM для обробки запитів на обслуговування, діагностики проблем, оркестрації робочих процесів між корпоративними системами та зменшення навантаження на ІТ‑команди. Клієнти використовують Atomicwork, щоб забезпечити швидшу підтримку співробітників та підвищити ефективність операцій у ІТ та бізнес‑процесах.

Ви раніше співзаснували Minjar, створили її бізнес управління корпоративною хмарою, а потім очолювали операції в Nutanix після придбання. Які уроки з побудови, продажу та інтеграції компанії з корпоративним програмним забезпеченням переконали вас заснувати Atomicwork у 2022 році та заново створити управління ІТ‑сервісами з нуля для епохи ШІ?

У Minjar ми розробили програмне забезпечення, яке могло скоротити витрати компанії на хмару на третину за рахунок автоматизації. Клієнти захоплювалися рекомендаціями. Але вони залишали їх без дії протягом двох кварталів. Мені знадобився час, щоб зрозуміти чому, і відповідь не була технічною. Коли автоматизація робить виклик і щось йде не так, немає нікого, кого можна притягнути до відповідальності. Підприємства не просто купують програмне забезпечення чи результати. Вони купують когось, хто несе відповідальність. Програмне забезпечення, яке не має місця в організаційній схемі, не отримує повноважень, якими б воно не було хорошим.

Придбання дало мені більш вузький урок. Точкові продукти купують. Системи запису будуються на їх основі. Ви можете мати кращий продукт, і все одно все життя обходитись навколо того, хто володіє робочим процесом.

Роки у Nutanix об’єднали ці два підходи. Я спостерігав, як ІТ купує управління сервісами для контролю, а співробітники сприймають його як форму та чергу. Я також зрозумів, що квиток ніколи не був продуктом. Продуктом був журнал аудиту. Ось чому ITSM пережив сорок років ненависті до нього, і чому його неможливо видалити.

Отже, питання у 2022 році не полягало в тому, чи може ШІ виконати роботу. А в тому, чи можна дати ШІ місце в організаційній схемі. Традиційні платформи ITSM не можуть цього зробити, бо в їхній моделі даних в центрі стоїть людський виконавець, і кожен SLA, затвердження та звіт базуються на цьому припущенні. Додайте ШІ, і ви отримуєте швидшу форму.

Ми створили інший підхід, коли ШІ забезпечує гібридну робочу силу, а не лише програмне забезпечення. AI‑співробітники виконують роботу, а ІТ керує ними так, як HR керує людьми. Ви не налаштовуєте AI‑співробітника. Ви наймаєте його на посаду, оцінюєте його роботу і відкликаєте, якщо він не виконує завдання. Це різниця між ШІ як функцією та ШІ як робочою силою.

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

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

Для цього потрібно набагато більше, ніж потужна модель. AI‑співробітнику потрібна ідентичність, належні дозволи, доступ до схвалених інструментів, організаційний контекст, бюджет і чіткі межі та роль у роботі. Він має працювати через бізнес‑системи, розуміти, коли (і у кого) запитувати затвердження, і залишати журнал аудиту після кожної дії. Ось чому ми так сильно зосередилися на платформі навколо моделі. Надійний ШІ залежить від оркестрації, управління та виконання так само, як і від інтелекту.

Автономність ніколи не повинна бути необмеженою. AI‑співробітник має діяти в межах своїх посадових обов’язків, а люди залишаються залученими, коли робота впливає на чутливі системи або має юридичні, фінансові чи трудові наслідки.

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

Ми не вважаємо, що один AI‑співробітник повинен виконувати усі завдання. ІТ‑організації вже розподіляють обов’язки між різними командами, оскільки кожна роль має різні цілі, дозволи та експертизу. Ми застосували цей підхід до AI‑співробітників, тому запустили сертифікованих AI‑співробітників, які спеціалізуються в різних ІТ‑операційних сферах.

Кожен співробітник відповідає за конкретну функцію, залишаючись у спільному корпоративному контексті. Коли співробітник створює заявку в Atomicwork, розумна маршрутизація забезпечує її направлення до відповідного AI‑співробітника, який працює над запитом, і (залежно від запиту) перенаправляє її іншому AI‑співробітнику, створює дочірні заявки, щоб AI‑співробітники могли одночасно вирішувати проблему (наприклад, заявка на адаптацію може бути розбита на паралельні дії) або ескалює її до людини. Під час переміщення роботи від одного співробітника до іншого, відповідна інформація переходить разом із нею через заявку (систему запису), а також отримує доступ до релевантних систем, таких як сервіс‑деск, платформи ідентифікації, HR‑системи та інструменти співпраці. Такий спільний контекст дозволяє кожному співробітнику приймати рішення, спираючись на вже наявну інформацію, а не починати з нуля.

Atomicwork підтримує різні агентські фреймворки та моделі від постачальників, таких як OpenAI, Anthropic та Google. Як ви визначаєте, яка модель повинна обробляти пошук, міркування, планування та виконання, і як підприємства можуть підтримувати послідовну поведінку, коли базові моделі продовжують змінюватися?

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

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

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

Корпоративні знання рідко зосереджені в одному місці. Частина їх знаходиться в документації, частина — у системах запису, а частина — у повсякденній діяльності бізнесу. ШІ потребує всього цього контексту, щоб приймати надійні рішення.

Universal Context об’єднує ці джерела, поєднуючи корпоративні знання з даними про людей, мережу, інфраструктуру та пристрої з живих операційних систем. AI‑співробітник може посилатися на інформацію з платформ, таких як Confluence або SharePoint, MDM‑систем, як-от Intune та JAMF, а також розуміти, що відбувається в системах, таких як Jira, Workday, Salesforce або постачальники ідентифікації. Він також дотримується існуючих дозволів, тому люди та AI‑співробітники мають доступ лише до тієї інформації, яку вже дозволено бачити.

Ми пояснили, як Universal Context з’єднує корпоративні системи та зберігає межі безпеки, але не описали, як він вирішує конфліктну інформацію, коли довірені джерела не збігаються, або як визначає, яке джерело має перевагу. Ці деталі впровадження не входять до нашої публічної документації.

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

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

Ці можливості працюють лише за умови довіри співробітників. Ми вважаємо, що візуальний доступ має вимагати явної згоди, і користувачі повинні завжди знати, коли він активний. Конфіденційна інформація захищається маскуванням персональних даних (PII), адміністративними контролями та відповідними політиками зберігання.

Ми також чітко заявляємо, що дані клієнтів не використовуються для навчання наших моделей або моделей сторонніх постачальників. Це дає організаціям можливість впроваджувати мультимодальний ШІ, не втрачаючи контролю над своїми даними.

Atomicwork можна розгорнути поряд з існуючим середовищем ServiceNow або Jira Service Management без необхідності негайної міграції. Чи розглядаєте ви це головним чином як стратегію переходу, чи багато підприємств будуть постійно експлуатувати AI‑робочу силу над їхньою застарілою системою запису?

Більшість великих підприємств протягом років будували процеси, інтеграції та управління навколо платформ, таких як ServiceNow та Jira Service Management. Вимагати заміну цих систем перед впровадженням ШІ створює зайві труднощі.

Ми створили інтеграції Atomicwork з ServiceNow та Jira Service Management, щоб клієнти могли трансформувати досвід співробітників і доповнювати свої команди сервісу AI‑співробітниками з першого дня, не порушуючи систем, на які вони вже покладаються. Конектор підтягує релевантний корпоративний ІТ‑контекст для використання AI‑співробітниками, одночасно підтримуючи двосторонню синхронізацію для сервісних агентів у їхній існуючій системі. Ми не вважаємо, що підприємства мають обирати один шлях одразу. Пріоритетом є допомога їм у впровадженні ШІ за їхнім власним графіком.

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

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

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

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

Ми значно інвестували в оцінку, забезпечення політик, моніторинг та тестування червоної команди, оскільки розгортання ШІ — лише початок. Організації потребують впевненості, що ці співробітники продовжують поводитися так, як очікується, коли моделі та корпоративні середовища розвиваються.

Звіт Atomicwork State of AI in IT 2026 виявив, що дві третини ІТ‑фахівців повідомляють про позитивну віддачу від інвестицій у ШІ, тоді як лише одна з п’яти організацій повністю інтегрувала ШІ у свої команди управління сервісами. Що відрізняє впровадження, які приносять вимірювану бізнес‑вартість, від пілотних проектів, що залишаються в експериментальній фазі?

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

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

Наші дослідження також показали, що відповідальний ШІ залишається однією з найвищих пріоритетних задач для ІТ‑лідерів. Це логічно, оскільки організації не надаватимуть ШІ більше відповідальності, доки не зрозуміють, як він приймає рішення, зможуть переглянути їх пізніше та впевнені, що встановлені належні обмеження.

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

ШІ візьме на себе більшість повторюваних операційних завдань, які навантажують сучасні служби підтримки, дозволяючи людям більше часу приділяти обробці винятків, вдосконаленню процесів та уточненню знань, від яких залежить ШІ.

Команди ІТ‑операцій все більше зосереджуватимуться на управлінні AI‑співробітниками, а не на ручному виконанні кожного робочого процесу. Вони визначатимуть дозволи, підключатимуть системи, моніторитимуть продуктивність і забезпечуватимуть, щоб ШІ продовжував працювати в межах встановлених політик.

Я також очікую, що роль CIO розшириться. Управління сотнями AI‑співробітників починає нагадувати управління будь‑якою іншою корпоративною інфраструктурою. Хтось має вирішувати, до чого ці співробітники мають доступ, як їх оцінювати, коли їх оновлювати та чи вони приносять цінність. Бізнес‑команди продовжуватимуть визначати роботу, тоді як ІТ стане HR для ШІ, тобто відповідальним за платформу, управління та операційний контроль, які забезпечують безпечну роботу корпоративної ШІ‑робочої сили.

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