Orkas Orkas
Главная Блог Право записи для агента
Управление

Прежде чем дать агенту право записи в рекламном аккаунте

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

В обсуждении на r/PPC людям, использующим ИИ-инструменты с реальным правом записи в аккаунты клиентов, задали четыре вопроса: в чём инструмент ошибся, как вы контролируете его работу, действительно ли он сократил трудозатраты и что вы отключили через шестьдесят дней. Ответы сложились во что-то более полезное, чем рекомендация инструмента, — список мер контроля.

Вот этот список. По нему можно проверять любого поставщика, в том числе нас.

Коротко Журнал аудита и этапы согласования — это и есть продукт Модель можно заменить. Необъяснимые изменения в аккаунте клиента — нельзя. Ниже — семь обязательных мер контроля и четыре меры, которых в Orkas пока нет.
Скачать Orkas — бесплатно

Семь мер контроля

1. Чтение актуальных данных перед рекомендацией

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

2. Показ изменений перед записью, а не их описание

Рассказ агента — не доказательство. «Я снижу ставку для неэффективных объектов» — это фраза. ставка 1.40 → 0.95 для 3 целей — это конкретные изменения. Проверить можно только второе.

3. Ограничение масштаба последствий

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

4. Подтверждение человеком только существенных изменений

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

5. Классификация под контролем приложения, а не инструмента

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

6. Журнал аудита, который можно передать клиенту

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

7. Механизм отката, созданный до того, как он понадобится

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

Ошибка, которую не ловит ни одна из этих мер

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

Широко разошёлся рассказ продавца со здоровой рентабельностью рекламных расходов (ROAS) 3,5–4x: он позволил модели убедить себя перестроить кампании и потерял деньги. Самый популярный ответ объясняет причину: модель не знает ни ваших запасов, ни договорных ограничений, ни истории аккаунта. Как выразился другой участник, они не умеют выбирать между двумя хорошими вариантами. В поиске закономерностей эти модели действительно сильны. В выборе между двумя обоснованными стратегиями — нет.

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

Что Orkas обеспечивает сегодня

Orkas — настольное приложение с несколькими агентами и приоритетом локальной работы. Его коннекторы для торговли — Shopify, Amazon Seller Central, eBay, Etsy, TikTok Shop, Shopee, WooCommerce, Walmart и другие — работают через слой политик, которым управляет само приложение. Восемь из перечисленных мер реализованы, а четыре — нет. Лучше вы узнаете об этом здесь, чем после ошибочной записи.

Мера контроляСтатусЧто реализовано
Четырёхуровневая модель риска действийКаждое действие коннектора относится к R / W / H / D — чтение, запись, действие с существенными последствиями, разрушительное действие
Предпросмотр перед записьюДействия записи требуют подтверждения с предпросмотром, а не выполняются сразу
Новое подтверждение для движения денегДействия с существенными последствиями помечаются как внешнее или финансовое изменение и требуют нового подтверждения
Ограничение масштаба последствийЛимит числа объектов, которые может затронуть одно действие за вызов, проверяется до его выполнения
Подключение только для чтенияКоннектор можно ограничить перечислением возможностей, описанием действий и чтением
Классификация под контролем приложенияРиск определяется фиксированной таблицей приложения по точному идентификатору действия; подсказки инструмента не могут расширить доверие
Блокировка неизвестных действий по умолчаниюНеклассифицированное действие считается действием с существенными последствиями; торговое действие без доверенной политики отклоняется и не выполняется
Список блокировок на уровне продуктаФиксированный список действий, которые никогда не доступны, независимо от выданных разрешений
Отдельные разрешения на операции (создание / редактирование / приостановка)Разрешения разделены по уровню риска, а не по операциям
Денежный лимит расходов или максимальный процент изменения бюджетаЛимит ограничивает число объектов, а не сумму
Механизм откатаНе реализован. Пакет изменений отменяется вручную
Экспортируемый неизменяемый журнал аудитаВызовы коннекторов отслеживаются для телеметрии; это не журнал аудита для клиента

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

Другой путь: вообще без права записи

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

Почему это трудно купить в готовом виде

API платформ обычно бесплатны. Барьер — согласование, а не цена. Собственный MCP-сервер Amazon Ads требует действующих учётных данных Ads API. Shopify требует, чтобы приложение принадлежало продавцу и находилось в той же организации, что и магазин. TikTok Shop требует Custom App, прошедшее проверку разработчика-продавца. eBay требует набор ключей Developers Program для рабочей среды и собственный ключ подписи. Для продавца-одиночки каждый из этих шагов — отдельный проект, а не заполнение формы. Поэтому многие используют экспорт и вообще ничего не подключают. Это разумный выбор, и любой достойный инструмент должен хорошо работать и в таком режиме.