Теневой ИИ 2.0 переносит большие языковые модели на конечные устройства

Последние 18 месяцев справочник по безопасности (playbook) для директора по информационной безопасности (CISO) в сфере генеративного ИИ был относительно прост: контролировать браузер.

Команды безопасности ужесточили политики брокеров безопасного доступа к облачным ресурсам (CASB), заблокировали или взяли под мониторинг трафик к известным ИИ-эндпоинтам и направили использование через санкционированные шлюзы. Операционная модель была ясна: если конфиденциальные данные покидают сеть для вызова внешнего API, мы можем это отследить, залогировать и пресечь. Но эта модель начинает давать сбои.

Тихий сдвиг в аппаратном обеспечении вытесняет использование больших языковых моделей (LLM) за пределы сети — прямо на конечные устройства. Назовите это теневым ИИ версии 2.0 (Shadow AI 2.0) или эпохой «принеси свою собственную модель» (BYOM): сотрудники запускают мощные модели локально на ноутбуках, оффлайн, без вызовов API и каких-либо заметных сетевых следов. Дискуссия об управлении рисками по-прежнему ведется в терминах «утечки данных в облако», однако более актуальным риском для предприятий все чаще становится «непроверенный инференс прямо на устройстве».

Когда инференс происходит локально, традиционные средства предотвращения утечки данных (DLP) это взаимодействие не видят. А если служба безопасности этого не видит, она не может этим управлять.

Почему локальный инференс внезапно стал практичным

Два года назад запуск полезной LLM на рабочем ноутбуке был нишевым трюком. Сегодня для технических команд это рутина.

Сошлись три фактора:

• Ускорители потребительского класса стали серьезными: MacBook Pro с 64 ГБ объединенной памяти зачастую способен запускать квантованные модели класса 70B на рабочей скорости (с практичными ограничениями на длину контекста). То, что раньше требовало серверов с несколькими графическими процессорами (GPU), теперь во многих реальных рабочих процессах реализуемо на высококлассном ноутбуке.

• Квантование стало мейнстримом: теперь модели легко сжимать в более компактные и быстрые форматы, которые помещаются в память ноутбука, зачастую с приемлемым компромиссом по качеству для многих задач.

• Дистрибуция не имеет трения: модели с открытыми весами устанавливаются одной командой, а экосистема инструментов делает процесс «скачать → запустить → общаться» тривиальным.

Результат: инженер может загрузить многогигабайтный файл модели, отключить Wi-Fi и локально выполнять конфиденциальные рабочие задачи: ревью исходного кода, суммаризацию документов, составление черновиков деловых писем для клиентов и даже исследовательский анализ регулируемых наборов данных. Никаких исходящих пакетов, никаких логов прокси, никакого облачного аудиторского следа.

С точки зрения сетевой безопасности такая активность может быть неотличима от ситуации, когда «ничего не произошло».

Риск заключается уже не только в уходе данных из компании

Если данные не покидают ноутбук, почему CISO должен об этом беспокоиться?

Потому что главные риски смещаются от утечки к целостности, происхождению (провенансу) и комплаенсу. На практике локальный инференс порождает три категории «слепых зон», к которым большинство компаний еще не выработало регламентов.

1. Загрязнение кода и решений (риск целостности)

Локальные модели часто внедряются из-за их скорости, конфиденциальности и принципа «не требуется одобрения». Обратная сторона медали заключается в том, что они зачастую не проверены для корпоративной среды.

Типичный сценарий: опытный разработчик скачивает дообученную сообществом модель для написания кода, поскольку у нее хорошие показатели в бенчмарках. Он вставляет внутреннюю логику аутентификации, платежные потоки или инфраструктурные скрипты, чтобы «причесать» код. Модель выдает результат, который выглядит компетентно, компилируется и проходит модульные тесты, но незаметно снижает уровень безопасности (слабая валидация входных данных, небезопасные настройки по умолчанию, хрупкие изменения параллелизма, выбор зависимостей, не разрешенных внутри компании). Инженер фиксирует изменения (коммит).

Если это взаимодействие происходило в оффлайне, у вас может не остаться никаких записей о том, что ИИ вообще повлиял на этот путь кода. И когда позже вы начнете расследование инцидента, вы будете исследовать симптом (уязвимость) без понимания первопричины (бесконтрольное использование моделей).

2. Лицензионные риски и угроза интеллектуальной собственности (комплаенс-риски)

Многие высокопроизводительные модели поставляются с лицензиями, содержащими ограничения на коммерческое использование, требования к указанию авторства, ограничения по сферам применения или обязательства, которые могут быть несовместимы с разработкой проприетарных продуктов. Когда сотрудники запускают модели локально, такое использование может обходить стандартные процессы закупок и юридической проверки в организации.

Если команда использует некоммерческую модель для генерации промышленного кода, документации или поведения продукта, компания может унаследовать риски, которые проявятся позже — во время проверки при слияниях и поглощениях (M&A), клиентских аудитов безопасности или судебных разбирательств. Самая сложная проблема заключается не только в условиях лицензии, но и в отсутствии инвентаризации и прослеживаемости. Без управляемого репозитория моделей или записей об их использовании вы можете оказаться неспособны доказать, что и где применялось.

3. Риски цепочки поставок моделей (риск происхождения)

Локальный инференс также трансформирует проблему цепочки поставок программного обеспечения. На эндпоинтах начинают скапливаться крупные файлы моделей и окружающие их тулчейны: загрузчики, конвертеры, среды выполнения (рантаймы), плагины, графические оболочки и пакеты Python.

Здесь есть критически важный технический нюанс: формат файлов имеет значение. Хотя новые форматы вроде Safetensors созданы для предотвращения произвольного выполнения кода, старые файлы PyTorch на основе Pickle могут выполнять вредоносную полезную нагрузку просто в момент их загрузки. Если ваши разработчики скачивают непроверенные чекпоинты с Hugging Face или других репозиториев, они не просто загружают данные — они потенциально скачивают эксплойт.

Команды безопасности потратили десятилетия на то, чтобы научиться воспринимать неизвестные исполняемые файлы как враждебные. BYOM требует распространения этого подхода на артефакты моделей и сопутствующий стек рантайма. Главный организационный пробел сегодня заключается в том, что у большинства компаний нет аналога спецификации состава программного обеспечения (SBOM) для моделей: данных о происхождении (провенансе), хэшей, разрешенных источников, сканирования и управления жизненным циклом.

Смягчение рисков 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: всплески активности графического процессора в оффлайн-режиме или при отключенном VPN.

• Отсутствие инвентаризации моделей: невозможность сопоставить результаты работы кода с конкретными версиями моделей.

• Лицензионная неопределенность: наличие «некоммерческих» весов моделей в продакшн-сборках.

Shadow AI 2.0 — это не гипотетическое будущее, а предсказуемое следствие быстрого «железа», простой дистрибуции и спроса со стороны разработчиков. CISO, сосредоточенные исключительно на сетевых средствах контроля, упустят из виду то, что происходит на кремниевых чипах прямо на столах сотрудников.

Следующий этап управления ИИ меньше связан с блокировкой сайтов и больше — с контролем артефактов, происхождения и политик на уровне эндпоинтов, причем без ущерба для продуктивности.

Джаячандер Редди Кандакатла — старший MLOps-инженер.

Добро пожаловать в сообщество VentureBeat!

Наша программа гостевых публикаций — это площадка, где технические эксперты делятся инсайтами и представляют непредвзятый, независимый глубокий анализ ИИ, инфраструктуры данных, кибербезопасности и других передовых технологий, формирующих будущее бизнеса.

Читайте далее в рамках нашей программы гостевых публикаций и ознакомьтесь с нашими рекомендациями, если вы хотите предложить собственную статью!