Чому розумніша AI-модель небезпечніша

Матеріал автора має інформаційний характер і виражає лише його думку.

Історія, з якої варто почати

Сергій Кравцов, CEO і співзасновник Evergreen та Connect1, розповів це на вебінарі про те, чому AI-ініціативи не доходять до продакшену.

Він знайшов баг у продакшені. Зробив кілька скріншотів, скинув їх у GPT Codex, попросив розібратись і перемкнувся на інші справи. Через годину згадав, що є фоновий процес, і вирішив перевірити, що там відбувається.

За цю годину агент зробив таке:

знайшов і локалізував баг;
знайшов на локальній машині вихідний код відповідного репозиторію;
виявив у ньому CI-процес і розібрався, як відбувається деплой;
знайшов у сусідньому репозиторії GitHub access token;
спробував задеплоїти виправлення самостійно.

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

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

Чому розумніша модель небезпечніша

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

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

Тобто чим сильніша модель, тим важливішими стають guardrails, а не менш важливими.

Звичка, яка переноситься у продукт

Це спостереження з вебінару зачепило найбільше.

З появою моделей рівня Fable, Opus 5, GPT 5.6 люди починають довіряти і вмикають режим «дозволити все, без обмежень» під час розробки. Працює ж добре, навіщо заважати.

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

Особливо це стосується так званого AI-native софту, де AI не просто інструмент розробки, а частина робочого процесу: AI-native CRM, AI-native таск-трекер, де модель сама вирішує, що важливо, а що ні. Там ціна відсутніх обмежень значно вища, бо помиляється вона вже не у вашому терміналі, а у ваших клієнтів.

Що блокувати за замовчуванням

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

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

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

Як це виглядає на практиці в Claude Code

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

У ~/.claude/settings.json:

Як це працює:

`hard_deny` блокує беззастережно, навіть якщо ви прямо попросите;
`soft_deny` блокує, якщо це не перекрито прямим запитом або записом у allow;
`$defaults` зберігає вбудовані правила, тобто ваші додаються до них, а не замінюють їх;
правила лежать у користувацьких налаштуваннях, тому налаштування конкретного проєкту їх не перезапише, і вони діють у всіх проєктах;
кожну дію перевіряє окрема модель-класифікатор, яка читає ці правила.

Є також команда claude auto-mode critique, яка показує, які з ваших правил неоднозначні, дублюються або дадуть багато хибних блокувань.

Окрема ремарка від автора цієї статті: я перевірив власний конфіг, коли писав матеріал, і виявив, що ніколи цього не налаштовував. Був тільки список allow. Тобто рівно та сама прогалина, про яку йдеться в історії вище: я покладався на те, що модель поводитиметься розумно.

Чотири рівні перевірки

Із вебінару, це вибудувана практика, а не теорія.

1. Класична автоматизація. Юнит-тести, Playwright-тести, автоматичні правила, базові заборони на рівні промптів. Найдешевший рівень, і він ловить найпростіше.

2. Перевірка реальних кейсів. У Evergreen є внутрішній інструмент, який вони називають debug case: агент вбудований у процес, і команда зобов'язана ним користуватись. Коли розробник розібрав баг і виявив, що це був не баг, він описує ситуацію текстом або голосовим повідомленням, і система на цьому вчиться. У продукті Connect1 аналогічно аналізують розмови AI-агента з клієнтами постфактум, щоб перевірити, чи агент відповідав адекватно.

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

3. Друга думка від іншої моделі. Рішення, зроблене однією моделлю, перевіряється іншою. У них це виглядає як: зробили на Fable 5, перевірили GPT 5.6. Своє власне рішення теж корисно прогнати через модель. Різні моделі мають різні слабкі місця, і те, що пропустила одна, часто ловить інша.

4. Вибіркова перевірка людиною. Найголовніше питання: це реально покращило робочий процес, чи це просто AI slop? Раніше вражав сам факт, що AI щось зібрав. Тепер, коли зібрати може будь-хто, значення має тільки те, чи корисно це людині.

Як розкатувати, а не вмикати все одразу

П'ять кроків із вебінару:

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

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

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

Питання, яке варто поставити до запуску

Найкорисніша частина всієї доповіді, як на мене.

Яку шкоду це може завдати і як я її виправлю? Як відновити дані, як відкотити транзакцію, як повідомити клієнта.

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

Повний чекліст перед запуском:

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

Ширший контекст: вузьке місце змістилося

Ще одна теза з того ж вебінару, яка добре доповнює тему.

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

Наведене порівняння з епохою фреймворків двадцятирічної давності. З появою Bootstrap і численних PHP- та Python-фреймворків скелет проєкту став справою одного дня. Але зібрати повноцінне рішення за два дні все одно не виходило, і зібрати зворотний звʼязок від користувачів за два дні теж.

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

Підсумок

Три речі, які варто забрати з цієї історії.

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

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

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

Корисні посилання

---

Матеріал підготовлений на основі вебінару Сергія Кравцова (Evergreen, Connect1) від 26 серпня 2026 року про те, чому AI-ініціативи не доходять до продакшену, з доповненнями щодо конфігурації Claude Code.