Аудит розповідає, що сталося. Погодження визначає, чи має це статися взагалі.
Ця різниця стає ключовою, коли AI-агенти переходять від підготовки чернеток і аналізу до операційної роботи. Асистента лише для читання можна перевірити постфактум. Агент, який надсилає лист, змінює запис клієнта, оформлює повернення коштів, оновлює запаси, змінює робочий процес або викликає виробничий API, може спричинити наслідки раніше, ніж хтось устигне переглянути журнал.
Питання для CTO не в тому, чи потрібна людина в кожній дії. Це знищило б сенс автоматизації. Питання в тому, які дії можуть виконуватися автоматично, які потребують контрольного шлюзу, а які слід заборонити, доки система не зможе підтвердити більше контексту.
Системи лише з аудитом реагують запізно, коли йдеться про роботу з незворотними наслідками. Системи погодження переносять точку контролю на раніший етап.
Коротко
- Аудит відбувається постфактум; погодження — це рішення до фіксації дії
- Правильний типовий режим визначають класи дій, а не окремі випадки: дозволити, дозволити за умов, вимагати погодження або заборонити
- Набір даних для погодження — запропонована дія, клас, суб’єкт, докази, засіб скасування та строк дії — відрізняє поінформовану перевірку від формального схвалення
- Автоматичне виконання не ворог управління; ворог — автоматичне виконання без управління
- «Поганий успіх» — технічно успішна дія, що порушує межі бізнесу; погодження допомагає йому запобігти, а аудит лише діагностує його
Не кожна дія потребує однакового тертя
Перша помилка — вважати «дію ШІ» єдиним класом ризику.
Агент, який читає внутрішній документ, — це не те саме, що агент, який надсилає договір. Рекомендація в чернетці — не те саме, що виконане оновлення бази даних. Внутрішню мітку, яку можна скасувати, не можна прирівнювати до незворотного платіжного доручення. Повідомлення клієнту — не те саме, що внутрішня аналітична нотатка.
Проєктування погоджень починається з класів дій. CTO має знати, які класи є в агентній системі та який типовий шлях призначено кожному з них.
Низькоризикові дії, які можна скасувати, часто можуть виконуватися автоматично. Для них усе одно потрібні аудиторські докази, але не потрібно погоджувати кожен окремий випадок із людиною. Приклади: внутрішнє підсумовування, доповнення несенситивними даними, створення чернеток, додавання міток або спрямування в чергу, якщо відкат зрозумілий, а вплив обмежений.
Дії середнього ризику можуть потребувати умовного погодження. Вони можуть виконуватися автоматично, якщо залишаються в межах відомих порогів, використовують затверджені джерела даних і визначають засіб скасування. Якщо дія перетинає поріг або спирається на незнайомий контекст, її ізолюють.
Дії із суттєвим впливом або незворотними наслідками потребують шлюзу погодження. Зовнішні побічні ефекти, регуляторні рішення, зміни облікових записів, платіжні доручення, сповіщення клієнтів, руйнівні операції та юридичні чи фінансові зобов’язання не повинні покладатися лише на аудит постфактум.
Ця класифікація — не вистава для відповідності вимогам. Саме вона дає автоматизації змогу зберігати швидкість, не вдаючи, що кожна дія безпечна.
Погодження — це рішення під час виконання
Погодження не має існувати лише в нотатках із зустрічі, політиці введення в роботу чи контрольному списку розгортання. Воно має бути представлене під час виконання.
Агент пропонує дію. Рівень управління класифікує її. Політика перевіряє клас, суб’єкта, контекст, поріг, докази та можливість скасування. Система повертає вердикт. Якщо потрібне погодження, дія очікує. Якщо погодження надано, реєстр фіксує, хто її погодив, що він бачив, яка версія політики діяла і яку дію виконали.
Це не те саме, що просити людей перевіряти випадкові результати. Добрий шлюз погодження надає рецензенту стислий набір даних для рішення: що агент хоче зробити, чому, які докази використав, яким може бути вплив, яке правило застосовується та що станеться, якщо дія буде помилковою.
Без такого набору погодження стає здогадкою. Людина присутня, але не обов’язково поінформована. Саме тут дають збій багато систем із «людиною в контурі». Вони додають людину, але не дають їй повноважень, контексту чи структурованого запису. Про те, що насправді означають повноваження втручатися за Актом ЄС про ШІ, читайте в матеріалі «Стаття 14: пояснення людського нагляду».
Погодження має означати, що людина може відповісти «так», «ні», змінити дію або передати її на вищий рівень — і що система записує це рішення як частину ланцюга подій.
Так погодження стає придатним до перевірки. Якщо клієнт згодом запитає, чому сталася дія, відповідь не зводитиметься до «хтось натиснув “погодити”». Вона спиратиметься на повний запис погодження.
Межа автоматичного виконання
Автоматичне виконання не ворог управління. Ворог — автоматичне виконання без управління.
Зріла агентна система має дозволяти виконувати зворотні низькоризикові дії без затримки на перевірку людиною. Інакше команди оминатимуть систему. Модель контролю має бути суворою там, де вплив великий, і майже непомітною там, де він малий.
Корисну межу визначають можливість скасування та масштаб впливу.
Якщо дію можна скасувати, її вплив обмежений, вона належить до відомого класу й підкріплена достатніми доказами, автоматичне виконання зазвичай виправдане. Водночас система має створити рядок у реєстрі аудиту, застосувати вибіркову перевірку або перевірку за політикою та зупинятися, якщо поведінка змінюється. Але їй не потрібно щоразу чекати на натискання людини.
Якщо дію важко скасувати, вона впливає на клієнта, переміщує кошти, змінює регульований запис або виходить за межі відомого класу, погодження має бути обов’язковим. Дія очікує, доки уповноважена особа не перевірить потрібний набір даних.
| Характер дії | Типовий шлях | Реєстр аудиту | Погодження людиною |
|---|---|---|---|
| Лише внутрішній аналіз для читання | Дозволити | Обов’язковий | Ні |
| Внутрішня зворотна зміна стану у відомому класі | Дозволити, якщо є засіб скасування | Обов’язковий | Ні |
| Повідомлення клієнту | Умовне погодження, якщо твердження, клас одержувача або чутливість перетинають поріг | Обов’язковий | Іноді |
| Зовнішній фінансовий чи юридичний побічний ефект | Погодження обов’язкове | Записи погодження та виконання з обраними засобами контролю цілісності | Так |
| Руйнівна чи незворотна операція у виробничому середовищі | Заборонити, якщо робочий процес не визначає затверджений аварійний шлях | Запис погодження; цілісність і строк зберігання визначаються застосовними обов’язками | Так, визначена роль |
Точні класи різняться залежно від компанії. Сам шаблон — ні.
Погодження запобігає поганому успіху
Інциденти з ШІ не завжди виглядають як очевидні збої. Іноді агент робить саме те, що йому наказали, і в цьому проблема.
Агент підтримки може оформити щедре повернення коштів, яке суперечить політиці. Агент продажів може надіслати умови знижки, яких фінансовий відділ не погоджував. Операційний агент може оновити запис на основі застарілих даних. Агент робочого процесу може закрити заявку, яку слід було передати на вищий рівень. Модель не дала збою. API повернув успіх. Журнали мають бездоганний вигляд.
Це і є поганий успіх: технічно успішна дія, що порушує межі бізнесу.
Аудит допомагає виявити поганий успіх постфактум. Погодження допомагає запобігти йому, коли клас дії потребує перевірки.
В анонімізованому впровадженні для роздрібних операцій практичний ризик полягав не в гучному збої ШІ. Він полягав у тихому накопиченні автоматизованих рішень, що змінювали операційний стан. Рішенням стало розрізняти рекомендацію, сповіщення, запис і запис поза дозволеними межами. Рекомендації могли проходити далі. Типові сповіщення — теж. Суттєві записи проходили через шлюз управління. Записи поза дозволеними межами ізолювали з поясненням причин.
Робота не сповільнилася. Вона стала зрозумілішою. Оператору більше не доводилося відновлювати кожен виняток із пам’яті. Система знала, які дії потребують уваги, а які можуть виконуватися.
У цьому й мета архітектури погоджень: зменшити навантаження на людей, залишаючи людське судження для рішень, де воно має значення.
Набір даних для погодження
Запит на погодження має бути достатньо коротким для швидкої перевірки й достатньо повним для подальшої підзвітності.
Щонайменше він має містити:
- Запропоновану дію
- Клас дії
- Ідентичність суб’єкта або агента
- Цільову систему чи запис
- Вплив на бізнес
- Посилання на докази
- Версію політики
- Причину, з якої потрібне погодження
- Засіб скасування або причину, чому його немає
- Строк дії або поведінку після тайм-ауту
Рецензенту не доведеться читати сирі сліди моделі, крім незвичайних випадків. Система має підсумовувати релевантний контекст і зберігати докладніші докази для аудиту.
Це важливо, бо черги погоджень можуть стати вузьким місцем. Якщо кожен пункт потребує розслідування, люди механічно схвалюватимуть запити, затримуватимуть або покидатимуть робочий процес. Набір даних для погодження відрізняє поінформований контроль від показового тертя.
Це важливо й для регуляторної перевірки. Майбутній рецензент має бачити те, що бачив особа, яка погоджувала дію. Якщо інтерфейс показував відполірований підсумок, а реєстр зберіг лише часову позначку та ідентифікатор користувача, доказів не вистачає. Запис погодження має зберігати контекст рішення, а не лише натискання.
Вибір типового режиму
Типовий шлях — найважливіше проєктне рішення.
Деякі команди за замовчуванням дозволяють дії заради швидкості. Це працює, аж поки не з’являється новий клас дій і не виконується до того, як хтось його помітить. Інші команди за замовчуванням вимагають ручної перевірки заради безпеки. Це працює, аж поки черга перевірок не стає настільки шумною, що люди перестають їй довіряти.
Краще рішення — враховувати клас:
Відомі низькоризикові класи дозволяють із аудитом. Відомі умовні класи дозволяють лише за виконання порогів і наявності доказів. Невідомі класи ізолюють. Відомі класи з великим впливом вимагають погодження. Відомі заборонені класи відхиляють.
Невідомий клас не означає, що дію дозволено. Це означає, що система зустріла тип дії, якого конституція ще не розуміє. Правильна відповідь — ізоізоляція: вона зберігає безпеку, але не блокує розвиток продукту назавжди. Рецензент може класифікувати нову дію, додати правило й дозволити коректно обробляти майбутні випадки.
Так модель погоджень удосконалюється з часом. Вона не вимагає передбачити кожен сценарій під час початкового проєктування. Вона вимагає, щоб система під час виконання не нормалізувала новий ризик мовчки.
Ефективність системи зростає разом зі зрілістю класів дій. На початку впровадження система може частіше ізолювати дії. Згодом більше з них можна виконувати автоматично, бо команда має докази, пороги та перевірені способи скасування. Зі зрілістю управління має пришвидшуватися, а не обтяжувати процес.
Про архітектурного родича цієї моделі — рівень підзвітності, який відповідає за шлюз, реєстр і маршрутизацію ескалацій, — читайте в матеріалі «Що таке рівень підзвітності AI-агентів?».
Що CTO варто запитати цього кварталу
Якщо ваша компанія впроваджує агентів, попросіть показати карту погоджень.
Які дії виконуються автоматично? Які потребують погодження? Які заборонені? Які ізолюють, бо вони нові або неоднозначні? Хто має право погоджувати? Які докази бачать ці люди? Де зберігається запис погодження? Як система поводиться, якщо ніхто не відповідає? Що відбувається після зміни політики?
Якщо відповіді розкидані між коментарями Jira, системними запитами та неформальними знаннями команди, рівень погодження ще не працює по-справжньому.
Негайний крок — вибрати перший робочий процес із незворотними наслідками та реалізувати в ньому повний шаблон: класифікацію дій, вердикт під час виконання, набір даних для погодження, запис у реєстрі, поведінку після тайм-ауту й експорт для перевірки. Коли шаблон запрацює, застосуйте його до наступного процесу.
Не починайте з погодження всього. Почніть із дій, для яких аудит постфактум буде запізним.
Поширені запитання
З: «Погодження» — це те саме, що «людина в контурі»?
Частково. «Людина в контурі» означає, що людина присутня; погодження описує структуру її рішення. Людина може бути «в контурі», переглядаючи випадкові результати, але це не погодження — це вибіркова перевірка. Погодження — це коли дія очікує, поки визначена роль оцінить структурований набір даних, а вердикт буде записано як частина ланцюга подій.
З: А як щодо затримки? Хіба черги погоджень не сповільнять агента?
Лише для дій, які потребують погодження. Маршрутизація за класами потрібна саме для того, щоб низькоризикові дії, які можна скасувати, ніколи не потрапляли до черги й виконувалися автоматично. Черга залишається для дій, вплив яких виправдовує очікування. Якщо в черзі опиняється все, проблема в класифікації, а не в черзі.
З: Як обробляти тайм-аут?
Явно. У кожному запиті на погодження слід визначити, що станеться, якщо уповноважена особа не відповість у межах часу очікування: відхилити (безпечний типовий варіант для незворотних дій), передати на вищий рівень або завершити без дії із записаною причиною. Мовчазні тайм-аути — це неминучий провал аудиту.
З: Чи може агент сам погоджувати свої дії, якщо це «модель-наглядач»?
Ні. Погодження від іншого ШІ в тій самій межі довіри — це перевірка, а не погодження. Погодження потребує визначеної ролі людини, уповноваженої прийняти наслідки. Модель-наглядач може попередньо фільтрувати, оцінювати чи коментувати запит, допомагаючи людині-рецензенту, але не може замінити її в записі погодження.
З: Як запобігти механічному схваленню?
Є три способи. По-перше, звузити чергу завдяки суворій маршрутизації за класами дій, щоб рецензенти бачили лише запити, які справді потребують судження. По-друге, спроєктувати набір даних так, щоб рецензент міг відповісти менш ніж за 60 секунд. По-третє, вибірково перевіряти саму чергу погоджень: відстежувати відмови й зміни та сприймати 100% схвалень як сигнал, що запити потрапляють не за призначенням.
Автор — Нікола Ковтун, засновник Infracortex AI Studio. Ми допомагаємо командам розділяти автоматичне виконання та погодження, щоб низькоризикові дії відбувалися швидко, а суттєві зупинялися на потрібному шлюзі. Cortex Governance Gate відповідає за маршрутизацію за класами дій; Cortex Audit Ledger записує повний набір даних; рівень ескалації поєднує їх. Для вашого технологічного стеку замовте ознайомчу розмову або перегляньте опис послуги Security Gate.
Дивіться також: «Стаття 14 Акта ЄС про ШІ: людський нагляд» | «Що таке рівень підзвітності AI-агентів?» | «Кейс: операційні процеси європейського ритейлу»