Протягом останніх 18 місяців основним підходом для керівників служби безпеки (CISO) щодо генеративного ШІ було просте правило: контролювати браузер.
Команди безпеки посилили політики брокерів безпеки хмарного доступу (CASB), блокували або моніторили трафік до відомих кінцевих точок ШІ та спрямовували використання через санкціоновані шлюзи. Операційна модель була чіткою: якщо конфіденційні дані залишають мережу для виклику зовнішнього API, ми можемо спостерігати за ними, реєструвати їх і зупиняти. Але ця модель починає руйнуватися.
Тиха зміна апаратного забезпечення призводить до того, що використання великих мовних моделей (LLM) переміщується з мережі на кінцеві пристрої. Назвіть це “Тіньовим ШІ 2.0” або ерою “принеси свою модель” (BYOM): співробітники запускають потужні моделі локально на ноутбуках, офлайн, без викликів API та без очевидних мережевих сигнатур. Дискусія щодо управління все ще зосереджена на “витоку даних у хмару”, але більш нагальною корпоративною ризиком стає “неперевірена інференція всередині пристрою”.
Коли інференція (обробка запитів моделлю) відбувається локально, традиційні засоби запобігання втраті даних (DLP) не бачать цієї взаємодії. А коли безпека цього не бачить, вона не може цим керувати.
Чому локальна інференція раптом стала практичною
Два роки тому запуск корисної LLM на робочому ноутбуці був нішевим експериментом. Сьогодні для технічних команд це стало буденністю.
Збіглися три фактори:
-
Споживчі прискорювачі стали серйозними: MacBook Pro з 64 ГБ уніфікованої пам’яті часто може запускати квантовані моделі класу 70B з прийнятною швидкістю (з практичними обмеженнями щодо довжини контексту). Те, що колись вимагало серверів з кількома GPU, тепер можливо на ноутбуці високого класу для багатьох реальних робочих завдань.
-
Квантування стало мейнстрімом: Зараз легко стискати моделі у менші, швидші формати, які вміщуються в оперативну пам’ять ноутбука, часто з прийнятними компромісами щодо якості для багатьох завдань.
-
Розповсюдження безперешкодне: Моделі з відкритими вагами (open-weight models) доступні за одну команду, а екосистема інструментів робить процес “завантажити → запустити → спілкуватися” тривіальним.
Результат: Інженер може завантажити модель розміром у кілька гігабайт, вимкнути Wi-Fi і локально запускати конфіденційні робочі процеси: аналіз вихідного коду, узагальнення документів, підготовку комунікацій для клієнтів, навіть дослідницький аналіз регульованих наборів даних. Жодних вихідних пакетів, жодних логів проксі, жодного хмарного аудиту.
З точки зору мережевої безпеки, така діяльність може виглядати невідрізненно від “нічого не сталося”.
Ризик полягає не тільки у витоку даних з компанії
Якщо дані не виходять за межі ноутбука, чому керівника безпеки це має хвилювати?
Тому що домінуючі ризики зміщуються з витоку на цілісність, походження (provenance) та відповідність вимогам (compliance). На практиці локальна інференція створює три типи “сліпих зон”, для яких більшість підприємств ще не розробили операційних процедур.
1. Забруднення коду та рішень (ризик цілісності)
Локальні моделі часто використовуються, тому що вони швидкі, приватні та “не потребують дозволу”. Недоліком є те, що вони часто не перевірені для корпоративного середовища.
Типовий сценарій: Старший розробник завантажує модель для написання коду, налаштовану спільнотою, тому що вона добре показує себе в бенчмарках. Він вставляє внутрішню логіку автентифікації, платіжні потоки або скрипти інфраструктури, щоб “очистити їх”. Модель повертає результат, який виглядає компетентним, компілюється і проходить модульні тести, але непомітно погіршує безпеку (слабка перевірка вхідних даних, небезпечні значення за замовчуванням, крихкі зміни паралелізму, вибір залежностей, які не дозволені всередині компанії). Розробник комітує (зберігає) зміну.
Якщо ця взаємодія відбулася офлайн, ви можете не мати жодного запису про те, що ШІ вплинув на шлях коду. І коли ви пізніше проводитимете розслідування інциденту, ви будете розслідувати симптом (вразливість) без видимості ключової причини (неконтрольоване використання моделі).
2. Ліцензування та розкриття інтелектуальної власності (ризик відповідності)
Багато високоефективних моделей постачаються з ліцензіями, які включають обмеження на комерційне використання, вимоги щодо зазначення авторства, обмеження сфери застосування або зобов’язання, які можуть бути несумісні з розробкою власної продукції. Коли співробітники запускають моделі локально, таке використання може обійти звичайний процес закупівель та юридичної експертизи організації.
Якщо команда використовує некомерційну модель для генерації коду для виробництва, документації або функціоналу продукту, компанія може успадкувати ризики, які виявляться пізніше під час перевірки на злиття та поглинання (M&A), перевірки безпеки клієнтів або судових розглядів. Складнощі полягають не лише в умовах ліцензії, а й у відсутності інвентаризації та відстеження. Без керованого центру моделей або запису використання ви можете не мати змоги довести, що і де було використано.
3. Експозиція ланцюга постачання моделей (ризик походження)
Локальна інференція також змінює проблему ланцюга постачання програмного забезпечення. Кінцеві пристрої починають накопичувати великі артефакти моделей та інструменти навколо них: завантажувачі, конвертери, середовища виконання, плагіни, оболонки інтерфейсу користувача та пакети Python.
Тут є критичний технічний нюанс: важливий формат файлу. Хоча новіші формати, як-от Safetensors, розроблені для запобігання довільному виконанню коду, старі файли PyTorch на основі Pickle можуть виконувати шкідливі коди просто під час завантаження. Якщо ваші розробники завантажують неперевірені контрольні точки (checkpoints) з Hugging Face або інших репозиторіїв, вони не просто завантажують дані — вони можуть завантажити експлойт (засіб для використання вразливостей).
Команди безпеки десятиліттями вчилися ставитися до невідомих виконуваних файлів як до ворожих. BYOM вимагає розширення цього мислення на артефакти моделей та оточуючий стек середовища виконання. Найбільшою організаційною прогалиною сьогодні є те, що більшість компаній не мають еквіваленту специфікації програмного забезпечення (software bill of materials) для моделей: походження, хеші, дозволені джерела, сканування та управління життєвим циклом.
Зменшення ризиків BYOM: ставтеся до ваг моделей як до програмних артефактів
Ви не можете вирішити проблему локальної інференції, блокуючи URL-адреси. Вам потрібні елементи керування, що враховують кінцеві пристрої, та досвід розробника, який робить безпечний шлях найлегшим.
Ось три практичні способи:
1. Перенесіть управління на кінцевий пристрій
Мережеві DLP та CASB все ще важливі для використання в хмарі, але вони недостатні для BYOM. Почніть розглядати локальне використання моделей як проблему управління кінцевими пристроями, шукаючи конкретні сигнали:
-
Інвентаризація та виявлення: Скануйте на наявність високоточних індикаторів, таких як файли .gguf розміром понад 2 ГБ, процеси, як-от llama.cpp або Ollama, та локальні слухачі на загальноприйнятому порту за замовчуванням 11434.
-
Усвідомлення процесів та середовища виконання: Відстежуйте повторне високе використання GPU/NPU (нейронного процесорного блоку) несанкціонованими середовищами виконання або невідомими локальними серверами інференції.
-
Політика пристроїв: Використовуйте політики керування мобільними пристроями (MDM) та виявлення та реагування на кінцевих точках (EDR) для контролю встановлення несанкціонованих середовищ виконання та забезпечення базового зміцнення безпеки на інженерних пристроях. Мета — не карати за експерименти, а відновити видимість.
2. Надайте “готову дорогу”: внутрішній, курований центр моделей
Тіньовий ШІ часто є результатом тертя. Схвалені інструменти надто обмежувальні, надто загальні або надто повільні для затвердження. Кращий підхід — це запропонувати курований внутрішній каталог, який включає:
-
Схвалені моделі для поширених завдань (написання коду, узагальнення, класифікація)
-
Перевірені ліцензії та рекомендації щодо використання
-
Закріплені версії з хешами (з пріоритетом більш безпечних форматів, як-от Safetensors)
-
Чітку документацію щодо безпечного локального використання, включаючи інформацію про те, де дозволено, а де заборонено використовувати конфіденційні дані. Якщо ви хочете, щоб розробники припинили шукати рішення на стороні, запропонуйте їм щось краще.
3. Оновіть формулювання політик: “Хмарні сервіси” вже недостатньо
Більшість політик прийнятного використання говорять про SaaS та хмарні інструменти. BYOM вимагає політики, яка явно охоплює:
-
Завантаження та запуск артефактів моделей на корпоративних кінцевих пристроях
-
Прийнятні джерела
-
Вимоги щодо відповідності ліцензіям
-
Правила використання моделей із конфіденційними даними
-
Очікування щодо збереження та журналювання для інструментів локальної інференції. Це не повинно бути обтяжливим, але має бути однозначним.
Периметр знову зміщується до пристрою
Протягом десятиліття ми переносили засоби безпеки “вгору”, у хмару. Локальна інференція повертає значну частину діяльності ШІ “вниз”, на кінцевий пристрій.
5 ознак того, що тіньовий ШІ перемістився на кінцеві пристрої:
-
Великі артефакти моделей: Незрозуміле споживання пам’яті файлами .gguf або .pt.
-
Локальні сервери інференції: Процеси, що слухають на портах, як-от 11434 (Ollama).
-
Моделі використання GPU: Сплески використання GPU під час офлайн-режиму або відключення від VPN.
-
Відсутність інвентаризації моделей: Неможливість зіставити результати коду з конкретними версіями моделей.
-
Неоднозначність ліцензування: Наявність вагових файлів моделей “не для комерційного використання” у виробничих збірках.
Тіньовий ШІ 2.0 — це не гіпотетичне майбутнє, а передбачуваний наслідок швидкого апаратного забезпечення, легкого розповсюдження та попиту з боку розробників. Керівники безпеки, які зосереджуються лише на мережевих засобах контролю, пропустять те, що відбувається на кремнії, який знаходиться просто на робочих столах співробітників.
Наступний етап управління ШІ — це менше блокування веб-сайтів і більше контролю артефактів, походження та політик на кінцевому пристрої, не вбиваючи при цьому продуктивність.
Джаячандер Редді Кандакатла — старший інженер MLOps.
Ласкаво просимо до спільноти VentureBeat!
Наша програма гостьових публікацій — це місце, де технічні експерти діляться своїми думками та надають нейтральні, неупереджені глибокі дослідження щодо ШІ, інфраструктури даних, кібербезпеки та інших передових технологій, що формують майбутнє підприємств.
Читайте більше з нашої програми гостьових публікацій — і перегляньте наші рекомендації, якщо ви зацікавлені у внесенні власної статті!
Як захиститися (Порада ІТ-Блогу): Запровадьте на підприємстві сувору політику щодо використання локально встановлених моделей ШІ, яка чітко визначає дозволені джерела, умови ліцензування та правила роботи з конфіденційними даними. Обов’язково проводити регулярні аудити кінцевих пристроїв для виявлення несанкціонованих моделей та їх використання.
Інформація підготовлена на основі матеріалів: venturebeat.com