Регламент использования ИИ в маркетинговой команде
Что закрепить в коротком регламенте по ИИ: разрешённые данные, карта ролей, обязательная проверка результата и порядок пересмотра правил. С образцом разделов, полями для заполнения и оговоркой: иностранные ориентиры — не российский закон.

Содержание
- Зачем маркетинговой команде письменный регламент по ИИ
- Что зафиксировать: данные, результат и ответственность
- Карта ролей: автор, проверяющий, владелец решения
- Какие данные нельзя загружать во внешние сервисы
- Обязательная проверка результата до публикации
- Как внедрить регламент без сопротивления команды
- Как пересматривать правила по мере изменения задач
Сотрудники уже используют ИИ, но правила живут в переписке и в голове одного человека. Регламент превращает эту практику в понятный документ. Он отвечает на три вопроса: какие данные можно передавать во внешний сервис, кто проверяет результат и кто отвечает за решение. Ниже — минимальный состав такого документа, карта ролей и порядок пересмотра. Это рабочий инструмент управления, а не бюрократия.
Зачем маркетинговой команде письменный регламент по ИИ
Устные договорённости работают, пока команда маленькая. При найме и подключении подрядчиков они распадаются: каждый трактует границы по-своему. Регламент нужен не для контроля ради контроля, а чтобы убрать разброс решений. Сотрудник получает короткий ответ: что можно, что нельзя и кто отвечает.
Международные ориентиры советуют закреплять правила заранее. Руководство NIST по управлению рисками ИИ (AI RMF 1.0, январь 2023) относит политику, процедуры и распределение ролей к функции GOVERN. Такой документ задаёт порядок, а не готовый текст для вашей команды.
Что зафиксировать: данные, результат и ответственность
Не пытайтесь описать всё сразу. Начните с трёх областей, которые чаще всего вызывают спор в команде.
| Область | Вопрос команды | Что записать в документ |
|---|---|---|
| Данные | Что можно передавать во внешний сервис? | Перечень разрешённых и запрещённых категорий данных |
| Результат | Как убедиться в качестве? | Обязательные шаги проверки и критерий готовности |
| Ответственность | Кто отвечает за публикацию? | Роли, подпись и порядок эскалации спорного случая |
Ниже — короткий образец разделов регламента. Скопируйте его и заполните поля под свою команду.
- Назначение и область: [какие команды и задачи попадают под регламент].
- Разрешённые данные: [какие категории можно передавать во внешний сервис].
- Запрещённые данные: [что не уходит во внешний сервис].
- Роли: [автор запроса], [проверяющий], [владелец решения], [владелец регламента].
- Проверка результата: [обязательные шаги до публикации].
- Порядок эскалации: [кто решает спор].
- Пересмотр: [периодичность], [кто ведёт версию].
Держите основную часть короткой. Одна страница правил работает лучше, чем тридцать страниц, которые никто не открывает. Детали и примеры вынесите в приложения. Храните шаблон и приложения рядом с другими рабочими документами команды.
Назначьте автора регламента. Обычно это руководитель маркетинга или операционный владелец процесса. Он собирает требования, согласует спорные пункты с юристом и отвечает за актуальность документа. Без назначенного автора регламент быстро устаревает и теряет силу.
Карта ролей: автор, проверяющий, владелец решения
Ошибки чаще всего возникают там, где один человек готовит материал и сам же его утверждает. Разделите роли даже в маленькой команде.
| Роль | Задача | Чего не делает |
|---|---|---|
| Автор запроса | Формулирует задачу, готовит допустимые данные, сохраняет исходники | Не публикует результат без проверки |
| Проверяющий | Сверяет факты, цифры, ссылки и тон, помечает непроверенное | Не утверждает то, что не смог проверить |
| Владелец решения | Утверждает публикацию и отвечает за обещания клиенту | Не перекладывает ответственность на сервис ИИ |
| Владелец регламента | Ведёт документ, обучает команду, назначает пересмотр | Не оставляет правила без даты пересмотра |
Роли могут совмещаться, но не на одном и том же материале. Если сотрудников мало, проверяющим назначают другого человека, а не автора. Для крупных решений владельца определяют отдельно.
Отдельно опишите порядок эскалации. Если автор и проверяющий не согласны, спор решает владелец решения с учётом риска. Такой пункт снимает простои и не превращает разногласие в личный конфликт.
Какие данные нельзя загружать во внешние сервисы
Это самая чувствительная часть регламента. Даже если сервис обещает не использовать данные для обучения моделей, правовое основание для передачи остаётся вашей задачей, а не задачей поставщика.
- персональные данные клиентов и сотрудников, если не проверено применимое основание и не получено согласие, когда оно требуется;
- договоры, цены, условия сделок и коммерческая тайна;
- внутренние финансы, зарплаты, данные доступов и ключи;
- материалы под соглашением о неразглашении от заказчика;
- записи звонков и рабочую переписку, пока не проверены применимое основание, права доступа и правила компании; согласие — только когда оно требуется.
Обработку персональных данных регулирует отдельное законодательство и внутренние правила компании. Если задача требует таких данных, сначала согласуйте основание с юристом, а не после запуска. Регламент не заменяет юридическую проверку.
Обязательная проверка результата до публикации
Проверка должна быть повторяемой. Опишите шаги так, чтобы их мог выполнить любой сотрудник, а не только автор запроса.
- Подтвердите каждый факт по первоисточнику.
- Сверьте каждую цифру и цитату с источником.
- Проверьте, что цитата не вырвана из контекста.
- Откройте каждую ссылку и убедитесь, что она работает.
- Проверьте текст на персональные данные и коммерческую тайну.
- Сверьте тон и обещания с политикой компании.
- Зафиксируйте подпись проверяющего.
Шаг с подписью важен: он превращает проверку из намерения в действие. В журнале публикаций отмечайте, кто проверил материал и на какие источники он опирался. Так видно, где процесс дал сбой.
Разбирайте ошибки, которые прошли проверку. Каждый такой случай — повод уточнить критерий или добавить шаг. Записывайте вывод коротко, чтобы правило осталось рабочим, а не превратилось в длинный список запретов.
Как внедрить регламент без сопротивления команды
Регламент, спущенный сверху как запрет, обходят. Правила принимают, когда они экономят время и снимают неопределённость.
- Начните с одной страницы и одной частой задачи.
- Объясняйте требование через риск, а не через запрет.
- Дайте примеры допустимых и недопустимых запросов.
- Встройте проверку в текущий процесс, а не поверх него.
- Назначьте владельца и дату пересмотра.
Объясните команде, что регламент описывает обязанности и порядок проверки результата. Он не снимает личную ответственность и не даёт юридической гарантии, но снимает неопределённость.
Как пересматривать правила по мере изменения задач
Инструменты и задачи меняются быстрее, чем документы. Назначьте регулярный пересмотр: раз в квартал или сразу после смены инструмента. Другие материалы по теме собраны в блоге CMO.PRO.
- Храните версию и дату каждого изменения.
- Собирайте случаи, где правило мешало или не помогало.
- Обучайте новых сотрудников по последней версии.
- Убирайте пункты, которые потеряли смысл.
Пример (условный). Маркетинговый отдел из десяти человек обкатывает регламент на одной задаче — подготовке писем по открытым материалам. Правила описаны, но итог проверки зависит от конкретной команды. Это иллюстрация порядка действий, а не результат проекта.


