Хто несе відповідальність за AI-агента у вашій компанії: шість обов’язків та особи, які їх виконують.
Хто у вашій компанії володіє штучним інтелектовим агентом? Що стосується документа SR 26-2, який не регулює питання агентів, шести ролей, за які несеться відповідальність, способів формування персоналу з існуючих команд та щоденного керування.
Джерела: Who Owns What When Your Company Deploys an AI Agent: Six Responsibilities, and Which Teams Hold Them
Агентський ШІ — це програмне забезпечення, яке самостійно обирає послідовність дій та використовує інструменти замість того, щоб дотримуватися фіксованого сценарію. Коли таке програмне забезпечення працює в компанії, виникає просте запитання: хто за нього несе відповідальність?
Регулятори ще не дійшли згоди щодо цього. У спільному листі під номером SR 26-2 від 17 квітня 2026 року Федеральна резервна система та Управління грошової системи, яке замінило документ SR 11-7 — рекомендації з управління ризиками моделей, за якими працювали банки з 2011 року — скасували власні бюлетені Управління, що походили з 1997 року. У примітці до цього листа зазначено, що генеративний та агентський ШІ не підпадають під ці рекомендації. Крім того, поняття „власника моделі“, яке детально описувалося у старому документі, зовсім не згадується у новому.
Через п’ять місяців до Сінгапуру підійшли інакше. Запропоновані Грошовою адміністрацією Сінгапуру рекомендації щодо управління ризиками з використанням ШІ, консультації щодо яких завершилися у січні 2026 року та на момент написання тексту не мали остаточної версії, прямо включають агентів ШІ до сфери дії цих правил. У них попереджають, що агент із доступом до системи може виконувати дії, які суперечать бізнес-цілям чи інтересам клієнтів, та закликають до незалежної перевірки, тобто до аналізу особами, які не створювали систему, перед тим, як будь-що з високим рівнем ризику буде запущено в експлуатацію. Цей текст ще не є законом та буде обов’язковим лише для ліцензованих установ у одній юрисдикції.
Жоден із документів не вказує, хто в компанії несе відповідальність за агента після його запуску, і цю прогалину не можна чекати, поки її заповнить регулятор. Програмне забезпечення, яке виконує дії, потребує межі дії, тобто лінії, яка розділяє те, що воно може робити самостійно, від того, що вимагає участі людини. Забезпечення дотримання цієї межі є технічною проблемою. Визначення того, хто несе відповідальність, є організаційним питанням, і жоден текст його не регулює. У наступному описано все, що агент може зробити або зробити неправильно, та для кожного випадку вказано особу, яка має нести за це відповідальність. Розглядається, хто дає згоду, як заповнити ці посади з існуючих команд, що включає в себе експлуатація агента після запуску та що мають знати розробники. Джерелами є регуляторні тексти, дослідження, опубліковані з 2024 року, та компанії, які підтвердили свої твердження конкретними прикладами.
Шість обов’язків, шість відповідальних осіб
Агент у процесі розробки створює шість обов’язків, і кожен з них потребує відповідального власника. Уявіть собі діаграму обов’язків: відповідальна особа несе відповідальність за результат, особа, яка виконує роботу, її виконує, а особа, з якою консультуються, надає пропозиції, але не має остаточного слова.
- Бізнес та сфера діяльності. Власник бізнесу та експерти з відповідної галузі. Власник несе відповідальність за сценарій використання, а один із експертів водночас є стандартним власником — особою, яка досить добре знає цю галузь, щоб визначати, що є правильним.
- Продукт та архітектура. Архітектор, менеджер продукту та дизайнер процесів комунікації.
Внутрішній аудит не входить до цього списку, оскільки SR 26-2 стверджує, що він зазвичай не дублює діяльність з управління ризиками моделей. Кілька компаній, наведених нижче (Kaiser Permanente, Thomson Reuters, Morgan Stanley), використовують інструменти для створення та пошуку інформації замість повністю автономних агентів, що робить їх найближчими доступними публічними аналогами.
Власник бізнесу: схвалення дій агента
Це схвалення стосується обсягу діяльності, грошових порогів та клієнтів, до яких агент не має права звертатися, з розрізненням за рівнем ризику, як це передбачено у пропозиції Сінгапуру. Воно також охоплює фінансування системи та її подальше припинення роботи. У банках існує частковий попередник для виконання цієї ролі в межах бізнесу. Згідно з посібником експертів OCC 2021 року, за SR 11-7 власником моделі зазвичай була відповідна бізнес-одиниця, хоча це не було загальноприйнятим правилом, а у редакції 2026 року ця посада була вилучена без жодного замінника.
Практичний аргумент є сильнішим за попередні приклади. Кожне рішення щодо схвалення – чи то поріг, чи виключений сегмент клієнтів, чи термін припинення дії – передбачає компроміс між доходами чи послугами та ризиком. Єдиний, хто може укласти такий компроміс та нести за нього відповідальність, – це той, хто несе відповідальність за результати. Той, хто займає цю посаду, потребує як бюджету, так і можливості припинити процес, і лише власник бізнесу має обидва елементи: ризик може зупинити те, що не може профінансувати, а інженерія може створити те, що не може зупинити. Передача цієї посади інженеру дозволила б йому схвалювати власні обсяги робіт, а передача її підрозділу з управління ризиками залишила б нікого, хто несе відповідальність за позитивні результати. Формулювання в Сінгапурі вказують у тому ж напрямку, оскільки вони визначають шкоду відносно бізнес-цілей та інтересів клієнтів, і лише бізнес може визначити, що це таке. Рекомендації в Гонконзі покладають відповідальність на раду директорів.
Архітектор: власник дизайну
Дизайн визначається там, де агент зупиняється, і втручається людина. Він складається з процесу, якого дотримується агент, точок передачі обов’язків людині та дозволів, які запобігають подальшому розвитку ситуації. Останні два елементи разом утворюють конкретні межі дій. Дві компанії розмістили точки передачі обов’язків у одному місці. Лікарі Kaiser Permanente редагують чернетку Ambient-Scribe перед тим, як вона потрапить до медичної картки, а, згідно з їхнім оголошенням, інструмент Debrief від Morgan Stanley дозволяє консультанту внести зміни до узагальнення зустрічі перед тим, як щось буде записано в базу даних клієнтів. Інженери або постачальники можуть створити модель дозволів та інтерфейс. Проте архітектор залишається керівником, оскільки розташування цих меж є частиною дизайну, яка має залишатися незмінною, незалежно від того, хто пише код.
Власник стандарту: розробка критеріїв
Рубрика — це чек-лист, який визначає, що має міститися у правильній відповіді. У Thomson Reuters старші юристи на рівні партнерів присвятили місяці розробці рубрик для програми пошуку інформації. Підсумовуючи результати, вони зазначили, що хороша відповідь має п’ятнадцять необхідних компонентів, тоді як відповідь, що виглядає правдоподібною, — дев’ять. Лише юрист може відрізнити п’ятнадцять від дев’яти, що означає, що розробка рубрики вимагає часу фахівця в галузі, а також єдиного власника, оскільки критерії змінюються, коли оцінюють кілька осіб. Дослідження щодо перевірки інструментів для перевірки ШІ виявило, що критерії змінюються після початку оцінювання, а дослідження Шрейї Шанкар та Адіт’ї Парамесварана про користувачів інструментів для запитів до даних дійшло до тієї ж висновку, зазначивши, що тягар перевірки лягає на користувача.
Встановлення стандарту та його перевірка — це дві різні задачі. Перевірка, тобто щоденний цикл оцінок та аналізу помилок, здійснюється інженерами та фахівцями з даних. Вони створюють механізм оцінки, складають код, який виконує тестові випадки через агента та оцінює результати, а також вивчають виниклі проблеми. Потім фахівець з перевірки аналізує рівень покриття та налаштування механізму оцінки, не перезапускаючи тести команди з розробки.
Операції: підтримка функціонування
Після запуску робота полягає у контролі рівня покриття, обробці сповіщень, вимкненні та відновленні системи, повторному виконанні набору тестів на виявлення регресій (тестові випадки, які запускаються після кожної зміни) та відстеженні рівня використання та витрат. Хтось із представників бізнесу бере участь у черзі чергування, оскільки деякі сповіщення стосуються бізнес-рішень. Планування, класифікація за ступенем серйозності та процедура ескалації належать керівнику операцій, яким є інженер.
Валідатор: перевірка перед запуском
Перевірка валідатором складається з трьох частин. Він шукає ознаки вставки команд (зловмисних інструкцій, розміщених у матеріалах, які читає агент), а також незаконних викликів інструментів. Він аналізує, які персональні дані потрапляють у журнал дій агента, тобто у запис його дій крок за кроком. Крім того, він стежить за людьми, які схвалюють дії агента.
Менеджер постачальника: керування контрактом
Місце використання системи з’являється лише тоді, коли компанія її купує. Тоді постачальник створює частину системи, запускає її функціонування та генерує докази, які має перевірити верифікатор, при цьому відповідальність залишається на своєму місці. Тим часом усі інші власники залежать від чогось, що може надати лише контракт. Верифікатору потрібні права на аудит. Операційній частині системи необхідна заздалегідь повідомлення про зміни моделі, адже саме це запускає процес перевірки на наявність регресії. Власнику стандарту потрібен спосіб експорту слідів та даних, інакше у компанії не буде нічого для оцінки. Власнику бізнесу потрібні умови виходу, інакше вимкнення системи перетворюється на переговори, а не на рішення. Менеджер постачальника забезпечує ці чотири аспекти, не виконуючи жодної з чотирьох обов’язків. Відділ закупівель консультується щодо обсягу робіт та їх прийняття, але не несе відповідальності ні за що з цього.
Три з шести функцій — визначення сценарію використання, вирішення питання про те, що вважається правильним, та незалежна перевірка результатів — не можуть бути виконані командою з реалізації від постачальника самостійно. Призначення відповідальної особи для кожної з цих функцій — це те, що не передбачено нормативними документами.
Поповнення посад за рахунок наявних команд
На ці посади призначаються люди з уже існуючих команд, і порядок має значення, оскільки кожна посада залежить від попередньої.
Почніть з керівника проекту; поки такої особи немає, проект змушений чекати. Ця особа контролює бюджет, процеси та має повноваження вимкнути систему, а також визначає рівень ризику та схвалює дії представника. Інженерні кадри не можуть замінити цю посаду, оскільки ніхто інший не може нести відповідальність за її компроміси.
Далі — архітектор. Ідеально, якщо це людина, яка добре знає бізнес-процес та систему, щоб бути відповідальною за момент, коли закінчується робота агента та починається робота людини. Якщо така особа існує, це місце належить їй. Якщо ніхто не підходить, зовнішня сторона може розпочати роботу, проте компанія все одно мусить призначити внутрішнього отримувача, адже місце не може залишатися вакантним навіть тоді, коли робота виконується в іншому місці.
На третьому місці — стандартний власник, а вирішальним фактором є те, чи має експерт з домену реальний час для роботи. Якщо час захищений, експерт сам складає критерії оцінки, як це робили юристи Thomson Reuters. Якщо ні, спеціалісти з продукту та дизайну розробляють їх для підпису експертом, і стандарт починає зміщуватися, адже саме ті, хто знає, як має виглядати хороша відповідь, не є тими, хто її записує. У своєму листі акціонерам Джеймі Даймон формулює загальне правило: робота, яка є лише частиною обов’язків багатьох людей, ніколи не завершується, а для виконання місії потрібна команда, присвячена їй на повний робочий час.
Під час калібрування судді та відстеження відхилень функція вимірювання цього модуля має бути передана до відділу даних чи аналітики, якщо такий існує в компанії. Якщо ні, то окремий співробітник команди розробки повинен виділити на це спеціальний час. Приклади показують, як це змінює роль команди з науки про дані, коли модель агента надається постачальником. Моделювання та налаштування залишаються у компетенції постачальника, тому вже не можна вважати, що це завдання належить команді з штучного інтелекту. Те, що залишається, — це калібрування та моніторинг відхилень як постійні функції, а також нове завдання щодо моделей кредитування, боротьби з шахрайством, ціноутворення та прогнозування, які команда продовжує розробляти: необхідно вказувати цільову аудиторію кожної моделі перед тим, як агенту дозволять використовувати її як інструмент. Страхові компанії та лікарні, ймовірно, стикаються з такими ж питаннями щодо власних моделей, але жоден із розглянутих тут джерел їх не торкається.
Четвертим є валідатор, а вирішальним фактором є момент, у який вступає в силу принцип відповідності. Принцип відповідності може забезпечити визначення ризиків з самого початку, що, за повідомленнями, робить команда з питань відповідності Chime, або ж може перевірятися лише на етапі випуску продукту; у такому разі сценарій високого ризику все одно потребує незалежної перевірки перед розгортанням, як вимагає проєкт закону Сінгапуру. Для банку найпростішим варіантом здається використання вже існуючої функції керування ризиками моделей, оскільки SR 26-2 не регулює діяльність агентів та дозволяє кожній установі приймати рішення самостійно. Проте жоден джерело з 2024 року не повідомляє про те, що якийсь банк скористався цим підходом.
П’ятим є операційне управління, а вирішальним фактором є те, хто буде стежити за системою після її запуску. У наступному розділі йдеться про це.
Два елементи є спільними для всіх сценаріїв використання. По-перше, це шлюз – єдиний шлях, яким кожен агент використовує для доступу до моделі, де перевіряється ідентичність та фіксуються виклики; ним керує власник операцій. Компанія Wealthsimple зазначила, що приблизно 80 відсотків трафіку її ШІ проходить через цей шлюз, що залишає нез’ясованим питання про те, чи контролюється решта трафіку. По-друге, це система вимірювання, тобто інструменти для збору даних та оцінки, якими спільно керують відділи науки про дані чи аналітики, адже дві команди, які оцінюють один одного за допомогою різних інструментів, отримують показники, які неможливо порівняти. Решта елементів – а саме сценарій використання, критерії оцінки, власник стандартів та місце в системі чергування – залишаються у відповідному бізнес-підрозділі, який ним керує.
Здебільшого ці посади розширюють існуючі обов’язки та не створюють нових. Власник бізнесу, який вже відповідає за прибуток та збитки, додає схвалення обсягу роботи. Експерт у певній галузі додає критерії до знань, які вже є у нього в голові. Інженер бере на себе функції судді та керівника. Спеціалісти з науки про дані, які вже стежать за своїми моделями на наявність проблем, поширюють цей контроль на агента. Відділ комплаєнсу об’єднує визначення ризиків у процес перевірки, який він вже проводить. Не передбачається найм нових працівників. Лише посада верифікатора не може бути розширена, оскільки ця робота закінчується там, де починається процес створення.
Щоденна робота з агентом
Після запуску протягом усього терміну існування системи виконується шість обов’язків. Власник операцій бере на себе чотири з них, власник стандартів — один, а верифікатор — ще один; кожен з цих обов’язків потребує визначеної особи та часу відповіді.
Тріаж попереджень передається до відділу операцій, де чергує спеціаліст з бізнесу. Попередження не є однаковими: помилка дозволів, перерва у роботі та неправильно відхилена заява вимагають різного підходу, причому останнє є бізнес-рішенням. Як проєкт закону Сінгапуру, так і Закон ЄС про ШІ передбачають процес ескалації саме такого типу.
Зупинка схвалюється власником бізнесу та виконується відділом операцій у чотирьох етапах: негайна зупинка, технічне відновлення, корекція роботи бізнесу та дозвіл на повторний запуск. Закон ЄС про ШІ передбачає, що особа, яка контролює систему високого ризику, повинна мати можливість зупинити її за допомогою кнопки зупинки або подібної процедури, яка переводить її у безпечний стан. Людина, яка створює цю кнопку, не є тією, хто вирішує натиснути її. Закриття вікна чату не скасовує оплату чи сповіщення, які вже знаходяться у черзі, а корекція роботи бізнесу не має еквівалента скасуванню коду. Тож рішення про зупинку є справою бізнесу, а її виконання — завданням відділу операцій.
Тестування на регресію після зміни моделі — це спільні зусилля спеціалістів з науки про дані, інженерів та бізнесу, причому випуск схвалюється валідатором. Документованим прикладом є Assistant від Morgan Stanley: він працює на моделях OpenAI, проте банк створив власну систему оцінки. Консультанти та інженери з формулювання запитів щодня разом оцінюють набір тестів на регресію, а постачальник не надав ні критеріїв оцінки, ні основ для їх застосування. Джерелом цього є OpenAI, яке отримує вигоду від презентації клієнта, і йдеться про додаток для пошуку інформації. Процес починається з повідомлення про зміну від постачальника, яке має отримати менеджер постачальника.
Використання та витрати належать до операційних процесів, причому правильною одиницею є завершена задача. Спроби повторної обробки, оцінка та корекція роботи — усе це є частиною однієї задачі, а один виклик моделі — лише її частина, тому наведення цін за кожен виклик відображає лише частину сукупних витрат.
Передача інформації про проблеми у виробництві до системи оцінки є постійним обов’язком власника стандарту. У доповіді, перепублікованій компанією Arize, клієнтом якої є Uber, дизайнер діалогів Uber зазначив, що система оцінки та її набір даних оновлюються щотижня, оскільки сигнали з застарілих даних є гіршими, ніж їх відсутність. Це означає, що дизайнер виконує роботу, яку вищезазначені посади покладають на інженерів та науковців з даних. За повідомленнями, сигнали про дотримання стандартів від Chime надходять до системи оцінки протягом кількох годин через офлайн-аналіз, який проводиться пізніше.
Стеження за особами, які схвалюють — це постійна робота верифікатора. Anthropic повідомляє, що близько 93 відсотків запитів на надання дозволів для його кодувального агента приймаються, що є досить високим показником, який свідчить про формальне схвалення без справжньої перевірки. Оскільки це стосується кодувального агента, а не агента для бізнес-процесів, це ілюструє ризик, але не квантує його тут. Профіль генеративного ШІ від NIST, який є добровільним, пропонує фіксувати кожен раз, коли людина перевершує результати системи — це та сама перевірка, яку можна побачити з протилежного боку.
Ці обов’язки ніколи не закінчуються, і жоден публічний звіт не вказує кількість годин, які витрачає кожен з них. Ротацію, тести на регресію та відстеження витрат можна замовити ззовні, що є темою для подальшої дискусії.
Що має навчитися команда та наскільки високі стандарти
Навчання піднімає три запитання: що кожен у команді повинен вміти робити, де все ще необхідний спеціаліст, та який рівень якості вважається достатнім.
Чотири навички стосуються всіх, незалежно від посади:
- спостереження за слідами та результатами оцінки безпосередньо, без покладання на чиїсь узагальнення
- міркування щодо розподілу результатів, а не окремих прикладів
- оцінка роботи за кінцевим станом, який вона залишила, а не за тим, що агент стверджує, що зробив
- чітке сформулювання завдання для його делегування, а потім контроль за результатом
Керівник відділу інформаційних технологій Goldman Sachs Марко Ардженті називає саме цю послідовність. За його словами, лідери повинні опанувати три навички управління: опис завдання, його делегування ШІ-агенту та контроль за результатами.
Половина роботи з оцінювання все ще вимагає спеціаліста. Цикл оцінок та аналізу помилок, щоденна робота з оцінюванням результатів та визначенням причин несправностей, поділяється на рутинну та епізодичну частини. Рутинна частина включає написання коду для оцінювача, створення необхідних інструментів та аналіз помилок кожного дня. Для цього потрібні інженерні навички та статистичне мислення, і роботодавці все частіше об’єднують ці обов’язки під однією назвою — інженер з ШІ. «Skills Map» від DeepLearning.AI описує цю посаду на основі оголошень та інтерв’ю, хоча його видавець пропонує саме ті курси, які зазначаються в цих оголошеннях. Епізодична частина полягає у калібруванні оцінювача за допомогою людських оцінок та виявленні відхилень, що краще підходить для датасайентиста та зазвичай потрібне під час перевірок. Не технологічна компанія розумно буде навчати інженерів з програмного забезпечення на посади інженерів з ШІ, а науку про дані залишити для калібрування та підтримки процесу перевірки валідаторами. Жодне дослідження не порівнює ці два підходи, а звіт Skills Map відображає лише те, що вимагають роботодавці.
Цей інструмент призначений для виявлення тих типів несправностей, які інструменти постійно пропускають, і ця відповідальність лежить на власнику стандарту та перевіряючому. У дослідженні 2026 року Антаріпа Саха та Хамел Хусейн, які викладають платні курси з оцінювання, використали шість автоматизованих систем перегляду для аналізу 100 зразків продуктивної роботи, що містили 39 несправностей, позначених вручну. Найкраща система виявила 87 відсотків позначених несправностей, а пропуски були систематичними — один тип несправностей уникає кожної системи. Усі вони також позначали несправності, які проігнорував людський перевіряючий, тому ці показники не є рейтингом, а дані складаються з однієї бази даних із позначками одного експерта. Дослідження все ж показує, де все ще потрібні люди: власник стандарту, чия шкала визначає, що вважається несправністю, та перевіряючий, чий контроль охоплення шукає саме те, що пропускають інструменти.
Ця здатність розвивається шляхом демонстрації людям невдач та підтримується через планові перевірки. Хусейн та Шанкар, які мають спільний інтерес до платних курсів, розділяють оцінювання між інженерами та менеджерами продукту. Інженери виявляють технічні проблеми, такі як помилки отримання даних та проблеми з інструментами, тоді як менеджери продукту виявляють недоліки продукту, наприклад, ті очікування користувачів, які не були задоволені. Одна особа, відповідальна за прийняття рішень, займається щоденним оцінюванням, що є різною роллю від незалежної перевірки верифікатора. Щоб забезпечити підтримку, вони радять не представляти оцінки окремо, а натомість показувати колегам, що з’являється під час аналізу даних. У проєкті закону Сінгапуру додано ще один аспект: саму цю здатність необхідно періодично переоцінювати.
Що може та чого не може підтвердити цей доказ
Кожен елемент регуляторного тексту та кожен конкретний випадок мають своє власне джерело, але важливими є також їхні межі. Регуляції визначають вимоги, і SR 26-2 виключає штучний інтелект у формі агента з їхньої сфери дії. Дослідження ґрунтуються на користувачах, які виконують запити до даних, на 39 випадках невдач у одному наборі даних та на невеликій кількості якісних зразків. Assistant від Kaiser, Thomson Reuters та Morgan Stanley є інструментами для пошуку чи складання тексту, а не багатоетапними агентами, які діють самостійно. Жодна нетехнологічна компанія не оприлюднила список своїх команд агентів, і наведені фірми — це ті, що вирішили це зробити, тому про проекти, які тихо зазнали невдачі, у зразку немає. Більшість таких компаній не будуть довго роздумувати над купівлею платформи для агентів; вони оберуть одного з провідних постачальників хмарних послуг та продовжать роботу. Складнішим є вибір щодо зовнішньої допомоги — чи то консультації, додаткові співробітники чи інженер, який працюватиме безпосередньо на проекті, — та те, що залишиться після завершення співпраці. Усі шість посад залишаються в межах компанії, а те, що можна придбати, — це послуги з їх виконання.
У квітні Федеральна резервна система видала інформацію про власника моделі зі своїх рекомендацій, а Сінгапур ще за п’ять місяців раніше запропонував, щоб агента з доступом до системи перевіряли особи, які не належать до команди розробки. У жодному з документів не зазначено, хто в компанії несе відповідальність за агента. Компанії потрібно шість визначених власників, починаючи з власника бізнесу, який схвалює дії агента, оплачує їх та може їх зупинити. Регулятори більше не описують цю посаду, проте її не можна залишати порожньою, адже саме це схвалення визначає межі роботи всіх інших. Попередження Марко Ардженті залишається актуальним: делегування обов’язків агенту без можливості його контролю призводить до катастроф, тому людям потрібне нове розуміння контролю якості та відповідальності.
Пов’язані матеріали
- Ваш Agent Graph має бути у форматі YAML: компіляція LangGraph з 17 агентами під час запуску — як невеликий движок компілює один YAML-файл у структуру LangGraph StateGraph: генерація стану, плагіни importlib, маршрутизатори міток, адаптивні виклики та заміна вузлів протягом сеансу.
- Gemini Spark пояснено: завдання, навички, графіки, безпека та ціни — що робить агент Gemini Spark від Google, який працює постійно, у Gmail, Календарі та Docs, як функціонують його механізми безпеки, скільки він коштує, де його блокують та хто повинен його використовувати.