Що означають попередження про безпеку ШІ від колишніх дослідників з проєкту Anthropic для розробників

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

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

Сьогодні увага зосереджується на агентах ШІ, здатних виконувати завдання самостійно, а не просто відповідати на запити.

Ця зміна має велике значення.

Вона також змінює загальну дискусію про те, куди рухатиметься ШІ.

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

Нещодавно Білал Чугтай, колишній дослідник Google DeepMind, висловив подібні занепокоєння щодо можливості катастрофічних наслідків від ШІ.

Такі заяви варто уважно розглянути.

Не тому, що вони стверджують, ніби ШІ ось-ось знищить людство за одну ніч.

Це не те твердження, яке робиться.

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

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

Не тому, що кожен розробник мусить стати експертом з безпеки ШІ.

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

Це насправді не про чат-ботів

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

Таке формулювання тут не дуже корисне.

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

Існує значна різниця між ШІ, яке відповідає на запитання на кшталт:

"Як написати цю функцію на Python?"

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

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

Це справді корисно.

Але саме тут стає складніше все аналізувати.

Чим більше можливостей набуває система, тим важливішими стають обмеження, які на неї накладені.

Штучний інтелект, який може створювати лише текст, може завдати обмеженої шкоди у разі помилки.

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

Це вже не просто генерація результату.

Це вжиття дій у реальному світі.

А дії мають наслідки.

Те, що викликає у мене дискомфорт

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

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

API може повертати дані, які ніхто не планував.

База даних може містити записи, які ніколи належним чином не очищувалися.

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

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

Системи ШІ успадковують усі ці ризики.

У певному сенсі вони їх навіть посилюють.

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

Натомість системи ШІ генерують результати, які ніхто не вводив безпосередньо.

Це є частиною того, що робить їх потужними.

Це також те, що ускладнює їх безпечну розробку.

Робота над системою ШІ означає необхідність дбати не лише про те, чи дає вона правильну відповідь у більшості випадків.

Справжнє питання полягає у тому, що відбувається, коли вона робить помилки.

Що станеться, якщо вхідні дані будуть некоректними?

Що станеться, якщо залежний API вийде з ладу?

Що станеться, якщо модель неправильно інтерпретує мету запиту?

Що станеться, якщо хтось навмисно надасть їй шкідливий контент?

Що станеться, якщо агент отримає доступ до інструменту, до якого йому не слід мати доступу?

І, можливо, найскладніше з усього:

Що станеться, коли система зробить щось, чого ніхто не очікував?

У міру того, як системи ШІ набувають більшої автономії, саме ці питання стають найважливішими.

Гонка з ШІ — це частина проблеми

Є ще один аспект, який легко проігнорувати.

Конкуренція.

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

Ця конкуренція сприяла значному прогресу.

Вона також створила величезний тиск на швидке впровадження рішень.

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

Але залишається складне питання.

Хто має право вирішувати, що насправді означає „занадто швидко“?

І хто буде контролювати це після того, як з’явиться стандарт?

Це набагато складніша проблема, ніж просто прохання до компаній бути обережнішими.

Чи варто уповільнити розвиток ШІ?

Тут немає однозначної відповіді „так“ чи „ні“.

З обох боків існують переконливі аргументи.

ШІ, безумовно, приносить багато користі.

Це допомагає дослідникам зрозуміти складний науковий матеріал.

Це підтримує лікарів та медичних дослідників.

Це прискорює розробку програмного забезпечення.

Це допомагає студентам навчатися.

Це надає малим підприємствам нові можливості.

Це усуває мовні бар’єри та розширює доступ до інформації.

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

Ці переваги не є гіпотетичними.

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

Метою такого проекту є не просто навчання моделі та показ одного числа-результату.

Справжня мета — створення повноцінної системи на основі цієї моделі.

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

Робота з цим потоком даних робить щось очевидним.

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

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

Погані вхідні дані призводять до поганої моделі.

Погана модель призводить до того, що API повертає оманливі відповіді.

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

Цей приклад є дуже простим порівняно з ШІ масштабу передових технологій.

Але принципи інженерії добре працюють у будь-якому масштабі.

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

Неправомірне використання у реальному світі вже існує

Nемає причин чекати, поки якась гіпотетична суперрозумність почне серйозно ставитися до безпеки ШІ.

Неправомірне використання вже відбувається сьогодні.

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

Чому це важливо? Тому що це змінює всю перспективу обговорення.

Безпека — це не лише питання про те, чи перевершить якась машина в майбутньому людський інтелект.

Це також питання про те, що люди вже можуть досягти за допомогою сучасних потужних систем.

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

Зловмисник може використовувати ШІ для створення шкідливого коду.

Шахрай може використовувати його для створення повідомлень, достатньо переконливих, щоб обманути уважних читачів.

Одна людина може автоматизувати роботу, яка раніше вимагала цілої команди.

Для всього цього не потрібно, щоб сама модель була шкідливою.

Люди подають злі наміри.

І таке зловживання вже відбувається, а не є якоюсь далекою можливістю.

Автономні агенти ще більше підвищують ризик

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

Стандартний чат-бот відповідає лише тоді, коли його запитують.

Натомість агент може проявляти ініціативу та діяти самостійно.

Ця різниця може здатися незначною.

Це не так.

Ви надаєте йому права на запис для створення файлів.

Ви дозволяєте йому виконувати команди.

Ви під’єднуєте його до зовнішніх API.

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

Те, що ви створили, набагато потужніше за простого чат-бота.

Але ви також створили набагато більшу поверхню для атак.

Що станеться, якщо він неправильно інтерпретує завдання?

А що, якщо він стере щось критично важливе?

А якщо прихована інструкція, захована в файлі, тихо змінить його поведінку?

А що, якщо він витекне конфіденційні дані до якоїсь зовнішньої служби?

А що, якщо він буде продовжувати виконувати дії ще довго після того, як фактична мета вже була досягнута?

Жоден з цих прикладів не є гіпотетичними експериментами з науково-фантастичного сценарію.

Це звичайні проблеми інженерії програмного забезпечення.

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

Чому алінгмент — це не просто академічний жаргон

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

Але існує набагато більш практичний спосіб мислення про це.

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

Це звучить досить просто.

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

Припустимо, ви кажете штучному інтелекту: «Зроби цей додаток швидшим».

Швидше у якому сенсі?

Кменший використання пам’яті?

Швидші часи відповіді API?

Кменше операцій з базою даних?

Швидше завантаження сторінок на фронтенді?

Простіша модель?

Агент мусить якимось чином здогадатися, що саме ви мали на увазі.

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

Витрати внаслідок неправильного розуміння цієї мети зростають відповідно.

Ось справжня проблема, що стоїть за завданням узгодження.

Справа ніколи не була у тому, щоб чат-бот звучав ввічливо.

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

Безпека не повинна бути додатком у останню хвилину

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

Це справедливо навіть для найменших додатків.

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

Той самий принцип має застосовуватися й до систем штучного інтелекту.

Якщо ви створюєте щось, що працює за допомогою ШІ, права доступу потребують уваги з першого дня.

До яких ресурсів може отримати доступ модель?

Що вона може змінювати?

Яка інформація їй доступна?

Що робити, якщо щось зламається?

Чи мають користувачі можливість скасувати її рішення?

Чи існує журнал аудиту?

Чи можна його вимкнути?

Чи можна простежити виконані нею дії?

Чи можна пізніше відтворити збою для дебаггінгу?

Жодне з цих питань не є захоплюючим.

Вони не зроблять демо більш вражаючим для перегляду.

Але саме відповіді на їхні запитання відрізняють розумний прототип ШІ від справжньої інженерної системи.

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

Сама модель — це лише одна частина набагато більшої загадки.

Важливі базові дані.

Важлива також частина системи, що працює на задньому плані.

Важливі API, які вона використовує.

Важлива база даних, що знаходиться за нею.

Так само важлива автентифікація.

Так само важливий моніторинг.

Так само важлива процедура розгортання.

І безпека пронизує все це.

Розробники мають більше впливу, ніж усвідомлюють

Розробникам легко думати, що безпека ШІ — це справа когось іншого.

Можливо, це завдання великих лабораторій.

Можливо, регулятори повинні втрутитися.

Можливо, це суто проблема досліджень у сфері узгодження.

Ці зусилля справді мають значення. Але окремі розробники все одно несуть велику відповідальність.

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

Надання дозволу API — це рішення.

Підключення до бази даних — це рішення.

Створення автоматизації — це рішення.

Дозволення автономних дій — це рішення.

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

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

Надсилання запиту до моделі швидко стає загальнопоширеною навичкою.

Розуміння того, як поводиться вся система від початку до кінця, має набагато більшу цінність.

Створення ШІ все ще варте зусиль

Усе це не означає відмови від розробки ШІ.

Позитивні аспекти просто занадто значні, щоб ігнорувати їх.

Правильною відповіддю з точки зору розробника є покращення навичок створення продуктів відповідально.

Продовжуйте розробляти.

Продовжуйте експериментувати.

Продовжуйте досліджувати.

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

Але також серйозно підходьте до їх належного тестування.

Вивчайте, чому вони зазнають невдач.

Ставіться серйозно до безпеки.

Обмежуйте права доступу лише тим, що дійсно необхідно.

Продовжуйте стежити за системами після їх запуску.

Будьте відвертими щодо того, що залишається невизначеним.

А коли щось йде не так, сприймайте це як можливість навчитися, а не як щось, що потрібно приховати.

Темпи розвитку технологій не сповільнюються.

Інженерна дисципліна мусить наздогнати їх.

Краще запитання, ніж „Чи знищить нас ШІ“

Найкорисніше запитання — це не

«Чи може ШІ знищити людство?»

Ніхто не може відповісти на це з справжньою впевненістю.

Деякі дослідники вважають цей ризик серйозним.

Інші оцінюють ймовірність екзистенційних наслідків значно нижче.

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

Більш корисне запитання звучить так: що станеться, якщо ми створимо системи, які перевершать нашу здатність контролювати їх?

Це формулювання набагато важче проігнорувати.

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

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

Це змінює мій погляд на власні проекти з ШІ

Коли я ще працював над проектами з ШІ студентом, основною турботою було лише змусити модель працювати.

Навчити її.

Протестувати її.

Підвищити показники точності.

Під’єднати її до фронтенду.

Випустити її у продакшн.

Ось весь перелік завдань.

Такий підхід більше не є дійсним.

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

Звідки насправді походять дані для навчання?

Чи є вони надійними?

Що станеться, коли реальні дані почнуть відрізнятися від тих, які бачила модель під час навчання?

Яку міру впевненості слід приписувати певному результату?

Який запасний варіант, якщо виклик API зазнає невдачі?

Чи може хтось навмисно подавати системі погані чи ворожі дані?

Як система висловлює сумніви чи невизначеність користувачеві?

Чи є спосіб, яким людина може втрутитися та скасувати рішення?

Чи можна пояснити, чому система дійшла до певної відповіді?

Ці запитання створюють труднощі в будь-якому проекті.

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

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

Майбутнє не буде визначатися лише в лабораторіях ШІ

Легко припустити, що траєкторія розвитку ШІ повністю знаходиться в руках кількох провідних лабораторій — Anthropic, OpenAI, Google DeepMind та інших.

Це припущення є хибним.

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

Дослідники також впливатимуть на нього.

Так само будуть робити уряди.

Так само — університети.

Так само — стартапи.

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

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

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

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

Ми входимо у іншу фазу штучного інтелекту

Протягом багатьох років основним питанням у цій галузі було просто: наскільки здатними можемо ми зробити ці моделі?

Зараз набуває значення ще одне питання: наскільки автономії ми насправді повинні їм надати?

Це зовсім інший тип питання.

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

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

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

Вони не є доказом того, що неминуча катастрофа через ШІ вже на підході.

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

Саме це заслуговує на увагу.

Нам не потрібен паніка

Усе це не вимагає від розробників реакції наляканості.

Паніка не призводить до кращого коду.

Страх сам по собі не робить ШІ безпечнішим.

Те, що справді допомагає, — це кращі інженерні практики в усіх аспектах.

Більш ретельні тести.

Міцніша безпека.

Більш уважна оцінка.

Вища прозорість.

Глибші дослідження.

Більш розумна політика.

І більш кваліфіковані розробники.

Мета не в тому, щоб зробити ці системи менш корисними.

Мета — переконатися, що наша здатність розуміти та контролювати їх відповідає їхньому рівню складності.

Це, можливо, одна з найважливіших інженерних проблем цього покоління.

І, чесно кажучи, саме це робить цю галузь настільки привабливою зараз.

Це не просто ще одна категорія програмного забезпечення, яку створюють.

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

Це відкриває величезні можливості.

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

Справжнє питання

Чи зможе ШІ колись стати достатньо потужним, щоб загрожувати виживанню людства, — це питання, на яке я не можу відповісти з упевненістю.

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

І я не думаю, що хтось може точно сказати, що принесе наступне десятиліття.

Але одне є досить очевидним.

Чим потужнішими стають наші системи, тим важливішим є їхнє відповідальне проектування, а не менш важливим.

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

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

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

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

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

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

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