Давайте честно: когда речь заходит про ИИ в корпорации, у CISO дёргается глаз. Не потому что технология плохая — а потому что 152-ФЗ, утечки, regulatory compliance и куча страхов, которые мы разбирали в статье «Почему корпорации до сих пор боятся ИИ: 5 скрытых причин». В Alpina Digital мы прошли этот путь: от полного отрицания до промышленной эксплуатации AlpinaGPT, которая обрабатывает конфиденциальные данные клиентов. Расскажу на пальцах — без хайпа, с кровью и архитектурными костылями.
Проблема: данные не должны утекать, но ИИ должен работать
Любая LLM, которая дёргает облачный API — это чёрный ящик. Ваш промпт, ваши документы, ваша внутренняя переписка улетают на сервера OpenAI или Anthropic. Европарламент уже выключил ChatGPT — читайте «Европарламент выключил ChatGPT: почему облачные ИИ стали угрозой для корпоративных секретов». В РФ добавился 152-ФЗ со штрафами до 6% оборота. А ещё есть Указ 490 и методичка ФСТЭК 117 — я писал об этом в «ИИ-комплаенс в РФ: ФСТЭК 117 и Указ 490 глазами разработчика, который уже попал на штраф». Вывод: облачные модели под корпоративными секретами — прямой путь к катастрофе.
Но просто запретить ИИ нельзя — конкуренты улетят вперёд. Решение — три архитектурных подхода, которые мы обкатали на реальных проектах. Подходы не взаимоисключающие. Часто они работают в связке: гибрид для быстрых задач, air-gap для sensitive data, федеративка для дообучения на персональных данных.
Подход №1. Гибридный шлюз (Hybrid Gateway) — «почти как облако, но под контролем»
Суть: чувствительные данные — on‑prem, всё остальное — через облачную LLM с шифрованием и фильтрацией.
Первый подход — самый понятный и популярный. Ставите прокси-сервер (шлюз) внутри корпоративной сети. Он решает: какой запрос можно отправить в облако, а какой — завернуть на локальную модель. Критерии — классификация данных, имена пользователей, гриф секретности. В Alpina Digital мы строили такой шлюз на базе Envoy + OPA (Open Policy Agent) с кастомным модулем на Rust.
1 Размечаете данные
Без классификации шлюз бесполезен. Вы должны понимать, что у вас персональные данные (ПДн), коммерческая тайна, а что — публичная информация. Для этого поднимайте DLP-модуль или используйте готовый классификатор. Мы, например, написали внутренний сервис, который на основе regex и ML определяет тип данных в промпте.
2 Настраиваете политики маршрутизации
OPA-правила:
# if data contains PII -> route to local model
allow = true {
not contains_pii(input.prompt)
}
allow = true {
contains_pii(input.prompt)
input.model == "local"
}В облако вы шлёте только те промпты, где нет ПДн. Если сомневаетесь — шлите на локальный LLM. У нас это Mistral‑7B, дообученная на корпоративных данных.
3 Шифруете и логгируете всё
Даже те запросы, что ушли в облако, должны быть зашифрованы end‑to‑end. Используйте mTLS. Все логи — в SIEM. Это не только для compliance, но и для расследования инцидентов.
Ошибка: не пытайтесь маршрутизировать на уровне DNS или ingress — это медленно и не учитывает содержимое. Шлюз обязан читать тело запроса.
Подход №2. Изолированный куб (Air‑Gapped LLM) — «бетонная стена для данных»
Если у вас ФСБ-лицензия, госзаказ или просто паранойя (здоровая), то гибрид не прокатит. Нужна полная изоляция. Никаких внешних запросов. Вся модель, все данные — внутри контура. Про это мы подробно писали в «Локальный ИИ за бетонной стеной». Здесь подход радикальный: физическая или виртуальная сеть без доступа в интернет.
1 Выбрать модель
Берите открытые веса: Llama 4, Mistral, Qwen 2.5. Скачиваете один раз, проверяете хеш, помещаете в registry внутри периметра. Никаких pull с Docker Hub — только ваш mirror.
2 Разворачиваете инференс
Мы используем vLLM на GPU-серверах с Kubernetes. Каждый pod — изолирован. Настроена NetworkPolicy так, что под не может общаться ни с чем кроме кластерного storage и API-шлюза. Prometheus + Grafana — без доступа наружу, всё внутри.
3 Организуете доступ
Пользователи заходят через VPN или внутренний портал. No public endpoints. Аутентификация — через Kerberos или OpenID Connect с IAM.
Типичная ошибка: думать, что air‑gap решает все проблемы. Если модель не дообучена на ваших данных, ответы будут бесполезны. А дообучать в изоляции сложно — нужны синтетические данные или федеративное обучение.
Подход №3. Федеративный RAG (Federated RAG) — «обучение без потери контроля»
Самый молодой подход, но уже рабочий. Суть: модель не видит данные напрямую. Она получает только векторы или агрегированные градиенты из разных источников внутри компании. Каждый источник (департамент, филиал) держит данные у себя, а центральный оркестратор собирает общие знания через векторные базы или федеративное обучение.
В Alpina Digital мы построили федеративный RAG для юридического департамента: договоры не покидают локальную сеть юристов, но агент работает единообразно по всей компании. Подробнее про архитектуру AI-агентов и безопасность — в «Практическом руководстве по разработке AI-агентов».
1 Индексируете на местах
В каждом филиале или отделе ставится локальный embedding‑сервис (например, huggingface/text‑embeddings‑inference). Документы индексируются в локальную векторную БД (Chroma, Qdrant). Наружу торчит только API для поиска — без доступа к сырым документам.
2 Оркестрируете федеративный поиск
Центральный сервис получает запрос, рассылает его по всем локальным индексам, собирает топ‑k результатов, ранжирует и отдаёт LLM. LLM тоже может быть локальной или общей. Важно: никакие сырые данные не пересекают границу.
3 Аудит и мониторинг
Каждый запрос логируется. Можно внедрить политики доступа — например, юристы видят только свои контракты, HR — только кадровые данные. И всё это без перемещения исходников.
Плюсы: данные не покидают периметр, высокая скорость, scalability. Минусы: сложность синхронизации метаданных, задержки при агрегации.
Какой подход выбрать? Чек-лист зрелости
Прежде чем выбирать, прочитайте «Когда внедрение ИИ убыточно: практический чек-лист зрелости процессов компании». Если ваши процессы не готовы — никакая архитектура не спасёт.
| Критерий | Гибридный шлюз | Air-Gapped LLM | Federated RAG |
|---|---|---|---|
| Уровень безопасности | Средний | Высокий | Очень высокий |
| Скорость внедрения | Высокая | Низкая | Средняя |
| Качество ответов | Высокое (облачная модель) | Среднее (зависит от локальной) | Высокое (при хорошей индексации) |
| Соответствие 152-ФЗ | Среднее (нужен шлюз) | Полное | Полное |
FAQ: ответы на то, о чём молчат вендоры
Что делать, если модель Air‑Gap ошибается? Обновлять веса — целая эпопея.
Да, но можно организовать pipeline с офлайн-обновлением: скачиваете образ модели на USB-ключе, проверяете контрольную сумму, монтируете в кластер. Не быстро, но безопасно.
Федеративный RAG — это же просто распределённый поиск? В чём отличие?
В том, что ты не копируешь данные в центр. Каждый узел сам решает, какие документы индексировать, и отдаёт только векторы. Плюс можно внедрить федеративное обучение ранкера — тогда модель улучшается без sharing raw data.
Гибридный шлюз не замедлит работу? Каждая проверка — overhead.
На практике задержка 100-300 мс на классификацию. Это меньше, чем уход в облако. Если поставить локальный классификатор на GPU — ещё быстрее. Овчинка стоит выделки.
Какой подход выбрали вы сами для AlpinaGPT?
Мы используем гибридный шлюз как базовый слой, а для чувствительных операций — Air‑Gap. Федеративный RAG пока в пилоте для юридического департамента. Планируем через полгода сделать его основным.
Неочевидный совет
Самая частая ошибка — начинать с архитектуры, не разобравшись с данными. Потратьте месяц на инвентаризацию и классификацию. Иначе даже самый красивый шлюз превратится в «чёрную дыру», где данные утекают молча. Проверьте, как у вас с управлением ИИ-автоматизацией — контроль важнее скорости внедрения. И ещё: не бойтесь резать по живому. Мы в Alpina Digital дважды переписывали шлюз после первого месяца эксплуатации — и это нормально.
А вы уже выбрали подход? Если нет — начните с гибрида и добавляйте изоляцию по мере необходимости. И помните: 152-ФЗ не шутит, а LLM — не игрушка.
