Безопасное внедрение ИИ в корпорации: 3 архитектурных подхода и опыт Alpina Digital

от автора

88% компаний используют ИИ, но только 1% достиг зрелости. Главный барьер — не технология, а безопасность данных. Что мы делали два года и почему пришли к гибридной архитектуре.

Жемал Хамидун, Head of AI Alpina Digital, CPO AlpinaGPT, автор тг-канала «Готовим ИИшницу».

По данным исследования McKinsey, 88% компаний используют ИИ — но только 1% достиг зрелости. Между «попробовали ChatGPT» и «работающей корпоративной системой» лежит пропасть, и чаще всего она связана с вопросами безопасности данных и соблюдения 152-ФЗ. Что делать, если служба безопасности заблокировала любые внешние LLM. В этой статье — три архитектурных подхода, которые работают в российских корпорациях, и опыт Alpina Digital, прошедшей через все три за два года.

Меня зовут Жемал Хамидун, я CPO AlpinaGPT и Head of AI Alpina Digital. С 2023 года мы внедряем ИИ в собственное производство книг и в компании-клиенты — от издательств до фармы и ритейла. Эта статья — концентрат того, что мы поняли о безопасности корпоративного ИИ, когда сами прошли путь от первых пилотов до промышленной эксплуатации в контуре заказчика.

Почему большинство  ИИ-пилотов не доходят до промышленной эксплуатации

Картина типичная: компания запускает пилот, два-три отдела пробуют LLM, появляются первые впечатляющие демки — а потом всё застревает. По исследованию McKinsey 88% компаний уже используют ИИ хотя бы в одном процессе, и только 1% достиг зрелости — стадии, на которой нейросети работают как часть промышленного контура, а не как игрушка в руках энтузиастов. Это значит, что между «попробовали» и «внедрили» отваливаются 87 компаний из 88.

Главный барьер на этом пути — не качество моделей и не цена. Качество моделей сегодня более чем достаточно для большинства задач. Цена снизилась настолько, что один сотрудник со всеми передовыми нейросетями обходится дешевле подписки на одну зарубежную модель. Барьер — информационная безопасность и соответствие законодательству: куда уходят данные сотрудника, как обеспечить 152-ФЗ, что делать с коммерческой тайной, как объяснить службе безопасности, что внешний контур безопасен.

Когда мы выходили на рынок с AlpinaGPT, мы думали, что главный вопрос будет «какая модель лучше». Оказалось, что главный вопрос — «как сделать так, чтобы наш CISO разрешил это запустить». И именно с него стоит начинать любой проект внедрения корпоративного ИИ.

  • Куда физически уходят запросы пользователей

  • Кто и как может получить доступ к этим данным

  • Дообучается ли модель на корпоративных запросах

  • Где хранятся истории чатов и кто их администрирует

  • Как обеспечивается соответствие 152-ФЗ и внутренним политикам

  • Что происходит при утечке учётной записи сотрудника

«Эйнштейн с деменцией»: как на самом деле работает доступ к зарубежной LLM

Чтобы дальше говорить о безопасности предметно, нужно разобраться, как технически устроен доступ к моделям OpenAI, Anthropic или Google. Бо́льшая часть страхов и мифов здесь основана на том, что внутри компании смешивают два совершенно разных способа взаимодействия с LLM: через пользовательский интерфейс (приложение ChatGPT, Claude.ai) и через API-ключ. Это разные продукты с разными правилами обработки данных.

Самая точная аналогия выглядит так. За закрытой дверью сидит Эйнштейн — очень умная модель. К нему можно попасть только с ключом. У провайдера ИИ этих Эйнштейнов много, и они стоят за разными дверями. У нас, как у компании, есть API-ключ: мы его купили, и теперь можем открыть дверь, задать Эйнштейну вопрос и получить ответ. Но есть нюанс: это Эйнштейн с деменцией. Мозг гениальный, памяти нет. Он отвечает на запрос, забывает его и идёт дальше. Запрос пользователя не остаётся «у него в голове», не используется для дообучения, не попадает в общее векторное пространство.

Так работает API-доступ — он регулируется публичными контрактами провайдеров и не дообучает модель на запросах. А вот когда сотрудник скачивает приложение ChatGPT на свой ноутбук и работает там лично — модель в этом интерфейсе дообучается на пользовательских данных, формирует локальную память, и если кто-то ломанёт его аккаунт, получит доступ ко всем перепискам, файлам и фото, которые сотрудник туда отправил. Большая часть страшилок про «утечки в ChatGPT» — это про этот сценарий, а не про API.

Из этой простой аналогии вытекает первый практический вывод. Запретить сотрудникам пользоваться личным ChatGPT — это правильно, но недостаточно. Если вместо этого ничего не дать, они продолжат пользоваться им скрытно, потому что задачи никуда не делись. Корпоративная архитектура должна предложить альтернативу: те же мозги, но через контролируемый канал.

Подход 1: зарубежные модели через корпоративный API-шлюз

Первый архитектурный подход — самый быстрый в инсталляции. Компания получает доступ к зарубежным моделям (GPT, Claude, Gemini) через корпоративный шлюз с API-ключами вместо личных подписок. Запросы маршрутизируются через хабы в дружественных юрисдикциях, к провайдеру идёт обезличенный API-трафик без привязки к сотруднику, история чатов остаётся в РФ на серверах сервиса, дообучения модели на корпоративных данных не происходит. Юридически и технически — это совершенно другая история, чем личный аккаунт ChatGPT, хотя на первый взгляд кажется тем же самым.

Подход подходит компаниям, для которых критично качество ответов, но не критична физическая локализация модели. Это типично для редакций, маркетинга, аналитики, R&D, продуктовых команд — везде, где работают с публичной информацией, открытыми данными, концепциями и идеями, а не с персональными данными граждан или государственной тайной. Условия применимости: внутренняя политика компании допускает обработку этого класса данных за рубежом, служба безопасности готова провести аудит и подписать архитектурное решение.

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

Параметр

Личный ChatGPT/Claude

Корпоративный шлюз через API

Дообучение на запросах

Да

Нет (по контракту провайдера)

Где хранится история

В аккаунте провайдера

В контуре сервиса в РФ

Видимость для SOC/DLP

Нулевая

Полная (логи, аудит)

Доступ к чатам сотрудника

Только у сотрудника

По ролям + админ компании

Контроль ролей и доступов

Нет

Есть (RBAC)

Соответствие 152-ФЗ

Не предусмотрено

Достижимо при правильной настройке

Сравнение личного и корпоративного доступа к одной и той же модели

Подход 2: российские модели и open-source on-premise

Второй подход — полная локализация. Модели разворачиваются на серверах компании, данные никогда не покидают периметр. Здесь два варианта: российские коммерческие модели (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 стоят миллионы, плюс зарплаты команды, плюс электричество и охлаждение.

Тип модели

Качество

Стоимость владения

Соответствие 152-ФЗ

GPT / Claude (через API)

Топ-уровень

Низкая (только токены)

Через корпоративный шлюз

YandexGPT / GigaChat

Средний

Средняя (лицензии)

Полное

Open-source 70B+ on-prem

Высокий

Очень высокая (GPU, MLOps)

Полное

Open-source 7-13B on-prem

Средний

Средняя (одна GPU)

Полное

TCO и качество для трёх классов моделей

Подход 3: гибридная архитектура — то, что в итоге выбрали мы

Третий подход возникает из понимания, что разные задачи имеют разную чувствительность к данным. Сгенерировать иллюстрацию для презентации — никаких конфиденциальных данных, нужно максимальное качество, идеально подходит топовая зарубежная модель через API. Обработать рукопись автора, которая ещё не вышла в свет, — это коммерческая тайна, нужна локальная модель в контуре. Дальше: суммировать публичный отчёт о продажах — можно через API, суммировать клиентскую базу с персональными данными — только on-premise.

Гибридная архитектура выглядит так: один интерфейс для пользователя, под капотом — роутер запросов, который на основе политики компании отправляет запрос либо во внешний API, либо в локальную on-premise модель, либо блокирует его до решения сотрудника. Перед самой моделью стоит слой премодерации: агент, проверяющий запрос на конфиденциальность. Если в тексте найдены признаки чувствительных данных (имена, номера счетов, выгрузка из CRM), запрос автоматически перенаправляется на локальную модель или возвращается пользователю с предупреждением.

К такой архитектуре мы шли два года и собрали её в продукт, чтобы не пересобирать заново у каждого клиента. AlpinaGPT — это и есть та платформа: один интерфейс для сотрудников, под капотом маршрутизация запросов между внешним API и локальной моделью по политике компании, премодерация перед отправкой в модель, DLP-интеграция, ролевой доступ, чаты в контуре заказчика. Разворачивается в облаке для команд, где допустим внешний API, или on-premise — для зрелых требований безопасности. На сегодня через эту архитектуру прошли 40+ корпоративных внедрений в фарме, ритейле, финтехе и медиа.

У гибрида есть честный минус — он сложнее в проектировании. Нужно с самого начала классифицировать данные, описать политики маршрутизации, согласовать их со службой безопасности, выбрать локальную модель под нагрузку, обеспечить SLA на оба слоя. Это не быстрый MVP «за две недели», это полноценный архитектурный проект на 2–4 месяца. Но в обмен компания получает решение, в котором ни один из подходов 1 или 2 не работает отдельно: качество топовых моделей там, где можно, и локализация там, где обязательно.

Что нужно при любом подходе: организационные и технические меры

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

Политика AI-внедрения. Это формализованный документ: какие классы данных можно обрабатывать в ИИ, какие — нельзя, что считается инцидентом, как реагировать на утечку. Без политики каждый сотрудник принимает решение сам, и через полгода у компании накапливается теневое использование ИИ, которое невозможно проконтролировать.

Роль Chief AI Officer. В крупных компаниях появляется отдельная должность — специалист, который отвечает за внедрение нейросетей и развитие AI-стратегии. Важно: это не айтишник в чистом виде. Большая часть работы — это менеджмент изменений, обучение, борьба со страхами сотрудников, выстраивание процессов. Технология здесь — инструмент, а не самоцель.

Классификация данных и обучение. До запуска платформы каждый класс данных должен быть промаркирован: «можно отправлять в публичные модели», «можно отправлять только в локальные», «нельзя обрабатывать в ИИ вообще». Все сотрудники проходят обучение по корпоративному стандарту работы с ИИ — иначе любая архитектура утечёт через самое слабое звено. В нашем опыте курс на 4–6 часов на сотрудника окупается за первый же квартал за счёт качества запросов и снижения инцидентов.

Технический слой. Логирование всех запросов, доступ по ролям, DLP-интеграция, шифрование чатов, premoderation-агент перед моделями, регулярный аудит использования. Без логирования невозможно расследовать инциденты. Без RBAC любой стажёр получает доступ к самой дорогой модели и съедает токены. Без премодерации сотрудник может случайно отправить персональные данные в внешний API — и формально нарушить 152-ФЗ.

  • Утверждена политика AI-внедрения с классами данных и регламентами реагирования

  • Назначен ответственный за AI-стратегию (CAIO или эквивалент)

  • Проведена классификация данных по уровням чувствительности

  • Все сотрудники прошли обязательное обучение работе с ИИ

  • Включены логирование, RBAC, шифрование чатов

  • DLP-система интегрирована с корпоративным AI-шлюзом

  • Премодерация запросов работает до отправки в модель

  • Регулярный аудит использования — хотя бы раз в квартал

Что в итоге дала правильная архитектура: цифры из нашего внедрения

Все эти разговоры об архитектуре имеют смысл только в одном случае — если в финале есть измеримый результат. Расскажу про наш собственный кейс, потому что про чужие я могу говорить только в общих чертах под 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-процессов, только на экономии разрозненных подписок и устранения теневого использования.

  • Начинайте не с выбора модели, а с классификации данных и политики безопасности

  • Не противопоставляйте API и on-premise — собирайте гибрид под реальные сценарии

  • Корпоративный API-шлюз ≠ личный ChatGPT, разнесите это в коммуникации с CISO

  • Заложите в дорожную карту обучение сотрудников — без него любая архитектура утечёт

  • Считайте окупаемость не только по подпискам, но и по core-процессам — там основной эффект

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

А если хотите глубже погрузиться в тему внедрения ИИ  — подписывайтесь на Телеграм-канал «Дело в промпте». Делимся там тем, что не помещается в статьи: кейсами, результатами внедрений, гайдами и готовыми промптами.

Источники

ссылка на оригинал статьи https://habr.com/ru/articles/1035766/