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