Меня зовут Жемал Хамидун, я CPO AlpinaGPT и Head of AI в Alpina Digital, веду тг-канал «Готовим ИИшницу». С 2023 года мы внедряем ИИ в собственное производство книг и в компании-клиенты — от издательств до фармы и ритейла. Эта статья — концентрат того, что мы поняли про безопасность корпоративного ИИ, пройдя путь от первых пилотов до промышленной эксплуатации в контуре заказчика.
По данным исследования McKinsey, 88% компаний используют ИИ, но только 1% достиг зрелости. Между «попробовали ChatGPT» и «работающей корпоративной системой» лежит пропасть, и чаще всего она связана с безопасностью данных и соблюдением 152-ФЗ. Что делать, если служба безопасности заблокировала любые внешние LLM? Дальше — три архитектурных подхода, которые работают в российских корпорациях, и опыт Alpina Digital, прошедшей через все три за два года.
Картина типичная: компания запускает пилот, два-три отдела пробуют LLM, появляются первые впечатляющие демки — а потом всё застревает. По исследованию McKinsey 88% компаний уже используют ИИ хотя бы в одном процессе, и только 1% достиг зрелости — стадии, на которой нейросети работают как часть промышленного контура, а не как игрушка в руках энтузиастов. То есть между «попробовали» и «внедрили» отваливаются 87 компаний из 88.
Главный барьер на этом пути — не качество моделей и не цена. Качество сегодня более чем достаточное для большинства задач. Цена упала настолько, что один сотрудник со всеми передовыми нейросетями обходится дешевле, чем подписка на одну зарубежную модель. Барьер — информационная безопасность и соответствие законодательству: куда уходят данные сотрудника, как обеспечить 152-ФЗ, что делать с коммерческой тайной, как объяснить службе безопасности, что внешний контур безопасен.
Когда мы выходили на рынок с AlpinaGPT, думали, что главным будет вопрос «какая модель лучше». Оказалось, что главный вопрос — «как сделать так, чтобы наш CISO разрешил это запустить». Именно с него и стоит начинать любой проект внедрения корпоративного ИИ. На старте полезно ответить себе:
Чтобы говорить о безопасности предметно, надо разобраться, как технически устроен доступ к моделям OpenAI, Anthropic или Google. Большая часть страхов и мифов рождается из того, что внутри компании путают два разных способа взаимодействия с LLM: через пользовательский интерфейс (приложение ChatGPT, Claude.ai) и через API-ключ. Это разные продукты с разными правилами обработки данных.
Самая точная аналогия такая. За закрытой дверью сидит Эйнштейн — очень умная модель. Попасть к нему можно только с ключом. У провайдера ИИ таких Эйнштейнов много, и стоят они за разными дверями. У нас как у компании есть API-ключ: мы его купили и теперь можем открыть дверь, задать Эйнштейну вопрос и получить ответ. Но есть нюанс — это Эйнштейн с деменцией. Мозг гениальный, памяти нет. Он отвечает на запрос, забывает его и идёт дальше. Запрос пользователя не остаётся «у него в голове», не используется для дообучения, не попадает в общее векторное пространство.
Так работает API-доступ: он регулируется публичными контрактами провайдеров и не дообучает модель на запросах. А вот когда сотрудник ставит приложение ChatGPT на ноутбук и работает там лично, модель в этом интерфейсе дообучается на пользовательских данных, формирует локальную память, и если кто-то взломает аккаунт, получит доступ ко всем перепискам, файлам и фото, которые сотрудник туда отправлял. Большая часть страшилок про «утечки в ChatGPT» — именно про этот сценарий, а не про API.
Отсюда первый практический вывод. Запретить сотрудникам личный ChatGPT — правильно, но недостаточно. Если взамен ничего не дать, они продолжат пользоваться им скрытно, потому что задачи никуда не делись. Корпоративная архитектура должна предложить альтернативу: те же мозги, но через контролируемый канал.
Первый подход — самый быстрый в инсталляции. Компания получает доступ к зарубежным моделям (GPT, Claude, Gemini) через корпоративный шлюз с API-ключами вместо личных подписок. Запросы маршрутизируются через хабы в дружественных юрисдикциях, к провайдеру идёт обезличенный API-трафик без привязки к сотруднику, история чатов остаётся в РФ на серверах сервиса, дообучения модели на корпоративных данных не происходит. Юридически и технически это совершенно другая история, чем личный аккаунт ChatGPT, хотя на первый взгляд кажется тем же самым.
Подход подходит компаниям, для которых критично качество ответов, но не критична физическая локализация модели. Это типично для редакций, маркетинга, аналитики, R&D, продуктовых команд — везде, где работают с публичной информацией, открытыми данными, концепциями и идеями, а не с персональными данными граждан или гостайной. Условия применимости: внутренняя политика допускает обработку этого класса данных за рубежом, служба безопасности готова провести аудит и подписать архитектурное решение.
Когда подход не подойдёт: банки и страховые с массовыми персональными данными, госкомпании, оборонка, разработчики критической инфраструктуры. Им нужны другие два варианта.
Если коротко сравнить личный и корпоративный доступ к одной и той же модели: при личном ChatGPT/Claude модель дообучается на запросах, история лежит в аккаунте провайдера, видимость для SOC/DLP нулевая, доступ к чатам только у сотрудника, контроля ролей нет, соответствие 152-ФЗ не предусмотрено. При корпоративном шлюзе через API дообучения на запросах нет (по контракту провайдера), история хранится в контуре сервиса в РФ, видимость для SOC/DLP полная (логи, аудит), доступ к чатам — по ролям плюс админ компании, есть RBAC, а соответствие 152-ФЗ достижимо при правильной настройке.
Второй подход — полная локализация. Модели разворачиваются на серверах компании, данные никогда не покидают периметр. Здесь два варианта: российские коммерческие модели (YandexGPT, GigaChat) или open-source модели на собственных GPU (Llama от Meta, Mistral, Qwen от Alibaba, DeepSeek). Юридически чисто, под 152-ФЗ закрывается без оговорок, аудит службы безопасности проходит без вопросов.
Цена подхода — компромисс по качеству. Российские модели активно догоняют лидеров, но по открытым бенчмаркам пока отстают от GPT и Claude на сложных задачах рассуждения, генерации кода и работы с длинным контекстом. Open-source модели приближаются к лидерам, но требуют серьёзной инфраструктуры: для нормальной работы 70B-моделей нужны GPU класса A100/H100 или несколько RTX 4090, профильная команда MLOps, мониторинг, обновления.
Когда оправдан этот путь: обработка чувствительных данных, которые в принципе не могут покидать контур — медицинских записей, финансовых операций, конфиденциальной переписки, исходных текстов под NDA. А также компании, где служба безопасности категорически не принимает архитектуру с внешним API в любом виде. Реальное ограничение — стоимость владения: одни только GPU стоят миллионы, плюс зарплаты команды, плюс электричество и охлаждение.
Если разложить TCO и качество по классам моделей: GPT/Claude через API — топ-уровень качества при низкой стоимости (только токены), соответствие 152-ФЗ — через корпоративный шлюз. YandexGPT/GigaChat — среднее качество, средняя стоимость (лицензии), полное соответствие 152-ФЗ. Open-source 70B+ on-prem — высокое качество, очень высокая стоимость (GPU, MLOps), полное соответствие. Open-source 7–13B on-prem — среднее качество, средняя стоимость (одна GPU), полное соответствие.
Третий подход вырастает из понимания, что у разных задач разная чувствительность к данным. Сгенерировать иллюстрацию для презентации — никаких конфиденциальных данных, нужно максимальное качество, идеально подходит топовая зарубежная модель через API. Обработать рукопись автора, которая ещё не вышла, — это коммерческая тайна, нужна локальная модель в контуре. Дальше: суммировать публичный отчёт о продажах — можно через API, суммировать клиентскую базу с персональными данными — только on-premise.
Гибридная архитектура выглядит так: один интерфейс для пользователя, под капотом — роутер запросов, который по политике компании отправляет запрос либо во внешний API, либо в локальную on-premise модель, либо блокирует его до решения сотрудника. Перед самой моделью стоит слой премодерации: агент, проверяющий запрос на конфиденциальность. Если в тексте найдены признаки чувствительных данных (имена, номера счетов, выгрузка из CRM), запрос автоматически уходит на локальную модель или возвращается пользователю с предупреждением.
К такой архитектуре мы шли два года и собрали её в продукт, чтобы не пересобирать заново у каждого клиента. AlpinaGPT — это и есть та платформа: один интерфейс для сотрудников, под капотом маршрутизация запросов между внешним API и локальной моделью по политике компании, премодерация перед отправкой в модель, DLP-интеграция, ролевой доступ, чаты в контуре заказчика. Разворачивается в облаке для команд, где допустим внешний API, или on-premise — для зрелых требований безопасности. На сегодня через эту архитектуру прошли 40+ корпоративных внедрений в фарме, ритейле, финтехе и медиа.
У гибрида есть честный минус — он сложнее в проектировании. Нужно с самого начала классифицировать данные, описать политики маршрутизации, согласовать их со службой безопасности, выбрать локальную модель под нагрузку, обеспечить SLA на оба слоя. Это не быстрый MVP «за две недели», это полноценный архитектурный проект на 2–4 месяца. Но в обмен компания получает решение, где работают оба подхода, которые поодиночке не закрывают задачу: качество топовых моделей там, где можно, и локализация там, где обязательно.
Когда мы помогаем компаниям внедрять ИИ, мы видим типичную ошибку: фокус только на технологическом стеке. Развернули свою сборку — и думают, что задача решена. На практике половина успеха — это организационная подготовка, и без неё технология не работает, как бы хорошо она ни была спроектирована.
Политика AI-внедрения. Формализованный документ: какие классы данных можно обрабатывать в ИИ, какие нельзя, что считается инцидентом, как реагировать на утечку. Без политики каждый сотрудник решает сам, и через полгода у компании накапливается теневое использование ИИ, которое невозможно проконтролировать.
Роль Chief AI Officer. В крупных компаниях появляется отдельная должность — специалист, отвечающий за внедрение нейросетей и развитие AI-стратегии. Важно: это не айтишник в чистом виде. Большая часть работы — менеджмент изменений, обучение, борьба со страхами сотрудников, выстраивание процессов. Технология здесь инструмент, а не самоцель.
Классификация данных и обучение. До запуска платформы каждый класс данных должен быть промаркирован: «можно отправлять в публичные модели», «можно отправлять только в локальные», «нельзя обрабатывать в ИИ вообще». Все сотрудники проходят обучение по корпоративному стандарту работы с ИИ — иначе любая архитектура утечёт через самое слабое звено. В нашем опыте курс на 4–6 часов на сотрудника окупается за первый же квартал за счёт качества запросов и снижения инцидентов.
Технический слой. Логирование всех запросов, доступ по ролям, DLP-интеграция, шифрование чатов, premoderation-агент перед моделями, регулярный аудит использования. Без логирования невозможно расследовать инциденты. Без RBAC любой стажёр получает доступ к самой дорогой модели и съедает токены. Без премодерации сотрудник может случайно отправить персональные данные во внешний API и формально нарушить 152-ФЗ. Минимальный чек-лист готовности:
Все эти разговоры об архитектуре имеют смысл только при одном условии — если в финале есть измеримый результат. Расскажу про наш собственный кейс, потому что про чужие могу говорить только в общих чертах под NDA.
Ядро бизнеса Alpina Digital — производство книг. Цикл от покупки прав до выхода тиража традиционно занимал около 9 месяцев. Это инвестиционный процесс: деньги вложены, книга ещё не приносит выручку, оборачиваемость капитала медленная. Когда в 2023 году пошёл бум LLM, мы запустили внутренние эксперименты: где в этом цикле ИИ может ускорить работу без потери качества — редактура, корректура, аннотации, перевод, маркетинговые материалы, оформление.
За два года мы прошли тот же путь, который сейчас описываем компаниям. Сначала был хаос с личными подписками. Потом — корпоративный шлюз с API. Потом добавили локальную модель для чувствительных рукописей под NDA. Финальная архитектура — гибрид: AlpinaGPT как единый интерфейс, внешние API для генерации иллюстраций, маркетинговых текстов и переводов, локальная модель — для работы с неопубликованными авторскими текстами.
Результат: цикл производства книги — с 9 месяцев до 2 месяцев. Это ускорение в 4,5 раза при сохранении качества. Оборачиваемость капитала выросла соответственно, потому что каждая книга начинает возвращать вложения значительно раньше. Это не маркетинговая цифра — это операционный показатель, который мы видим в собственной P&L.
Экономика. Использование собственной платформы вместо разрозненных подписок дало нам экономию в 8 раз. Раньше отдельные команды покупали 120-долларовые подписки на ChatGPT, Claude, Midjourney — в сумме на всю компанию выходило около 800 тысяч рублей в месяц. Через корпоративный шлюз с API-ключами по себестоимости мы тратим около 100 тысяч рублей в месяц на токены. И при этом получаем доступ ко всем передовым моделям сразу, а не к одной по выбору каждой команды.
Срок окупаемости при правильной архитектуре — около 6 месяцев для типичной корпорации от 100 сотрудников. И это даже без учёта ускорения core-процессов, только на экономии разрозненных подписок и устранении теневого использования.
Пять выводов, которые я бы вынес из всего этого:
Если вы сейчас на стадии «пилоты есть, промышленной эксплуатации нет» — самый частый блокер не в технологии, а в архитектурном решении по безопасности.
Это адаптированное изложение для архива публикаций Жемала Хамидуна. Полная версия статьи со всеми деталями — на Хабре: читать оригинал →