Вашим ШІ-агентам потрібні посадові інструкції, а не кращі промпти

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

Запитайте ту саму компанію, що дозволено робити її новому агенту з обробки рахунків, — і вам часто покажуть знімок екрана з промптом.

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

Чому промпт не може замінити посадову інструкцію

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

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

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

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

Скасування проєктів свідчить про проблеми з управлінням

За прогнозом Gartner, до кінця 2027 року буде скасовано понад 40% проєктів із агентним ШІ через зростання витрат, нечітко визначену бізнес-цінність і неналежний контроль ризиків.

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

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

Як застосувати традиційні інструменти управління до агентів

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

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

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

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

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

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

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

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

Про що запитають під час розбору інциденту

Зрештою деякі з цих агентів зроблять те, чого не повинні були робити. Коли це станеться, під час розбору інциденту запитають про те саме, про що запитують щодо людей. Що йому дозволялося робити і де це зафіксовано? Хто схвалив розширення його доступу? Скільки часу знадобилося, щоб його зупинити? Хто за нього відповідав?

Якщо чесні відповіді — «промпт», «ніхто не пам’ятає», «кілька годин» і «незрозуміло», краща модель вас би не врятувала.

Де зрештою опиниться перевага

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

Різниця — у системі управління, побудованій навколо моделі. Таку систему створюють повільно, здебільшого люди, які раніше керували організаціями.

Якби завтра ваш найновіший агент вийшов за межі своїх повноважень, чи помітив би це хтось у вашій компанії? І чи змогли б ви письмово показати аудитору, де проходила межа?