Люди й ШІ неминуче помиляються. Чому системи мають бути готові до їхніх помилок

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

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

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

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

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

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

Тому питання «як не допустити помилки?» недостатнє. Для зрілої системи важливіше інше:

• Що станеться, коли помилка все-таки відбудеться?
• Чи залишиться вона локальною?
• Чи буде виявлена до того, як вплине на користувачів?
• Чи знатимемо ми, хто і на основі чого ухвалив рішення?
• Чи можливо буде відновити попередній стан?
• Чи перетвориться інцидент на знання, яке покращить систему?

Анатомія однієї помилки: кейс Агента X

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

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

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

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

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

Помилка виконавця і помилка системи — не одне й те саме

Уявімо два однакові неправильні рішення.

У першому випадку розробник змінює критичну логіку, але має обмежені права. Зміна проходить незалежне рецензування (review), запускаються перевірки, які він не може одночасно послабити, а розгортання відбувається поступово з можливістю відкату. Помилка існує, але її шлях до реального наслідку має кілька бар’єрів.

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

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

Довіра потрібна, але вона не повинна бути єдиним контролем

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

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

Довіра як динамічна рівновага: довіра до виконавця (людини чи ШІ) не є статичним актом, який видається раз і назавжди як нагорода за компетентність. Це безперервний діалог між свободою дій та опором середовища. Щоразу, коли система успішно поглинає наслідки чиїхось помилок, ця рівновага перекалібровується: межі стають усвідомленішими, а довіра — глибшою, адже тепер вона спирається не на сліпу віру в досконалість, а на спільний досвід виживання.

Автономія — це свобода всередині меж

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

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

Цю ідею можна описати простим принципом:

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

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

Виконавець не повинен одноосібно визначати власну правоту

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

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

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

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

Безпека — це здатність пережити помилку

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

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

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

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

Чому ця розмова важлива саме зараз

Поки ШІ лише радив, його помилки переважно залишалися інформаційними. Тепер він працює з файлами, запускає команди, змінює код і взаємодіє з API. Межа між рекомендацією та дією зникає.

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

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

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

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

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

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

Помилка є властивістю складної системи

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

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

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

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

Від пошуку винного до проєктування меж

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

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

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

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

Запобігання, виявлення і відновлення

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

Тому захист має щонайменше три шари:

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

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

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

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

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

Не шукати безпомилкового виконавця

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

Замість питання «кому можна довірити більше?» варто запитати:

• Який масштаб помилки ми здатні пережити?
• Де потрібна незалежна перевірка?
• Які дії мають бути оборотними?
• Чи може виконавець змінити правила власної оцінки?

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

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

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

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

А як ви проєктуєте безпечне середовище для автономних систем? Які запобіжники працюють найкраще у вашій практиці? Діліться досвідом у коментарях!