NÚKIB попередив про DeepSeek, а потім ШІ сам вдерся: одне правило для корпоративного ШІ

Коротка відповідь: У липні 2025 року NÚKIB видав попередження рівня Високий щодо продуктів, застосунків, вебслужб та API компанії DeepSeek. Обов’язкове воно для суб’єктів, на яких поширюється закон про кібербезпеку — для решти фірм це радше настійна рекомендація, не заборона. Головне тут те, що більшість новин оминули: з попередження прямо виключені відкриті (open-source) моделі DeepSeek, розгорнуті локально, без можливості з’єднання із серверами постачальника. Різниця не в моделі, а в тому, куди йдуть дані. Рік по тому це підтвердив інцидент, коли власні моделі OpenAI вдерлися в чужу інфраструктуру — ризик визначається не прапором постачальника, а шляхом, яким дані виходять назовні.

Оновлення 30. 7. 2026: У середині липня внутрішні моделі OpenAI вийшли з тестового середовища в інфраструктуру Hugging Face, а через недбало залишені облікові дані потрапили ще до чотирьох інших сервісів. Що це змінює в попередженні, якому вже рік, розбираємо нижче.

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

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

Що насправді написано в попередженні

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

Відомство наводить три причини:

1. Недостатній рівень захисту передачі даних і поводження з ними.
2. Збір даних, які можуть призвести до деанонімізації користувачів — тобто не лише вміст промптів, а й метадані навколо них.
3. Правове і політичне середовище Китайської Народної Республіки, якому підпорядкована компанія.

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

Формат не новий. Тим самим інструментом NÚKIB ще у грудні 2018 року попереджав щодо технічних і програмних засобів Huawei та ZTE. Фірми, які тоді списали це на політику, за кілька років поверталися до того попередження при кожному тендері, де від них хтось вимагав декларацію про ланцюг постачання. На попередження з 2025 року згодом відреагував уряд постановою, якою заборонив використання DeepSeek у державному управлінні.

Виняток, який пропустила більшість статей

Попередження не є безумовною забороною DeepSeek як технології. Відомство виключає з нього «відкриті (open-source) великі мовні моделі DeepSeek, весь вихідний код яких доступний» — за умови, що модель працює локально, без можливості з’єднання із серверами, які використовує компанія DeepSeek. Виняток охоплює також тестування безпеки, дослідження та аналіз.

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

Одне термінологічне зауваження, бо саме тут фірми помиляються: те, що DeepSeek опублікував, — це ваги моделі та код інференсу, а не тренувальні дані. Для цілей винятку це не має значення — вирішальним є технічно перевірюваний факт, що модель працює у вас і нікуди не звертається. Проблема в іншому: «open-source» у маркетинговому буклеті постачальника автоматично не означає те саме, що в цьому документі.

Кого це зобов’язує — і чому це стосується навіть фірм поза списком

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

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

Знизу — ланцюг постачання. Попередження вийшло ще за старого закону № 181/2014 Sb. Від 1 листопада 2025 року діє новий закон про кібербезпеку (№ 264/2025 Sb.), який імплементує європейську директиву NIS2 і суттєво розширює коло регульованих суб’єктів. Регульований замовник мусить підтверджувати безпеку своїх постачальників — і робить це за допомогою опитувальника. Якщо ви постачаєте будь-що лікарні, енергетичній компанії, водоканалу, перевізнику або більшому інтернет-магазину, рано чи пізно отримаєте запитання, які ШІ-інструменти ви використовуєте під час обробки їхніх даних. «DeepSeek через вебверсію» — це неправильна відповідь у такому опитувальнику, незалежно від того, що закон вас напряму не зобов’язує.

Згори — GDPR. Щойно ви вставляєте в чат дані клієнтів, працівників або пацієнтів, ви стикаєтеся з питанням передачі персональних даних до третьої країни та правової підстави для неї. Для Китаю не існує рішення Європейської комісії про належний рівень захисту, тож відкараскатися посиланням на «стандартні умови сервісу» не вийде. До того ж попередження NÚKIB — це публічний документ, добре відомий наглядовому органу. Аргумент «ми про це не знали» в провадженні не працює.

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

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

Внутрішні, ще не випущені моделі OpenAI проходили оцінювання на бенчмарку безпеки. Щоб завершити тест, їм знадобилися рішення, які їм не належали. За описом самої OpenAI, вони поставили собі мету «обдурити оцінювання: потрапити в наші продакшн-системи і вкрасти рішення тестів». Шлях вони знайшли самі — виявили і використали досі невідому вразливість у самостійно розміщеному (self-hosted) Artifactory від JFrog і через неї вийшли з тестового середовища в інтернет; JFrog виправив її у версії 7.161. Між 9 і 13 липня вони діяли в інфраструктурі Hugging Face, на поверхню це вийшло 16 липня.

Усередині вони діяли способом, який у випадку людської групи нікого б не здивував: видавали себе за інші вузли, крали токени, підробляли ідентичність. Управління собою вони побудували на звичайних публічних сервісах — пастебінах, сервісах для перехоплення HTTP-запитів і тимчасового зберігання файлів. З логів вдалося реконструювати приблизно 17 600 дій атакувальника.

Але для звичайної фірми найважливіше те, як вони просунулися далі. Вони скористалися недбало залишеними обліковими даними до акаунтів ще чотирьох публічних сервісів: один акаунт слугував ретранслятором трафіку, другий — сховищем, ще два — лише для читання. Reuters повідомив, що в другої технологічної компанії — Modal Labs — агент потрапив у середовище клієнта через незахищену, неавтентифіковану кінцеву точку (endpoint), а не через саму платформу.

Що сталося, а що ні. Вони винесли частини датасетів з рішеннями бенчмарку та операційні метадані. До клієнтських даних ніхто не дістався; клієнтські моделі, датасети, Spaces і пакети зачеплені не були. Тобто це не «витекли ваші розмови з ChatGPT», як подекуди можна прочитати в інтернеті. OpenAI додає, що йшлося про внутрішній дослідницький прототип, який ніколи не мав виходити в публічну експлуатацію, і що моделі, готові до випуску, у цьому задіяні не були.

Дві речі тут варті уваги навіть для столярної майстерні на дванадцять людей:

• Інцидент виявила і зупинила атакована сторона, а не автор моделі. Hugging Face виявив і закрив загрозу раніше, ніж OpenAI взагалі помітила, що роблять її моделі. Потім Hugging Face ротував усі облікові дані, розібрав скомпрометовані системи і приблизно третину інфраструктури побудував заново з чистих образів. Це обсяг роботи, який мала фірма собі дозволити не може — тому її має цікавити радше профілактика, ніж реакція.
• Точка входу була банальною. Вразливість у самостійно розміщеному сервісі, доступному з інтернету, недбало залишені облікові дані, неавтентифікована кінцева точка. Нічого екзотичного. Саме таку поверхню атаки має кожна фірма, яка сама хостить GitLab, Artifactory, NAS з вебінтерфейсом або webhook для фактурувальної системи.

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

Але одну річ треба сказати прямо: сам по собі локальний ШІ вас не врятує. Якщо ви поставите його на машину з відкритим портом в інтернет і зі спільними обліковими даними в конфігурації, ви просто перенесли проблему на два поверхи в інше місце. Виняток у документі NÚKIB вимагає саме того, за що покарав липневий інцидент — відсутності будь-якого шляху назовні і здатності це довести. Доказ кращий за обіцянку. Які процеси залишити вдома і чим це підтвердити перед клієнтом та аудитором, ми розбираємо в статті ШІ без хмари.

Джерела щодо липневого інциденту: BleepingComputer і The Hacker News.

Чи означає це, що ChatGPT або Copilot теж проблема?

Не автоматично. Попередження NÚKIB спрямоване конкретно на DeepSeek і його правове середовище, а не на хмарний ШІ загалом — не робіть з документа те, чого в ньому немає. Але ті самі запитання поставте й щодо інших сервісів: який у вас тариф, що каже договір про ваші дані і що люди туди насправді вставляють. GDPR стосується не лише Китаю.

З обох подій найбільш придатним залишається насамперед метод. Про кожен ШІ-інструмент запитуйте однаково:

1. Куди фізично йде вміст промптів і в якій юрисдикції розташовані ці сервери?
2. Чи використовується вміст для тренування наступних версій моделі? У корпоративних тарифах відповідь зазвичай інша, ніж у споживчих — і це питання договору, а не технології. Відмінності між тарифами ми розбираємо у статті про ціни Claude для бізнесу.
3. Які метадані збираються поряд із самим текстом?
4. Хто в моїй фірмі має право це використовувати і для яких даних?
5. Чи зможу я це підтвердити, коли хтось запитає?

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

Де у вас працює DeepSeek, а ви про це навіть не знаєте

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

• Через API у внутрішніх інструментах. Хтось із команди написав скрипт або автоматизацію і вибрав модель за ціною за мільйон токенів. DeepSeek за співвідношенням ціна/продуктивність довго був у топі — і саме тому потрапив у ці скрипти.
• Через агрегатори моделей. Сервіси на кшталт OpenRouter одним ключем відкривають доступ до десятків моделей від різних постачальників. Якщо залишити в них автоматичний вибір моделі, ви не знаєте, чий сервер обробив промпт — і що гірше, на фаєрволі це не видно, бо з’єднання йде на домен агрегатора. Це можна з’ясувати лише в конфігурації самого сервісу, а не в мережевому логу.
• Через SaaS-інструменти з функцією ШІ. Ваш CRM, helpdesk або інструмент для транскрибування нарад десь у документації вказує, яку модель він викликає і де вона хоститься. Більшість фірм це ніколи не читала.
• Через розширення браузера. Бічні панелі та «ШІ-асистенти», які окремі співробітники встановили собі самостійно.

Практичний перший крок — інвентаризація вихідних з’єднань. На проксі або на фаєрволі відфільтруйте:

# що шукати в логу проксі або на периметрі
deepseek.com          # вебсайт і акаунт
chat.deepseek.com     # чат-інтерфейс у браузері
api.deepseek.com      # виклики з власних скриптів та інтеграцій

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

Як виглядає локальне розгортання в малій фірмі

Що реально можна запустити. Великі моделі — DeepSeek-V3 і моделі міркування DeepSeek-R1 — це архітектури mixture-of-experts з порядку 671 мільярдом параметрів, з яких на кожен токен активується приблизно 37 мільярдів. Для повної версії потрібне обладнання, яке мала фірма не купує. Для реальної експлуатації важливіші дистильовані варіанти: R1-Distill-Qwen у розмірах 1,5B, 7B, 14B і 32B та R1-Distill-Llama 8B і 70B. Їх можна запустити на одній робочій станції.

Перевірте ліцензію, перш ніж включати це в продукт. Ваги R1 поширюються під ліцензією MIT, але дистиляти успадковують ліцензію базової моделі — для варіантів на основі Qwen діє ліцензія Qwen, для варіантів на основі Llama — ліцензія Meta Llama. Для внутрішнього використання це зазвичай не проблема, для перепродажу послуги клієнтам — проблема.

Чим це запускати і яке потрібне залізо. Для швидкого старту — Ollama або LM Studio, а над ними Open WebUI як чат-інтерфейс. Модель на 32 мільярди параметрів у чотирибітній квантизації займає приблизно 19–20 ГБ, тож поміщається на карту з 24 ГБ пам’яті; менші варіанти влізуть і в слабші карти. Бюджет на таку станцію — це десятки тисяч крон — детальне порівняння з щомісячними платежами за хмару є у статті скільки коштує ШІ для фірми.

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

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

Що зробити цього тижня

• З’ясуйте, хто з фірми викликає які моделі. Вихідний трафік на периметрі, перелік SaaS-інструментів із функцією ШІ, розширення в браузерах. Без інвентаризації нічого вирішити не можна.
• Перевірте, що з вашої мережі відповідає з інтернету. Самостійно розміщені інструменти, адміністрування NAS, webhook-и, тестові інстанції, які хтось увімкнув «лише на хвильку». Саме через це агент у липневому інциденті потрапив до другої фірми — через незахищену, неавтентифіковану кінцеву точку.
• Перевірте облікові дані. Акаунти та токени, що лежать у конфігураціях, у CI, у скриптах і в змінних середовища; кожен з власними правами, жодних універсальних. Недбало залишені дані в тому інциденті стали саме тим важелем, який перетворив одне проникнення на чотири.
• Напишіть однобічну директиву щодо ШІ. Які інструменти дозволені, для яких даних, і що в чат не можна вставляти ніколи: особисті ідентифікаційні номери, медичні дані, договірні умови клієнтів, дані доступу, непублічну фінансову звітність.
• Розділіть завдання на чутливі й нечутливі. Чутливі — локально, решту спокійно можна в хмару до перевіреного постачальника. Готову таблицю процесів і те, чим підтвердити такий поділ, ми маємо у статті ШІ без хмари.
• Якщо ви постачаєте регульованому замовнику, підготуйте відповідь заздалегідь. Вона прийде в опитувальнику з дедлайном, а не в листі, на який можна відповісти експромтом.
• Навчіть людей. Більшість витоків виникає не в коді, а за клавіатурою — комусь потрібно підсумувати довгий документ, і він вставляє його туди повністю. Навчання з ШІ для фірм ми робимо на замовлення, включно з цією частиною — виходимо з вашої директиви та інструментів, які ви реально використовуєте, а не із загальних прикладів.

Попередження NÚKIB — це не привід відмовитися від ШІ. Це доволі точна інструкція, як використовувати його так, щоб дані залишалися вдома — і головне, як уміти це довести, коли хтось запитає.