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

Привет, коллеги. Пока AI в компании помогает только писать тексты, собирать сводки или искать идеи, вопрос прав доступа кажется вторичным. Но как только AI начинает публиковать, менять данные, отправлять письма, запускать кампании или создавать задачи от имени бизнеса, это уже не «ещё один удобный инструмент». Это исполнительный слой. И у него должен быть понятный контур полномочий.

Я уже разбирал, кто в компании должен быть владельцем AI-workflow, показывал, как внедрять AI в команду без теневого хаоса, и недавно писал, что ломается в AI-workflow через 30 дней. Следующий логичный слой после этого — не абстрактная «безопасность AI», а практический вопрос: кто вообще имеет право нажимать кнопку запуска от имени бизнеса, кто может пропускать risky action дальше по контуру и у кого должен быть ручной стоп.

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

Почему вопрос прав на запуск AI возникает раньше, чем кажется

Самая частая ошибка — считать, что governance нужен только корпорациям. На практике он нужен уже в тот момент, когда AI начинает делать что-то необратимое: публиковать пост, обновлять карточку товара, отправлять письмо, создавать заявку в CRM, менять бюджет, перезаписывать базу знаний, трогать прод. Не потому, что AI «опасный», а потому что бизнес-последствия у этих действий вполне обычные и реальные.

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

С чего начинать: не с ролей людей, а с матрицы действий

Я бы не начинал с вопроса «кому доверяем». Я бы начинал с вопроса «какие действия AI вообще умеет делать от имени бизнеса». Это намного честнее и технически полезнее. Когда список действий лежит на столе, дальше уже можно назначать роли и границы.

Такой подход хорошо охлаждает лишний энтузиазм. Очень быстро становится видно, что «запуск AI» — это не один флажок. Это пачка разных действий с разной ценой ошибки. А значит, и право запуска не может быть одинаковым для всех.

Какие роли реально нужны в праве запуска AI

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

Роль	Что можно	Чего нельзя без эскалации
Operator	Запускать безопасные сценарии, готовить черновики, проверять входные данные, перезапускать workflow в рамках инструкции.	Публиковать наружу, менять рискованные данные, обходить обязательный review.
Reviewer	Подтверждать контент, сверять output, открывать следующий шаг, возвращать правки в систему.	Менять правила доступа, обходить лог событий, скрывать инциденты.
Owner	Разрешать рискованные действия, утверждать сценарий, лимиты, список интеграций и критические публикации.	Передавать право запуска «по умолчанию всем» без явной матрицы и стоп-линии.
Stop-holder	Останавливать сценарий, если найден риск: неверный контекст, инцидент, доступ, утечка, публикация не туда.	Игнорировать остановку без разбора причин и follow-up.

Самый важный момент здесь — manual stop. В зрелой системе право остановить сценарий должно быть не только у owner. Иначе всё превращается в опасную скорость: все видят, что что-то пошло не туда, но никто формально не может поставить контур на паузу.

Где чаще всего ломается матрица прав

По моему опыту, неудачные AI-контуры ломаются не на сложной криптографии и не на редких edge cases. Они ломаются в бытовых вещах:

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

Как я бы разделил права для маркетинга, продаж и операционки

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

Контур	Operator	Reviewer	Owner approval
Контент и маркетинг	Собрать исследование, черновик статьи, post pack, SEO-рекомендации.	Подтвердить фактуру, тон, ссылки, брендовые риски, каналы публикации.	Финальная публикация от имени бренда, если это новая рубрика, острый кейс или спорный месседж.
Продажи и CRM	Разметить лиды, подготовить follow-up, создать черновик ответа.	Проверить сегментацию, критерии приоритета, корректность данных.	Массовые изменения в CRM, триггерные рассылки, удаление или слияние данных.
Операционка и знания	Обновить черновик инструкции, оформить handoff, собрать чек-лист.	Проверить, что новая версия не ломает текущий маршрут и не убирает контрольные точки.	Изменение мастер-инструкций, production workflow и правил доступа.

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

Что должно быть у каждого сценария кроме прав доступа

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

1. Источник запуска. Кто инициировал сценарий: человек, расписание, входящий сигнал, webhook.
2. Уровень риска. Внутренний черновик, изменение внутри команды, внешнее действие.
3. Лог подтверждения. Кто одобрил рискованный шаг и на каком основании.
4. Ручной стоп. Кнопка или команда, которая реально останавливает сценарий, а не просто пишет в чат.
5. Разбор after-action. Если был инцидент, знание возвращается в инструкцию, а не остаётся на уровне «запомним на будущее».

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

Минимальная матрица, с которой уже можно жить

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

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

Вывод

Право запускать AI от имени бизнеса — это не вопрос доверия к одному человеку и не спор про «боимся ли мы AI». Это вопрос операционного дизайна. Пока AI только помогает думать, жёсткая матрица может казаться избыточной. Но как только он начинает публиковать, обновлять, отправлять и менять что-то в реальном контуре бизнеса, у вас должны быть роли, уровни риска, review и ручной стоп.

Если этого нет, AI либо станет игрушкой без влияния, либо опасным shortcut, который держится на памяти пары сильных людей. Нормальная система лежит посередине: быстрый запуск там, где риск низкий, и жёсткий контур подтверждения там, где ошибка дорогая.