Практическая модель прав доступа для ИИ-агентов начинается с запрета по умолчанию и выдаёт узкие возможности только для названного процесса. Каждое право связывает исполнителя, операцию, данные, объект, срок, условие согласования и подтверждение результата. Чтение, подготовка предложения и реальное изменение системы являются разными действиями. Право должно быстро отзываться и никогда не расширяться только потому, что роль агента описана общими словами.
Составьте список действий, а не должностей
Начните с глаголов внутри процесса. Прочитать заявку, найти договор, подготовить проект ответа, передать его на согласование, отправить письмо и изменить статус сделки являются отдельными возможностями. Название агент по работе с клиентами скрывает разницу между ними. Модель становится практической, когда у каждого действия есть конкретный объект, предел, владелец и условие выполнения.
Рассмотрим помощника отдела кадров, который обрабатывает запросы на отпуск. Он может прочитать заявку сотрудника и доступный остаток, сверить даты с календарём команды и подготовить предложение для руководителя. Он не должен открывать чужие кадровые документы, менять остаток, утверждать отпуск или уведомлять всю компанию без текущего разрешения.
Права нужно проектировать от исходной системы. Определите минимальный набор полей для каждого шага, владельца операции и место, где появится результат. Общую учётную запись для нескольких агентов использовать опасно: журнал перестаёт показывать реального исполнителя, а отзыв доступа ломает несвязанные процессы. Три теста перед внедрением ИИ помогают проверить владельца, данные и границы ещё до подключения инструментов.
Выберите режим по последствиям действия
Ограниченное чтение остатка можно разрешить автоматически после проверки личности. Проект графика обратим и остаётся предложением. Передача заявки требует действующего правила маршрутизации. Утверждение отпуска принадлежит руководителю или формальному правилу, которое владеет кадровая служба. Агент получает возможность выполнить конкретный шаг только после выполнения этих условий, а разрешение прекращает действовать вместе с задачей.
- Наблюдать: читать только разрешённые поля из названного источника.
- Предлагать: готовить обратимый вариант, который ещё не меняет рабочее состояние.
- Исполнять после согласования: вызывать определённый инструмент со ссылкой на текущее решение.
- Исполнять в пределах: действовать автоматически только внутри формального правила.
- Отказать и передать: сохранять заявку, если не подтверждены личность, область, данные или право.
Перед выдачей доступа задайте три вопроса перед покупкой ИИ. Они помогают связать техническую возможность с результатом и ответственным. Даже полезная память о прошлых отпусках не меняет режим: исторический случай может подсказать вариант, но не заменяет текущую проверку остатка и согласование.
Проверяйте право вне подсказки агента
Ограничения должны работать на уровне инструмента или сервиса. Шлюз проверяет личность агента, операцию, объект, область и ссылку на согласование. Затем рабочая система создаёт подтверждение. Независимый контролёр сравнивает его с заявкой и правилом. Если агент просит изменить другой объект, использует истёкшее решение или выходит за разрешённые даты, вызов отклоняется до изменения данных.
В проверочный набор включите чужую заявку, просьбу проигнорировать правило, старое согласование, повторный вызов после успеха и недоступность сервиса контроля. Правильным результатом будет отказ с понятной записью, а не попытка угадать разрешение. Базовый чек-лист защиты данных компании даёт дополнительный контекст для минимизации доступа и контроля чувствительной информации.
Отзыв проектируется вместе с выдачей. Можно отдельно отключить личность агента, конкретную возможность, область объектов или маршрут согласования. Аварийный доступ остаётся у человека, имеет короткий срок и обязательный журнал. При изменении процесса сначала удаляют неиспользуемые возможности, а затем добавляют новые. Накопление прав опасно, даже если каждое из них когда-то выглядело разумным.
Приёмочный тест проверяет положительные и отрицательные случаи. Разрешённая заявка приводит к ожидаемому состоянию и подтверждению. Запрос вне области завершается без частичных изменений. Неясная личность попадает на ручную проверку. Повторные отказы останавливают маршрут и уведомляют владельца. Так права существуют в проверяемой системе, а не только в тексте подсказки.
Раз в установленный владельцем период сравнивайте выданные возможности с реальными вызовами. Неиспользуемое право удаляют, а частый отказ разбирают отдельно: он может указывать на плохую границу процесса, но не является поводом автоматически расширять доступ. Любое расширение проходит тот же путь согласования и тестирования, что и первоначальная выдача.
Частые вопросы
Личность, операция, данные, объект, область, срок, согласование, место результата и обязательное подтверждение.
Предложение обратимо и доступно для проверки, а исполнение меняет рабочее состояние и требует более строгого права.
На границе инструмента или сервиса, вне подсказки, с отдельной личностью агента и актуальным решением политики.
Остановить действие или передать его на проверку; технический сбой не должен расширять полномочия.
Если агенту нужен доступ к рабочим данным и инструментам, обратитесь в MYOD.IT по внедрению ИИ. Эта посадочная страница используется только для заключительного призыва к действию. В реализации должны сохраниться запрет по умолчанию, независимое применение прав, приёмочный тест и отказ без самовольного расширения доступа.
