AI Gateway: как организовать безопасное использование LLM в компании

Понедельник, 10:15. Юрист копирует договор с контрагентом в публичный чат-⁠бот, чтобы быстро найти рисковые пункты. В тексте — ФИО, ИНН, реквизиты, сумма сделки. Через час разработчик вставляет в другой сервис кусок конфигурации с токеном доступа. Никто не нарушал регламент специально: удобного и разрешённого инструмента просто не было.

Запретить LLM не получится — люди найдут обходной путь. Разумнее дать сотрудникам ИИ, но провести все обращения через контролируемый слой. Этот слой и называют AI Gateway, или ИИ-⁠шлюз. Разберём, какие проблемы он закрывает, что должен уметь и как выбрать решение.

Зачем компании AI Gateway: четыре проблемы

Потребность в шлюзе редко возникает из одной точки. Обычно это набор проблем, которые копятся одновременно:

• Shadow AI. Сотрудники пользуются личными аккаунтами в публичных сервисах. Компания не знает, какие модели используются, кем и для каких задач.
• Утечки через промпты. В запросы попадают персональные данные, коммерческая тайна, фрагменты кода, учётные данные. Промпты нигде не журналируются, поэтому восстановить, что и куда ушло, невозможно.
• Неуправляемые AI-⁠агенты. Агент с доступом к Git, Jira, ITSM или CMDB может выполнить действие, которое не согласовано ни с кем. Ролевая модель, которая действует для людей, на агента часто не распространяется.
• Зоопарк ключей и провайдеров. Каждая команда заводит свои API-⁠ключи и свои интеграции. Смена провайдера превращается в переписывание приложений, а ключи расползаются по конфигурациям и репозиториям.

У всех четырёх проблем общий корень: между людьми, приложениями и моделями нет точки, где компания может посмотреть, что происходит, и применить свои правила. Точечные меры — запрет сайтов, регламент, обучение — снижают риск, но не дают ни контроля, ни удобного легального инструмента. Сотрудник, у которого нет разрешённого ИИ, продолжит пользоваться неразрешённым.

Что такое AI Gateway (ИИ-⁠шлюз)

AI Gateway — прокси-слой между пользователями, приложениями и AI-⁠агентами с одной стороны и языковыми моделями с другой. Все запросы к LLM идут через него, и на этом пути шлюз применяет политики: кто может обращаться к какой модели, какие данные можно отправлять наружу, что записать в журнал.

Для пользователя шлюз почти незаметен: он работает в привычном чате или через API, которые подключены к шлюзу. Для ИБ шлюз — единая точка контроля. Для ИТ — один интерфейс ко всем моделям вместо десятка разрозненных интеграций.

Чем ИИ-⁠шлюз отличается от DLP и обычного прокси

DLP умеет заметить и заблокировать отправку чувствительных данных, но не даёт альтернативы: запрос либо уходит как есть, либо не уходит вовсе. Обычный API-⁠прокси умеет маршрутизировать трафик и считать запросы, но не понимает, что внутри промпта. AI Gateway соединяет оба подхода и добавляет третий: он понимает содержимое запроса, маскирует его так, чтобы задача всё равно решалась, и знает, какой пользователь, приложение или агент стоит за каждым обращением.

Маскирование данных для LLM: как не отправить ПДн в модель

Маскирование — главная функция ИИ-⁠шлюза с точки зрения ИБ. Идея в том, чтобы модель получила смысл запроса, но не получила чувствительные значения. Для большинства задач — резюмировать договор, написать ответ клиенту, разобрать инцидент — настоящее ФИО или ИНН модели не нужно.

1. 01

   Распознавание

   Шлюз находит в запросе чувствительные сущности по настраиваемым правилам: ФИО, телефоны, email, ИНН и СНИЛС, реквизиты, номера договоров, суммы, IP-⁠адреса, имена хостов, токены.

2. 02

   Замена масками

   Значения заменяются метками вида [PERSON-1], [INN-1], [CONTRACT-1], [AMOUNT-1]. Фраза «Договор № 17/24 с Ивановым И. И., ИНН 7700000000» превращается в «Договор [CONTRACT-1] с [PERSON-1], ИНН [INN-1]».

3. 03

   Запрос к модели

   В LLM уходит только замаскированный текст. Модель работает со структурой и смыслом, не видя исходных данных.

4. 04

   Де-⁠анонимизация ответа

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

5. 05

   Журналирование

   В аудит записываются запрос, ответ, какие сущности были замаскированы, какой провайдер обработал запрос и какая политика применилась.

Важно, чтобы правила распознавания настраивались под компанию: у каждой организации свои форматы номеров договоров, внутренние коды проектов, имена серверов. Универсальный набор из коробки — только отправная точка.

Политики, маршрутизация и аудит

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

Пример: маркетинг работает с внешней моделью для текстов, но с включённым маскированием контактов. Юристы и финансисты отправляют документы только в локальную модель в контуре компании. Разработчики получают доступ к модели для кода с лимитами на объём запросов. Всё это настраивается в одном месте, а не в каждом приложении отдельно.

Отдельная тема — лимиты. Когда доступ к моделям идёт через один шлюз, видно, какая команда и какое приложение сколько запросов отправляет. Это позволяет ограничить объём для экспериментальных сервисов, заранее заметить агента, который ушёл в бесконечный цикл, и планировать нагрузку на локальные модели по фактическим данным, а не по оценкам.

Свобода выбора моделей без vendor lock-⁠in

Рынок моделей меняется каждые несколько месяцев. Если приложения интегрированы с провайдером напрямую, смена модели означает доработку каждой интеграции. Шлюз отвязывает приложения от конкретного провайдера: они обращаются к шлюзу, а он маршрутизирует запрос во внешнюю, внутреннюю или локальную модель. Несколько моделей можно объединить в единый провайдер с маршрутизацией и резервированием.

AI-⁠агенты под контролем: workflow как предохранитель

Чат с моделью — только половина истории. Всё чаще LLM работает как агент: сам вызывает инструменты, читает тикеты, создаёт задачи, меняет конфигурации. Стандарт MCP (Model Context Protocol) упростил подключение агентов к Git, Jira, ITSM, CMDB, SIEM — и одновременно сделал вопрос контроля острым.

Надёжная схема — «workflow как предохранитель»: агент не выполняет действие сам, а предлагает его. Платформа проверяет предложение по тем же правилам, что и действие человека: есть ли права у инициатора, допустимо ли действие для этого объекта, нужно ли согласование. Только после валидации действие выполняется. В журнал пишется, кто инициировал действие, какие данные использовались и какое решение применилось.

Как это выглядит на практике. DevOps-агент разбирает упавшую сборку, находит причину в конфигурации и предлагает откатить изменение и закрыть связанную задачу в Jira. Шлюз проверяет: у инициатора есть права на откат в этом репозитории, а для продуктивного окружения регламент требует подтверждения дежурного. Агент получает не «выполнено», а «ожидает согласования» — и это правильный ответ.

Тот же принцип работает в SOC. Агент может обогатить инцидент и подготовить черновик отчёта, но изоляцию узла или блокировку учётной записи должен выполнить валидированный сценарий — о том, как устроены такие сценарии, читайте в статье «Что такое SOAR».

AI Gateway и 152-⁠ФЗ

Для российских компаний вопрос безопасного использования LLM почти всегда упирается в персональные данные. Отправка ПДн во внешний сервис — это обработка по поручению или передача третьему лицу, а если сервер находится за рубежом — ещё и трансграничная передача, которую 152-⁠ФЗ регулирует отдельно. Кроме того, закон требует, чтобы оператор мог показать, какие меры защиты он применяет.

AI Gateway помогает выстроить эти меры технически: маскирование снижает объём ПДн, уходящих наружу, политики позволяют направлять запросы с чувствительными данными только в локальные модели, а аудит даёт доказательную базу. Подробнее о регуляторном контуре — в статье о SGRC и комплаенсе.

Чек-⁠лист выбора AI Gateway

Как это устроено в Версиум AI

Версиум AI — модуль управления ИИ, который работает как корпоративный AI Gateway. Он стоит между сотрудниками, приложениями, AI-⁠агентами и любыми LLM — внешними, внутренними или локальными. Модуль маскирует чувствительные данные масками вида [PERSON-1] и [INN-1] с обратной подстановкой в ответ, журналирует запросы и ответы, применяет политики по ролям, проектам и типам данных и выполняет действия агентов, в том числе через MCP, только после валидации. Устанавливается на Windows или Linux, в том числе в Docker.

Версиум AI поставляется отдельно или вместе с модулями платформы Versium — тогда тот же ИИ помогает настраивать саму платформу и работать с инцидентами. Подробности о запуске — в новости о выпуске Версиум AI. Чтобы увидеть маскирование и политики на ваших сценариях, запросите демонстрацию.