1544 видео, ноль рекламы и около $1200 расходов: как ИИ автоматизировал слив денег
Полторы тысячи видео лежат в черновиках. В Google Ads не загрузили ни одного. А платная генерация продолжала запускаться каждый час.
Владелец оценил расходы примерно в $1200.
Самая неприятная деталь этой истории: для такого результата системе даже не потребовалось эффектно сломаться. Она продолжала производить видео. День за днём.
Именно поэтому этот кейс стоит прочитать каждому, кто хотя бы раз говорил нейросети: «Напиши мне скрипт, чтобы всё работало автоматически».
Самая страшная цифра здесь — ноль
В проекте автоматизации Google Ads обнаружили 1544 видео со статусом draft — черновик.
Из них 1470 были созданы через Veo, генератор видео Google. По разбору базы, эти генерации накопились с 22 августа. В Google Ads видео не загружались.
Представьте склад, на который исправно привозят новые коробки. Производственная линия работает. Электричество оплачивается. Склад заполняется. Только до магазина товар почему-то не доезжает.
Вот примерно это и произошло с рекламными креативами.
Сами ролики при этом могут быть вполне пригодными. Мы не знаем, использовались ли они где-то ещё. Но в рамках описанного процесса подтверждённый результат для загрузки видео в Ads — ноль.
Для системы, которая должна помогать с рекламой, разница между «создано» и «дошло до рекламного кабинета» слишком дорогая, чтобы её игнорировать.
Один час. Ещё один. Потом целый месяц
Генерацией управлял workflow в n8n — сервисе, который связывает разные программы и запускает автоматические действия.
Каждый час он обращался к скрипту. Скрипт запускал генератор видео.
По данным разбора, с 6 сентября создавалось примерно 44–48 роликов в день. Почасовая автоматизация продолжала работать до вечера 8 октября.
Масштаб легко оценить даже без тарифов.
Если условный запуск производит два видео, то за сутки получается 48. За 30 дней — 1440.
Ни одного бешеного скачка нагрузки для этого не требуется. Достаточно привычного расписания.
Именно такой расход легко пропустить: каждый отдельный запуск может выглядеть совершенно обычным. Проблема становится заметной, когда складываешь все запуски, стоимость и судьбу результата.
У расписания нет усталости. Ему не надоест производить очередную партию, пока предыдущие лежат без движения.
У «работает» есть очень дорогая обратная сторона
Проверить, что программа запускается, сравнительно просто.
Она ответила. Генератор вернул видео. Файл сохранился. В базе появилась запись.
На техническом уровне есть результат, который можно показать.
Но бизнесу нужны ещё ответы: зачем понадобился этот ролик, кто его использует и сколько разрешено потратить на следующие попытки?
В описанном кейсе проверяли безопасность, двойные записи в Ads и тесты. Проверка утром смотрела на статус запуска. При этом, согласно разбору, максимальную стоимость работы не проверяли, а лимитов денег и количества вызовов в коде не было.
Получается неприятная ситуация: система проходит те проверки, которые ей назначили, и продолжает создавать расходы.
Фраза «скрипт работает» звучит убедительно ровно до момента, когда открываешь рядом две колонки: «потрачено» и «передано в работу».
Одна растёт. Вторая остаётся пустой.
В счёте оказался целый набор ИИ-услуг
На предоставленном фрагменте биллинга по проекту Pugin-alerts в строке Gemini API отображается итог 1124,95. Из него 922,40 приходится на Veo Fast Generation 720p with Audio — около 82% показанной суммы.
Рядом есть расходы на генерацию изображений и текстовые обращения к моделям.
В кадр не попали валюта и выбранный период, поэтому точную сумму всего инцидента по этому фрагменту восстановить нельзя. Около $1200 остаётся оценкой владельца.
Но структура расходов показывает ещё одну неприятную особенность подобных автоматизаций.
Пока вы смотрите на самое дорогое звено — например, видео, — деньги могут уходить и на другие этапы: подготовку текста, изображения, обработку ответов.
Ограничение только одного генератора оставляет остальные платные операции без общего потолка.
А если добавить повторные попытки и запасных провайдеров, считать нужно уже весь процесс.
В этом проекте были несколько ключей, повторы и резервный Grok. Их точный вклад в расходы не установлен. Но любая такая ветка должна пользоваться тем же разрешённым бюджетом, что и основная.
Смена ключа не пополняет кошелёк владельца.
Самый важный вопрос забыли задать до написания кода
Когда человеку нужен скрипт, он обычно описывает действие:
Для платной автоматизации к действию обязательно нужно добавить границу: сколько работы разрешено и когда она заканчивается.
Допустим, для рекламного теста нужны три варианта видео. Один уже готов, второй генерируется. Значит, осталась потребность ещё в одном.
Следующее срабатывание таймера должно проверить эту потребность. Создавать новую партию только потому, что прошли шестьдесят минут, незачем.
Если же задача — заранее подготовить библиотеку креативов, у библиотеки должен быть согласованный размер. Если нужно постоянное пополнение, должен быть целевой запас.
Без этого слово «автоматически» легко превращается в разрешение работать бесконечно.
А платное «бесконечно» — слишком смелый тариф для любого бизнеса.
«Поставим лимит на день» — только часть решения
Дневной потолок сдерживает скорость расхода. Но если каждый новый день выдаёт свежий бюджет, автоматизация всё равно может тратить месяцами.
Нужен общий предел на заказ или разрешённый период работы.
Причём считать следует и уже возникшие расходы, и стоимость операций, которые ещё выполняются.
Представьте, что у вас осталось денег на одно видео. Два процесса одновременно увидели этот остаток и оба решили, что средств хватает. Без общего резервирования каждый по отдельности выглядит правым. Платить придётся за их совместный результат.
Есть и другая ловушка: запрос ушёл к генератору, а ответ потерялся. Скрипт решил попробовать ещё раз. Первая генерация при этом могла уже начаться.
Поэтому ошибка связи не должна автоматически означать «ничего не произошло и денег не потратили».
В рассматриваемом кейсе неудачные вызовы вообще не записывались в базу. Это осложняет даже расследование: сохранённые ролики видны, а полного следа попыток нет.
Для денег нужен журнал всех операций, включая незавершённые и спорные.
Пользователь не обязан становиться инженером, чтобы попросить скрипт
Можно, конечно, предложить каждому человеку заранее изучить блокировки, очереди, квоты, повторные запросы и особенности облачного биллинга.
Тогда смысл обещания «просто опиши задачу» заметно тускнеет.
Фабрика разработки должна сама распознавать, что создаёт программу с платными последствиями. И уже из этого выводить необходимые ограничения.
- Какой результат требуется и сколько единиц достаточно.
- Каков общий разрешённый бюджет.
- Кто или что принимает готовый результат.
- При каких условиях производство приостанавливается.
Часть ответов можно взять из проекта и ранее согласованных правил. Недостающую финансовую границу придётся уточнить: по фразе «напиши скрипт» её достоверно не угадаешь.
Зато всю техническую часть — учёт, ограничения, проверки повторов, сохранение состояния — фабрика должна закладывать сама.
Наличие API-ключа означает, что к сервису можно обратиться. Оно ничего не говорит о том, сколько владелец согласен потратить.
Почему этот кейс важен для Getzilla
Для Getzilla, фабрики разработки с ИИ-агентами, здесь есть вполне конкретная задача.
В её коде уже существуют лимиты исполнения задач, резервирование бюджета и учёт расходов. Это полезная основа.
Дальше нужно доказать, что ограничения доходят до программ, которые фабрика создаёт, и сохраняются после их развёртывания.
Агент может закончить задачу разработки сегодня. Написанный им скрипт способен обращаться к платному сервису ещё через месяц.
Поэтому проверка должна охватывать весь этот срок жизни: что произойдёт при повторном запуске, смене ключа, накоплении черновиков, недоступности рекламного кабинета?
Это можно проверять на симуляторе. Подать множество событий расписания, имитировать ошибки и убедиться, что программа перестаёт создавать новые платные операции при достижении ограничений.
Самого наличия красивого правила в документации недостаточно. Нужен наблюдаемый результат: очередной запрос остановлен до возникновения нового расхода, причина записана, ранее созданные материалы сохранены.
В этом конкретном инциденте владелец сам отозвал ключ. Позже workflow отключили.
Такую остановку стоило предусмотреть ещё до первого платного запуска.
Проверьте свою автоматизацию, пока она просто «работает»
Посмотрите на любую программу, которая регулярно обращается к платному сервису.
Сможете ли вы сразу сказать, сколько она потратит за месяц без вашего участия? Что случится, если следующий этап перестанет принимать результаты? Где она остановится?
В хорошем отчёте рядом должны находиться стоимость, количество готовых результатов, их передача на следующий этап и остаток разрешённого бюджета.
Тысяча новых файлов сама по себе ещё ничего не говорит о выполненной бизнес-задаче.
Этот кейс показал, насколько легко получить большой объём технической работы и пропустить разрыв, из-за которого результат остаётся лежать в черновиках.
У автоматизации есть одна замечательная способность: она избавляет человека от повторяющихся действий.
И одна опасная: она продолжает повторять их, когда человек уже давно перестал смотреть.
Если ваша автоматизация не умеет вовремя останавливаться, вы автоматизировали расходы. Польза пока в бэклоге.
А у вас есть скрипт, который давно проверяют только на то, что он «работает»?