AI-агент изменил бюджет в клиентском кабинете. Кто за это ответит?

В предыдущих материалах мы разобрали, что такое MCP в рекламе, как подключить его к рекламному кабинету и какие задачи уже можно передать AI-агенту. Но чем больше полномочий получает агент, тем важнее становится следующий вопрос: а что именно ему разрешено делать?

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

Первый вопрос возникает до первого изменения

Доступ агентству — это ещё не доступ AI-агенту.

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

Сотрудник агентства может технически авторизовать агента через свой аккаунт. И именно здесь появляется первая ловушка: техническая возможность выглядит как разрешение.

Хотя она не отвечает на три ключевых вопроса:

• разрешил ли клиент использовать конкретный AI-инструмент;
• какие данные и рекламные аккаунты можно ему передавать;
• какие действия агентство вправе делегировать без нового согласования.

Если хотя бы один ответ не зафиксирован, конфликт не устранён. Он просто отложен до первого спорного действия.

Но это только первый слой.

Что такое ads MCP и какие права он даёт агенту

Ads MCP — это MCP-сервер рекламной платформы: стандартный интерфейс, через который внешний AI-агент подключается к рекламному кабинету и вызывает его функции по текстовой инструкции. Агент работает не от своего имени, а от имени пользователя, который его авторизовал, и получает ровно те права, которые есть у этого пользователя. Разница между платформами — в том, ограничены ли эти права чтением или включают write-действия: создание кампаний, изменение бюджетов, смену статуса показа.

Платформа может сказать «да». Клиент — нет

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

• Meta Ads MCP server — часть семейства Ads AI connectors. Агент может создавать и редактировать кампании, группы объявлений и объявления, работать с каталогами и вытягивать отчётность. Владелец бизнеса может ограничить его правилами ads_mcp_rules: правило запрещает конкретное действие на конкретном рекламном аккаунте или каталоге — например, повышение бюджета выше заданного процента или изменение статуса показа. Те же контроли доступны в настройках Meta Business Suite, но пока в limited availability.
• TikTok for Business MCP Server идёт дальше всех: около 400 инструментов и «full lifecycle control» над кампаниями, группами и объявлениями. Агент может создавать кампании, менять бюджеты и корректировать ставки в реальном времени. Авторизация подключения действует 30 дней, затем её нужно продлевать.
• Google Ads MCP на момент публикации работает в read-only режиме: агент может читать данные, но не менять ставки, создавать ассеты или останавливать кампании.
• Snapchat Ads MCP также пока ограничен чтением — write-доступ заявлен на будущий релиз. Сначала агента одобряет администратор организации, затем каждый пользователь отдельно авторизует собственный доступ. Больше прав, чем есть у пользователя, агент не получает.

Права AI-агента в Meta, TikTok, Google и Snapchat: сравнение

Одни платформы уменьшают риск через read-only. Другие дают больше возможностей и предлагают устанавливать контроли доступа.

Но ни один технический контроль не читает договор между брендом и агентством.

Поэтому разрешение платформы — лишь первое из трёх «да», которые должны совпасть.

Три «да» перед одним действием

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

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

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

Три уровня полномочий AI-агента: схема

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

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

Два «да» уже есть. Этого всё равно недостаточно.

И тут возникает следующий вопрос: кто вообще должен произнести третье?

Кто нажимает approve, когда речь о деньгах

Самый безопасный ответ звучит просто: клиент подтверждает каждое изменение.

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

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

Рабочая схема строится на двух вопросах:

• входит ли изменение в утверждённый медиаплан;
• находится ли оно ниже заранее согласованного финансового порога.

Маршрут согласования изменения бюджета: схема

Если оба ответа — «да», подтверждение можно оставить за named approver со стороны агентства: например, медиабайером или аккаунт-менеджером.

Если хотя бы один ответ — «нет», решение возвращается бренду или владельцу рекламного аккаунта.

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

А AI-агент? Он может предложить действие и объяснить логику. Но ответственным субъектом от этого не становится.

Ответственность остаётся у тех, кто задал границы, предоставил полномочия и нажал approve.

Пять решений, которые нельзя оставлять «на потом»

Эта схема работает только тогда, когда её границы определены заранее. До первого write-действия нужно принять пять решений.

1. Одобрить инструмент. зафиксировать, какой агент, MCP-сервер и внешний провайдер разрешены, кто вправе подключить их и чей OAuth используется.
2. Разделить классы действий. отдельно определить read, draft, create paused, publish, budget, billing и permissions. Право читать статистику не должно автоматически означать право менять кампанию.
3. Назначить согласующего. указать конкретную роль или человека для каждого типа действия, а также замену на время отпуска или увольнения.
4. Установить лимиты. задать сумму, процент, частоту изменений и максимальный период автономной работы.
5. Определить stop-механизм. решить, кто и как мгновенно останавливает автоматизацию, отзывает токены и проверяет последствия.

Каждый из этих пунктов кажется очевидным.

Пока не меняется сотрудник, подрядчик или владелец процесса.

Сотрудник ушёл. А агент?

Системы забывают медленнее, чем люди.

Сотрудника можно удалить из чата и рекламного кабинета. Но связанный OAuth, refresh token, правило или scheduled workflow могут продолжить жить отдельно.

Поэтому offboarding AI-агента — это не одна кнопка. Нужно проверить всю цепочку:

• отозван ли OAuth и связанные refresh tokens — и на каком уровне: в Snapchat, например, участник отзывает не одного агента, а Ads MCP целиком, а администратор организации может отозвать доступ сразу для всех;
• удалены ли правила, scheduled workflows и автоматизации;
• известен ли срок жизни авторизации — в TikTok for Business MCP Server, например, окно составляет 30 дней; при этом истёкшая авторизация не заменяет явный отзыв доступа;
• сменился ли владелец approval-процесса;
• не сохранились ли доступы к другим клиентским аккаунтам;
• зафиксировано ли прекращение мандата со стороны бренда.

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

Иначе вместе с токенами следующему подрядчику передаётся чужая история решений. А вместе с ней — размытая ответственность.

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

Лог показывает действие. Но не решение

Platform activity log обычно отвечает на два вопроса: что изменилось и под каким пользователем.

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

Поэтому нужен не просто технический лог, а сквозной audit trail.

Сквозной audit trail действий агента: схема

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

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

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

Что особенно важно, когда деньги уже потрачены.

Если ошибочный спенд уже произошёл

В этот момент поздно спорить, кто «обычно» отвечает — бренд или агентство.

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

Поэтому нужен заранее согласованный incident-процесс:

• остановить автоматизацию и предотвратить новые изменения;
• сохранить platform logs, prompt, ответ агента и approval;
• сопоставить действие с медиапланом, лимитами и договорным мандатом;
• определить, на каком уровне произошёл сбой;
• зафиксировать корректирующие меры и, если применимо, порядок компенсации.

Только после этого можно обсуждать, кто нарушил правило и кто несёт последствия.

Главный вопрос — не «может ли агент»

Платформа может разрешать действие. Этого мало.

Сотрудник может иметь нужные права. Этого тоже мало.

Даже human approval не решает проблему, если согласующий не был уполномочен клиентом.

Поэтому перед подключением AI-агента агентству стоит задать другой вопрос:

💡 совпадают ли разрешение платформы, операционный мандат и договорённость с клиентом?

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

Если нет, автоматизация лишь ускорит то, что и раньше работало неясно.

FAQ

Может ли AI-агент менять бюджет в Google Ads?

Нет. Официальный Google Ads MCP работает в режиме read-only: агент читает данные, но не может менять ставки, создавать ассеты или останавливать кампании. Write-действия доступны в Meta Ads MCP и TikTok for Business MCP Server.

Достаточно ли агентского доступа, чтобы подключить AI-агента?

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

Какие права лучше давать AI-агенту?‍

По принципу least privilege — только те, которые нужны для конкретной задачи. Например, для анализа кампаний достаточно доступа на чтение. Если агент должен менять бюджеты или настройки, write-доступ стоит ограничить и дополнить лимитами, approval от человека и логированием изменений. Не стоит сразу давать агенту полный контроль над рекламным аккаунтом.

Кто отвечает, если AI-агент перерасходовал бюджет клиента?

Универсального ответа нет: распределение риска зависит от владельца аккаунта, договора, условий рекламной платформы, настроек инструмента и причины ошибки. Сам агент субъектом ответственности не становится — она остаётся у тех, кто задал границы, предоставил полномочия и нажал approve.

Как отозвать доступ AI-агента к рекламному кабинету?

Отозвать OAuth и связанные refresh tokens, удалить правила и scheduled workflows, передать владение approval-процессом и проверить доступы к другим клиентским аккаунтам. Уровень отзыва зависит от платформы: в Snapchat участник снимает Ads MCP целиком, а администратор организации может отозвать доступ сразу для всех.

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