Відповідність для агентного ШІ: як захищати, контролювати і спостерігати за ШІ-агентами

Чат-бот може дати погану відповідь. Агент може ухвалити погане рішення і виконати його.

Роками додати ШІ на сайт означало додати чат-бот. Відвідувач ставив питання. Модель генерувала відповідь. Розмова завершувалася.

Ця архітектура змінюється.

ШІ-асистенти переїжджають усередину сайтів, e-commerce платформ, CRM, систем підтримки, внутрішніх інструментів, систем планування і фінансових процесів. Вони більше не обмежені генерацією тексту. Вони вміють шукати в базах, викликати API, оновлювати записи, створювати тікети, змінювати замовлення, запускати процеси, а іноді й ініціювати транзакції.

У момент, коли ШІ-система отримує здатність діяти, а не відповідати, змінюється архітектура. Разом із нею змінюється і задача відповідності.

Чат-бот дає погану відповідь. Агент виконує погане рішення.

Аргумент цієї статті йде в одному напрямку, і його варто назвати до всього іншого.

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

Відповідність тут не тема. Це наслідок.

Від відповідей до дій

Від відповідей до дій

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

Ключове слово тут, дії.

Класичне управління ШІ фокусувалося на моделі та її виводі. Чи точна вона? Чи доречні навчальні дані? Чи дає вона упереджені результати? Чи можна пояснити її вивід? Ці питання лишаються важливими.

Агент додає зовсім інший шар. До яких систем у нього є доступ? Якими інструментами він може користуватися? Які рішення може ухвалювати? Що може змінити? Хто це дозволив? Коли йому потрібна людина? Чи зможе організація відновити, що саме сталося?

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

Дві архітектури

Різницю легко показати.

Класичний ШІ-асистент працює за схемою користувач → модель → відповідь. Модель отримує інформацію і генерує щось для користувача.

Агентна система працює інакше: користувач → агент → міркування → вибір інструмента → API → бізнес-система → результат → наступна дія. ШІ тепер працює всередині більшої системи.

Візьмімо клієнтську підтримку. Класичний чат-бот відповідає: «Ваше замовлення обробляється». Агентний асистент може розпізнати клієнта, зайти в систему замовлень, вивчити замовлення, визначити, що воно підпадає під повернення, створити заявку на повернення, оновити CRM, повідомити клієнта і записати транзакцію.

Друга система куди корисніша. Нею також значно важче керувати.

Якщо повернення оформлене хибно, проблема більше не в тому, що ШІ згенерував неправильне речення. Змінився бізнес-процес.

Момент, коли з'являються права

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

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

Кожну можливість агента хтось йому видав.

У цьому й полягає зсув. Відповідність перестає бути документом і стає властивістю системи.

Три різні питання

Три різні питання

Три поняття вживають як взаємозамінні, і це хибно.

Управління ШІ запитує, що системі взагалі має бути дозволено. Це питання політики, і відповідають на нього люди.

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

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

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

Стек контролю

Стек контролю

Продакшен-агенту потрібні п'ять шарів, і кожен відповідає на своє питання.

1. Ідентичність

Хто діє? Не яка модель, а якій ідентичності приписується дія. Агент, що діє від імені користувача, і агент, що діє як сервісний акаунт, це різні речі, і журнал аудиту зобов'язаний їх розрізняти.

2. Авторизація

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

А зупинятися не слід, бо привілеї, це лише половина питання.

Мінімальні привілеї обмежують доступ. Мінімальна автономія обмежує рішення.

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

3. Інструменти

Реальну поверхню агента задають інструменти. Не модель і не промпт, а інструменти.

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

4. Політика поза моделлю

Інструкції в промпті, це не контроль. Це прохання.

Робоча архітектура ставить механізм політик між агентом і продакшеном: агент → механізм політик → дозволений інструмент → бізнес-система.

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

5. Докази

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

Не тому, що може запитати аудитор. Тому що коли щось піде не так, цей запис, єдиний спосіб з'ясувати, що насправді сталося.

Хто відповідає

Хто відповідає

Щойно ШІ-система отримує здатність діяти, регулювання ускладнюється, хоча й не з тієї причини, про яку зазвичай думають.

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

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

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

Питання не в тому, як це називається. Питання в тому, що воно може зробити.

Що застосовується і коли

Служба підтримки AI Act наводить календар, який варто знати точно, бо зобов'язання набувають чинності не одночасно.

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

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

Із 2 грудня 2027 і 2 серпня 2028 року відповідно агенти, класифіковані як високоризикові системи, підпадають під додаткові вимоги Глави III.

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

Ще один момент заслуговує на акцент, бо регулятори рідко кажуть таке прямо. Комісія описує власні регуляторні міркування щодо ШІ-агентів як попередні на цьому етапі, а Офіс з ШІ продовжує стежити за розвитком.

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

Що це змінює для розробки

Якщо читати регуляторну картину практично, а не юридично, вона вимагає від компанії, що будує агента, трьох речей.

Знати, що агент робить і на що впливає, достатньо детально, щоб його класифікувати. Уміти показати, що класифікація правильна. І пред'явити докази, що заявлені контролі працювали.

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

Вимоги прозорості стоять поруч із цим і часто приймаються за все ціле. Повідомити користувачу, що він спілкується з ШІ, не відповідає на питання, до чого агент має доступ, якими інструментами він користується, що вимагає схвалення і як розслідувати інцидент.

Прозорість повідомляє людям щось про систему. Управління визначає, що система може робити.

Три шари ризику

Три шари ризику

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

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

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

Ризик системи, це те, що відбувається далі. Дія поширюється. Змінюється замовлення, спрацьовує інтеграція, реагує інший процес, іде сповіщення. Питання тут не в тому, чи мав ШІ рацію, а в тому, якими є бізнес-наслідки збою.

Ризик рухається ланцюгом

Ці шари не незалежні. Невелика помилка моделі стає рішенням агента, яке стає зміною в системі, яка стає бізнес-наслідком.

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

Помилка моделі, це речення. Помилка системи, це транзакція.

Тому корисне питання не в тому, наскільки точна модель, а в тому, як далеко помилка може піти, перш ніж щось її зупинить.

Вісім способів зламатися

Вісім способів зламатися

1. Надмірна автономія

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

Кожна додаткова можливість збільшує радіус ураження. Найбезпечніший агент не той, що дурніший. Це той, чия автономія співмірна задачі.

2. Надмірні привілеї

Агент успадковує широкі права, бо видати потужний сервісний акаунт простіше, ніж спроєктувати гранулярну авторизацію.

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

3. Зловживання інструментами

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

Краща архітектура відкриває інструменти умовно. Агент підтримки може прочитати замовлення, оновити тікет і скласти чернетку відповіді, але не провести повернення, поки не виконана умова політики.

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

4. Підміна мети

Агентні системи працюють у напрямку мети, а не виконують одну детерміновану команду, що робить маніпуляцію метою окремою категорією атаки.

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

Це відрізняється від звичайної вразливості. Система може працювати рівно так, як спроєктована.

5. Отруєння пам'яті і контексту

Агенти, що утримують контекст, несуть свої помилки далі. Хибний факт, прийнятий одного разу, може визначати рішення до кінця сесії, а за постійної пам'яті й довше.

Збій тихий, бо нічого не зламалося. Агент просто вірить у те, чого немає, і послідовно на цьому діє. Про те, наскільки переконливо це відбувається, ми писали у статті Чотири ШІ погодились. Ми так нічого й не перевірили.

6. Каскадні відмови

Один агент викликає API, який запускає процес, який викликає іншого агента, який пише в базу, яка шле сповіщення.

Ланцюг агент A → API → процес → агент B → база → сповіщення ефективний, коли правильний, і важко розмотується, коли ні. Кожен крок був авторизований. Комбінацію не розглядав ніхто.

7. Зловживання ідентичністю і правами

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

Журнал має зберігати весь шлях: користувач → агент → процес → інструмент → авторизація → зміна в системі.

8. Експлуатація довіри людини до агента

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

Крок погодження, який завжди проклікують, це не нагляд. Це запис у журналі.

Нагляд має слідувати за ризиком

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

• Низький ризик: автономне виконання виправдане
• Помірний ризик: може вистачити обмежених прав і спостереження
• Високий ризик: може вимагатися схвалення людини
• Критичний або незворотний: системі може знадобитися повністю заборонити автономне виконання

Автономія має зменшуватись у міру зростання незворотності.

Чому в комерції складніше

Чому в комерції складніше

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

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

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

Одна інтеграція. Сім комерційних рішень. Без різниці між ними.

Проблема множника

Мультиринкові магазини роблять це суттєво гіршим, причому з причин, ніяк не пов'язаних із ШІ.

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

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

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

Швидкість прибирає запас міцності

Комерційні системи до того ж незвично невблаганні до часу.

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

Вікно між хибним рішенням і бізнес-наслідком, яке в більшості софту вимірюється циклами рев'ю, тут вимірюється секундами.

Які контролі тут справді важливі

Три з описаних раніше контролів у комерційному середовищі важать непропорційно багато.

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

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

Спостереження і докази

Спостереження і докази

Спостерігати за агентом, це не те саме, що спостерігати за застосунком, бо збої влаштовані інакше.

Звичайна система ламається помилкою. Агент ламається тим, що успішно робить не те. Кожен виклик API повертає 200. Кожна інтеграція працює. Бізнес-результат при цьому хибний.

Успішний виклик API не означає успішної бізнес-дії.

За чим стежити

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

Останнє найчастіше відсутнє, і саме воно ловить агента, який тихо робить щось законне, авторизоване і неправильне. Те саме питання довіри, застосоване до контенту, а не до дій, розібране у статті Human-First контент-стратегія.

Аудитованість, це не логування

Логи фіксують, що щось сталося. Журнал аудиту відновлює, чому.

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

Мета не в тому, щоб закрити чек-лист. Мета в тому, щоб отримати придатні докази.

Автоматизація забезпечує політику, але не визначає її

Частина відповідності автоматизується: інвентаризація систем, збір логів, перевірка прав, виявлення аномалій, застосування політик, формування звітів.

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

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

Фреймворки, це не архітектура

Фреймворки, це не архітектура

Корисний спосіб думати про агентну систему:

Відповідність = Політика + Повноваження + Контролі + Докази + Нагляд

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

Приберіть будь-який елемент, і система ослабне цілком певним і передбачуваним чином.

Задача перекладу

В організацій сьогодні є справді корисні фреймворки. EU AI Act дає правову, ризик-орієнтовану структуру. NIST пропонує рекомендації щодо довіреного ШІ. OWASP публікує практичні рекомендації з безпеки агентних застосунків.

Жоден із них не перетворює агента на систему, що відповідає вимогам у продакшені, бо кожен формулює принципи, а не механізми. Інженерна робота полягає в перекладі:

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

Цей переклад і є основною роботою, і він інженерний, а не нормативний.

Агенту потрібен шар управління

Звідси випливає архітектурний висновок. Серйозна агентна система, це не мовна модель із промптом і API-ключами.

Їй потрібен шар управління навколо: ідентичність, щоб установити, хто діє; політика, щоб визначити, що дозволено; авторизація, щоб вирішити, чи дозволена ця дія зараз; контроль інструментів, щоб обмежити використовувані можливості; записи виконання про те, що реально сталося; спостереження, щоб судити про нормальність поведінки; аудит, щоб це довести; і задані точки, де автономне виконання припиняється.

Модель лишається важливою. Але модель більше не є архітектурою.

Шар управління, це те, що перетворює можливість ШІ на систему, на яку бізнес може покластися.

Референсна архітектура

Референсна архітектура

Зібрані разом, шари утворюють один шлях. Кожен запит агента проходить його по порядку.

КОРИСТУВАЧ → ІДЕНТИЧНІСТЬ → АГЕНТ → МЕХАНІЗМ ПОЛІТИК → АВТОРИЗАЦІЯ ІНСТРУМЕНТА → ІНСТРУМЕНТ → БІЗНЕС-СИСТЕМА → АУДИТ І СПОСТЕРЕЖЕННЯ

Що дає кожен шар, у тому порядку, в якому запит із ним зустрічається:

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

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

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

Агент пропонує. Система дозволяє.

Авторизація інструмента. Зводить рішення до конкретної іменованої можливості. Не доступ до бази, а getCustomerOrder, updateSupportTicket, createRefundRequest, approveRefund. Чотири іменовані інструменти з різними вимогами авторизації, це інший рівень захищеності, ніж один рядок підключення.

Бізнес-система. Виконує. До цього моменту рішення вже ухвалене і перевірене, у чому й полягає сенс попередніх шарів.

Аудит і спостереження. Записують, що сталося, і стежать, чи мало статися. Будуються з самого початку, бо незафіксовані докази не можна відновити пізніше.

Де підключається людина

Схвалення, що існує як крок процесу, рано чи пізно пропустять. Схвалення, що існує як токен виконання, пропустити не можна.

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

Зворотність як проєктне обмеження

Дії поділяються на зворотні, відновлювані і незворотні, і автономію слід калібрувати за цим поділом, а не за впевненістю в моделі.

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

Пояснюваність, це не ланцюг міркувань

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

Це структурований запис того, що сталося, а не розповідь про те, що думала модель.

Тестувати на відмову, а не на успіх

Більшість тестів агента запитують, чи впорався він із задачею. Корисніше запитувати, що відбувається, коли впорюватися не слід.

Хибна інформація. Шкідлива інформація. Відмова інструмента. Відмова прав. Суперечливі інструкції. Отруєння контексту. Каскадна відмова. Тайм-аут людини.

Агент, протестований лише на успіху, не протестований.

Життєвий цикл і зрілість

Життєвий цикл і зрілість

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

Discovery встановлює, для чого агент і що він може змінити. Архітектура визначає ідентичність, повноваження і межі контролю. Розробка реалізує інструменти і забезпечення політик. Тестування покриває режими відмови. Розгортання налагоджує спостереження. Експлуатація стежить за бізнес-результатами, а не лише за технічними. Перегляд перевіряє, чи відповідають видані повноваження фактичному використанню.

Модель зрілості

Більшість організацій можуть знайти себе на короткій шкалі.

• Рівень 0, експеримент: промпт і модель
• Рівень 1, асистент: модель, інтерфейс, обмежений доступ до даних
• Рівень 2, інтегрований агент: агент з інструментами і API
• Рівень 3, контрольований агент: механізм політик, обмежені інструменти, журнал аудиту
• Рівень 4, керована система: усе перелічене плюс спостереження, нагляд, відновлення і перегляд

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

Кому це справді потрібно

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

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

Асистенту, який дістає закриті дані, потрібні ідентичність, контроль доступу і робота з даними. Діяти він і далі не може, але вже може розкрити те, що не повинен.

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

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

Ризик починається не зі слова ШІ. Він починається з повноважень.

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

Починати з наслідків, а не з відповідності

Найпрактичніший вхід у цю роботу не в тому, щоб відкрити фреймворк. Він у тому, щоб поставити шість питань по порядку.

Що робить агент? Що може піти не так? Що агент може змінити? Яким буде наслідок? Який контроль запобіжить або обмежить цей наслідок? Який доказ підтвердить, що контроль спрацював?

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

Нова межа ПЗ

Нова межа ПЗ

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

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

Нове те, що у відповідь тепер входить учасник, який міркує і чия поведінка ймовірнісна, а не детермінована. Де цей учасник стоїть у ширшому комерційному ланцюгу, розібрано у статті SEO приводить до вас. AEO робить так, щоб вас рекомендували., а чи потрібен він взагалі, у статті Чи потрібен мені розробник, чи вистачить ШІ?

Будувати шар контролю до масштабування агента

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

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

Питання, яке варто поставити першим

Не «яку модель нам взяти?», а:

Які рішення і дії ми готові делегувати?

На це питання бізнес може відповісти без технічних знань, і все подальше випливає з відповіді.

До чого це веде

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

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

Модель дає інтелект. Агент дає автономію. Архітектура дає контроль.

ШІ-агенти дедалі частіше ставатимуть частиною сайтів, застосунків, e-commerce платформ і внутрішніх систем. Питання не в тому, чи використовуватимуть їх компанії. Питання в тому, скільки повноважень вони їм дадуть.

Коли софт може діяти за бізнес, відповідність стає архітектурою.

Часті питання

Що таке відповідність для агентного ШІ?

Практика управління, захисту, спостереження і аудиту ШІ-агентів так, щоб їхні автономні дії лишалися в застосовних правових, організаційних, security і операційних межах. Відмінна риса в тому, що йдеться про дії, а не про вивід.

Чим ШІ-агент відрізняється від чат-бота?

Чат-бот генерує відповіді. Агент може використовувати інструменти, звертатися до систем, ухвалювати рішення і виконувати дії. Ця різниця створює вимоги до авторизації, спостереження, аудитованості і нагляду людини, яких немає в системи, що лише виробляє текст.

Чи регулює EU AI Act ШІ-агентів?

Так, хоча й не як окрему категорію. Служба підтримки AI Act Європейської комісії зазначає, що ШІ-агенти не є окремою категорією в межах Акта, і що наявних визначень ШІ-системи і моделі загального призначення достатньо, щоб їх охопити. Зобов'язання тому залежать від системи, її призначення і класифікації ризику. Комісія також описує свої міркування щодо агентів як попередні на цьому етапі.

Коли набувають чинності зобов'язання?

Заборони на шкідливі маніпуляції та експлуатацію вразливостей уже діють. Правила прозорості застосовуються з 2 серпня 2026 року там, де агент взаємодіє з людьми або генерує контент. Додаткові вимоги для високоризикових систем застосовуються з 2 грудня 2027 і 2 серпня 2028 року відповідно.

Які головні ризики?

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

Чи мають ШІ-агенти вимагати схвалення людини?

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

Що таке мінімальна автономія?

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

Як проводити аудит ШІ-агента?

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

Коли починати цю роботу?

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