Хватит сливать данные в Claude и GPT: как поднять свой on‑prem LLM

Представим на секунду, что есть проблема, которую надо срочно пофиксить, в рабочем чате никто не отвечает, инженер, на котором висит этот проект, недоступен. Ну и чтобы сделать всё быстро и эффективно, сотрудник берёт репозиторий, закидывает его в ChatGPT вместе со всеми чувствительными данными, оставив все .env-файлы. И вот через минуту у него уже готовый результат, а у OpenAI уже есть все продовые креды данного проекта. Но ни у кого не было цели слить данные: был инженер со срочной задачей, для которой он нашёл самое быстрое решение. И в этот момент главное — не совершить ошибку ^[1]: нужно не запрещать, а предлагать альтернативу. Люди всё равно будут пользоваться агентами, просто, возможно, после запрета они будут делать это незаметно.

В этой статье предлагаю разобраться, почему сегодня это явление приобретает такой массовый характер, почему просто запретить — не выход, чем аренда GPU у облачного провайдера отличается от on-prem и как развернуть инференс внутри команды, чтобы инженеры не порывались слить данные.

Почему это происходит у всех, а не только у вас

Возможно, на этом моменте у вас в голове возникла мысль: ну это же проблема неопытного джуна, хороший инженер не будет так делать. Так вот, это неправда. В рамках опроса ISACA AI Pulse Poll 2026 ^[2] из 3400 специалистов по IT-аудиту 90% подтвердили, что сотрудники используют различные AI-инструменты, но при этом политика по использованию подобных инструментов есть только у 38% организаций. В результате по статистике Verizon в DBIR 2026 ^[3] после прогона через DLP 858 440 событий, связанных с AI-инструментами, были получены 3 важных показателя:

• Shadow AI — третье по частоте неумышленное инсайдерское действие. За год рост в 4 раза.

• Чаще всего во внешние модели сливается исходный код, после него идут изображения.

• За год доля сотрудников, которых можно считать регулярными пользователями AI-инструментов, выросла с 15% до 45%. Если смотреть на динамику, то в феврале 2023 года Cyberhaven показал ^[4], что чувствительные данные составляют 11% от общей информации, которую пользователи передают в ChatGPT, а в отчёте за 2025 год ^[5] этот показатель вырос уже до 34,8%.

Очень важно понимать, что большая часть пользователей использует несогласованные корпоративные аккаунты, по телеметрии LayerX за 2025 ^[6] год это 71,6% всех обращений.

Самый показательный кейс — Samsung в 2023 году. 11 марта они сняли внутренний запрет на использование ^[7], а к 30 марта было выявлено 3 инцидента утечки данных ^[8]: два слива исходников в поисках решения бага, а также один слив записи совещаний для генерации протоколов.

Первым действием со стороны Samsung было ограничение лимита на размер запроса до 1024 байт, а также предупреждение сотрудников, что при повторении ^[9] инцидентов доступ к ChatGPT будет заблокирован из корп-сети. В итоге в мае Bloomberg сообщил ^[10], что Samsung Electronics окончательно запретила сотрудникам пользоваться AI-инструментами. Решило ли это проблему? Как было сказано выше, маловероятно, потому что люди пользуются личными аккаунтами из личных сетей. Политика запрета просто превратила наблюдаемый риск в ненаблюдаемый, а также могла вызвать у сотрудников тихую неприязнь к security-инженерам.

«Просто объяснить» не работает — и вот почему

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

• Для менеджера формулировка «данные могут утечь» значительно слабее, чем «Claude сделает задачу в 10 раз быстрее, ещё и качественнее». Поэтому нужно использовать аналогии, а не термины. Например: «Представьте, что вам нужно распечатать документ, и вы отправляете его в другую страну на печать, при этом, принимая соглашения, сами соглашаетесь с тем, что сотрудники типографии могут его прочитать, а в случае чего — передать суду по запросу». Также хороший показатель — это цифры: они понятны всем. Взлом с использованием Shadow AI может обойтись нам в очень-очень большую сумму.

• Если дать просто запрет, то в поисках простого пути решения задачи люди всё равно будут пользоваться AI-инструментами, просто вы об этом не узнаете. При этом важно предлагать альтернативу сразу, потому что это не настраивает сотрудников против вас же.

Почему «у нас корпоративный тариф» не снимает вопрос

Вы можете купить Enterprise/Business API с zero data retention, однако это всё ещё очень далеко от on-prem, и вот почему:

• ZDR может покрывать не всё. Например, Anthropic и OpenAI по умолчанию могут не включить ZDR для обычного веб-чата. Для этого нужно прописывать дополнительные условия при покупке.

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

• Суд обязывал OpenAI сохранять и передавать все логи наших переписок. В этот пул входили даже логи чатов, которые пользователи удаляли. Таким образом, ваш промт может оказаться доказательством в чужом деле, к которому ни вы, ни ваша компания не причастны.

On-prem ≠ «просто арендовать GPU в облаке»

А вот тут стоит остановиться подробнее. Я много раз слышал ошибочное мнение, что если мы арендуем GPU и поднимаем на нём свою модель, то можно больше не переживать за слив корп-инфы, однако это не так. По сути мы просто поменяли одного наблюдателя наших данных на другого. И помимо того, что данные могут утечь провайдеру, они также могут попасть к другим пользователям.

Во-первых, VRAM не всегда защищена между тенантами. CVE-2026-46229 — яркий пример: это уязвимость в драйвере AMD на Linux, суть которой в том, что новый буфер VRAM отдавался в userspace без зачистки. В результате, зная все нужные параметры, злоумышленник мог по кускам восстановить из памяти ^[11] то, что там лежало до него, включая фрагменты промтов, ключи и т. п. Провайдер обязан обеспечивать зачистку памяти на мультитенантной архитектуре, однако мы это никак не проверим.

Во-вторых, гипервизор видит всё, что видит GPU. Ваши данные в любом случае окажутся физически на хосте, и, имея доступ к гипервизору, можно получить всю вашу чувствительную информацию. А недорогой провайдер не станет запариваться с каким-то шифрованием.

Что с этим делать:

В итоге, если задача — просто не сливать всё подряд OpenAI и Anthropic, то dedicated-аренда у хорошего провайдера — отличный вариант, который значительно дешевле собственного железа. Однако если стоит задача сохранить данные с очень жёсткими требованиями, то без своей стойки тут не обойтись.

Немного практики

Ну и для того, чтобы понимать, что это всё не что-то нереальное, давайте посмотрим, а как вообще можно развернуть свою модель.

Модель

Тут важно понимать, какие именно задачи вы хотите делать и сколько готовы потратить на это из бюджета. На середину 2026 года ориентир выглядит примерно так:

Важный момент: не нужно сразу пытаться интегрировать самую крутую модель. Начните с более простой и смотрите, закрывает ли она ваши задачи. Возможно, и 32B будет достаточно для эффективной работы.

Инференс-движок: vLLM или Ollama

Здесь всё зависит от нагрузки. Не будем вдаваться в технические подробности, но, если вкратце, то для 5–10 лёгких пользователей Ollama будет достаточно: она проще в развёртывании и дальнейшей поддержке. А вот если нам нужны тяжёлые задачи для большого числа пользователей, то тут уже только vLLM. Ollama будет очень сильно просаживаться в таких сценариях, и пользователи только ощутят, что модель «безбожно» тормозит.

Gateway: SSO, аудит, единая точка входа

Развернуть модель — это только полбеды, потом нам надо как-то выдать её пользователям, давать всем ходить по одному API-ключу — не лучшая идея, для этого есть LiteLLM либо любой другой reverse-proxy gateway. В результате мы получим:

• нормальную аутентификацию через IdP, легко настроить под внутренний стандарт;

• у каждого пользователя свой ключ;

• пишет аудит-логи по каждому из пользователей.

В результате у вас получится лёгкий Docker Compose на 30–40 строк, в котором будут vLLM, LiteLLM и Open WebUI. При развёртывании не забудьте спрятать vLLM за внутренней сетью Docker, у него не должно быть прямого выхода наружу.

Окупится ли?

Тут вопрос неоднозначный: если ваши данные очень чувствительные и ценные, то по сути окупаемость моментальная, потому что слив вашей информации стоит явно дороже своей self-hosted LLM. А так принято считать, что при нагрузке в 2 млн токенов в день вы догоняете стоимость API, а дальше амортизация карты уже выгоднее.

Выводы

On-prem LLM — нужен, но не всем и не всегда. Можно поднять всё на своём железе, а в итоге нерадивый сотрудник всё равно всё сольёт во внешние сервисы, потому что у вас ещё и медленный ассистент. Придерживайтесь важного правила: «Мы не запрещаем, мы предлагаем альтернативу не хуже».

Ещё один важный момент: разделяйте, что даёт вам настоящую изоляцию, а что — мнимую. Своя модель, но в облаке, может быть недостаточно безопасным решением.

Ну и последнее: закладывайте бюджет чуть с запасом, а также готовьтесь к тому, что придётся поддерживать вашу модель. Это станет такой же регулярной статьёй расходов, как и подписка на API.

© 2026 ООО «МТ ФИНАНС»