Запретить сотрудникам пользоваться генеративным ИИ технически сложно и организационно недальновидно. Открыть доступ без правил — значит создать неконтролируемый канал передачи документов, исходного кода и коммерческой информации.
Рабочая альтернатива — управляемый AI-контур, в котором выбор модели и доступных действий зависит от пользователя, типа данных и сценария.
Начать с классификации, а не с модели
Архитектура должна различать как минимум четыре класса информации:
- публичные данные, которые можно обрабатывать во внешнем сервисе;
- внутренние материалы без критичных ограничений;
- конфиденциальные данные, доступные только утверждённым моделям и группам;
- сведения, которые нельзя передавать AI-системе или использовать для обучения.
Классификация может поступать из DLP, MDM, каталога документов или правил конкретного приложения. Главное — не перекладывать решение на пользователя в момент отправки запроса.
Единый AI-шлюз
Облачные и локальные модели лучше подключать через общий шлюз. Он решает несколько задач:
- Аутентифицирует пользователя и получает его роли.
- Определяет класс запроса и вложенных данных.
- Выбирает разрешённую модель и маршрут обработки.
- Применяет маскирование, фильтрацию и ограничения инструментов.
- Записывает технический аудит без лишнего копирования чувствительного содержания.
Шлюз не заменяет DLP, IAM или SIEM. Он связывает их решения с поведением AI-приложения.
RAG тоже требует границ
Корпоративная база знаний не должна становиться единым массивом, доступным каждому агенту. При индексации необходимо сохранять источник, владельца, класс данных и правила доступа. При поиске фильтрация выполняется до передачи фрагментов модели, а не после генерации ответа.
Это особенно важно для документов, которые внешне похожи, но относятся к разным проектам, юридическим лицам или уровням конфиденциальности.
Агенту нужны права меньшие, чем человеку
AI-агент, который умеет не только читать, но и выполнять действия, создаёт новый класс риска. Доступ к ERP, CRM, файловым хранилищам и сервисным системам следует выдавать через отдельные инструменты с узкими операциями.
Критичные действия требуют подтверждения человеком. Для каждого вызова фиксируются инициатор, цель, входные параметры, результат и применённая политика.
Локальная модель не решает всё
Размещение LLM внутри периметра снижает риск передачи данных третьей стороне, но не устраняет ошибочные права, утечки между подразделениями, prompt injection и неконтролируемые действия агента.
Поэтому выбор между облачной и локальной моделью — только один элемент архитектуры. Зрелость контура определяется политиками, наблюдаемостью, качеством данных и способностью расследовать инцидент.
Минимальный первый этап
Для начала достаточно одного полезного сценария, двух классов данных и ограниченного набора моделей. На пилоте стоит проверить:
- корректность маршрутизации запросов;
- работу разграничения доступа в RAG;
- качество маскирования чувствительных данных;
- полноту аудита;
- понятность отказов и предупреждений для пользователя;
- стоимость и задержку каждого маршрута.
Такой пилот отвечает не только на вопрос «насколько хорошо отвечает модель», но и показывает, может ли организация безопасно управлять новым технологическим контуром.