Human in the loop: свідомі рішення й межі автономії

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

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

Передумови. Достатньо розуміти, що агент виконує кроки через інструменти, а оркестратор координує ці кроки (глава 73). Попереднє знання систем погодження не потрібне: необхідні поняття пояснені нижче.

Людина в контурі ухвалення рішень (human in the loop) — це спосіб організувати роботу, де власник політики заздалегідь визначає рішення й дії, що потребують людського судження або повноважень, а система готує потрібні докази й технічно дотримується цієї межі. Це не означає ручне підтвердження кожного читання, тесту чи виклику інструмента. І це не кнопка, яка перетворює нечітке «так» на необмежену довіру.

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

Блок A. Хто відповідає, що можна робити і де межа дозволу

74.1. Розподіліть людські ролі

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

Роль	За що відповідає	Яке рішення не можна підмінити текстом агента
Власник мети	Що потрібно отримати та за якими критеріями це корисне	Чи відповідає результат реальній потребі
Власник системи або даних	Доступ, технічні обмеження, класифікація й збереження даних	Чи дозволена дія саме на цьому ресурсі
Автор зміни	Втілення обмеженого плану, пояснення diff та відомих ризиків	Чи є зміна повною й перевіреною на заявленій ревізії
Рецензент	Незалежне зіставлення результату з критеріями та доказами	Чи є конкретний дефект або відхилення від погодженого обсягу
Відповідальний за ризикову дію	Прийняття рішення щодо публікації, доступу, грошей, продакшену чи видалення	Чи прийнятний для організації конкретний залишковий ризик

У маленькій команді одна людина може мати кілька ролей; у регульованому чи високоризиковому процесі політика може вимагати їх розділяти. В обох випадках роль треба прив’язати до повноваження в конкретній системі. Повідомлення «агент вважає, що це безпечно» не доводить, що особа мала право дозволити саме цю дію.

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

74.2. Оцініть дію за впливом і відновлюваністю

Назви «читання» й «запис» надто грубі, щоб самі визначали дозвіл. Читання невеликої локальної конфігурації відрізняється від читання медичної бази; запис у тимчасову гілку — від зміни доступу до продакшену. Перевірте щонайменше масштаб, чутливість ресурсу, зовнішність ефекту, вартість помилки, можливість відкотити результат і те, чи можна його помітити.

Клас дії	Типова межа автономії	Доказ до або після дії
Публічне чи локальне читання для поставленої задачі	Може виконуватися автоматично в дозволеній області	Джерело, потрібний фрагмент і версія
Читання персональних або секретних даних	Лише за явною потребою, мінімальним обсягом і дозволеним призначенням	Власник даних, категорія, ціль і спосіб мінімізації
Локальна оборотна зміна у виділеній гілці	Може бути делегована в межах контракту	Diff, commit, перевірки та процедура відновлення
Зовнішній запис, надсилання або публікація	Межа залежить від аудиторії, даних і незворотності	Ціль, вміст, адресат, попередній перегляд і власник дозволу
Доступи, секрети, платежі чи рахунки	Вимагає мінімальних повноважень і спеціального контролю	Яка саме роль, сума або секрет змінюється та як дія обмежена
Продакшен, міграція або видалення	Зазвичай потрібні сильніші докази й політичний gate	Ревізія, середовище, план відновлення, вікно та відповідальна особа

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

74.3. Дайте обмежений дозвіл за контрактом

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

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

Дозвіл діє для визначеної версії плану, а не для всіх кроків, які модель згодом назвe «необхідними». Якщо вимога зростає, система має позначити відхилення і показати наслідок. Наприклад: «Початково дозволено лише зміну файлів у гілці. План тепер додає міграцію й публікацію пакета; цих дій у дозволі немає».

Практичний дозвіл варто записати як перевірні поля, а не як довгий абзац. Наприклад, правило може сказати: «дозволено змінити файли src/ у гілці задачі, запускати локальні тести й відкрити чернетку запиту на злиття змін (pull request, PR); заборонено зливати, публікувати пакет, змінювати секрети або виконувати міграцію». Система перевіряє кожний інструментальний виклик навпроти такого правила. Схвалений план не перетворюється автоматично на дозвіл для нового ресурсу чи іншого інструмента.

Офіційний посібник OpenAI описує переривання виконання перед чутливим викликом і відновлення тієї самої сесії після схвалення; він також радить перевіряти політику біля інструмента, що створює зовнішній ефект, бо guardrails на рівні агента діють не на кожному кроці ланцюга OpenAI: guardrails та погодження. У Managed Agents від Anthropic політика може дозволяти дію, чекати на людину або передати оцінку серверу; конфігурація набору інструментів і власні інструменти застосунку мають окремі межі, а вже запущена сесія зберігає конфігурацію, з якою її створили Anthropic: політики дозволів. Ці приклади показують можливі механізми продуктів, а не готову політику для кожної організації.

74.4. «Лише читання» не завжди означає «безпечно»

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

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

Практичний підхід — спочатку зменшити потрібний обсяг: агрегувати локально, вилучити прямі ідентифікатори, відфільтрувати колонки або скористатися тестовими даними. Якщо для рішення потрібні сирі чутливі записи, зупинитися й залучити власника даних. Це може вимагати людського дозволу навіть тоді, коли зовнішній виклик формально позначений read-only.

Блок B. Зробіть погодження зрозумілим і чинним для конкретної дії

74.5. Пакет рішення має показувати наслідок

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

1. Що саме планується? Один опис дії простими словами, без загального «продовжити роботу».
2. Де це станеться? Репозиторій, гілка й commit, таблиця, одержувач, середовище або платіжний акаунт.
3. Що змінилося й чому? Посилання на diff, запит, набір даних або план; відокремте факт від припущення.
4. Які є альтернативи? Наприклад, зупинитися після локального виправлення, підготувати міграцію без її запуску або анонімізувати дані.
5. Який можливий вплив і відновлення? Кого зачепить помилка, чи є резервна копія і хто може відкотити дію.
6. Що не перевірено? Відкриті ризики, відсутні джерела, невідомі наслідки або залежність від іншої команди.
7. Що дозволяє рішення? Чіткий обсяг, умова завершення й строк дії; схвалення однієї дії не повинно мовчки покривати наступну.

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

Документація GitHub описує pull request review як простір для коментарів, пропозицій, схвалення чи запиту змін до злиття. Вона також дає адміністраторам змогу вимагати рев’ю для захищених гілок GitHub: огляд рев’ю pull request. У GitHub Actions окремий environment може чекати на визначеного рецензента перед запуском job; у цьому режимі його secrets недоступні до погодження, а для захищеного середовища можна вимкнути саморев’ю ініціатора GitHub: захист середовищ розгортання. Ці механізми стосуються конкретних можливостей GitHub і залежать від плану та конфігурації; вони не означають, що кожний PR чи кожний deployment у будь-якому продукті мусить чекати на ручне схвалення. У [главі 75](75-text-only-course-production-and-publishing.md) розглянуто механіку рецензування й публікації курсу; тут важливо прив’язати погодження до конкретного артефакту та його ревізії.

74.6. Розмістіть gate там, де він справді змінює ризик

Gate — перевірка, без якої наступна дія не починається. Визначайте її політикою, а не універсальним правилом «завжди перепитай перед записом». Типові точки рішення:

Точка	Запитання для gate	Що має бачити людина
Зміна мети або істотне розширення scope	Чи погоджує власник новий результат?	Початковий контракт і конкретна різниця
Архітектурний компроміс або нова залежність	Хто несе майбутню вартість підтримки?	Варіанти, наслідки, ризики та обмеження
Новий дозвіл, роль або секрет	Чи має ця ідентичність потрібні повноваження?	Ціль, обсяг, строк і можливість відкликання
Злиття, production або публікація	Чи дотримано політику релізу?	Ревізія, перевірки, одержувачі й план відновлення
Destructive migration або видалення	Чи є потрібні копії та власник відновлення?	Точний ресурс, очікуваний вплив, rollback і вікно
Billing або витрата зовнішніх коштів	Який бюджет або зобов’язання створюється?	Сума, період, отримувач і ліміт

Система може автоматизувати безпечну перевірку, яка стоїть перед gate: зібрати тести, порівняти перелік файлів із дозволеним scope, підготувати план міграції, обчислити суму або створити чернетку повідомлення. Людина ухвалює саме те рішення, яке не делеговане наперед. Якщо ж політика дозволяє автоматичне злиття після незалежного review і успішних перевірок безперервної інтеграції (continuous integration, CI), вимагати ще одне ручне «так» лише через те, що це merge, може не додати контролю.

Гейт не усуває потреби в технічних обмеженнях. Якщо система вже видала агенту доступ до продакшену, а далі сподівається лише на діалогове «попроси людину», пропущений запит може перетворитися на реальний запис. Мінімальні дозволи, ізоляція середовища, обмежений секрет, серверна перевірка аргументів і gate мають доповнювати одне одного. OpenAI окремо наголошує, що контроль має бути біля інструмента з побічним ефектом; Anthropic описує ізоляцію середовища (containment) за допомогою обмеженого середовища виконання (sandbox) як інший шар захисту OpenAI: guardrails та погодження, Anthropic: як обмежують Claude.

74.7. Прив’яжіть рішення до версії й строку

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

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

Скорочена форма в псевдокоді:

PSEUDOCODE
approval = {
    actor: authorized_reviewer,
    action: "run migration",
    resource: "staging/database-17",
    proposal_revision: "commit:abc123",
    scope: "tables: invoices, dry_run: false",
    expires_at: "<task-specific timestamp>",
    decision: "approve",
    evidence: ["review:482", "backup-check:77"],
}

if not valid_for_current_action(approval):
    pause_and_request_a_new_decision()
else:
    execute_only_approved_action()

Це приклад полів, не схема конкретного інтерфейсу програмування застосунків (application programming interface, API). Зміна середовища з staging на production або commit із abc123 на новий код робить цей дозвіл непридатним без нової перевірки. У схемах власних tool-ів валідатор має звіряти цей контекст до дії, а не тільки просити модель вставити схожий текст.

74.8. Зупиняйтеся на конкретній невизначеності

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

Погане повідомлення: «Я не можу продовжити, що робити?» Воно передає людині всю нерозв’язану роботу. Краще: «Локальні тести пройшли на commit abc123. План містить міграцію двох таблиць, якої немає у первинному дозволі. Я підготував план міграції бази даних і перевірку резервної копії; потрібно вирішити, чи дозволено виконати міграцію лише в staging. Продакшен не змінювався».

Якщо відповідальний недоступний, система лишається в blocked, зберігає пакет доказів і не виконує дію пізніше за старим дозволом. Це стосується і відхилення: reject — завершене рішення для запиту, а не сигнал переформулювати те саме прохання, поки хтось не натисне approve. Нову пропозицію можна подати лише після реальної зміни варіанта чи доказів і з явним поясненням різниці.

74.9. Зробіть дозволену роботу до того, як турбувати людину

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

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

Блок C. Людська увага, відповідальність і навчання політики

74.10. Керування кількістю запитів — це частина безпеки

Якщо агент питає про кожний крок, у людини накопичуються переривання. З часом вона швидше натискає «approve», відкладає всю чергу або перестає розрізняти звичайний read і ризикову публікацію. Якщо ж запитів немає зовсім, система може приховати рішення, яке варто було бачити. Мета — не мінімальна кількість діалогів; мета — щоб важливий запит дістав увагу.

В інженерній публікації Anthropic від 25 березня 2026 року компанія повідомляє, що користувачі Claude Code схвалювали близько 93% запитів на дозволи; автори називають це можливим джерелом втоми від частих погоджень (approval fatigue). У травневому розборі ізоляції Anthropic повідомляє про зменшення кількості таких запитів на 84%: запис дозволявся у визначеній робочій області, а мережевий доступ за замовчуванням блокувався Claude Code auto mode, як Anthropic обмежує Claude. Це власні телеметрія й інженерний опис постачальника, а не універсальний показник усіх агентів.

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

Щоб менше зношувати увагу, можна:

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

Групування не повинно ховати повноваження в багатоступеневій кнопці «погодити все». У пакеті можна одним оглядом показати пов’язані дії, але записати різні рішення: дозволити кодову зміну, відхилити міграцію, запросити власника даних для публікації. Відмову або пропуск не треба трактувати як мовчазне схвалення.

74.11. Зніміть залежність від засновника, зберігши людського власника

Gerber у The E-Myth Revisited розрізняє роботу всередині бізнесу й роботу над системою, яка має давати повторюваний результат без того, щоб засновник вручну координував кожен крок. Для агентної роботи корисне вузьке перенесення цього принципу: повторювані низькоризикові рішення можна закодувати в ясні процедури та делегувати, але хтось залишається власником правил, винятків і змін політики. Книга про малий бізнес; вона дає аналогію щодо систематизації, а не технічний стандарт для агентів.

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

Team Topologies, 2nd edition, корисна тут як принцип ясних власників і взаємодій та керування когнітивним навантаженням команд. Власник системи має знати, як попросити безпекову або операційну роль переглянути конкретну зміну, а не відправляти людину в невизначений ланцюг чатів. Команди можуть розділити межі компетенції: наприклад, автор змін готує докази, власник даних оцінює експорт, відповідальний за операції вирішує запуск. Не копіюйте типологію команд у безособовий набір агентів; організаційна відповідальність і повноваження лишаються людськими.

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

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

Для швидкого аудиту згрупуйте запис у три частини:

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

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

У сховищі для аудиту доречно мати події на кшталт approval_requested, approved, rejected, expired, revoked, action_started, action_completed, action_failed і result_verified. Фіксуйте причинний зв’язок через ідентифікатор задачі та ревізію контракту. Якщо дозвіл відхилено, зберігайте цей результат так, щоб інший worker чи новий запуск не вважав відсутність дії доказом дозволу.

74.13. Розширюйте автономію за доказами, а не за вдалими враженнями

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

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

Чотири розібрані приклади

Приклад 1. Замість невеликої зміни агент додає міграцію й публікацію

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

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

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

Приклад 2. Та сама міграція для staging і production

Файл міграції однаковий, але оточення змінює ризик. У тестовій базі є штучні дані й відновлювана копія; у production на цей момент записують рахунки клієнтів, а rollback може бути складним. Назва run_migration не визначає, чи слід діяти автономно.

Контракт дозволяє автоматично перевірити план, backup та вплив на staging. Якщо staging відповідає політиці, агент запускає лише там і зберігає результат. Для production-переходу він складає новий пакет: цільове середовище, ревізія міграції, оцінка часу, очікуване блокування, стан backup, rollback або forward-fix, вікно запуску, відповідальна особа та відомі невизначеності. Уповноважена людина може погодити, відхилити чи відкласти цей конкретний production крок.

Якщо використовуються GitHub environments, можна налаштувати окремий deployment gate: workflow чекає на required reviewer, а environment secrets відкриваються лише після дозволу. GitHub дозволяє запобігти саморев’ю ініціатора, але наявність і поведінка цих функцій залежать від налаштувань репозиторію та плану. Схвалення staging тут не переноситься на production, бо інші дані, радіус впливу й відповідальність.

Приклад 3. Експорт клієнтських записів без зміни джерела

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

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

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

Приклад 4. Рецензент отримує запитання, на які вже є відповіді

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

Перед ескалацією worker читає доступну документацію, перевіряє схему, робить дозволений diff і запускає звичайні локальні перевірки. Замість шести запитів він подає короткий пакет: «Формат і каталог визначені документом X; перевірки пройшли на ревізії Y. Єдине невирішене питання: чи дозволено публікувати вибрані записи до зовнішнього сервісу Z? Ось поля, мета, утримання даних, альтернатива без передачі та власник рішення».

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

Короткий підсумок

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

Джерела та подальше читання

Офіційні документи й сторінки видавців перевірено 10 жовтня 2026 року. Властивості продукту нижче належать до зазначеної документації та можуть змінитися.

• OpenAI, Guardrails and human review — налаштоване погодження виклику інструмента, переривання та відновлення запуску зі збереженого стану, межі guardrails. Перевірено 10.10.2026.
• OpenAI, Safety best practices — приклад доступу людини до джерел, потрібних для перевірки підсумку; загальні рекомендації платформи, а не політика кожної організації. Перевірено 10.10.2026.
• Anthropic, Managed Agents permission policies — політики always_allow, always_ask і auto, межі вбудованих, MCP та власних інструментів, конфігурація набору інструментів у запущеній сесії; функція позначена бета-версією. Перевірено 10.10.2026.
• Anthropic Engineering, How we built Claude Code auto mode, 25.03.2026, та How we contain Claude across products, 25.05.2026 — власні спостереження компанії про схвалення permission prompts, sandbox, межі середовища й виявлену вразливість до показу діалогу довіри. Власна телеметрія не є незалежним універсальним виміром.
• GitHub, Pull request reviews і Deployments and environments — рішення рецензента, вимога рецензування, заборона саморев’ю та доступність секретів середовища лише після погодження. Деталі залежать від плану та налаштувань.
• Tom DeMarco і Tim Lister, Peopleware: Productive Projects and Teams, 3rd edition, Addison-Wesley Professional, 2013, сторінка та зміст Pearson — людські умови роботи, flow, переривання, непоєднувана багатозадачність, часткова увага й командні практики.
• Michael E. Gerber, The E-Myth Revisited, 1995, офіційна сторінка автора — робота над бізнесом і повторювана система замість постійного ручного керування; застосовано лише як організаційну аналогію, не інженерний стандарт.
• Matthew Skelton і Manuel Pais, Team Topologies: Organizing Business and Technology Teams for Fast Flow, 2nd edition, IT Revolution, 2025, офіційна сторінка другого видання — когнітивне навантаження, ясне володіння межами та відповідальність за командні взаємодії. Перевірено 10.10.2026.