Практика внедрения
Матрица доступа для ИИ-функции: роли, данные и подтверждения
Шаблон матрицы, который помогает согласовать роли, источники, действия и подтверждения до корпоративного ИИ-пилота и проверить запреты на практике.
До пилота корпоративной ИИ-функции сведите права в одну матрицу: кто запускает функцию, какие источники она может читать, что может подготовить и какое действие требует подтверждения человека. Такая таблица превращает формулировку «доступ по ролям» в набор правил, которые можно настроить и проверить.
Матрица не заменяет модель угроз, архитектурную схему или политики информационной безопасности. Она связывает их с одним рабочим сценарием и помогает владельцу процесса, ИТ и ИБ одинаково понимать границы пилота.
Что должно быть в одной строке
Одна строка матрицы описывает одно сочетание роли, функции, источника и действия.
| Поле | Что зафиксировать |
|---|---|
| Роль | Кто запускает функцию |
| Функция | Какой рабочий результат готовится |
| Источник | Какой документ, раздел или система доступны |
| Уровень доступа | Чтение, подготовка проекта или изменение |
| Действие | Что произойдёт с результатом |
| Подтверждение | Кто разрешает значимое действие |
| Условие остановки | Когда функция не продолжает работу |
| Проверка запрета | Как доказать, что лишний доступ не сработал |
Не объединяйте несколько ролей или систем в строку «все сотрудники — корпоративные данные». Такое правило нельзя однозначно проверить и трудно безопасно изменить.
Заполненный пример
Ниже — иллюстративный сценарий подготовки проекта протокола встречи. Это не описание клиентского внедрения или наблюдаемого результата Тау Хаб.
| Роль | Функция | Источник | Доступ | Действие | Подтверждение | Остановка |
|---|---|---|---|---|---|---|
| Руководитель проекта | Проект протокола | Расшифровка своей проектной комнаты | Чтение | Создать черновик | Не требуется | Расшифровка недоступна или неполна |
| Руководитель проекта | Проект протокола | Карточка своего проекта | Чтение | Добавить известные сроки | Не требуется | Сроки противоречат расшифровке |
| Руководитель проекта | Публикация протокола | Утверждённый черновик | Подготовка | Отправить участникам | Подтверждает руководитель проекта | Есть непроверенные решения |
| Участник другой команды | Проект протокола | Чужая проектная комната | Запрещён | Любое | Не применимо | Доступ отклонён до чтения данных |
Последняя строка так же важна, как разрешённые сценарии. Матрица должна описывать не только успешный путь, но и ожидаемое поведение при чужой роли, отсутствующем источнике и попытке выполнить действие без подтверждения.
Как собрать матрицу за пять шагов
1. Начните с одной функции
Сначала заполните паспорт ИИ-функции: рабочую задачу, владельца, результат и условия остановки. Если функция пока описана как «помогать сотрудникам», границы доступа будут постоянно расширяться вместе с трактовкой задачи.
2. Перечислите роли, а не фамилии
Используйте устойчивые роли: менеджер проекта, руководитель функции, проверяющий, администратор. Фамилии и временные исключения храните в системе управления доступом, а в матрице оставьте правило.
Для каждой роли задайте два вопроса: нужна ли ей сама функция и нужны ли ей все источники, доступные функции. Право вызвать функцию не должно автоматически означать право прочитать каждый подключённый документ.
3. Разберите источники по отдельности
Возьмите реестр из руководства по подготовке базы знаний и сопоставьте каждый источник с ролями. Укажите действующую версию и владельца источника. Если права зависят от проекта, подразделения или уровня конфиденциальности, запишите это условие явно.
4. Отделите подготовку от внешнего действия
Создать черновик и отправить его адресату — разные полномочия. То же относится к формированию заявки и её отправке, подготовке записи и изменению системы, предложению платежа и его проведению.
Для каждого действия выберите один режим:
- функция только готовит результат;
- человек проверяет и подтверждает действие;
- действие разрешено автоматически в заранее ограниченных условиях;
- действие запрещено в пилоте.
Если автоматическое действие допустимо, укажите его пределы: тип объекта, получатель, сумма, система или рабочее окно. Не оставляйте слово «безопасные действия» без измеримого определения.
5. Назначьте владельца изменения
Матрица устаревает при смене роли, источника, функции, интеграции или маршрута данных. Назначьте человека, который согласует изменения, и события обязательного пересмотра. Новое право сначала вносится в матрицу и проверочный набор, затем в техническую конфигурацию.
Какие отрицательные тесты провести
Проверяйте запреты под реальными тестовыми ролями, а не только чтением настроек.
- Роль без функции не видит или не может запустить её.
- Разрешённая роль не получает сведения из чужого источника.
- Недоступный документ не раскрывается в ответе, цитате или ссылке.
- Недостаток данных приводит к остановке или запросу уточнения.
- Действие с подтверждением не выполняется до явного решения человека.
- Отмена подтверждения не меняет внешнюю систему.
- После отзыва права прежний доступ действительно перестаёт работать.
Сохраните вход, роль, ожидаемое правило и фактический результат. Эти строки можно перенести в рабочую таблицу приёмки и повторять после каждого значимого изменения.
Как применить матрицу в Тау Хаб
В Тау Хаб рабочее место можно настроить с фиксированным согласованным набором ИИ-функций без обязательного свободного чата. Для пилота выберите одну функцию, сопоставьте её с ролями и разрешёнными источниками, затем отдельно определите действия, которые остаются черновиками или требуют подтверждения.
Размещение платформы и подключение модели рассматривайте отдельно. Тау Хаб может размещаться в облаке или в контуре заказчика; LLM подключается ключом заказчика либо через прокси Тау. Для выбранной комбинации зафиксируйте маршрут данных и ответственных. Использование LLM оплачивается отдельно от платформы и внедрения.
NIST AI RMF Playbook: Govern связывает управление рисками ИИ с документированными ролями, ответственностью, политиками и надзором. Страница проверена 21 сентября 2026 года. Предложенная матрица — практический шаблон Тау Хаб, а не обязательная форма NIST.
Следующий шаг — заполнить матрицу для одной функции, добавить минимум по одному тесту на каждое разрешение и запрет и только после этого переносить правила в конфигурацию пилота.