Кто отвечает, если ИИ-агент слил бюджет: зона ответственности в эпоху автопилотов

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

Кто отвечает за перелив бюджета ИИ-агентом по умолчанию

Ответственность по умолчанию несёт оператор — компания или агентство, которое развернуло агента и дало ему доступ к рекламному кабинету и деньгам. ИИ-агент — это программная система, которая самостоятельно принимает решения и совершает действия (ставки, запуск кампаний, перераспределение бюджета) без подтверждения человека на каждом шаге. У такой системы нет правосубъектности: она не может подписать договор, не может быть истцом или ответчиком, и поэтому любое её действие по умолчанию приписывается тому, кто её запустил; разработчик модели и сама модель ответственности не несут (ATXP, 2026).

ATXP предлагает рабочую иерархию ответственности для ИИ-агентов, которая разводит четыре роли:

• Оператор (бизнес или агентство, развернувшее агента) — отвечает перед клиентом за перелив бюджета независимо от того, был ли умысел.
• Разработчик агента — делит ответственность, если в системе не было лимитов трат или возможности ручного override.
• Вендор базовой модели (OpenAI, Anthropic и аналогичные) — по своим пользовательским условиям снимает с себя ответственность за результаты и расходы, к которым привела работа модели.
• Конечный пользователь — отвечает только в мультитенантных схемах, где он формально зарегистрирован как оператор записи.

Для российского бизнеса это означает одно: если агентство или внутренняя команда подключает стороннего ИИ-агента к Яндекс.Директу или VK Рекламе, по умолчанию убыток ложится на того, кто настроил доступ и бюджет: разработчик инструмента в эту ответственность не входит. Разбираться, что именно умеет современный агентный ИИ в рекламе и где проходит грань его автономии, нужно до подключения, до первого расхода.

Почему вендор модели и разработчик агента обычно остаются в стороне

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

Разработчик агента, когда это внешний подрядчик (не внутренняя команда заказчика), делит ответственность только в одном случае — если в системе отсутствовали базовые защитные механизмы: лимиты трат, возможность остановить агента, override на уровне инфраструктуры. Если такие механизмы были предусмотрены, но оператор их не включил или отключил, ответственность возвращается к оператору.

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

Что уже работает как защита от перелива бюджета в медиабаинге

Рабочие guardrails против перелива бюджета — это инфраструктурные лимиты трат, человеческое одобрение выше порога суммы и внутренние агенты-контролёры; инструкция в промпте такой защитой не считается. Digiday (2026) описывает перелив рекламного бюджета ИИ-агентом как гипотетический риск, а не как задокументированный случай: подтверждённой статистики по реальным инцидентам в индустрии пока нет — это страх маркетологов, который опережает факты. Генри Вебстер из KSM Media формулирует этот страх прямо: «Would it blow a quarter's worth of budget in a weekend?» (Digiday, 2026) — то есть способен ли агент спустить бюджет целого квартала за выходные, пока никто не смотрит.

Отсутствие зафиксированных инцидентов не означает отсутствие риска — оно означает, что индустрия успела выставить защиту раньше, чем случился масштабный убыток. Несколько примеров таких защит из практики западных агентств и брендов (Digiday, 2026):

Гленнис Ричардс из Bayer формулирует норму, которая остаётся дефолтом в индустрии даже при высокой автономии агентов: она хочет, чтобы за ботом наблюдал человек (Digiday, 2026). Это согласуется с тем, что финансовую экспозицию по ошибкам агентов де-факто несут агентства: у брендов и у вендора модели больше рычагов переложить риск дальше по цепочке, у агентств — меньше, поэтому убыток падает именно на них.

Что меняет калифорнийский закон AB 316 и почему это важно даже не в США

AB 316 закрывает в суде аргумент «ИИ действовал автономно, поэтому я не виноват» — для всех, кто разработал, модифицировал или использовал ИИ-систему. Закон подписан в Калифорнии 13 октября 2025 года и действует с 1 января 2026-го, добавляя статью Cal. Civ. Code §1714.46 (JD Supra, 2025). Он распространяется на всю цепочку — от разработчика базовой модели до компании, которая просто развернула агента у себя, — и убирает одну конкретную линию защиты.

Важная деталь: AB 316 не вводит строгую (безусловную) ответственность. Причинность, предвидимость вреда и сравнительная вина остаются доступными защитами в суде (JD Supra, 2025). Закон не делает компанию автоматически виновной — он просто запрещает ей сказать «агент решил сам» как единственное оправдание.

Практическое следствие для бизнеса: документация становится юридическим активом — формальной бумагой она больше не считается. Логи тестирования, мониторинга, доказательства человеческого надзора и аудиторские следы по обновлениям модели — это то, чем компания доказывает разумную осторожность, когда аргумент об автономности ИИ больше недоступен (JD Supra, 2025). Пересмотр договоров с вендорами — индемнификация, лимиты ответственности — выходит на первый план именно по этой причине.

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

В Евросоюзе единая Директива об ответственности за ИИ была отозвана Еврокомиссией в 2025 году из-за разногласий между странами — вопрос смещается к национальным судам и к пересмотренной Директиве о продуктовой ответственности, которая распространит строгую ответственность производителя на софт, включая ИИ, но только для продуктов, выпущенных на европейский рынок после 9 декабря 2026 года — это срок, к которому страны ЕС обязаны перенести новые правила в национальное законодательство. То есть защиты по типу AB 316 в Европе пока формально нет.

Что из западной практики действительно переносится на российский рынок

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

Прямо переносится:

• Перенос лимитов трат с уровня приложения на уровень инфраструктуры — промпт-инъекцией можно обойти инструкцию в коде, но не отбивку вызова на уровне API-доступа.
• Изолированные API-ключи и доступы на каждого агента — чтобы ограничение по одному агенту не зависело от честности остальных.
• Обязательное человеческое одобрение выше порога суммы — это превращает «агент решил сам» в «человек одобрил», что выгоднее и с точки зрения контроля, и с точки зрения будущего спора.
• Условие о распределении ответственности при переливе бюджета ИИ-агентом — прямо в договоре с агентством и с вендором ИИ-инструмента. По умолчанию такие контракты молчат об этом (ATXP, 2026; Digiday, 2026) — значит, убыток достанется тому, у кого слабее переговорная позиция.

Не переносится прямо:

• AB 316 как норма права — в России нет запрета на аргумент об автономности ИИ в суде.
• Утверждения о позиции Яндекс.Директа или VK Рекламы по инцидентам с ИИ-агентами — открытых данных по реальным случаям в России на момент написания статьи нет, и выдавать догадки за факт нельзя.

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

Как распределить ответственность до того, как агент потратит бюджет

Распределять ответственность нужно на этапе внедрения — через инфраструктурные лимиты, договор и журнал решений агента; разбор инцидента постфактум для этого не годится. Научная модель из arXiv (2026) предлагает делить вред по типу взаимодействия человека с агентом — архитектура системы здесь вторична, — и это помогает понять, где именно лежит риск в вашей конкретной настройке:

1. Автономный дрифт — агент сам меняет подцели без подтверждения пользователя. Это аналог ситуации, когда сотрудник отклоняется от прямого поручения по собственной инициативе: ответственность пользователя снижается, у разработчика возникает строгая ответственность за дефект дизайна, если в системе отсутствовали проверки на уровне исполнения.
2. Чистый инструмент — человек контролирует каждый шаг, агент только исполняет команды. Здесь применяются обычные нормы о недостатках продукта, как к любому софту.
3. Совместное планирование — ИИ сам придумывает способ достичь цели, поставленной человеком (похоже на тест контроля независимого подрядчика), или человек выполняет рекомендацию ИИ без проверки (похоже на профессиональную халатность того, кто решение принял).

Иллюстрация того, почему общая формулировка задачи опасна: в кейсе из arXiv (2026) агент, которого попросили «обеспечить доступ» на деловой форум, сам согласился на спонсорский взнос в 24 000 швейцарских франков (примерно 31 000 долларов США). Пользователь не смог заплатить эту сумму, организаторы угрожали не пустить его на форум, и в итоге он заплатил почти 4000 евро, чтобы всё же попасть внутрь. Общая просьба обеспечить доступ не должна автоматически превращаться в разрешение на пятизначное финансовое обязательство — и интерфейс обязан давать человеку проверить трату до того, как агент её совершит, — не постфактум.

Отсюда — рабочий «стандарт разумного агента» (arXiv, 2026) для любой рискованной операции, включая управление рекламным бюджетом:

• лимит трат на уровне инфраструктуры — ограничение на уровне инструкции агенту ненадёжно;
• предварительный просмотр операции до её выполнения (dry-run) вместо отчёта по факту;
• явное одобрение человека для сумм выше установленного порога;
• явное обозначение неопределённости — агент показывает, где он не уверен, вместо того чтобы маскировать это уверенным тоном;
• форензик-журнал — таймстемпированная запись всех вводов, выводов, вызовов инструментов и одобрений.

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

Частые ошибки

• Доверить агенту прямой доступ к рекламному кабинету без лимита трат на уровне платформы. Инструкция «не превышай бюджет» в промпте обходится переформулировкой задачи или промпт-инъекцией; защищает только ограничение на уровне API-ключа или кабинета.
• Считать, что договор с вендором ИИ-инструмента уже покрывает финансовую ответственность за перелив. По умолчанию пользовательские условия вендоров моделей снимают с них ответственность за расходы (ATXP, 2026) — если в договоре с агентством или подрядчиком это не прописано отдельно, убыток достанется бизнесу.
• Давать агенту общую, не детализированную задачу на крупную трату. Формулировка вроде «обеспечь присутствие на мероприятии» или «выжми максимум из бюджета» оставляет агенту пространство для решений, которые человек не рассматривал как часть задачи.
• Не вести журнал решений агента. Без таймстемпированного лога вводов, выводов и одобрений невозможно доказать ни разумную осторожность оператора, ни момент, где агент вышел за рамки.
• Переносить калифорнийскую логику AB 316 на российский договор как уже действующую норму. В России нет закона, запрещающего ссылаться на автономность ИИ в суде; рассчитывать на эту норму как на защиту в споре с подрядчиком в России нельзя.
• Считать отсутствие публичных инцидентов доказательством безопасности. Digiday (2026) описывает перелив бюджета ИИ-агентом как гипотетический, а не задокументированный риск; то, что инцидентов пока не видно, во многом результат того, что индустрия уже поставила guardrails, а не доказательство, что угроза исчезла.

Источники

• Marketers put up guardrails as AI agents reshape programmatic buying — Digiday, 2026
• Who Is Liable When an AI Agent Overspends? — ATXP.ai, 2026
• California Eliminates the "Autonomous AI" Defense: What AB 316 Means for AI Deployers — JD Supra, 2025
• Acting with AI: An Interaction-Based Framework for Agentic Tort Liability — arXiv, 2026

FAQ

Кто юридически отвечает, если ИИ-агент слил рекламный бюджет?

По умолчанию отвечает оператор — бизнес или агентство, которое развернуло агента и дало ему доступ к бюджету. У ИИ-агента нет правосубъектности, поэтому его действия приписываются тому, кто его запустил: разработчик модели в эту цепочку не входит (ATXP, 2026).

Может ли вендор модели нести ответственность за перелив?

Обычно нет: пользовательские условия крупных вендоров моделей снимают с них ответственность за финансовые решения, принятые на основе их продукта. Разработчик самого агента делит ответственность только тогда, когда в системе отсутствовали базовые защитные механизмы — лимиты трат или возможность остановить агента (ATXP, 2026).

Действует ли в России закон, аналогичный калифорнийскому AB 316?

Нет. AB 316 — норма калифорнийского права, которая убирает защиту «ИИ действовал автономно» в суде (JD Supra, 2025). В России специального регулирования для таких споров нет, и они решаются через общие нормы о причинении вреда и условия договора.

Были ли в России зафиксированные случаи перелива рекламного бюджета ИИ-агентом?

Открытых данных по таким инцидентам в России на момент написания статьи нет. Digiday (2026) показывает похожую картину и в западном медиабаинге: индустрия обсуждает этот риск как гипотетический, подтверждённых случаев перелива там тоже не приводится — риск здесь пока воспринимается как будущий, не как уже случившийся.

Какие практические меры снижают риск перелива бюджета ИИ-агентом?

Лимиты трат на уровне инфраструктуры (а не в инструкции агенту), изолированные доступы на каждого агента, обязательное одобрение человека выше определённого порога суммы и полный журнал решений агента (ATXP, 2026; arXiv, 2026).

Нужно ли прописывать ответственность за действия ИИ-агента в договоре с подрядчиком?

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

Отвечает ли конечный пользователь за ошибку агента?

Как правило нет — если он не зарегистрирован формально как оператор системы в мультитенантной схеме. В большинстве случаев ответственность лежит на компании или агентстве как операторе: конкретный сотрудник, который нажал кнопку запуска, в стороне (ATXP, 2026).

Если зона ответственности за ИИ в маркетинге для вас вопрос уже практический, встроенный в реальные бюджеты и контракты, на интенсиве Marketing OS разбирают, как выстраивать систему контроля и P&L маркетинга в условиях, когда часть решений принимает не человек.