Останні 18 місяців Директори з інформаційної безпеки (CISO) дотримувалися простої стратегії управління генеративним ШІ: контролюйте браузер. Використовуючи брокерів безпечного доступу до хмари (CASB) і відстежуючи мережевий трафік до відомих ШІ-сервісів, команди безпеки могли спостерігати, реєструвати і блокувати передачу конфіденційних даних ще до того, як вони покидали корпоративну мережу.
Однак фундаментальний зсув апаратного та програмного забезпечення робить цей захист периметра застарілим. Ми вступаємо в епоху «Принеси свою модель» (BYOM — Bring Your Own Model) — феномена, при якому співробітники запускають потужні великі мовні моделі (LLM) безпосередньо на своєму локальному обладнанні.
Оскільки ця діяльність відбувається в автономному режимі або через локальні процеси, вона не залишає слідів мережі, обходить традиційні засоби запобігання витоку даних (DLP) і створює величезний розрив у видимості для корпоративної безпеки.
Чому локальний запуск раптом став можливим
Перехід від хмарного ШІ до локального виконання-це не просто тренд; він обумовлений трьома технічними факторами, які зробили високопродуктивний ШІ практичним навіть на звичайному ноутбуці:
-
-
- Апаратне прискорення: * * Сучасні споживчі ноутбуки, особливо оснащені високопродуктивною уніфікованою пам’яттю (як MacBook Pro), тепер можуть запускати складні моделі класу 70B, які раніше вимагали величезних серверних кластерів.
-
-
-
- Масова квантування: * * методи стиснення моделей в більш компактні і ефективні формати стали зрілими, що дозволяє високоякісному ШІ працювати в межах обсягу пам’яті портативного пристрою.
-
-
-
- Безперешкодне розповсюдження: * * моделі з відкритими вагами тепер неймовірно легко завантажувати та розгортати. Всього однією командою інженер може перетворити порожній термінал в повністю функціонального приватного ШІ-асистента.
-
Це створює» тихий ” робочий процес: інженер може завантажити модель, відключитися від Wi-Fi і використовувати конфіденційний вихідний код або регульовані набори даних для підсумовування документів або аудиту коду — і все це без єдиного пакету даних, що пройшов через корпоративний проксі-сервер.
Три критичні ризики ” неперевіреного запуску»
Коли ШІ переміщується з хмари на кінцевий пристрій, характер основної загрози змінюється. Мова йде вже не тільки про ексфільтрації даних (виведення даних з компанії), але і про * * цілісності, комплаенсе і походження.**
1. Ризик цілісності: забруднення коду та рішень
Коли розробники використовують неперевірені, налаштовані спільнотою моделі для «очищення» або оптимізації коду, вони створюють прихований ризик для ланцюжка поставок програмного забезпечення. Модель може видати код, який виглядає робочим і проходить юніт-тести, але містить тонкі уразливості — наприклад, слабку валідацію вхідних даних або небезпечні патерни багатопоточності. Якщо це відбувається локально, Служба безпеки не має контрольного журналу (audit trail), щоб пов’язати майбутню вразливість з ШІ, який її створив.
2. Ризик комплаєнсу: ліцензування та інтелектуальна власність
Не всі» відкриті ” моделі безкоштовні для використання в бізнесі. Багато високопродуктивні моделі поставляються з обмежувальними ліцензіями, що забороняють комерційне застосування. Якщо працівник використовує некомерційну модель для створення готової до експлуатації документації або коду, компанія бере на себе значну юридичну та фінансову відповідальність, яка може виявитися лише під час аудиту або перевірки злиття та поглинання (M&a).
3. Ризик Походження: ланцюжок поставок моделей
Завантаження моделі – це не те саме, що завантаження текстового файлу; це більше схоже на завантаження виконуваного файлу.
* * * Шкідливе навантаження: * * старі формати файлів (наприклад, деякі файли «Pickle» в PyTorch) можуть виконувати шкідливий код простим фактом їх завантаження.
* * * Відсутність інвентаризації: * * більшість компаній не мають «специфікації програмного забезпечення» (SBOM) для AI. Вони не можуть відстежити, які версії моделей використовуються, звідки вони взялися і чи проходили вони перевірку на безпеку.
Нова стратегія управління ШІ
Оскільки блокування URL-адрес більше не є ефективним рішенням, CISO повинні перенести фокус з мережі на кінцеві пристрої. Щоб керувати Shadow AI 2.0, організації повинні прийняти три ключові стратегії:
1. Впровадження засобів контролю на рівні кінцевих точок
Команди безпеки повинні відстежувати» сигнали ” локального використання ШІ за допомогою існуючих інструментів виявлення та реагування на кінцеві точки (EDR):
– Пошук файлів великих моделей (наприклад, файли .gguf або’. pt’).
– Виявлення локальних вихідних серверів (наприклад, процеси, що працюють на порту 11434, що використовуються Ollama).
– Моніторинг незвичайних патернів використання GPU або NPU (нейронних процесорів).
2. Створення ” второваної дороги “» курований хаб моделей)
Shadow AI зазвичай є реакцією на незручності. Якщо офіційні інструменти занадто повільні або обмежувальні, розробники знайдуть свої. Організації можуть пом’якшити цю проблему, надавши внутрішній кураторський каталог:
– Схвалених моделей для конкретних завдань (програмування, сумаризація і т.д.).
– Перевірених, комерційно безпечних ліцензій.
– Безпечних, хешованих версій моделей (з пріоритетом безпечних форматів, таких як Safetensors ).
3. Модернізація політик
Традиційні “політики прийнятного використання” зосереджені на SaaS та хмарних сервісах. Нові політики повинні чітко регулювати завантаження та запуск артефактів моделей на корпоративних пристроях, включаючи правила обробки даних та затверджені джерела моделей.
- Висновок: * * Периметр ШІ зміщується назад — до кремнію на робочому столі співробітника. Щоб підтримувати безпеку, не пригнічуючи інновації, підприємства повинні припинити намагатися заблокувати хмару та почати керувати артефактами та процесами, що відбуваються безпосередньо на пристроях.
