Корпоративный GPT в закрытом контуре: от страхов к внедрению

Недавно у нас был показательный случай. Звонит директор по безопасности крупного холдинга: «Мы поймали финансового директора, который загрузил в ChatGPT нашу управленческую отчётность за год. Просто хотел понять тренды. Что делать?». А делать уже поздно – данные ушли.

И это не единичный случай. Юристы загружают конфиденциальные договора для анализа. Менеджеры по продажам генерируют КП с реальными ценами и условиями для крупных клиентов. HR-ы обсуждают персонал с указанием фамилий и зарплат. Люди не со зла – просто AI реально помогает работать быстрее, а осознание рисков приходит позже.

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

Отсюда растущий интерес к корпоративному GPT в закрытом контуре – когда языковая модель работает исключительно на вашей инфраструктуре, данные никуда не уходят, а вы полностью контролируете, что происходит с запросами сотрудников.

За последние полтора года мы в CrmAI развернули больше двадцати таких систем – от скромных пилотов на одном сервере до серьёзных кластеров на 16 GPU. Набили достаточно шишек и видели, как набивают другие. Ниже – честный разбор: когда закрытый контур действительно нужен, а когда это дорогая игрушка для успокоения службы безопасности. Покажу реальную архитектуру, логику выбора моделей и как на самом деле считается экономика. Отдельно разберём ошибки, которые регулярно ломают внедрение – некоторые из них мы совершали сами.

Когда реально нужен закрытый контур (а когда – нет)

Начну с неприятной правды: большинству компаний закрытый контур не нужен. Это дорого, сложно в поддержке и требует квалифицированной команды. Примерно половина обращений к нам заканчивается рекомендацией «используйте Azure OpenAI с private endpoint, вам хватит». Да, мы теряем проект, но сохраняем репутацию – люди потом возвращаются с другими задачами.

Если ваша компания работает с публичной информацией, а сотрудники используют AI для типовых задач вроде написания текстов или перевода – облачные решения вполне подойдут. Но есть ситуации, когда альтернативы закрытому контуру просто нет.

За время работы мы выделили семь признаков. Если вы узнаёте себя хотя бы в трёх – стоит серьёзно рассмотреть on-premise. Расскажу про каждый с примерами из практики.

Мифы о безопасности облачных решений

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

«OpenAI читает все наши запросы и использует для обучения». Это правда для бесплатного ChatGPT, но не для API. При использовании платного API данные по умолчанию не идут в обучение. Это прописано в условиях сервиса, можно дополнительно подтвердить через DPA. Мы проверяли с юристами нескольких клиентов – условия реально соблюдаются.

«Данные хранятся вечно где-то на американских серверах». У большинства провайдеров чёткие политики retention – данные удаляются через 30 дней или быстрее. Есть zero-retention режим, когда данные вообще не сохраняются после обработки запроса. Другое дело, что доказать это клиенту с параноидальной службой безопасности бывает сложно.

«Облако = полное отсутствие контроля». Существуют промежуточные решения: Azure OpenAI Service, AWS Bedrock, private endpoints. Данные остаются в вашем виртуальном облаке, не смешиваются с другими клиентами, вы контролируете геолокацию серверов. Для одного клиента мы настроили Azure OpenAI с размещением в европейском регионе и private link – данные вообще не выходят в публичный интернет.

Если ваши требования не настолько жёсткие – возможно, вам подойдёт именно такой компромиссный вариант. Он значительно дешевле полноценного on-premise и не требует собственной GPU-инфраструктуры. Мы честно говорим об этом клиентам, даже если теряем проект.

Архитектура корпоративного GPT

Одна из первых наших ошибок – думать, что корпоративный GPT это просто «поставить модель на сервер». Клиент попросил развернуть Llama на их железе. Мы развернули. Через неделю звонок: «Почему всё тормозит? Почему нет логов? Как понять, кто что спрашивал?». Пришлось переделывать с нуля.

С тех пор мы строим полноценные экосистемы. Расскажу, из чего они состоят – это поможет понять масштаб задачи и не наступить на те же грабли.

Основные компоненты системы

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

Варианты развёртывания

Выбор способа развёртывания – это всегда компромисс между контролем, сложностью и имеющимися компетенциями. Расскажу про три подхода, которые мы реально используем, с их плюсами и подводными камнями.

Bare metal (физические серверы). Максимальная производительность, полный контроль, но и максимальная головная боль. Нужно самим закупать оборудование, настраивать охлаждение (GPU серьёзно греются – один клиент чуть не сжёг серверную, когда кондиционер сломался в выходные), заботиться о резервировании. Подходит для очень крупных компаний с собственным ЦОД и командой, которая умеет это поддерживать.

Kubernetes-кластер. Наиболее распространённый вариант и наша рекомендация по умолчанию. Гибкое масштабирование, удобное управление, можно использовать как собственное оборудование, так и арендованные GPU-серверы в частном облаке. Но есть нюанс: если в команде нет людей с опытом Kubernetes, первые месяцы будут болезненными. Мы видели проекты, где внедрение буксовало именно из-за нехватки DevOps-экспертизы.

Виртуализация (VMware, Proxmox). Компромиссный вариант для компаний, где уже есть виртуальная инфраструктура и админы, которые её знают. Проще в управлении, чем Kubernetes, но может быть сложнее с пробросом GPU – не все гипервизоры одинаково хорошо это поддерживают. Хорошо работает для пилотных проектов и небольших нагрузок. Один клиент так и остался на Proxmox – им хватает, зачем усложнять.

Требования к железу

«Сколько нужно GPU?» – этот вопрос задают на каждой первой встрече. Честный ответ: зависит от модели и нагрузки. Но чтобы не быть голословным, приведу реальные цифры из наших проектов. Это не теоретические расчёты, а то, что реально работает в продакшне.

Помимо GPU, не забывайте про остальное железо – мы на этом обжигались. Быстрые NVMe-диски обязательны: модели занимают десятки гигабайт, и если загрузка идёт с медленного HDD, первый запуск после рестарта занимает минуты вместо секунд. Оперативной памяти нужно минимум в 2 раза больше, чем VRAM GPU – иначе начинаются странные падения. Сетевое соединение между нодами кластера должно быть быстрым – для больших моделей с tensor parallelism это критично.

И отдельная история – охлаждение. Одна NVIDIA H100 потребляет до 700 Вт под нагрузкой. Кластер из восьми таких карт – это 5-6 кВт только на GPU, не считая остального оборудования. Был случай: клиент решил сэкономить и поставить сервер в обычной серверной без усиленного охлаждения. Через две недели начались термальные тротлинги, производительность упала вдвое. Пришлось срочно переезжать в нормальный ЦОД.

Выбор модели для закрытого контура

Ещё год назад выбор открытых моделей был грустным – они заметно уступали ChatGPT. Сейчас ситуация изменилась кардинально. Лучшие открытые модели уже догнали GPT-3.5, а некоторые приближаются к GPT-4. Для большинства бизнес-задач этого более чем достаточно.

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

Что выбрать: практические рекомендации

Теория – это хорошо, но расскажу, что мы реально рекомендуем клиентам после десятков внедрений.

Для большинства задач начните с Qwen 2.5 или Llama 3.1 в размере 70B. Это наш дефолтный выбор – оптимальный баланс между качеством и ресурсами. На двух A100 модели работают быстро и справляются с большинством бизнес-задач. Один из клиентов – юридическая компания – использует Qwen 72B для анализа договоров. Говорят, что качество сопоставимо с ChatGPT, а иногда даже лучше понимает российскую специфику.

Если русский язык критичен и бюджет позволяет – рассмотрите GigaChat. Сбер предлагает on-premise развёртывание для крупных заказчиков. Модель отлично понимает русский, включая деловую переписку, юридический язык, разговорную речь. Плюс сертификаты для работы с персональными данными – для банков и госструктур это важно. Минус – цена и закрытость: вы зависите от одного вендора.

Для пилота с ограниченным бюджетом – Qwen 2.5 7B или Llama 3.1 8B. Можно запустить даже на игровой RTX 4090 за 150 тысяч рублей. Качество будет ниже, но для проверки концепции хватит. У нас был клиент, который начал с 8B модели на одной карте, убедился в полезности, а потом уже выбил бюджет на нормальное железо. Хороший подход.

Если нужна максимальная скорость ответа – смотрите на Mistral. Архитектура Mixture of Experts даёт ответы быстрее при том же качестве. Особенно актуально для чат-ботов и голосовых ассистентов, где каждая секунда ожидания раздражает пользователей.

Лицензионные нюансы

Здесь бывают неприятные сюрпризы. Не все «открытые» модели можно использовать без ограничений. Llama 3.1 требует согласия с условиями Meta. Qwen 72B+ имеет ограничения на коммерческое использование. Был случай: клиент развернул модель, запустил в продакшн, а потом юристы вычитали лицензию и схватились за голову. Пришлось срочно менять.

Для российских компаний отдельная тема – происхождение модели. Если вы работаете с госконтрактами, использование китайских или американских моделей может вызвать вопросы на проверках. Видели ситуацию, когда заказчик в последний момент потребовал заменить Llama на отечественное решение. В таких случаях GigaChat или YandexGPT – более безопасный выбор.

Стоимость владения: облако vs on-premise

«Сколько это будет стоить?» – второй по популярности вопрос после «сколько нужно GPU». И здесь я буду честен: универсального ответа нет. Видел проекты, где on-premise окупался за год, и видел, где облако оставалось дешевле даже через три года. Всё зависит от интенсивности использования.

Давайте разберём реальную математику на примере типового проекта.

Расчёт TCO на 3 года

Возьмём сценарий, который мы видим чаще всего: компания с 200 активными пользователями, средняя интенсивность – 20 запросов на пользователя в день, средняя длина запроса и ответа – 1000 токенов. Это примерно соответствует ситуации, когда люди активно используют AI для рабочих задач, но не злоупотребляют.

Как видите, при умеренном использовании затраты сопоставимы. Но это средняя температура по больнице. Есть нюансы, которые могут кардинально изменить картину в любую сторону.

Когда облако дешевле

Был у нас клиент – небольшая консалтинговая компания, 30 человек. Хотели on-premise «для безопасности». Посчитали вместе: при их объёмах (50-100 запросов в день на всех) облако выходило в 5 раз дешевле. Убедили их начать с Azure OpenAI, через год вернулись – довольны, о железе и не думают.

Облако выигрывает на старте проекта, когда объёмы небольшие и непредсказуемые. Для компаний без собственной IT-инфраструктуры разворачивать Kubernetes с нуля только ради GPT – нерационально. И когда нужен доступ к самым современным моделям – GPT-4o, Claude 3.5 пока недоступны для on-premise в принципе.

Когда on-premise выгоднее

Другая история: крупный ритейлер, 2000+ сотрудников активно используют AI для работы с клиентами. Когда мы посчитали их текущие расходы на OpenAI API – CFO побледнел. Переход на on-premise с Llama 70B окупился за 14 месяцев, даже с учётом всех накладных расходов.

On-premise становится выгодным при высокой интенсивности использования. Если сотрудники отправляют сотни запросов в день, счета за API быстро становятся неподъёмными. Также on-premise выигрывает в долгосрочной перспективе – через 2-3 года оборудование окупается, остаётся только стоимость эксплуатации.

Неочевидный фактор – предсказуемость. CFO любят фиксированные расходы. С on-premise вы точно знаете, сколько потратите в следующем месяце. С облаком расходы могут скакать в разы в зависимости от активности пользователей – и объяснять это бухгалтерии каждый месяц утомительно.

Скрытые расходы, о которых забывают

При расчёте TCO on-premise часто упускают несколько статей – мы сами на это попадались. GPU устаревают: через 3-4 года захочется апгрейд на новое поколение. Обучение команды: Kubernetes и ML-инфраструктура требуют специфических компетенций, и если их нет – придётся нанимать или растить. Время на отладку: первые месяцы после запуска будут «сырыми». Резервирование: для критичных систем нужен второй комплект оборудования – это ещё +50-70% к стоимости железа.

С облаком свои подводные камни: внезапные изменения тарифов (OpenAI уже несколько раз менял цены, причём не всегда в меньшую сторону), rate limits могут стать проблемой при масштабировании, зависимость от внешнего провайдера. Один клиент столкнулся с тем, что OpenAI заблокировал их аккаунт за «подозрительную активность» – оказалось, просто резкий рост использования после внутреннего анонса. Разбирались неделю.

Безопасность и комплаенс

Главная причина выбора закрытого контура – безопасность. Но вот что я усвоил на практике: просто развернуть модель на своих серверах – это 10% работы. Остальные 90% – правильно настроить контроль доступа, аудит, политики обработки данных. Иначе вы просто перенесли риски из облака к себе.

RBAC и аудит запросов

Первое, что нужно настроить – разграничение доступа. Звучит очевидно, но вы удивитесь, сколько компаний дают всем сотрудникам одинаковые права. А потом стажёр из отдела маркетинга спрашивает у корпоративного GPT про зарплаты топ-менеджмента, потому что у него есть доступ к этим данным через RAG.

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

Аудит – не менее важная часть. Все запросы и ответы должны логироваться. Был случай: сотрудник использовал корпоративный GPT для составления резюме и поиска новой работы. Само по себе не криминал, но когда он попросил AI «переформулировать мой опыт работы над проектом X так, чтобы конкурент понял мою ценность» – это уже тревожный звонок. Без логов мы бы этого не увидели.

Политики обработки персональных данных

Если система будет работать с персональными данными (а в большинстве корпоративных сценариев будет), нужно соблюдать 152-ФЗ. Ключевые моменты: данные на территории России, согласие субъектов на обработку, возможность удаления по запросу, назначенный ответственный за ПД. Звучит формально, но штрафы за нарушения стали существенными.

Практический совет из нашего опыта: внедрите маскирование PII до отправки в модель. Заменяете реальные ФИО, телефоны, номера документов на плейсхолдеры, получаете ответ, подставляете реальные данные обратно. Один из клиентов – HR-департамент крупной компании – использует этот подход для анализа резюме. Модель видит «Кандидат_001» вместо реального имени, но результат анализа полезен.

Сертификация

Для некоторых отраслей нужна формальная сертификация. ГИС – сертификат ФСТЭК. Международные компании – ISO 27001. Банки – требования ЦБ по информационной безопасности. Это не просто бумажки: при проверках реально смотрят на соответствие.

Важно понимать: сертификация – это отдельный проект. Закладывайте 6-12 месяцев и отдельный бюджет. У нас был клиент, который думал, что сертификация ФСТЭК – это «заполнить пару форм». Когда увидел реальный объём работы, пришлось переносить запуск на полгода. Если требования менее строгие – возможно, достаточно внутреннего аудита и документирования политик. Но решайте это на старте, а не когда система уже в продакшне.

Пошаговый план внедрения

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

Этап 1: Аудит требований (2-4 недели)

Первое правило: не спешить с техникой. Был случай – клиент уже купил серверы на 15 миллионов рублей, а потом выяснилось, что им нужна совсем другая конфигурация. Теперь мы начинаем с серии интервью: IT-директор, служба безопасности, представители бизнес-подразделений. Каждый видит проект по-своему, и важно свести эти видения воедино.

Что выясняем: какие задачи будет решать AI, какие данные обрабатывать (и насколько они чувствительные), сколько пользователей и какая нагрузка, что уже есть из инфраструктуры, какие интеграции нужны (CRM, 1С, внутренние системы), какие регуляторные требования. На выходе – документ с архитектурой, планом и бюджетом. Иногда после аудита мы рекомендуем не делать on-premise вообще – и это тоже ценный результат.

Этап 2: Пилот на 10-20 пользователей (4-6 недель)

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

На пилоте разворачиваем минимум: один GPU-сервер, базовый интерфейс, простейшую интеграцию. Главная цель – проверить гипотезы. Подходит ли модель для задач? Какие сценарии реально востребованы? Один клиент был уверен, что им нужен GPT для генерации маркетинговых текстов. На пилоте выяснилось, что 80% запросов – это анализ договоров. Хорошо, что узнали до масштабирования.

Этап 3: Масштабирование (8-12 недель)

После успешного пилота начинается серьёзная работа: продакшн-оборудование, отказоустойчивость, бэкапы, интеграция с корпоративными системами (SSO, CRM, 1С), полноценный интерфейс, мониторинг, алертинг, обучение пользователей, документация. Звучит как много – так и есть. Поэтому 8-12 недель.

Масштабируйте постепенно: сначала один отдел, потом другой. Мы называем это «контролируемый пожар» – если что-то сломается, пострадает ограниченное количество людей, а не вся компания. Был случай, когда при полном rollout выяснилось, что модель странно отвечает на специфические вопросы одного отдела. При постепенном развёртывании это бы поймали раньше.

Этап 4: Эксплуатация и развитие (постоянно)

Внедрение – это не финиш, а старт. После запуска начинается самое интересное: анализ использования, выявление новых сценариев, оптимизация производительности. Модели обновляются – Llama 3.2 уже вышла, скоро будет 4.0. Нужно следить за новинками и обновлять систему.

Заложите ресурсы на постоянную поддержку: минимум один DevOps/MLOps инженер на part-time или договор с подрядчиком. Система требует внимания – обновления безопасности, мониторинг, реакция на инциденты. Один клиент решил сэкономить на поддержке. Через три месяца у них упал сервер, а поднять его было некому. Простой – неделя, потери – сами считайте.

5 типичных ошибок при внедрении

Набили шишек достаточно – и своих, и насмотрелись на чужие проекты. Эти ошибки мы видим снова и снова. Расскажу с примерами, чтобы вы не повторяли.

Подводя итоги

Корпоративный GPT в закрытом контуре – это серьёзный проект. Не буду приукрашивать: это дорого, это сложно, это требует команды и постоянного внимания. Но для компаний, где безопасность данных – не опция, а необходимость, это единственный способ получить возможности современных языковых моделей без компромиссов.

За полтора года работы над такими проектами мы убедились: успех зависит не от выбора самой крутой модели или самого дорогого железа. Он зависит от честного анализа потребностей, правильной архитектуры и готовности учиться на ошибках – желательно чужих.

Что я хочу, чтобы вы запомнили из этой статьи:

• Закрытый контур нужен не всем. Половине наших клиентов мы рекомендуем облачные или гибридные решения – и это честная рекомендация, а не попытка продать меньше
• Существуют промежуточные варианты. Azure OpenAI, AWS Bedrock, private endpoints – это не компромисс качества, а разумный баланс безопасности и стоимости
• Выбор модели – это не «какая круче», а «какая подходит». Qwen 72B для большинства задач работает не хуже GPT-4, а стоит в разы дешевле
• Экономика зависит от интенсивности использования. Считайте честно, с учётом скрытых расходов – и для облака, и для on-premise
• Безопасность – это не только изоляция. RBAC, аудит, политики обработки данных – без этого вы просто перенесли риски к себе
• Начинайте с пилота. Ошибки на 20 пользователях – это урок. Ошибки на 2000 – это катастрофа

Если вы дочитали до сюда – значит, тема для вас актуальна. Мы готовы помочь на любом этапе: от первичного аудита («а нужен ли нам вообще on-premise?») до полного развёртывания и сопровождения. Не стесняйтесь задавать вопросы – даже если в итоге решите делать сами или с другим подрядчиком, честный разговор всегда полезен.

Полезные материалы по теме

Статьи, которые помогут глубже разобраться в теме:

• Как выбрать LLM-модель для чат-бота – сравнение GPT, Claude, Llama и других
• RAG: как научить бота отвечать по документам – архитектура и практика
• Безопасность AI-чат-ботов – защита данных и комплаенс
• AI-ассистент для автоматизации рутины – практические сценарии использования