Як подолати уявлення про те, що «ШІ — це магія»: чому розуміння принципів роботи моделей ШІ має стати пріоритетом для всієї компанії

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

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

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

ШІ не є детермінованим — його результати мають імовірнісний характер

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

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

Великі мовні моделі ніколи не видаватимуть детермінованих результатів. Їхні відповіді мають імовірнісний характер. Коли ви вводите дані у звичайну програму, можна певною мірою передбачити результат — скажімо, отримати A, B або C. А ШІ може видати F, символ & або опис кота в сонцезахисних окулярах.

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

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

Засоби контролю мають бути в інфраструктурі, а не в моделі

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

Систематизація цього процесу особливо важлива для великих компаній, де в кожній команді можуть працювати десятки розробників, а сотні розробників протягом дня вносять зміни до коду. ШІ може дуже швидко виконувати багато завдань, і якщо щось піде не так, потрібна система, яка дасть змогу точно визначити, на якому етапі виникла проблема. Згадайте, як улітку агенти OpenAI проникли в системи Hugging Face. OpenAI перевіряла, наскільки добре її моделі можуть використовувати вразливості програмного забезпечення, за допомогою тестового набору під назвою ExploitGym. Для цього тесту компанія навмисно послабила обмеження, які забороняли моделям виконувати завдання зі зловмисної кібердіяльності. Єдиним шляхом виходу ізольованого середовища був проксі-сервер пакетів. Моделі виявили невідому вразливість у цьому проксі-сервері, вийшли за межі ізольованого середовища й понад два дні шукали відповіді на тест у продуктивних системах Hugging Face.

У заголовках це називали неконтрольованим ШІ. Я б назвав це детермінованим налаштуванням імовірнісної системи. OpenAI наказала моделям зламати систему, а потім покладалася на те, що вони діятимуть очікуваним чином. За словами автора тестового набору, моделі й раніше обманювали під час тестування, але завжди залишалися в ізольованому середовищі. Цього разу одна з них вийшла за його межі. Стандартні засоби контролю розраховані на стандартну поведінку, але ШІ не зобов’язаний дотримуватися стандартів.

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

Керування дозволами агента схоже на адаптацію нового молодшого розробника. Ви ж не надали б йому доступ рівня root до виробничого середовища в перший же день. Якби ви це зробили, і він видалив вашу базу даних, ви б не списали це на те, що він геніальний хакер. У разі інцидентів безпеки будь-якого масштабу надзвичайно важливо встановити першопричину. Чи винна модель? Компанія, яка створила модель? Компанія, яка надала моделі доступ? Хай би що це було, зрештою відповідальність несе людина.

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

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

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