Сотрудник может видеть общую инструкцию, заказы своего отдела и личную переписку с клиентом. Руководитель получает более широкий доступ. При появлении ИИ эти правила должны действовать на всем пути: от поиска исходных сведений до показа ответа и выполнения операции.
Локальное размещение определяет место работы компонентов. Права, сетевые границы, журналы и порядок обновлений требуют отдельного описания. На приемке заказчику полезно проверять действия конкретных ролей в конкретных ситуациях.
Ниже приведен методический комплект для такого разговора. Он включает матрицу полномочий, сценарии изменения доступа и план проверки обновлений. Пример относится к условному отделу клиентского сервиса; фактические правила утверждает компания.
Разделите ответственность приложения и инфраструктуры
Модель формирует результат по переданным сведениям. Приложение определяет, какие источники доступны пользователю, какие действия разрешены и когда требуется подтверждение. Инфраструктура обеспечивает размещение, сетевые соединения, учетные записи сервисов и эксплуатационные процедуры.
Эти уровни стоит показать на схеме. Отметьте путь запроса, место проверки роли, обращение к источнику, передачу контекста и сохранение журнала. Рядом подпишите ответственных. Тогда на приемке будет понятно, кому адресовать каждый вопрос.
Документация vLLM отдельно рассматривает сетевую изоляцию, контроль точек доступа и пределы действия API-ключа. Это пример того, почему настройки среды запуска входят в собственный перечень проверок. Защита развертывания vLLM.
Для всех компонентов соберите версии и способ получения обновлений. Установленная модель, прикладной код, поисковый индекс и интеграции меняются по разным причинам. Каждое изменение должно иметь владельца и проверку результата.
Начните с матрицы полномочий
Вместо общей роли «пользователь ИИ» опишите рабочие роли отдела. Сопоставьте их с источниками и разрешенными действиями. Учетная запись сервиса, которая обращается к CRM, тоже должна попасть в документ.
| Роль в примере | Доступные сведения | Разрешенные действия | Кто подтверждает | Что проверяется |
|---|---|---|---|---|
| Менеджер | Заказы своей группы и общие правила | Подготовить черновик, создать согласованную задачу | Менеджер перед записью | Принадлежность заказа группе и права на действие. |
| Руководитель отдела | Заказы отдела и сводные показатели | Просмотреть результат, разобрать спорный случай | Руководитель по правилам процесса | Границы отдела и состав выдаваемых сведений. |
| Редактор знаний | Назначенные документы и история редакций | Подготовить и передать новую редакцию | Владелец документа | Версия, дата действия и группы читателей. |
| Сервис интеграции | Согласованные поля рабочих систем | Выполнить перечисленные операции | Правила приложения | Поля, объект, инициатор и результат вызова. |
| Администратор | Согласованные технические сведения | Обновить компоненты и восстановить работу | Ответственный за эксплуатацию | Порядок доступа и история действий. |
В каждом проекте уточните полномочия администратора отдельно. Техническое обслуживание и чтение содержимого требуют явного решения о доступах и инструментах поддержки. Матрица должна отражать фактическую конфигурацию и договоренности компании.
Проверяйте доступ до передачи сведений модели
Для проектируемой системы задайте требование: поиск возвращает материалы, разрешенные текущему пользователю. Права должны учитываться также при сборке фрагментов, показе ссылок и открытии исходного документа.
В документации Azure AI Search описана проверка прав на документы при запросе к индексу. Она использует сведения о пользователе и разрешениях источников. Для своей системы команда должна выбрать и проверить подходящий механизм с учетом используемого хранилища. Права на документы в поиске.
В методическом примере менеджер отдела А спрашивает о заказе отдела Б. Ожидаемое поведение: приложение сообщает о границах его доступа и показывает согласованный маршрут обращения к ответственному. Содержимое заказа и его фрагменты остаются доступны назначенным ролям.
Ту же ситуацию стоит проверить через поиск, прямую ссылку, историю диалога и повторный запрос. Так приемка охватит разные пути получения сведений. Формулировки пользователя могут меняться; решение о доступе должно опираться на правила приложения и источника.
Включите изменения ролей в приемку
Рабочие права меняются: сотрудник переходит в другой отдел, получает временный доступ или завершает работу над проектом. Укажите, какое событие обновляет полномочия в ИИ-системе и через какое время изменение начинает действовать.
Проверьте также уже открытые окна и сохраненные разговоры. Компания должна выбрать, что пользователь увидит после изменения роли, какие ссылки сможет открыть и как система объяснит новый порядок. Эти условия влияют на интерфейс и хранение истории.
| Событие | Приемочная проверка | Подтверждение результата |
|---|---|---|
| Менеджер перешел в другой отдел | Повторить запросы к старым и новым заказам | Состав доступных объектов соответствует новой роли. |
| Временный доступ завершился | Открыть поиск, ссылку и прежний диалог | Применяются текущие полномочия и согласованный порядок истории. |
| У документа изменилась группа читателей | Повторить вопрос от разных ролей | Поиск и ссылки учитывают обновленные права. |
| Добавлен новый источник | Проверить роли до начала его использования | Источник входит в утвержденную матрицу. |
| Изменена учетная запись интеграции | Выполнить разрешенное действие и рабочее исключение | Права и результат вызова соответствуют карте обмена. |
Для каждой проверки сохраните исходную роль, событие, время, ожидаемый результат и фактическое поведение. Такой протокол помогает принять систему и позднее разбирать обращения сотрудников.
Согласуйте состав журналов
Журнал должен помогать ответить на практические вопросы: кто запустил запрос, какие источники использовались, какое действие было подтверждено и чем завершилась операция. Состав полей зависит от сценария и правил компании.
Полезно связать события одним идентификатором. Тогда запрос из интерфейса, вызов интеграции и результат проверки можно сопоставить. Для воспроизведения ошибки также пригодятся версии приложения, модели и корпуса документов.
Отдельно определите доступ к журналам, срок хранения и порядок выгрузки. Полные тексты обращений могут содержать рабочие сведения. Выбирайте объем записи по задачам диагностики и установленным правилам обработки данных. Решение зафиксируйте в эксплуатационной документации.
Проверяйте обновление через рабочие сценарии
Перед изменением сохраните согласованный комплект версий и конфигураций. Подготовьте порядок возврата к рабочему состоянию и человека, который принимает такое решение. Способ восстановления следует проверить на выделенной среде.
После смены модели повторите набор вопросов и операций, которые влияют на работу отдела. После обновления документов проверьте актуальные основания ответа. После изменения интеграции проверьте поля, права, повторные вызовы и подтвержденные действия.
Добавьте обычную нагрузку и характерные пики. Пользователю нужна понятная реакция при задержке: состояние обработки, возможность продолжить работу и маршрут поддержки. Эти действия стоит показать на приемке вместе с удачными ответами.
В итоговый комплект включите протокол, оставшиеся замечания, владельцев исправлений и инструкцию поддержки. Переход к эксплуатации происходит после согласованного решения по этим материалам. Дальнейшие изменения запускают соответствующую часть проверок.
Опыт проектирования ролей можно увидеть в DZ Board. Он дает предметный контекст для обсуждения прав в бизнес-системах. Архитектура ИИ, доступ к источникам и защита конкретного развертывания получают собственные проверки.
Для обсуждения проекта подготовьте роли, примеры источников и одно действие сотрудника. DEF.center поможет включить их в требования к ИИ-системе и интеграциям. Матрица полномочий и приемочные сценарии станут общей основой работы заказчика и инженеров.