У спеціальному кросоверному епізоді подкастів Security Intelligence та Mixture of Experts від IBM команда експертів з AI та кібербезпеки — Гейб Гудгарт (chief architect for AI open innovation), Мартін Кін (master inventor) та Джефф Крум (distinguished engineer з безпеки даних і AI) — розбирає одну з найгарячіших тем у технологіях: чи безпечний відкритий AI і що саме в ньому створює ризики.
За фасадом загального гасла «open source рухає інновації» ховається набагато складніша картина. В AI-світі «відкритість» означає одразу кілька різних речей — від відкритого програмного коду до відкритих ваг моделей — і кожна з них має власні, відмінні наслідки для безпеки.
Ця розмова показує: сучасний AI-стек варто описувати не як «безпечний», а як «такий, що може бути захищеним» — securable, але не secure за замовчуванням. І саме в цьому нюансі сьогодні ховається головна пастка для компаній, які масово інтегрують AI у свої продукти та процеси.
Дві різні «відкритості»: код проти ваг моделі
У публічних дебатах про відкритий AI часто все зводять до одного запитання: «Чи безпечний open source?» Але в контексті генеративних моделей це надто грубе спрощення.
Ключова відмінність, на якій наполягають технічні практики, — це розділення двох рівнів:
- відкритий програмний код, що реалізує AI-системи (фреймворки, оркестрація, інфраструктура, сервіси навколо моделей);
- відкриті ваги та архітектури самих моделей — тобто числові параметри та конфігурації, які визначають, як модель поводиться.
Ці два світи пов’язані: ваги та архітектури потрібно завантажити й виконати за допомогою програмного забезпечення. Але з точки зору безпеки це різні площини ризику, які необхідно оцінювати окремо.
Відкритий код — це продовження багаторічної традиції Linux, Kubernetes та інших інфраструктурних проєктів. Тут діють знайомі правила: є поверхня атаки, є вразливості, є патчі, є процеси оновлення. Це «звичайний» софт, тільки складніший і більш розподілений.
Відкриті ваги — зовсім інша історія. Вони безпосередньо визначають поведінку моделі: що вона знає, як відповідає, які обмеження дотримується. І саме тут відкритість створює унікальні ризики, яких не існувало в традиційному open source.
Коли ваги відкриті: як легко зняти «запобіжники» з моделі
Одне з головних практичних наслідків відкритих ваг — можливість повністю змінити поведінку моделі, зокрема позбутися вбудованих механізмів безпеки.
Комерційні хостингові платформи будують навколо своїх моделей багаторівневі «запобіжники»:
моделі навчають відмовлятися відповідати на шкідливі запити, фільтрувати небезпечний контент, не генерувати інструкції для злому чи насильства;
поверх моделі додають програмні guardrails — додаткові шари, які аналізують запити та відповіді, блокують небажані сценарії, відстежують підозрілу активність.
Поки модель доступна лише як сервіс через API, розробник платформи контролює цей захисний шар. Користувач може спробувати обійти обмеження, але не може змінити саму модель.
Ситуація кардинально змінюється, коли ваги стають публічними. Будь-хто може:
завантажити модель локально;
видалити або змінити безпекові налаштування;
провести донавчання (fine-tuning), яке «перепише» частину поведінки, включно з усіма відмовами та обмеженнями.
Технічно це не складніше, ніж звичайний fine-tuning для доменної адаптації. Якщо модель навчали казати «я не можу надати цю інформацію», то додаткове навчання може змусити її відповідати прямо протилежним чином.
У результаті з’являються «розблоковані» моделі, які:
ігнорують попередні політики безпеки;
відповідають на запити, які в хостингових версіях були б заблоковані;
можуть генерувати шкідливий або незаконний контент без жодних фільтрів.
Це не теоретичний сценарій, а прямий наслідок публікації ваг. Як тільки модель опиняється «на волі», контроль над її поведінкою переходить від вендора до будь-кого, хто має достатньо технічних навичок для fine-tuning.
І тут важливо розуміти: жодні ліцензійні обмеження чи політики використання не можуть технічно завадити цьому. Вони працюють лише настільки, наскільки користувачі готові їх дотримуватися.
Чому «securable» не означає «secure»: уроки Linux і Kubernetes для AI
Прихильники відкритого коду часто посилаються на класичний аргумент: «чим більше очей дивиться на систему, тим безпечнішою вона стає». У криптографії це формалізовано в принципі Керкгоффса: безпечними мають бути ключі, а не алгоритми; алгоритми краще робити публічними, щоб спільнота могла виявити вразливості.
У масштабі AI цей аргумент працює лише частково. Системи настільки великі й складні, що «тисяча очей» уже не гарантує повного аудиту. Мільярди параметрів, багаторівневі стеки, десятки залежностей — усе це робить повний аналіз практично неможливим навіть для великої спільноти.
Тому більш точна характеристика для сучасного AI-стеку — «securable, але не secure за замовчуванням». Це формулювання добре знайоме тим, хто працював з Linux або Kubernetes.
Linux — не «безпечний» сам по собі. Він:
має величезну поверхню атаки;
може бути налаштований як дуже вразлива система;
одночасно дозволяє побудувати надзвичайно захищене середовище за умови грамотної конфігурації, моніторингу та регулярних оновлень.
Те саме стосується Kubernetes: за замовчуванням це платформа з відкритими можливостями, а не фортеця. Без належного hardening, політик доступу, сегментації мережі та контролю секретів кластер стає легкою мішенню.
AI-стек — це продовження цієї логіки. Він складається з:
фреймворків для навчання та інференсу;
оркестраторів;
сховищ даних;
сервісів авторизації;
обгорток навколо моделей, які реалізують API, логування, моніторинг.
Кожен із цих компонентів має власну поверхню атаки. Без чіткої стратегії безпеки — від управління вразливостями до політик оновлень — система залишається лише «потенційно захищуваною», але не захищеною.
Відкритий код тут не є ні гарантією безпеки, ні автоматичною загрозою. Він просто означає, що:
вразливості можуть знайти як захисники, так і зловмисники;
якість безпеки залежить від того, наскільки серйозно організація ставиться до конфігурації, моніторингу та оновлень.
І саме тому спроби будувати безпеку AI виключно на «секретності» — наприклад, приховуючи внутрішні механізми — виглядають дедалі менш переконливо. Як і в криптографії, розрахунок на «security through obscurity» у довгостроковій перспективі не працює: інформація рано чи пізно витікає.
Закриті моделі як «фільтр»: коли безпека живе в софті, а не в самій моделі
Один із головних аргументів на користь закритих моделей — можливість контролювати не лише програмний стек, а й те, як саме користувачі взаємодіють із моделлю.
Коли модель доступна тільки через API, розробник платформи може:
впровадити складні guardrails на вході: аналізувати запити, блокувати небезпечні інструкції, обмежувати певні категорії контенту;
додати фільтри на виході: перевіряти відповіді моделі, видаляти або змінювати небажаний контент перед тим, як він потрапить до користувача;
відстежувати патерни використання: виявляти підозрілу активність, спроби масового обходу обмежень, автоматизовані атаки;
динамічно оновлювати політики: змінювати правила безпеки без необхідності перевчання моделі.
У такій архітектурі модель фактично стає «двигуном», захованим за багатошаровим програмним фасадом. Безпека реалізується не стільки в самих вагах, скільки в логіці навколо них.
Це не робить систему автоматично безпечною, але дає вендору важливий важіль контролю: навіть якщо модель теоретично здатна згенерувати шкідливу відповідь, програмний шар може її перехопити й заблокувати.
Коли ж ваги відкриті, цей баланс змінюється. Будь-хто може:
забрати модель із захищеного середовища;
запустити її без guardrails;
навчити її ігнорувати будь-які обмеження.
У такому світі безпека перестає бути властивістю сервісу й перетворюється на відповідальність кожного окремого користувача, який розгортає модель. Для корпоративних команд це означає: якщо ви інтегруєте відкриті ваги у власну інфраструктуру, саме ви стаєте «вендором безпеки» для цієї моделі — з усіма наслідками.
OpenClaw та ілюзія «безпечних за замовчуванням» AI-рішень
На тлі зростання інтересу до AI-агентів та оркестрації інструментів з’являється дедалі більше проєктів, які позиціонують себе як «безпечні» платформи для побудови AI-систем. Один із прикладів, що обговорюється в контексті IBM, — OpenClaw.
Характеристика, яку отримує OpenClaw, показова для всієї галузі: це система, яку можна зробити безпечною, але вона не є безпечною «з коробки». Іншими словами, це ще один приклад «securable, not secure».
Багато конкуруючих рішень, які ринок сприймає як «secure by design», на практиці концентруються переважно на двох аспектах:
ізоляція середовища виконання (sandboxing), щоб обмежити шкоду від потенційно небезпечних дій;
дозволи на інструменти (tool permissioning), які визначають, до яких зовнішніх сервісів або ресурсів агент має доступ.
Ці механізми важливі, але вони не вичерпують повний спектр загроз. Якщо звести безпеку лише до «пісочниць» і списків дозволених інструментів, залишаються відкритими питання:
як система поводиться з динамічними, недовіреними даними;
чи може агент бути «перепрограмований» через контент, який він обробляє;
як запобігти тому, щоб модель, маючи доступ до інструментів, виконувала небажані дії під впливом шкідливих підказок.
У випадку OpenClaw прямо підкреслюється: це платформа, яку можна налаштувати й посилити, але вона не є готовим «бункером» безпеки. Відповідальність за реальну захищеність лягає на архітекторів і розробників, які її впроваджують.
Це важливий сигнал для ринку: маркування продукту як «secure» не повинно заспокоювати. Потрібно дивитися глибше — на те, які саме загрози враховано в моделі безпеки, а які залишаються поза увагою.
Як бізнесу думати про безпеку відкритого AI сьогодні
З урахуванням усього цього ландшафту компаніям, які інтегрують AI, доводиться балансувати між інноваційністю відкритих рішень і реальними ризиками. З розмови експертів випливають кілька практичних орієнтирів.
По-перше, потрібно чітко розділяти, що саме у вашій AI-архітектурі є відкритим. Відкритий код інфраструктури — це одне; відкриті ваги моделей — зовсім інше. Ризики, процеси контролю та вимоги до комплаєнсу для цих двох рівнів різні.
По-друге, варто відмовитися від ілюзії, що «відкритість автоматично підвищує безпеку». Вона може покращити прозорість, полегшити аудит, прискорити виправлення вразливостей. Але без активної роботи з конфігурацією, моніторингом і оновленнями жоден AI-стек не стане безпечним сам по собі.
По-третє, у випадку відкритих ваг потрібно виходити з припущення, що:
будь-які вбудовані обмеження моделі можуть бути зняті;
«розблоковані» версії можуть з’явитися й поширюватися поза вашим контролем;
політики використання та юридичні угоди не є технічним бар’єром для зловмисників.
Це означає, що стратегії безпеки мають враховувати не лише ваш власний стек, а й екосистему загалом: від того, як моделі можуть бути використані іншими, до того, як це вплине на загальний рівень загроз.
По-четверте, при виборі платформ на кшталт OpenClaw або інших «безпечних» рішень для AI-оркестрації потрібно дивитися не на маркетингові обіцянки, а на реальну глибину моделі загроз. Чи обмежується вона sandboxing та дозволами на інструменти, чи включає ширший спектр ризиків, пов’язаних із поведінкою моделей і роботою з даними.
Висновок: безпека AI — це не властивість ліцензії, а результат інженерії
Дискусія навколо відкритого AI часто зводиться до ідеологічних гасел: «інформація хоче бути вільною» проти «нам потрібен контроль заради безпеки». Але в технічних деталях картина значно складніша.
Відкритий код і відкриті ваги — це різні виміри «open», які по-різному впливають на ризики. Відкритий код робить AI-стек прозорішим і потенційно більш керованим, але не звільняє від необхідності серйозної роботи з безпекою. Відкриті ваги, своєю чергою, відкривають двері до безпрецедентної гнучкості — і одночасно до можливості повністю зняти всі вбудовані запобіжники.
У цьому світі найточніший опис сучасного AI — це «securable, але не secure за замовчуванням». Як і у випадку з Linux чи Kubernetes, усе вирішує не сама технологія, а те, як її конфігурують, оновлюють і контролюють.
Для бізнесу це означає: питання безпеки AI не можна делегувати ні ліцензії, ні статусу «open source», ні бренду вендора. Це інженерна задача, яка вимагає власної стратегії, компетенцій і постійної уваги.
І чим швидше ринок перестане плутати «відкритий» із «безпечний» — тим менше буде гучних інцидентів, які можуть загальмувати розвиток технологій, що сьогодні справді змінюють індустрії.