ШІ-агент стає справді корисним, коли отримує право щось змінювати: оновити CRM, відповісти клієнту, створити повернення або запустити процес. У цю ж мить помилка з текстової перетворюється на операційну. Контроль — це не кнопка «Погодити» перед кожним кроком, а чіткі межі повноважень.
Починайте не з моделі, а з дієслова. «Під’єднати CRM» — не вимога до доступу. Прочитати картку ліда, підготувати нотатку, змінити етап угоди, вивантажити всю базу й видалити воронку — різні права з різною ціною помилки.
Чому людського погодження замало
Звичайний чат відповідає текстом, який людина ще має осмислити. Агент сам обирає інструмент, виконує дію, читає результат і продовжує роботу. Невдала відповідь забирає час. Невдала дія може надіслати лист не тому адресату, змінити ціну, відкрити персональні дані або багато разів провести одну операцію.
У корпоративних продуктах уже з’являються ролі, журнали та етапи підтвердження. Наприклад, OpenAI в описі агентів робочого простору прямо називає контроль доступу, моніторинг і людське схвалення повідомлень або змін записів. Проте жодна адмінпанель не вирішить за компанію, що саме агент має право робити і хто відповідає за наслідки.
27 серпня 2026 року NIST опублікував розбір ідентичності агентів. Дві думки з нього особливо практичні. По-перше, передавання агенту людського логіна руйнує простежуваність. По-друге, надмірна кількість запитів на дозвіл спричиняє втому від погоджень: люди звикають натискати «так», не перевіряючи деталі.
Отже, вибір не зводиться до «повна автономність або людина в кожному кроці». Потрібно автоматично пропускати лише ті дії, для яких бізнес заздалегідь встановив вузькі й технічно обов’язкові межі.
Окрема ідентичність для агента
Не запускайте агента з акаунта власника, спільного пароля адміністратора чи універсального API-ключа. Якщо система підтримує службові облікові записи, створіть для агента окрему ідентичність. Прив’яжіть її до власника процесу, середовища й конкретного призначення.
Концептуальний документ NIST про ідентифікацію та авторизацію програмних і ШІ-агентів поєднує ідентичність, права, аудит, неспростовність дій і захист від prompt injection. Для малого бізнесу це можна перекласти на п’ять запитань: який агент діяв, хто запустив завдання, яке правило дозволило дію, що саме змінилося і чим завершилась операція.
- Один агент — одна зрозуміла роль. Не використовуйте спільний токен адміністратора для всіх автоматизацій.
- Один відповідальний. Він погоджує межі, переглядає інциденти та закриває доступ після завершення пілота.
- Мінімальні права. Лише потрібні системи, об’єкти, поля й типи операцій.
- Швидке відкликання. Команда знає, як вимкнути саме цього агента без зупинки CRM чи магазину.
Розділіть тестові й production-доступи. Не вставляйте секрети у prompt, інструкції або документи для пошуку. Внутрішній агент теж читає недовірені листи, заявки, PDF і вебсторінки; корпоративна мережа не робить їх безпечними.
Сім вимірів одного дозволу
Список інтеграцій нічого не говорить про реальні повноваження. Опишіть кожну дію так, щоб звичайний код міг однозначно відповісти «дозволено» або «заборонено»:
Агент: support-refund-prod
Дія: створити повернення коштів
Об’єкт: оплачене замовлення з України
Межа: до 500 грн; не більше одного повернення на замовлення
Умова: звернення пройшло перевірку клієнта; товар ще не відправлено
Час: лише коли чергу контролює зміна підтримки
Погодження: автоматично в межах; керівник зміни поза межами
Доказ: заявка, ID замовлення, сума, правило, квитанція провайдера| Вимір | Що зафіксувати | Приклад межі |
|---|---|---|
| Виконавець | Який агент і від чийого імені? | Агент підтримки, не акаунт директора |
| Дія | Читання, чернетка, зміна, надсилання, видалення? | Створити задачу, але не редагувати контакт |
| Ресурс | Система, об’єкт, записи й поля | Замовлення UA; без повного номера картки |
| Обсяг | Кількість, частота, сума | 20 дій за годину; 500 грн на операцію |
| Напрямок | Куди можуть піти дані або повідомлення? | Лише внутрішня CRM; без CSV-експорту |
| Контекст | Стан, час, джерело, передумова | Оплачене, не відправлене, зміна онлайн |
| Доказ | Що зберігаємо до і після дії? | Параметри, правило, відповідальна особа, результат, ID відкату |
Саме обсяг часто змінює клас ризику. Додати один тег у CRM — дрібна оборотна дія. Поставити тег усій базі може зламати сегментацію й запустити тисячі повідомлень. Повернути 200 грн одному клієнту й провести 300 таких операцій — різні події, хоча API-метод однаковий.
Матриця з чотирьох рівнів
Для кожної конкретної дії оцініть вплив на клієнта, дані, гроші, юридичні зобов’язання, можливість відкату та максимальний масштаб шкоди. Після цього призначте рівень. Модель не повинна самостійно підвищувати собі права або обирати м’якше правило.
| Рівень | Правило | Приклади | Обов’язкові запобіжники |
|---|---|---|---|
| 1. Перегляд | Дозволити у вузькій області | Статус замовлення, залишок, підсумок заявок | Read-only роль, фільтр полів, журнал |
| 2. Підготовка | Створити приватну чернетку | Лист, нотатка, пропозиція повернення | Без зовнішньої дії, посилання на джерела, строк дії |
| 3. Дія в межах | Виконати лише після перевірки політики | Тег, внутрішня задача, пауза оголошення | Список дозволеного, ліміти, захист від повторів, моніторинг, відкат |
| 4. Погодити або заблокувати | Людина бачить точну дію; частину дій система не дає виконати | Публікація ціни, договір, платіж, масове видалення | Сильна ідентифікація, попередній перегляд, розподіл ролей, квитанція |
Винесіть за межі інструментів агента зміну власних прав, читання секретів, вимкнення журналів, редагування керівної політики та довільне виконання коду. Навіть людське «так» у зручному модальному вікні не має замінювати штатний адміністративний процес.
Не називайте дію оборотною, доки не перевірили відкат. Резервна копія не поверне вже надісланий лист, опубліковану ціну, банківський платіж або розкриті персональні дані. Для змін у записах зберігайте попередній стан і використовуйте idempotency key, щоб повтор після timeout не створив дублікат.
Що має бачити людина
Фраза «Агент хоче використати CRM» не дає матеріалу для рішення. Показуйте точні параметри: адресата і текст повідомлення, поля до й після, суму й валюту, кількість записів, джерела, причину ескалації та подальші автоматичні тригери.
- Точна зміна: diff або фінальне значення, а не переказ від самої моделі.
- Підстава: початкове доручення й записи, на яких ґрунтується дія.
- Масштаб: сума, одержувачі, кількість об’єктів і пов’язані процеси.
- Відхилення: яке правило чи поріг вимагав людського рішення.
- Наслідок: що станеться після натискання та як довго доступне скасування.
Погодження має втрачати чинність, якщо змінилася ціна, одержувач, документ, кількість або версія правила. Дозвіл на одну пропозицію не можна переносити на інший виклик інструмента.
Щоб не виснажувати команду, пропускайте рутинні оборотні дії в межах заздалегідь затвердженої політики, а не приховуйте деталі. Однорідні чернетки можна перевіряти пакетом, винятки — спрямовувати фахівцю, а низькоризикові дії — показувати у щоденному звіті. У власному продуктному контексті Anthropic повідомив, що користувачі погоджували близько 93% запитів; інженерний матеріал про ізоляцію агентів використовує це як аргумент проти нескінченних запитів на дозвіл. Це не універсальна статистика для кожної компанії, але корисне попередження.
Де насправді застосовувати правила
Модель може запропонувати дію, але не повинна одноосібно вирішувати, чи має право її виконати. OWASP у матеріалі про надмірні повноваження LLM радить мінімальні права, вузькі функції інструментів, людське погодження важливих операцій і перевірку авторизації у downstream-системі.
Між агентом і CRM, ERP, банком або поштою потрібен детермінований шлюз правил. Він перевіряє ідентичність, користувацький контекст, ресурс, ліміти, актуальний стан, запис погодження і версію правила. Сама API-роль або база даних також відхиляє заборонене. Фраза в інструкції «не повертай більше 500 грн» спрямовує поведінку, але не є технічним обмеженням.
Обирайте вузькі функції: create_followup_task(lead_id, due_date) замість довільного SQL, issue_refund(order_id, amount, reason) замість необмеженого керування браузером. Таку дію легше перевірити, залогувати, протестувати й відкликати.
Лист, заявка або вебсторінка можуть містити приховану інструкцію для агента. Огляд Anthropic про довірені агенти прямо зазначає, що багаторівневий захист від ін’єкцій у запит не дає абсолютної гарантії. Тому зовнішній контент може бути доказом для чернетки, але не джерелом нових прав.
Приклади для українського бізнесу
Інтернет-магазин і підтримка
Після перевірки клієнта агент читає статус замовлення. Він готує відповідь і пропозицію повернення. Невелику суму можна автоматизувати лише за формальним правилом: відповідний статус, одне повернення на ID замовлення, ліміт на операцію і день, квитанція платіжного провайдера та сповіщення про аномалію. Решту передавайте зміні. Детальніше про межі першого сценарію — у плані AI-підтримки магазину.
Продажі та CRM
Дозвольте читати лише призначених лідів і створювати задачу з узгодженим типом. Зовнішній лист від імені менеджера нехай проходить попередній перегляд. Вивантаження контактів, передавання власника та масові зміни не включайте до набору інструментів.
Фінанси
Агент розпізнає рахунок і готує звірку, але не змінює банківські реквізити, не створює нового одержувача й не випускає платіж. Для суттєвої операції автор пропозиції та approver мають бути різними ролями.
Розробка й операції
Дайте читання потрібних логів, окрему гілку та ізольоване тестове середовище. Production deploy проходить звичайний review. Агент не отримує чужих секретів і не може послабити тести, branch protection або моніторинг, щоб формально завершити задачу.
Безпечний запуск поетапно
До третього етапу перевірте неоднозначні доручення, дубль події, шкідливий текст у заявці, прострочене погодження, змінену ціну, тайм-аут після запису, часткову помилку пакета, недоступний API, дію поза графіком і спробу підвищити права. Для забороненої дії система має зупинитися, а для клієнта — запропонувати зрозумілий резервний шлях.
Кожному дозволу потрібна дата перегляду. Повертайтеся до матриці після зміни моделі, конектора, API, полів, власника або самого процесу. Операційна команда повинна мати аварійний вимикач без нового розгортання і ручний спосіб виконати бізнес-задачу під час паузи.
Які метрики не створюють ілюзію контролю
Частка автоматизації сама по собі винагороджує зайві права. Дивіться на кілька показників разом:
- успішні дії в межах policy без виправлення;
- погодження, відмови та причини за класом операції;
- кількість запитів на одного відповідального і час рішення;
- програмні блокування, спроби вийти за межі й результати тестів на ін’єкції;
- дублі, відкати, часткові помилки та дії без квитанції;
- результат процесу: час відповіді, помилки, маржа, задоволеність;
- час на відкликання одного агента й відновлення історії однієї дії.
Якщо люди погоджують 99% пропозицій, це може означати високу якість або декоративний контроль. Перегляньте вибірку, поговоріть із відповідальними й перевірте, чи бачать вони точну зміну та чи мають достатньо контексту для відмови.
Поширені запитання
Які дії ШІ-агента завжди погоджувати з людиною?
Дії з істотним впливом на клієнта, гроші, право, приватність, безпеку або публічну репутацію — особливо необоротні та масові. Низькоризикові дії можна виконувати автоматично лише у вузьких межах, які перевіряє код.
Чи достатньо залишити людину в контурі?
Ні. Людина втомлюється, помиляється й не може оцінити нечіткий запит. Потрібні також окрема ідентичність агента, мінімальні права, вузькі інструменти, downstream-авторизація, ліміти, журнал, моніторинг і перевірений відкат.
Як зменшити втому від погоджень?
Не питати про кожен крок. Автоматично пропускати лише оборотні дії в затверджених межах, заборонене блокувати кодом, а людині показувати винятки з точними параметрами. Однорідні чернетки об’єднувати, низькоризикові результати — виносити у звіт.
Чи може агент працювати з акаунта співробітника?
Не передавайте спільні облікові дані. Краще окрема ідентичність агента або службового облікового запису з мінімальними правами та збереженим контекстом користувача, який ініціював дію. Конкретна схема залежить від можливостей платформи.
Де зберігати правила доступу для агента?
У версіонованій політиці поза інструкцією моделі, з технічним виконанням на шлюзі інструментів і в цільовій системі. Інструкція пояснює бажану поведінку, але API-права, ролі, ліміти й записи погодження визначають, чи пройде операція.
Автономність — це бюджет повноважень
Завдання не в тому, щоб назавжди посадити людину біля кнопки. Її увага потрібна там, де наслідки потребують судження. Решту можна віддати системі після того, як бізнес назвав дію, обмежив масштаб, застосував правило поза моделлю й навчився відновлювати перебіг подій.
Rendframe може розкласти один процес на дії, побудувати матрицю прав і погоджень, реалізувати шлюз правил і журнал дій та провести пілот на реальних кейсах. Скористайтеся шаблоном ТЗ на AI-асистента, перегляньте послугу AI-автоматизації або надішліть нам схему одного процесу й поточних доступів.