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

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

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

Зафиксируйте полномочие и ответственного владельца до написания правил.

Заморозьте пакет утверждённых источников и не скрывайте противоречия.

Разделяйте обязательные правила, рекомендации, исключения и вопросы.

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

ИИ не должен писать «требуется законом» или «утверждено» без решения людей.

Вводите политику только после подписания конкретной версии уполномоченными ролями.

Откуда политика получает полномочия?

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

Ядро NIST AI RMF связывает управление риском с политиками, процессами, ответственностью и документированными ролями.［1］ Профиль NIST для генеративного ИИ добавляет характерные для таких систем риски.［2］ Эти документы дают полезные ориентиры, но не назначают согласующих и не превращают добровольную рамку в правовую обязанность.

До написания правил составьте реестр оснований:

ID основания	Источник	Область	Владелец	Статус толкования
A-01	Решение руководства	Названные подразделения	Спонсор	Подтверждено
A-02	Проверенное юристом требование	Юрисдикция и действие	Юрист	Подтверждено/спорно
A-03	Решение о риске безопасности	Системы и данные	Владелец безопасности	Подтверждено
A-04	Положение договора	Указанное соглашение и стороны	Владелец договора	Подтверждено/истекло

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

Как определить область, роли и структуру?

Укажите, кого, что, где и когда охватывает политика: организации, категории работников, системы, классы данных, места и условия вступления в силу. Назовите существенные исключения. Политика, которая говорит «все пользователи», но не определяет пользователей, ведёт к непоследовательному применению.

NIST SP 800-18 Rev. 2 подчёркивает документирование границ, ролей, обязанностей и мер в системном планировании.［3］ Не каждая политика является планом безопасности, но область и ответственность должны быть столь же проверяемыми.

Используйте устойчивую структуру:

цель и основание;
область и исключения;
определения;
положения политики;
роли и обязанности;
исключения и обжалование;
контроль и применение;
записи и сроки хранения;
цикл пересмотра и управление изменениями;
согласования и дата вступления в силу.

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

Как составить внутреннюю политику с ИИ с опорой на источники?

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

Это кандидат на проверку, а не создание полномочий.
Для каждого положения укажи ID основания.
Различай обязательное правило, рекомендацию, исключение и нерешённый вопрос.
Используй определённые термины точно.
Не утверждай, что правило требуется законом, если этого не говорит
переданное основание, одобренное юристом.
Не утверждай и не намекай, что положение уже согласовано.
Отмечай конфликт, неясную область, неназванную роль и пробел контроля.
Предлагай класс согласования, но не окончательное решение.

Пишите одну исполнимую идею в одном положении. Используйте ясный язык: знакомые слова, прямые глаголы, короткие предложения и конкретные условия. GOV.UK рекомендует простые слова и отказ от лишнего жаргона.［4］ Ясность важна: расплывчатая политика выглядит гибкой, но перекладывает трудные решения на отдельных сотрудников.

Избегайте абсолютов вроде «всегда», «никогда» или «нулевой риск», если основание действительно не создаёт такого правила. Избегайте пассива, который скрывает исполнителя: «Запросы должны быть рассмотрены» слабее, чем «Владелец приватности рассматривает запросы до согласования».

Как отмечать неизвестное и противоречия?

Не позволяйте ИИ сглаживать конфликт оснований, выбирая самую удобную фразу. Запишите конфликт, затронутое положение, владельцев и необходимое решение. Используйте в тексте видимые метки вроде UNRESOLVED-U03, а не комментарий, который может пропасть при экспорте.

Классифицируйте пробелы:

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

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

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

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

Используйте шаблон:

Policy ID	Authority	Scope	Rule	Rationale / evidence	Owner	Approval class	Approver	Status	Exception owner	Review date
P-01	A-01	Финансовые роли	Проект правила	Решение	Владелец финансов	Финансы	Названная роль	Draft	Делегат	Дата
P-02	A-02	Данные работников	Проект правила	Записка юриста	Владелец данных	Право + приватность	Названные роли	Needs review	Владелец приватности	Дата
P-03	A-03	Производственные системы	Проект правила	Решение о риске	Владелец безопасности	Безопасность + операции	Названные роли	Draft	Руководитель безопасности	Дата

Зафиксируйте допустимые статусы: Draft, Needs evidence, Needs domain review, Approved, Rejected, Superseded, Effective. ИИ не выставляет Approved или Effective ни при каких условиях: эти значения требуют записанного решения уполномоченной роли.

Класс согласования — метаданные маршрутизации, а не вердикт. Положение с меткой «Право + приватность» ещё не прошло ни одну из этих проверок. Если согласующие расходятся, сохраните оба решения и путь эскалации, а не просите ИИ усреднить мнения.

Как описать исключения, обжалование и применение?

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

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

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

Как провести утверждение версии политики?

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

ID и версия политики:
Проверенные положения:
Класс согласования:
Проверенные основания:
Конфликты и условия:
Решение: утвердить / отклонить / доработать
Полномочие назначить дату действия: да / нет
Имя и роль:
Дата решения:
Дата пересмотра:

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

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

Каких частых ошибок избегать при подготовке политики?

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

Итоги

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

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

Может ли ИИ определить, что требует закон?

Нет. Он может упорядочить материалы, одобренные юристом или иначе авторитетные, но толковать правовые требования и их применимость должны квалифицированные люди.

Может ли ИИ утвердить политику?

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

Чем политика отличается от SOP?

Политика задаёт утверждённые правила и ответственность; SOP описывает повторяемые действия для их выполнения.

Всем положениям нужен один согласующий?

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

Как показывать нерешённые вопросы?

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

Можно ли ввести политику до завершения всех задач?

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

Как часто пересматривать политику?

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

Это юридическая или комплаенс-консультация?

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

Источники

Sources checked 31 августа 2026 г.

NIST AI RMF, “Govern, Map, Measure, Manage” — https://airc.nist.gov/airmf-resources/airmf/5-sec-core/
NIST, “Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile” — https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence
NIST, “SP 800-18 Rev. 2: Developing Security, Privacy, and Cybersecurity Supply Chain Risk Management Plans for Systems” — https://csrc.nist.gov/pubs/sp/800/18/r2/final
GOV.UK Publishing, “Clear language” — https://guidance.publishing.service.gov.uk/writing-to-gov-uk-standards/writing-guidelines/clear-language/

Как составить внутреннюю политику с ИИ: согласования