Чтобы создать матрицу RACI с помощью ИИ, сопоставьте работу с утверждёнными ролями. ИИ ищет пробелы, а назначения подтверждают носители ролей.

Начните с контролируемого процесса ИИ и утверждённого плана проекта. RACI поясняет владение известной работой, но не проектирует организацию, не выдаёт полномочия и не заменяет карту заинтересованных сторон.

Ключевые выводы

Формулируйте строки как наблюдаемые результаты, действия, средства контроля или решения.

Формируйте столбцы по реальным ролям и делегированным полномочиям, а не стереотипам о должностях.

Сначала подтверждайте исполнителя, затем окончательно ответственную роль.

По умолчанию в строке один Accountable; исключение требует утверждённого правила.

Consulted означает двустороннее участие, Informed — одностороннее уведомление.

Проверяйте отсутствие R, несколько A, нехватку полномочий, перегрузку и конфликты ролей.

Что значит создать матрицу RACI с помощью ИИ?

Матрица показывает участие ролей в определённой работе. Responsible выполняет или координирует работу. Accountable окончательно отвечает за результат и обладает нужным правом решения. Consulted даёт мнение в двустороннем обмене. Informed получает односторонние уведомления.

Британское руководство Secure by Design использует матрицу RACI для согласования ролей и ответственности и определяет Responsible, Accountable, Consulted и Informed.［1］ Руководство GOV.UK Global HR Design добавляет, что процесс должен иметь одного ясного Accountable, хотя R, C и I могут быть множественными.［2］ Используйте это как полезное правило по умолчанию, а затем следуйте тем правилам управления, которые действительно применяются в вашей организации.

Код	Основной вопрос	Проверяемое доказательство
R	Кто выполняет или координирует?	Карта процесса, процедура, пакет работ
A	Кто вправе утвердить результат и отвечает за него?	Делегирование, устав, политика, право решения
C	Чьё мнение обязательно до действия или утверждения?	Контроль, экспертиза, обязанность консультации
I	Кто должен получить результат или статус?	Отчётность, уведомление, обязательство перед стороной

RACI не является оценкой эффективности и не показывает, кто важнее, старше, занятее или виноват. Имя в ячейке также не доказывает согласие, доступность или полномочие человека.

Какие данные собрать до запроса к ИИ?

Зафиксируйте область и версию. Матрица для всей трансформации обычно слишком размыта; выберите процесс, фазу, приращение продукта, последовательность решений или набор результатов с чёткой границей.

Соберите:

утверждённую область, декомпозицию работ, карту процесса или каталог контролей;
определения результатов и решений с точками приёмки;
каталог ролей со стабильными названиями ролей, где это практично, а не имена людей;
уставы, делегирования, лимиты утверждения и обязательные правила разделения обязанностей;
обязанности поставщиков или партнёров, если в область входит работа нескольких организаций;
обязательные шаги консультаций, уведомлений, регуляторных требований и ведения записей;
текущую нагрузку и порядок замещения;
правила исключений и эскалации.

Официальные ресурсы Северной Ирландии помещают роли и ответственность в один контекст с организацией, планированием, контролем и управлением проектом.［3］ Без этого контекста формально заполненная матрица может передать утверждение роли без действительного права решения.

Минимизируйте данные до обращения к ИИ: если личность не важна, замените имена сотрудников утверждёнными ID ролей и исключите оценки сотрудников, личную переписку, защищённые характеристики, оплату, медицинские и коммерческие сведения.

Как определить строки и столбцы?

Строка должна содержать действие, объект и момент завершения или решения. «Безопасность», «маркетинг» или «управление» слишком широки; «утвердить производственный доступ», «проверить доказательство приёмки» или «уведомить затронутых клиентов после утверждения» можно проверить.

Используйте три типа строк осознанно:

Результат — кто создаёт и кто принимает результат.
Действие — кто выполняет повторяемый шаг.
Решение — кто готовит доказательства, кто решает и кто получает итог.

Не смешивайте уровни в одной строке. Строка «спроектировать, создать, испытать, утвердить и запустить сервис» скрывает несколько разных R и A; разбейте её там, где меняется доказательство, полномочие или передача.

Столбцы должны иметь одинаковую детализацию. Не смешивайте «финансовый департамент», «руководителя проекта» и «Алекса», если модель управления действительно не работает на этих уровнях. Свяжите каждую роль с утверждённым описанием, делегированием или контрактом.

Для каждого назначения «рабочий элемент–роль» создавайте одну запись. Храните этот контракт полей вместе, чтобы рецензенты могли восстановить матрицу, доказательства и согласования:

Группа записи	Обязательные поля
Контроль	`Matrix ID/version`, `Scope`, `Owner`, `Effective date`, `Review trigger`, `Approval`, `Change log`
Рабочий элемент	`Deliverable/activity/decision ID`, `Work item`
Роль	`Role ID`, `Role holder`, `R/A/C/I`
Доказательства	`Authority source`, `Responsible evidence`, `Accountable evidence`
Коммуникация	`Consultation trigger`, `Information channel`
Исключение	`Exception rationale`

Например, синтетическая строка может содержать DEC-07: approve production release, ROLE-DELIVERY в качестве R, ROLE-CHANGE-AUTHORITY в качестве A, ROLE-SECURITY в качестве C и ROLE-SUPPORT в качестве I. Укажите DELEGATION-04 как источник полномочий и оставьте статус NEEDS_OWNER_REVIEW, пока реальные владельцы ролей не подтвердят назначение. Эти ID показывают структуру, а не рекомендуют распределение ролей.

Согласуйте строки и назначения с реальными владельцами ролей до вступления матрицы в силу. Контролем служит согласие, а не генерация документа.

Как назначить Responsible и Accountable?

Начните с Responsible. У какой роли есть процесс, ресурсы, доступ, компетенция и обязанность выполнить работу? Для каждой исполняемой строки обычно нужен хотя бы один R.

Затем подтвердите Accountable. Кто вправе принять результат, санкционировать решение, разрешить конфликт и отвечать за завершение? Нельзя выводить A из старшинства или названия должности: проверьте устав, делегирование, политику или договор.

По умолчанию используйте одного A на строку: один владелец решения делает эскалацию ясной. Если утверждённая модель действительно требует совместной ответственности, зафиксируйте правило, разделение полномочий, процедуру совместного решения и выход из тупика. ИИ не должен создавать такое исключение.

Избегайте таких схем:

всем назначен R, и никто не знает, кто ведёт работу;
A получает самый старший участник без доказательства делегирования;
поставщику назначен A за решение покупателя, которое он принять не может;
одна роль готовит и независимо утверждает контроль там, где требуется разделение;
R остаётся пустым, потому что от A ждут, что он «всё организует»;
указано имя человека там, где ответственность должна пережить кадровые изменения.

Как различать Consulted и Informed?

Consulted означает, что мнение запрашивается и учитывается до действия или решения. Обмен двусторонний, поэтому в строке укажите момент консультации, ожидаемый вклад и действие при задержке или споре.

Informed означает, что роль получает результат, статус или решение. Коммуникация в основном односторонняя: роль Informed не получает права утверждения только потому, что получает отчёт.

Используйте C экономно: большая группа Consulted создаёт скрытый процесс консенсуса и замедляет работу. Спросите, даёт ли роль необходимую экспертизу, владеет ли затронутым контролем, представляет ли определённое обязательство перед заинтересованной стороной или должна участвовать по политике. Если ничего из этого не верно, может хватить I.

И наоборот, не переводите обязательного владельца контроля из C в I только ради сокращения процесса. Отразите фактическую обязанность, а процесс улучшайте отдельно.

Как безопасно поручить черновик ИИ?

Передайте версионный список строк, каталог ролей, доказательства полномочий, ограничения назначения и схему вывода. Потребуйте сохранять идентификаторы источников и отдельно возвращать нерешённые вопросы.

Ограниченная инструкция должна требовать:

не добавлять, не удалять, не объединять и не переименовывать роли или строки работ;
не выводить полномочия, компетенцию и доступность из должности, как и ответственность;
предлагать назначение, только если его подтверждают предоставленные доказательства;
помечать недостающие доказательства как NEEDS_OWNER_REVIEW;
отмечать строки без R, без A, строки, где указано несколько A, и несовместимые назначения;
различать C и I по заданному требованию к коммуникации;
сохранять ссылки на исходный процесс, устав, делегирование или политику;
выдавать предложения, а не окончательные назначения.

ИИ может нормализовать названия ролей, привести строки к стандартному шаблону, найти пустые ячейки и подготовить вопросы для рабочей встречи. Он не назначает владельца, не меняет делегирование, не разрешает конфликт обязанностей и не трактует молчание как принятие роли.

Как системно проверить матрицу?

Выполните горизонтальные и вертикальные проверки.

Горизонтальные проверки — по каждой строке:

Есть ли хотя бы одна роль R? Отсутствие R — пробел, который нужно устранить.
Есть ли ровно один A или задокументированное исключение?
Подтверждены ли фактические полномочия A и путь эскалации?
Действительно ли роли C нужны до завершения или решения?
Отражены ли все обязательные уведомления через I?
Требует ли контроль разделения подготовки и утверждения?

Вертикальные проверки — по каждой роли:

Не отвечает ли одна роль R за нереалистичную долю работы?
Не перегружена ли номинальная роль A несвязанными утверждениями?
Не стоит ли роль в C повсюду лишь потому, что её боялись исключить?
Определены ли замещение, отсутствие и передача дел?
Соответствуют ли назначения между командами и поставщиками реальным договорённостям?
Нет ли конфликтов между матрицей и процедурами, правами доступа или делегированием?

Количество ячеек не измеряет нагрузку: две работы могут требовать совершенно разного времени. Используйте матрицу для поиска вопросов, затем подтвердите нагрузку у людей и по плановым данным.

Если работа описана как операционные шаги, согласуйте её с процессом создания SOP. Если требуется связь требований с доказательствами, используйте матрицу прослеживаемости требований, а не перегружайте RACI.

Как согласовать, опубликовать и обновлять матрицу?

Заранее разошлите область, определения строк, роли, ссылки на доказательства и черновик. Пригласите фактических носителей ролей и владельца модели управления, а не только руководителей, назначающих работу другим.

Рассматривайте по одной строке:

подтвердите результат или решение и условие завершения;
подтвердите R по фактическому рабочему процессу;
подтвердите A по записи о полномочиях;
подтвердите необходимые связи C и I;
проверьте конфликты, отсутствие, нагрузку и эскалацию;
запишите согласие, возражения, пробелы в доказательствах и утверждённые исключения.

Не превращайте встречу в перепроектирование организации. Если участники обнаружили отсутствующую роль, неясное делегирование или несовместимый контроль, запишите управленческое действие и его владельца. Строка RACI остаётся нерешённой, пока это действие не утверждено.

Как публиковать и обновлять матрицу?

Запись выпуска должна содержать ID, область, версию, дату действия, версии источников, утверждающего, исключения и журнал изменений. Ссылайтесь на неё из процедур и контролей, чтобы после изменения обязанностей люди не пользовались экспортированной копией.

Перепроектирование процесса, смена фазы или поставщика, изменение делегирования или контроля, реорганизация, повторный срыв передачи и вакансия ключевой роли должны запускать пересмотр. Периодический пересмотр задавайте только там, где его требует политика; пересмотр по событиям часто полезнее.

При каждой редакции сравнивайте строки и назначения, объясняйте причины изменений, заново получайте согласие и сохраняйте предыдущую версию по политике записей. Изменившееся имя не всегда означает изменившуюся роль, а новое название должности не доказывает изменения полномочий.

NIST AI RMF Core требует документировать роли, ответственность, подотчётность, человеческий надзор и управление рисками ИИ.［4］ Применяйте ту же дисциплину к подготовке черновика с помощью ИИ: назовите, кто предоставляет доказательства, кто проверяет предложения, кто утверждает матрицу и кто следит за её применением.

Итоги

Ограничьте RACI конкретной работой и решениями.
Используйте утверждённые роли и полномочия как источник истины.
Сначала подтверждайте R, затем A; по умолчанию один A в строке.
Отличайте двусторонний C от одностороннего I.
Проверяйте пробелы, полномочия, нагрузку, конфликты и разделение обязанностей.
Получите согласие владельцев ролей, версионируйте матрицу и задайте триггеры пересмотра.

Часто задаваемые вопросы (FAQ)

Может ли ИИ автоматически назначить роли RACI?

Нет. Он может упорядочить доказательства и найти противоречия, но ответственность назначают только уполномоченные люди. Должность не доказывает право и доступность.

В каждой строке обязательно один Accountable?

Один A — рекомендуемое правило для ясного решения. Совместная ответственность допустима лишь по утверждённой модели, определяющей полномочия и выход из тупика.

Может ли один человек быть R и A?

Да, если роль выполняет работу и отвечает за результат, а контроль не требует разделения. Убедитесь, что нагрузка, устройство контроля и полномочия утверждения делают такое сочетание уместным.

Что делать, если в строке нет Responsible?

Считать это пробелом операционной модели. Не назначать ближайшую должность, а выяснить, у кого есть процесс, компетенция, доступ и обязанность, затем получить согласие.

Что делать с несколькими Accountable?

Проверьте, не объединяет ли строка несколько решений или результатов, и при необходимости разделите её. Если совместная ответственность реальна, задокументируйте правило и способ эскалации, а не оставляйте неоднозначные несколько A.

Сколько Consulted — слишком много?

Универсального числа нет. Каждый C должен иметь конкретный вклад и момент участия; получение результата обычно относится к I.

RACI и организационная схема — одно и то же?

Нет. Схема показывает подчинённость, RACI — участие в конкретной работе. Ни один документ сам по себе не доказывает делегирование.

Когда пересматривать RACI?

При изменении процесса, фазы, поставщика, полномочий, контроля или команды, а также в установленный политикой срок. Повторные сбои передачи тоже являются триггером.

Отказ от ответственности: Материал содержит общую информацию о распределении ответственности. Применяйте требования своей организации к управлению, труду, контролю, договорам и записям.

Источники:

UK Secure by Design — Agreeing Roles and Responsibilities — https://www.security.gov.uk/policy-and-guidance/secure-by-design/activities/agreeing-roles-and-responsibilities/
GOV.UK — Global HR Design Principles 2024 — https://www.gov.uk/government/publications/global-hr-design/global-hr-design-principles-2024-html
Northern Ireland Department of Finance — Programme and Project Management Tools and Techniques — https://www.finance-ni.gov.uk/articles/programme-and-project-management-tools-and-techniques
NIST — AI Risk Management Framework Core — https://airc.nist.gov/airmf-resources/airmf/5-sec-core/

Sources checked 4 сентября 2026 г.

Как создать матрицу RACI с помощью ИИ