Теневой режим автоматизации: запуск AI без риска

Теневой режим автоматизации — это запуск AI-агента без внешнего действия: система уже читает заявки, считает деньги, готовит ответы и пишет отчёты, но человек видит решение до клиента. 13 июля 2026 в Solar такой режим одновременно держал 6 направлений: CRM, звонки, клубного бота, WhatsApp-переводчик, клиентский SEO-проект и контроль Paperclip. Это нормальный способ запускать автоматизацию бизнеса, когда ошибка стоит дороже красивого демо.

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

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

Что такое теневой режим для AI-автоматизации

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

Такой режим нужен не для красивой презентации. Он нужен, чтобы поймать расхождение между тем, как процесс описан в голове владельца, и тем, как он живёт в данных. В документации написано «после заявки менеджер отвечает за 10 минут», а в логах оказывается, что часть заявок приходит ночью, часть падает в личный Telegram, часть дублируется из формы, а часть не содержит контакта. Если сразу дать агенту право писать клиентам, он начнёт обслуживать эту кашу быстрее. Бизнес получит ускоренный хаос.

13 июля рабочая CRM Solar была включена именно так: она считала подходящие заявки и показывала будущие действия, но сообщения людям не отправляла. Это даёт владельцу 3 практических ответа. Первый: сколько реальных клиентов попадает под правило. Второй: какие данные нужны агенту для решения. Третий: где правило слишком грубое и требует ручной границы. Без этого этапа команда спорит о вкусах. С ним спор идёт о конкретных событиях в журнале.

Теневой режим полезен и для простой автоматизации без AI. Разница только в том, что AI-агент чаще работает с неструктурным текстом: письмами, голосовыми расшифровками, чатами, заметками менеджеров. Там выше риск неверной трактовки. Поэтому у агента должны быть не только промпт и модель, но и протокол сомнения: когда он обязан остановиться, спросить человека, записать причину и не продолжать цепочку. Хорошая система не стесняется ответа «не знаю». Плохая уверенно врёт, и потом люди называют это «искусственным интеллектом».

Почему быстрый запуск без стоп-кранов ломает процесс

В автоматизации бизнеса есть неприятная ловушка: чем лучше интеграция, тем быстрее ошибка уходит наружу. Ручной менеджер может забыть отправить 1 сообщение. Скрипт без ограничения отправит 100 сообщений за минуту. Голосовой помощник без проверки баланса может принять разговор, который никто не оплатил. CRM без проверки статуса клиента может написать человеку, который уже отказался. Отчёт без различения «ноль» и «нет данных» создаёт финансовую картинку, в которую потом кто-нибудь поверит.

Поэтому первый вопрос к AI-агенту не «что он умеет генерировать», а «какое действие он не имеет права сделать». В Solar этот принцип в один день проявился в 4 местах. Клубный бот и WhatsApp-переводчик сначала вернули доступ к секретам и временным файлам, затем прошли 3 контрольных запуска подряд. Голосовой контур получил правило времени: ночью с 20:00 до 08:00 WITA отвечает помощник, днём трубку поднимает человек. Финансовый контур клуба отделил подарочные доступы от платящих участников. Paperclip получил новые интервалы проверки, чтобы не объявлять рабочих агентов зависшими.

Каждый пример выглядит как техническая мелочь, но в сумме они отвечают за доверие. Если агент ошибся в доступе к секретам, он не должен тихо умереть. Если агент перепутал подарочный доступ с оплатой, он не должен увеличивать MRR. Если watchdog не понимает расписание рабочих сессий, он не должен поднимать ложную тревогу. Если клиентский магазин не имеет резервной копии, агент не должен менять карточки товаров, даже если уже прошёл 395 страниц и нашёл 383 товара с 634 вариантами.

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

Архитектура теневого запуска: события, решения, действия

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

Такой разрез сразу снимает половину тумана. Владелец видит не абстрактное «AI думает», а таблицу решений. Например: заявка 1472, последний контакт 42 дня назад, причина возврата — молчание после консультации, предлагаемое действие — короткое сообщение, уровень риска — низкий. Или: звонок пришёл в 22:14 WITA, клиент просит цену, агент собрал итог, но продажа требует оператора. В этих строках можно спорить о правилах, править промпт, добавлять поля и измерять качество до того, как клиент увидит ответ.

Второй элемент архитектуры — журнал отказов. Система должна отдельно сохранять случаи, где она могла бы действовать, но остановилась. Это не ошибка, а золото для настройки. Если за день набралось 18 остановок из-за пустого телефона, значит проблема не в AI, а в форме заявки. Если 7 диалогов остановились на цене, значит нужна отдельная карточка условий. Если отчёт 2 месяца подряд показывает неизвестные данные по выписке, бухгалтерский процесс дырявый, и агент не должен заклеивать его красивой цифрой.

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

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

CRM-агент обычно начинается с простого желания: вернуть клиентов, которые молчат. Но даже правило «30 дней тишины» содержит несколько ловушек. Клиент мог уже купить. Мог отказаться. Мог просить не писать. Мог перейти в другой канал. Мог быть партнёром, инвестором или подрядчиком, а не лидом. Если агент не различает эти статусы, он будет выглядеть настойчивым и глупым. Поэтому CRM-автоматизация должна начинаться с карты исключений, а не с текста сообщения.

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

В Solar CRM такой подход был выбран до внешнего запуска. Система сначала считает подходящие заявки и показывает будущие действия. Это позволяет увидеть объём очереди и качество сегмента. Если из 100 кандидатов 60 оказываются спорными, автопилот рано включать. Если из 100 кандидатов 90 проходят правила и человек почти не меняет тексты, можно дать агенту право отправлять часть сообщений. Переход должен быть не календарным, а статистическим: доля ручных исправлений падает, журнал отказов понятен, критичных ошибок нет.

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

Голосовой агент: почему звонок должен начинаться с баланса

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

В проектировании Telegram Voice для Solar схема была такой: днём звонок принимает человек, ночью с 20:00 до 08:00 WITA отвечает помощник. Запись начинается после ответа, расшифровка и итог уходят в рабочий бот. Для исходящего звонка кнопка в карточке клиента сначала соединяет оператора, затем клиента и возвращает разговор в CRM. Это не случайная осторожность. Исходящий звонок от имени бизнеса — действие с последствиями, и оно не должно стартовать без понятного владельца.

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

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

Контроль данных: отчёт без источника не становится нулём

Финансовые и управленческие отчёты ломаются не только из-за неверных формул. Частая проблема — система путает отсутствие данных с нулевым значением. В живом бизнесе это разные состояния. Ноль означает, что источник проверен и показал пустой результат. «Нет данных» означает, что источник не пришёл, доступ потерян, файл не загружен или период не закрыт. Если автоматизация заменяет второе первым, владелец получает спокойную таблицу с опасной ложью.

13 июля финансовый контур клуба дал именно такую поправку. Клуб показывал выручку по цене тарифа, хотя часть доступов была подарочной. После пересчёта осталось 6 активных участников, из них 4 платящих, и 6 249 рублей месячной выручки. В отчётности PT SPB март и апрель оставили неизвестными, потому что отсутствие выписки нельзя превращать в ноль. Это хороший пример для любой CRM, ERP или дашборда: статус данных должен быть частью модели.

Минимальная модель содержит 4 статуса: подтверждено, ожидает источник, требует проверки, исключено. Подтверждено можно использовать в отчётах. Ожидает источник нельзя складывать с нулём. Требует проверки должно попадать человеку. Исключено нужно хранить с причиной, чтобы через месяц никто не вернул строку обратно. Для AI-агента эти статусы важнее красивого ответа. Они показывают границы знания системы.

Тот же принцип работает с контентом, каталогом и клиентскими обещаниями. Если происхождение материала не подтверждено, карточка товара не должна утверждать легенду. Если клиентская цитата не согласована письменно, кейс не должен её использовать. Если GSC показывает видимость без органических кликов, SEO-отчёт не должен объявлять победу. Автоматизация взрослеет в тот момент, когда перестаёт заполнять пустоты уверенным тоном.

Операционный контроль: кто следит за агентами

Когда в компании появляется несколько агентов, возникает новый слой работы: контроль контролёров. Один агент публикует, второй проверяет, третий собирает отчёт, четвёртый смотрит за расписанием. Если правила проверки грубые, система начинает шуметь. Paperclip в рабочий день несколько раз объявлял агентов зависшими, хотя они работали по своим интервалам. Решение было не в том, чтобы выключить проверки, а в том, чтобы привести watchdog к реальному расписанию рабочих сессий.

Для multi-agent систем нужен реестр ожиданий. У каждого процесса должны быть имя, владелец, нормальный интервал, последний успешный запуск, допустимое опоздание, канал тревоги и действие при сбое. Агент, который должен работать каждые 30 минут, не равен агенту, который запускается раз в сутки. Если мониторинг не знает этой разницы, он будет либо молчать на реальном сбое, либо кричать на нормальную паузу. Оба варианта быстро приучают людей игнорировать алерты.

В Solar под одним оркестратором собрали 8 профильных рабочих сессий с проверкой каждые 30 минут. Параллельно остановили забытые рассылки и процесс, который сам воскресил давно замороженный сборщик контактов. Это отдельный класс риска: автоматизация может продолжить старую волю бизнеса после того, как решение уже отменено. Поэтому у процессов должен быть не только запуск, но и право на смерть: статус frozen, дата остановки, причина, запрет на автоподъём без новой команды.

Резервные копии тоже входят в операционный контроль. Падающая копия базы была заменена на проверенный архив размером 156 891 639 байт. Размер архива сам по себе не доказывает восстановление, но он лучше пустого «backup ok» без файла. В зрелой системе backup — это не строчка в cron, а проверяемый артефакт: где лежит, когда создан, какой размер, чем восстановить, кто получит тревогу при сбое. Автоматизация без восстановления — это оптимизм с расписанием.

Чек-лист перехода из тени в прод

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

Четвёртый пункт — известна цена ошибки. Напоминание внутри команды и сообщение клиенту — разные уровни риска. Обновление внутреннего статуса и списание денег — тоже разные уровни. Пятый пункт — ручные исправления падают. Если человек переписывает каждое второе сообщение, это не автономность, а дорогой автокомплит. Шестой пункт — есть план отката: как остановить агента, где лежат логи, как вернуть прежний процесс, кому сообщать.

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

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

Что забрать в свою систему

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

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

Третий шаг — разнести роли. Агент собирает данные, предлагает решение и пишет черновик. Человек утверждает рискованные действия и правит правила. Watchdog проверяет расписание, доступы и зависшие процессы. Отчёт показывает не только результат, но и дырки: неизвестные периоды, остановленные действия, спорные факты, неготовые источники. В такой схеме AI не изображает всезнание. Он делает операционную работу видимой.

Внутри Solar этот подход держится на простом принципе: хорошая автоматизация умеет не только действовать, но и останавливаться. 13 июля это проявилось в CRM, звонках, ботах, клиентском SEO, финансовом контуре и Paperclip. Снаружи всё выглядит как набор разных задач. На уровне системы это один паттерн: событие, решение, стоп-кран, журнал, человек, прод. Полный набор таких шаблонов, AGENTS.md, промптов и рабочих чек-листов я складываю в клуб «Solar — внутрянка», от 2 500 рублей в месяц. Бери и адаптируй: https://4bos.ru/inside/

Если нужно продолжить тему, рядом стоит прочитать материал про стоп-краны в автоматизации бизнеса. Там больше про go/no-go правила перед внешним действием. Эта статья — про теневой запуск как рабочий режим между тестом и продом. Вместе они дают базовую рамку для малого бизнеса: сначала видеть события, потом разрешать действия, затем повышать автономность только там, где журнал решений показывает устойчивое качество.