Чому саме доступ до ШІ, а не її можливості, є справжнім ризиком залежності
Ця стаття аналізує нещодавні інциденти з контролем експорту, пов’язані з Claude та GPT-5.6, щоб довести, що доступ до моделей ШІ є нестабільною змінною, незалежною від базових можливостей.
Що насправді відрізняє оренду інтелекту від його власності?
Приблизно протягом трьох років галузь зосереджувалася зовсім не на тому показнику.
Шли запеклі дискусії щодо критеріїв оцінки, здатності до логічних міркувань, рівня галюцинацій та розміру контекстного вікна — усе це було показниками того, наскільки розумними є ці системи.
Але сьогодні важливішим є інше питання: хто тримає перемикач, який може вимкнути цей інтелект?
12 червня 2026 року уряд США запровадив обмеження на експорт двох найновіших моделей Anthropic — Claude Fable 5 та Claude Mythos 5.
Цей наказ вимагав від Anthropic перервати доступ для іноземців, незалежно від того, чи знаходилися вони фізично всередині чи за межами Сполучених Штатів.
Anthropic заявила, що у неї немає надійного способу миттєво підтвердити національність.
У зв’язку з цим компанія вжила радикальних заходів: вона заблокувала доступ до обох моделей для всіх іноземців, включаючи працівників самої компанії.
Минуло вісімнадцять днів, перш ніж уряд скасував обмеження. 1 липня сервіс Fable 5 знову став доступним у всьому світі, а Mythos 5 було відновлено для певної групи американських організацій після отримання схвалення від уряду 26 червня.
OpenAI потім пішла майже таким самим шляхом, але почала з протилежного боку.
26 червня OpenAI запустила GPT-5.6, проте за проханням уряду спочатку обмежила доступ лише невеликою групою попередньо перевірених партнерів, ідентичності яких вже були надані чиновникам. OpenAI публічно зазначила, що не хоче, аби такий спосіб впровадження за посередництва уряду став стандартною практикою в майбутньому.
До 9 липня GPT-5.6 став доступним для всіх.
Розгляньте, що насправді розкриває ця послідовність подій.
Нічого не було конфісковано, видалено чи пошкоджено через помилковий код.
Проте протягом певного часу деякі з найсильніших комерційних систем штучного інтелекту, що існують, були технічно справними, але були недоступні саме для тих користувачів, які їх потребували.
Ця ситуація додає ще один рівень до тривалої дискусії щодо темпів розвитку штучного інтелекту — тепер йдеться не лише про те, наскільки швидко ми повинні розвивати його можливості, а й про те, наскільки обережно слід планувати їх впровадження та доступ до них.
Справжній урок полягає не в тому, що доступ зникає. Він у тому, що доступ діє як незалежна змінна, відокремлена від самих можливостей, керована власною логікою, що функціонує за власним графіком, та здатна змінитися в будь-якому напрямку швидше, ніж будь-яка організація зможе відреагувати.
Це набагато більш тривожна реальність, ніж повільно закриваючеся вікно, адже щодо зменшуваного вікна можна щось планувати. Щодо перемикача, який може бути змінений адміністративно у непередбачуваних напрямках протягом кількох днів, планувати неможливо.
Ось питання, над яким варто замислитися: якби модель, від якої ви залежите, зникла за одну ніч, чи вижив би ваша робота?
Власність — це не завантаження
Коли люди відчувають залежність, їхня первинна реакція — знайти щось, що може її компенсувати.
Ви берете відкриті параметри, зберігаєте їх на жорсткому диску та вважаєте, що можете спокійно відпочивати. Але наявність набору параметрів задовольняє лише частину вимог справжньої незалежності, і плутання цих понять створює певний вид хибної впевненості — це еквівалент у штучному інтелекті купівлі резервного генератора, який ніколи не перевіряють на працездатність.
Функціональний агент, який виконує значущу роботу, насправді є набором принаймні п’яти компонентів: самі ваги моделі, двигун інференсу, який їх запускає, накопичений контекст проекту, інструменти, які він може використовувати, та набір засобів оцінки, які показують, чи справді якийсь замінник виконує свої обов’язки належним чином.
Завантажений файл моделі — це лише одна з складових цього набору.
Справжня незалежність вимагає юридичного права на роботу з моделлю, середовища виконання інференсу, яке можна перебудувати лише на основі документації, стану проекту, який можна вільно експортувати, дозволів на використання інструментів, які знаходяться під контролем вашого додатку, а не постачальника, та доказів того, що замінна система справді може завершити роботу.
Лише юридичний аспект є складнішим, ніж здається на перший погляд.
„Відкриті ваги“ та „відкрите програмне забезпечення“ — це не синонімичні терміни; визначення ініціативи Open Source Initiative вимагає набагато більшого, ніж просто можливості завантажити параметри, а ліцензія з вільними умовами під час роботи не автоматично охоплює кожну модель, яка може працювати за її допомогою.
Вам потрібно фактично прочитати конкретну ліцензію, яка регулює кожен продукт, та зберігати її копію разом із цим продуктом у архіві.
Питання власності на дані знаходиться на абсолютно окремій осі. Згідно з комерційними умовами Anthropic, клієнти зберігають права на все, що вони надсилають, мають власність на результати роботи обох сторін, а Anthropic заборонено використовувати цей контент для навчання моделей через ці послуги. Просте надсилання вашого контенту постачальнику не означає передачі власності на нього. Чи буде цей контент збережений пізніше — це ще одне окреме питання, і відповідь залежить від конкретного продукту, контракту та налаштувань, а не від того, що ви колись десь прочитали.
Усе це не є аргументом проти використання хостованих моделей.
Це просто нагадування про те, що фраза „ми володіємо нашим ШІ“ охоплює п’ять-шість окремих умов, кожна з яких має бути дотримана, а більшість команд навіть не турбуються перевіряти жодну з них.
Арифметика самодостатності
Розрахунок кількості пам’яті, необхідної моделі, — це проста частина задачі: береться кількість параметрів, множиться на кількість бітів, які використовуються на кожен параметр, і ділиться на вісім.
Модель з вісьмома мільярдами параметрів при точності шістнадцять бітів потребує приблизно шістнадцять гігабайт; якщо знизити точність до чотирьох бітів, ця кількість скорочується приблизно до чотирьох. Модель з сімдесятьма мільярдами параметрів використовує близько ста сорока гігабайт при шістнадцяти бітах або близько тридцяти п’яти при чотирьох бітах.
Зазвичай саме тут люди припиняють думати про вимоги до апаратного забезпечення, і саме цей розрахунок вони здійснюють найчастіше правильно.
Справжні помилки з’являються далі у процесі обробки.
Кеш KV — структура, яка зберігає стан уваги протягом розмови, — розширюється у міру збільшення довжини вікон контексту, а також зростає з кожним одночасним запитом, який ви обробляєте.
Архітектури типу „суміш експертів“ створюють свої складнощі: оскільки кожен токен активує лише підмножину мережі, фактичні обчислення за токен залишаються невеликими, але кожен експерт, активний чи ні, все одно мусить знаходитися в пам’яті.
Знання про кількість активованих параметрів дозволяє оцінити вартість обробки за токен. Воно нічого не говорить про обсяг пам’яті, який займає модель.
Перенесення частини моделі в інше місце не усуває проблеми зберігання — воно лише її переміщує, і тепер доводиться платити штраф за передачу даних, якого раніше не було.
Модель, яка успішно завантажується в пам’ять, ще не доводить, що здатна ефективно обробляти запити користувачів.
Швидкість обробки запиту, швидкість генерації та загальний час виконання завдання — це три окремі показники, і висока швидкість прийому запиту нічого не говорить про те, наскільки швидко буде створено довгу відповідь.
Справді важливим є складний навантаження — великі документи, кілька одночасних користувачів, виклики інструментів, які постійно повторюються туди-сюди.
Тестування з одним коротким запитом приховує саме ті затримки через чергування та конфлікти пам’яті, які ускладнюють локальну обробку даних, коли нею починають користуватися кілька людей.
Усі ці помилки пов’язані одним закономірністю: кожна з них бере число, яке легко навести, і приймає його за справжній обмежувальний фактор.
Проведіть власні тестування на обладнанні, яке ви вже маєте, або орендуйте час на саме тій конфігурації, яку оцінюєте, перш ніж приймати рішення.
Купувати потужності до того, як ви визначите справжню проблему, — це хороший спосіб забезпечити її продовження.
Запит — це не дозвіл
Найважливіше непорозуміння у проектуванні агентів майже не пов’язане з тим, яку модель ви використовуєте.
Коли модель створює запит до інструменту, це просто прохання, більше нічого.
Якийсь окремий механізм має вирішити, чи справді це прохання буде виконано.
Дивно, але досить легко створити систему, у якій цей окремий механізм функціонально є просто моделлю, яка довіряє собі, підсиленою ввічливим запитом у формулі, який просить її дотримуватися меж.
Це лише перевага, а не справжня межа, і саме переваги використовують у атаках типу ін’єкції запитів.
Будь-що, що ваш агент отримує ззовнішніх джерел, вважається ненадійним вхідним даним.
Файл README може містити інструкції, адресовані вашому агенту. Те саме стосується коментаря, вбудованого у вихідний код, тіла запису в системі відстеження проблем чи звичайної веб-сторінки.
Рішенням є не більш розумні інструкції, а більш сувора модель дозволів: обмежити доступ лише до схваленого набору шляхів замість усієї файлової системи, встановити ліміти розміру файлів, контролювати те, що можна записувати, виконувати тести у тимчасовому середовищі, не дозволяти процесу-робітнику отримати доступ до облікових даних для розгортання та вимагати, щоб людина переглянула кожен патч перед тим, як він потрапить у продакшн.
Запуск власних локальних обчислень та обмеження дозволів інструментів — це дві різні проблеми, і легко припустити, що вирішення однієї автоматично вирішує іншу.
Якщо ви самі хостите ваги, це визначає місцезнаходження ваших даних у фізичному сенсі та чи залежить ваша система від онлайн-стану іншої компанії. Це зовсім не впливає на те, які дії насправді дозволено виконувати агенту.
Команди, які змішують ці два аспекти, у кінцевому підсумку отримують повністю самохостований модель, який все одно може завдати необмеженої шкоди їхньому власному кодовому базису.
У масштабах цілої команди та сама логіка вказує на необхідність розміщення автентифікованого шлюзу перед кінцевою точкою обробки даних, встановлення лімітів на використання для кожного користувача та визначення чіткої політики для кожного робочого процесу — виконувати його локально, дозволяти використання певного хостованого моделю чи направляти на перегляд людині.
Зберігайте контрольні точки перед повторною спробою виконання невдалих кроків, а будь-які інструменти з побічними ефектами потрібно розробляти так, щоб вони були ідемпотентними, аби спроба відновлення не могла тихо повторити дію, яка вже відбулася.
Чому надійність діє проти вас
Це змінює те, чого насправді слід очікувати від невеликої локальної моделі. Її справжня функція — не бути надзвичайно ефективною, а працювати надійно в рамках короткого, вузькосферного робочого процесу, який легко перевіряти та відновлювати у разі збою.
І що найважливіше, кількість кроків у цьому процесі не визначається вагами моделі. Це рішення, яке ви приймаєте під час створення додатку.
Скорочення кількості етапів, перевірка проміжних результатів та встановлення контрольних точок, щоб у разі збою можна було продовжити роботу замість початку все спочатку, зазвичай забезпечують більшу надійність, ніж використання більшої моделі.
Ось чому оцінка також не може залишатися розпливною чи ґрунтуватися лише на особистих спостереженнях.
Візьміть п’ятдесят завдань з вашого реального списку справ, кожне з яких має заданий результат, зафіксований у місці, до якого агент не може записувати чи змінювати інформацію.
Відстежуйте правильність — чи були виклики інструментів коректними, час відгуку, кількість спроб повторного виконання та час, який людина витратила на усунення проблем пізніше — усе це вимірюється при реалістичних обсягах даних та рівнях конкурентності, з оцінкою за пороговими значеннями, які ви встановили, щоб з’ясувати, яка модель виявиться кращою.
Одна особливість заслуговує окремого стовпця у вашому телеметрію: модель, до якої неможливо отримати доступ, та модель, яка надає погану відповідь, є фундаментально різними видами збоїв.
Перший — це проблема маршрутизації та відновлення. Другий — це проблема якості.
Якщо об’єднати їх у одне число показника успішності, ви втратите саме ту інформацію, яка показує, чи справжнім рішенням є збільшення пропускної здатності, краща модель чи менша, більш обмежена задача.
Що ви насправді купуєте
Єдине порівняння, яке варто проводити, — це вартість за кожну прийняту задачу.
Порівнюючи ціни токенів, ми порівнюємо речі, які не схожі між собою; порівнюючи прийняті завдання, ми порівнюємо речі, які схожі. У випадку локального розміщення ваші витрати складаються з амортизації обладнання, електроенергії, технічного обслуговування, часу простою та зусиль з перевірки. У випадку хостингу — це токени, кількість спроб та зусилля з перевірки.
Виконуйте ту саму суміш завдань за однаковими критеріями прийнятності в обох варіантах — будь-що менше перетворює порівняння на формальність.
Розрахунки виходять так, як ви і очікуєте.
Припустимо, локальна інфраструктура коштує вам шістсот доларів на місяць у вигляді постійних витрат, причому кожне прийняте завдання коштує два центи локально, на відміну від двадцяти центів через API хостингу. Точка беззбитковості досягається при близько 3 333 прийнятих завданнях на місяць.
Ці цифри є ілюстративними, а не результатами вимірювань, проте основна закономірність залишається незмінною: виконання обчислень локально — це інвестиція з фіксованими витратами, яка окупається лише після досягнення певного обсягу роботи, а при меншому обсязі спричиняє збитки.
Більшість команд будуть працювати нижче цього порогу.
Саме тут чесний аналіз переваг локального ШІ різко відрізняється від маркетингових тверджень.
При збитковості локальні обчислення не є дешевшим варіантом, і стверджувати протилежне робить цей вибір неприйнятним ще до першої перевірки цифр.
Насправді ви купуєте можливість — гарантію того, що зможете продовжувати роботу навіть у разі змін у умовах доступу, за умов, які ви контролюєте.
Ціни на такі опції визначаються на основі нестабільності, а не очікуваних середніх результатів.
Якщо нещодавні перерви щось і показали, то це те, що така нестабільність є справжньою, що вона походить від адміністративних рішень, а не технічних, і що вона настає без попередження.
Це слушна причина для витрачання грошей.
Але це інша причина, ніж та, яка зазвичай наводиться, і її варто обґрунтовувати саме за її власними перевагами, а не прикривати під приводом заощадження коштів.
Тест, який справді щось показує
Усе це не залежить від переконання, що закони масштабування й надалі будуть діяти, що якийсь проміжок часу для доступу справді закривається, або що AGI зможе чи не зможе розміститися у певній кількості VRAM.
Це прогнози, і ризик залежності не вимагає їхньої істинності.
Усе, що потрібно, — це усвідомлення того, що система, від якої ви залежите, може перестати працювати з причин, які не мають нічого спільного з її продуктивністю чи вашою поведінкою. Це стосувалося електромереж, підводних кабелів та мереж оплати, і тепер це також чітко стосується передових моделей ШІ.
Практична відповідь не є захоплюючою. Вона переважно означає необхідність опанування навичок, які ви зараз вважаєте само собою зрозумілими або припускаєте, що хтось інший вже цим зайнявся за вас.
Спробуйте ось що: повністю відновіть свою інфраструктуру на основі усіх нотаток та резервних копій, які у вас є, а потім передайте ці самі нотатки іншому інженеру та спостерігайте, як він намагатиметься здійснити таке ж відновлення самостійно. Ця проста вправа навчить вас більшого про те, наскільки ви насправді самодостатні, ніж будь-кілька легких розмов із моделлю, яка випадково є онлайн сьогодні. Те, що модель доступна зараз, нічого не гарантує щодо майбутнього, а єдиним справжнім доказом стійкості є те, чи зможе ваша система функціонувати без неї.
Пов’язана література
- ReAct Explained: Як AI-агенти поєднують міркування з діями у реальному світі — Дізнайтеся, як фреймворк ReAct поєднує міркування та використання інструментів для функціонування AI-агентів, та в чому його відмінності від моделей Chain-of-Thought, RL та інших моделей міркувань.