Первый этап внедрения ИИ в компанию: идентификация и AI-шлюз

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

Пока в компании нет ответа на два вопроса — «кто делает запрос» и «во что этот запрос обошёлся» — любая попытка масштабировать ИИ-инструменты превращается в хаос с ежемесячным сюрпризом в счёте.

Зачем начинать с идентификации

Автор серии референсных диаграмм по архитектуре корпоративного ИИ Уильям Чью (William Chiu) опубликовал первую детальную часть, посвящённую двум базовым блокам: управлению идентификацией и доступом (Identity & Access) и AI-шлюзу (AI Gateway). Оба расположены в самом низу стека — не потому что они тривиальны, а потому что всё остальное на них опирается.

Чтобы разобрать каждый элемент, автор использует вымышленную компанию Qingchuan — примерно 40 сотрудников, 8 инженеров, 2 маркетолога. До внепления описанной архитектуры ситуация там типичная: каждый сотрудник регистрируется на платформах ИИ-провайдеров сам, кто-то оплачивает с корпоративной карты, кто-то — с личной, а API-ключи вставляются в инструменты напрямую, в открытом виде.

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

SSO / IdP: кто делает запрос

Первый блок — единый провайдер идентификации (Identity Provider). Каждый запрос к любому ИИ-инструменту должен нести в себе идентификатор, выданный корпоративной системой. Без этого компания не может составить инвентарный список используемых аккаунтов.

Автор приводит личный пример: на одной публикационной платформе у него оказалось два аккаунта — скрипт для автоматической публикации был привязан к старому через API-ключ, а в браузере был открыт новый. Результат: черновики создавались в одном месте, а рабочее пространство показывало ноль. Никто ничего не скопировал неправильно — просто отсутствие единой системы идентификации привело к рассинхронизации.

Масштабируйте это на 10 человек, каждый со своими ключами и аккаунтаами — и получите ситуацию, при которой невозможно даже начать аудит.

Критерий готовности: аккаунт существует только если он выдан провайдером идентификации, а отключение сотрудника в IdP автоматически отзывает его доступ ко всем ИИ-инструментам.

Роли и области доступа: что именно разрешено

Второй блок отвечает на вопрос «что этот пользователь может делать» — какие модели, инструменты и (начиная со второго этапа) какие данные ему доступны.

Без ролевой модели получается так: инженер и маркетолог стучатся в один и тот же эндпоинт с одинаковыми привилегиями. Инвентаризацию проблему первый блок решил, но вопрос границ доступа остался открытым.

Важный нюанс: роль присваивается при входе и проносится через весь запрос до шлюза. Смена промпта не меняет набор доступных ресурсов — это принципиально. Если промпт-инжиниринг обходит ограничения ролевой модели, значит, модель реализована неправильно.

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

Хранилище секретов: ключи не должны попадать в промпты

Третий блок — Secrets Manager. API-ключи, токены и учётные данные коннекторов хранятся в защищённом хранилище, из которого сервисы читают их в рантайме. Никто не вставляет ключ вручную в чат-окно, конфигурационный файл или тикет.

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

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

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

AI-шлюз: единая точка входа

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

Маршрутизация

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

Критерий готовности: смена модели — это изменение конфигурации шлюза, а не деплой приложения.

Лимиты и бюджет

У каждой команды есть лимит расходов. Шлюз отказывает в следующем запросе, как только лимит исчерпан. Без этой системы счёт приходит раз в месяц без разбивки по командам, а скрипт с ошибкой может выжечь месячный бюджет за ночь — и никто не узнает до получения инвойса.

Важное уточнение: этот блок работает на уровне отдельного запроса. Остановка уже запущенного процесса — задача другого механизма (Halt & budget caps), который описан на пятом этапе архитектуры.

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

Логирование

Каждый вызов фиксируется: кто сделал, какая модель ответила, сколько токенов использовано и во что это обошлось. Без логирования при возникновении проблемы единственный способ выяснить, что произошло — спросить человека или сам AI, что ненадёжно.

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

Критерий готовности: любой недавний вызов можно найти по сотруднику, команде или модели, не задавая вопросов человеку, который его делал.

Фильтр PII / DLP

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

Критерий готовности: вызов, содержащий паттерн, который должен быть заблокирован, останавливается на шлюзе, и факт блокировки отображается в логе.

Провайдеры на границе сети

Отдельный архитектурный принцип: блок с внешними LLM-провайдерами расположен ровно на линии границы корпоративной сети, и все стрелки к нему идут исключительно из шлюза. Без этого шесть описанных выше компонентов могут быть реализованы, но один инженер с личным ключом и прямым сетевым путём обойдёт их все.

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

Проверка перед переходом к этапу 2

Автор предлагает провести конкретный тест: создать нового сотрудника, авторизовать его через SSO, проверить, что роль соответствует команде, отправить запрос сверх бюджета (должен быть отклонён) и запрос с PII-данными (должен быть заблокирован). Всё — автоматически, без наблюдателя.

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

Что дальше

Для самохостинга (self-hosted) вместо внешних API-провайдеров подставляются внутренние компоненты — реестр моделей и GPU-кластер для инференса, — но блоки идентификации и шлюза остаются неизменными. Вторая часть серии посвящена данным и retrieval-системе, где роли и области доступа, описанные в этой статье, становятся основой для ограничения видимости индексов.

Подход автора прагматичен: не пытаться построить сложную RAG-систему или настроить агентные workflow, пока в компании нет ответа на элементарные вопросы контроля. Семь блоков первого этапа — это не инновация, а необходимый минимум, который в зрелых IT-организациях давно считается baseline, но в контексте ИИ-инструментов часто игнорируется из-за спешки и давления на «быстрый PoC».