Компании хотят пользоваться нейросетями, но служба безопасности против: договоры, переписка с клиентами, кадровые документы и внутренние цифры не должны уходить во внешние сервисы. Отсюда частый запрос, с которым к нам приходят: можно ли поставить нейросеть у себя, чтобы данные не покидали компанию.
Можно. Локальная нейросеть для компании — это языковая модель, которая работает на ваших серверах или в выделенном контуре, а не у внешнего провайдера. Разберём, когда она действительно нужна, что важно знать про 152-ФЗ, из чего состоит такое решение и как запустить его без лишних затрат.
Что такое локальная нейросеть и чем она отличается от облачной
Облачная нейросеть — это сервис провайдера. Вы отправляете запрос через интернет, модель обрабатывает его на чужих серверах и возвращает ответ. Быстро и удобно, но текст запроса вместе с фрагментами документов оказывается у провайдера.
Локальная модель устроена иначе. Вы берёте открытую языковую модель, разворачиваете её на своём сервере или в изолированном сегменте облака и подключаете к своим системам. Запросы обрабатываются внутри компании, а данные не покидают ваш контур.
Это и есть нейросеть без передачи данных третьим лицам в прямом смысле: вы сами решаете, где хранятся запросы, кто видит журналы и сколько они живут.
| Облачная модель | Локальная модель | |
|---|---|---|
| Где обрабатываются данные | У провайдера | На ваших серверах или в выделенном контуре |
| Старт | Быстрый, нужен только доступ к API | Нужны сервер, развёртывание и настройка |
| Качество на сложных задачах | Обычно выше | Зависит от модели и задачи, проверяется на примерах |
| Контроль над данными и журналами | По договору с провайдером | Полный, но и ответственность ваша |
| Поддержка | На стороне провайдера | Своя ИТ-служба или подрядчик |
Когда компании нужна своя нейросеть
Корпоративная нейросеть на своих серверах оправдана не всегда. Если задача — писать тексты для соцсетей или переводить публичные материалы, облачного сервиса обычно достаточно. Своя модель нужна, когда в запросы попадает то, что нельзя отдавать наружу.
- Персональные данные. Анкеты клиентов, договоры с физлицами, кадровые документы, обращения в поддержку с ФИО и телефонами.
- Коммерческая тайна. Цены закупки, условия договоров, финансовая отчётность, технологические документы.
- Требования службы безопасности. Внутренняя политика запрещает отправлять данные во внешние сервисы, особенно иностранные.
- Закрытый контур. Часть систем не имеет выхода в интернет, и облачная модель туда просто не дотянется.
- Предсказуемость. Модель не меняется без вашего решения, не упирается в лимиты провайдера и не пропадает из-за смены его условий.
Типичные задачи для локальной LLM: ответы сотрудникам по внутренним документам, разбор входящих писем и заявок, извлечение данных из договоров и счетов, черновики ответов клиентам, поиск по архиву.
152-ФЗ и нейросети: что важно понимать
Сразу оговоримся: это не юридическая консультация. Мы разработчики, и схему обработки данных в каждом проекте согласуем с юристом и службой безопасности заказчика. Но несколько общеизвестных вещей стоит знать до начала проекта.
Федеральный закон № 152-ФЗ «О персональных данных» регулирует любые действия с персональными данными: сбор, хранение, использование, передачу. Если в запрос к нейросети попадает ФИО, телефон или паспортные данные, это тоже обработка персональных данных, и на неё распространяются требования закона.
- Цель и основание. Обработка должна иметь законную цель и правовое основание, например согласие человека или исполнение договора с ним.
- Передача третьим лицам. Отправка данных во внешний сервис — это передача другому лицу. Для неё нужны основания и, как правило, договор с поручением обработки.
- Трансграничная передача. Если сервер провайдера за рубежом, возникают дополнительные требования, включая уведомление Роскомнадзора.
- Локализация. При сборе персональных данных граждан России их запись и хранение должны вестись с использованием баз данных на территории страны.
- Меры защиты. Оператор обязан принимать организационные и технические меры: разграничение доступа, учёт, защиту от утечек.
Локальная модель снимает часть вопросов: данные не уходят провайдеру и не пересекают границу. Но она не освобождает от остального.
Локальная модель решает вопрос, куда уходят данные, но не отменяет вопрос, кто и зачем их обрабатывает.
Где разместить модель: свой сервер, российское облако или гибрид
«Локальная» не обязательно значит «в серверной офиса». Есть несколько вариантов, и выбор зависит от требований безопасности, нагрузки и того, есть ли у компании своя инфраструктура.
- Свой сервер. Максимальный контроль, но покупка оборудования с графическими ускорителями, размещение, охлаждение и обслуживание ложатся на вас.
- Выделенные серверы в российском облаке или дата-центре. Оборудование арендуется, данные остаются в России, модель работает в изолированном сегменте. Удобно для пилота и для компаний без своей серверной.
- Гибрид. Чувствительные задачи обрабатывает локальная модель, а обезличенные или публичные — облачная. Персональные данные можно маскировать до отправки во внешний сервис.
Мы обычно советуем начинать с аренды: так становится понятно, какая модель и какая мощность реально нужны под вашу нагрузку. Покупать железо до этого — ставка вслепую.
Как выбрать модель
Открытых языковых моделей много, и новые выходят постоянно. Поэтому мы не называем «лучшую»: лучшая модель та, что справляется с вашими задачами на вашем оборудовании. Выбирают её по нескольким критериям.
- Качество на русском языке и на вашей терминологии, а не в общих рейтингах.
- Лицензия: разрешено ли коммерческое использование и на каких условиях.
- Размер модели и требования к оборудованию: более крупная модель обычно умнее, но дороже в эксплуатации и медленнее.
- Длина контекста: сколько текста модель может прочитать за раз, это важно для договоров и длинных регламентов.
- Скорость ответа при вашей нагрузке: сколько сотрудников будут пользоваться одновременно.
Проверка простая по смыслу: собираем набор реальных примеров с правильными ответами и прогоняем через несколько моделей. Сравниваем точность, скорость и стабильность. Решение принимается по цифрам на ваших данных, а не по чужим тестам.
Что нужно, чтобы развернуть LLM на своём сервере
Сама модель — только часть решения. Чтобы ею могли пользоваться сотрудники и системы компании, вокруг неё строится обычный веб-сервис со всеми привычными требованиями.
- Оборудование. Сервер с графическими ускорителями под выбранную модель и нагрузку.
- Сервер инференса. Программа, которая загружает модель, принимает запросы и распределяет нагрузку.
- API и интеграции. Доступ к модели из CRM, портала, почты, мессенджера, 1С и других систем.
- Поиск по документам. Если модель отвечает по внутренним данным, нужен индекс документов и проверка прав доступа до того, как фрагменты попадут к модели.
- Авторизация и права. Вход через корпоративные учётные записи, роли, ограничения по разделам.
- Журналы и мониторинг. Кто и что спрашивал, сколько хранятся запросы, как сервис справляется с нагрузкой.
- Обновления и проверка качества. Набор эталонных вопросов, который прогоняется после смены модели или настроек.
По сути это разработка веб-сервиса с моделью внутри. Поэтому такие проекты мы ведём так же, как другие сервисы: с разбором процессов, архитектурой, интеграциями и поддержкой после запуска.
Как проходит внедрение
- Выбор задачи. Одна понятная задача с измеримым результатом: ответы по регламентам, разбор заявок, извлечение данных из документов.
- Разбор данных с юристом и безопасностью. Какие данные попадут в модель, на каком основании они обрабатываются, кто будет иметь доступ, сколько хранить журналы.
- Выбор размещения и моделей-кандидатов. Аренда или свой сервер, две-три модели для сравнения.
- Эталонный набор и сравнение. Реальные примеры с правильными ответами, замеры качества и скорости.
- Пилот. Сервис с интеграциями и правами доступа для небольшой группы сотрудников, сбор обратной связи.
- Масштабирование и эксплуатация. Подключение других отделов, мониторинг, регламент обновлений.
Такой порядок позволяет понять ценность до крупных вложений. Если пилот показал, что задача решается, решение о покупке оборудования принимается на основе замеров.
Частые ошибки
- Начать с закупки железа. Без пилота непонятно, какая модель нужна, и оборудование оказывается то избыточным, то недостаточным.
- Ждать качества облачных флагманов. Открытая модель может уступать на сложных задачах. Ожидания стоит сверять с замерами, а не с впечатлениями от публичных чатов.
- Забыть про права доступа. Модель, которая видит все документы компании и отвечает любому сотруднику, создаёт ту самую утечку, от которой хотели защититься.
- Хранить все запросы бессрочно. Журналы с персональными данными тоже требуют защиты и понятных сроков хранения.
- Не назначить ответственного. Без владельца сервис перестают обновлять, а качество незаметно падает.
Мы — IT-агентство Sphere из Москвы: разрабатываем сайты, приложения и веб-сервисы и внедряем ИИ для компаний в Москве и по России. Если вы прикидываете, нужна ли вам своя нейросеть, начните с одной задачи и честного сравнения моделей на ваших данных. Примеры веб-сервисов и интеграций есть в разделе наших проектов по разработке.
Частые вопросы
Если нейросеть стоит на нашем сервере, 152-ФЗ можно не учитывать?
Нет. Закон регулирует обработку персональных данных, а не место, где стоит модель. Локальная нейросеть убирает передачу данных внешнему провайдеру, но цели обработки, правовые основания, доступы и меры защиты всё равно нужно определить и описать. Конкретную схему стоит согласовать с юристом и службой безопасности.
Локальная модель будет отвечать так же хорошо, как облачная?
Зависит от задачи. На узких задачах вроде классификации обращений, извлечения полей из документов или ответов по базе знаний открытые модели часто справляются. На сложных рассуждениях и длинных текстах разница бывает заметной. Поэтому модель выбирают по результатам проверки на ваших примерах, а не по рейтингам.
Можно ли начать без покупки серверов?
Можно. Пилот часто запускают на арендованных мощностях в российском облаке или у провайдера с выделенными серверами. Так видно, какая модель и какое оборудование реально нужны, и покупка железа становится обоснованным решением, а не ставкой вслепую.
Кто будет поддерживать корпоративную нейросеть после запуска?
Нужен ответственный за сервер и сервис: обновления, мониторинг, резервные копии, разбор ошибок, проверка качества после смены модели. Это может быть своя ИТ-служба, подрядчик или их связка. Решить вопрос поддержки стоит до запуска, а не после первого сбоя.
