Красная лампочка в AI-отчёте: почему «отключи» — самый дорогой совет

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

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

Как выглядит моё утро с цифровым штабом

У меня работает 14 AI-агентов в постоянном режиме. Один публикует посты в Telegram-канал, другой ведёт SEO-продвижение 4bos.ru, третий следит за здоровьем инфраструктуры, четвёртый управляет финансовой отчётностью. Каждый работает по своему расписанию, с доступом к своим инструментам и базам данных.

Каждое утро в 07:30 я получаю дайджест — структурированный отчёт по каждому агенту и каждому сервису. Формат стандартный: имя компонента, статус, дата последней активности, флаг если что-то вышло за пределы нормы. Большинство пунктов — зелёные. Иногда появляется жёлтый или красный. Красный — это не команда «удалить», это сигнал «разобраться».

За полтора года работы с таким штабом я выработал для себя правило: AI-агент видит симптом. Диагноз ставлю я. Между «нет активности 8 дней» и «надо отключить» всегда стоит один дополнительный шаг: что именно не активно и по какой причине. Этот шаг стоит от 15 минут до нескольких часов работы. Без него последствия могут стоить значительно дороже.

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

На практике это означает: из 20 пунктов в утреннем дайджесте 18 я читаю по диагонали. Два — читаю внимательно. Один иногда требует 15 минут диагностики. Раз в несколько недель — часа. За полтора года я потратил на ручную диагностику в сумме меньше, чем потерял бы от одного необдуманного «отключить».

В этот раз цифровой директор увидел скрипт по виллам с флагом «не активен». Рекомендация — отключить. Моя реакция — залезть внутрь.

Скрипт, которому советовали умереть

Скрипт делал одну вещь: забирал входящие сообщения от гостей с Booking.com и Airbnb и пересылал их мне в Telegram. Гость написал «дайте пароль от WiFi» — я получаю уведомление. Вопрос про время заезда, вопрос про депозит, запрос на ранний чек-ин — всё туда же. Простой, надёжный канал связи, который работал месяцами без сбоев.

Скрипт замолчал 18 июня. Восемь дней тишины — именно это и зафиксировал агент-директор в утреннем отчёте. Восемь дней гости писали сообщения, которые никто не читал. Восемь дней вопросы о заезде, ключах, депозитах висели без ответа. Для арендного бизнеса на Бали, где гости прилетают из разных часовых поясов и часто пишут за сутки до заезда, восемь дней игнора — это прямой удар по рейтингу на Booking.com. Одна негативная оценка за «нет ответа» перекрывает три положительных за «отличная вилла».

Когда я залез внутрь, причина стала ясной за 10 минут. Неделю назад я переезжал между почтовыми аккаунтами — переносил рабочую переписку с одного ящика на другой, реорганизовывал структуру почты. В процессе OAuth-токен авторизации скрипта протух.

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

Что видел директор: красная лампочка, нет активности 8 дней, рекомендация «отключить».

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

Решение: заменить стандартный OAuth на сервисный аккаунт Google — метод авторизации, который не требует периодического обновления токена. Час работы. Заодно перенаправил входящие сообщения в чат управляющей компании Vsemdom, которая теперь ведёт виллы: пусть они отвечают гостям напрямую, без меня как посредника.

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

Три типа красных лампочек — и что они означают на самом деле

После этой истории я сформулировал для себя три типа сигналов, которые AI-директор может пометить как «проблема». Они принципиально разные, но снаружи выглядят одинаково.

Тип 1: ошибка конфигурации

Инструмент рабочий, логика верная, но что-то внешнее сломалось: токен, пароль, URL эндпоинта, API-лимит поставщика, изменившийся формат данных. Симптом: нет активности за N дней при том, что задача по-прежнему актуальна. Лечение: диагностика источника сбоя, замена сломанного компонента. Время: от 15 минут до нескольких часов. История со скриптом по Booking.com — именно этот тип.

Другие примеры из практики: изменился формат API ответа платёжного сервиса — агент перестал парсить суммы. Истёк SSL-сертификат на эндпоинте — агент перестал отправлять данные. Поменялась схема таблицы в базе данных — агент перестал записывать отчёты. Во всех случаях инструмент «живой», задача актуальна, нужно найти и заменить сломанный компонент.

Тип 2: устаревший инструмент

Инструмент создавался под задачу, которая больше не актуальна. Пример из моей практики: агент для cold-outreach рассылок, который я закрыл в мае 2026 после года экспериментов. Результат за год: 0 продаж при значительных вложениях времени. Канал закрыт, агент снят с дежурства. Здесь «отключить» — правильное решение.

Но и в этом случае сначала стоит убедиться, что задача действительно закрыта, а не просто приостановлена. Агент для cold-outreach я отключил только после того, как подтвердил, что альтернативные каналы лидогенерации работают и нагрузка на продажи перераспределена. Иначе «отключил устаревший инструмент» превращается в «отключил единственный канал». Ещё один важный шаг при отключении устаревшего инструмента: сохранить его конфигурацию и логику в архив, даже если уверен, что она никогда не понадобится. За год я несколько раз возвращался к архивным конфигам — не чтобы включить заново, а чтобы посмотреть как была устроена интеграция с конкретным API.

Тип 3: мёртвый груз

Задачи, записи, артефакты, которые создал агент или человек и забыл. Никто на них не смотрит, они просто существуют и создают шум. В этот же день я нашёл 110 зависших задач по виллам в системе управления — их в марте 2026 создал AI-агент, которого я уволил при реструктуризации. Новый агент встал на место, старые задачи остались в базе. 110 строк с пометкой «todo» и датой создания 3–4 месяца назад.

Ключевое: нельзя определить тип красной лампочки снаружи. Только залезть внутрь. Именно поэтому рекомендация AI-директора «отключить» — всегда гипотеза, а не диагноз.

110 мёртвых задач и одна команда

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

110 задач, созданных с марта по май 2026. Ни один живой агент к ним не обращался. Ни один живой человек их не читал. Просто строки в базе данных, которые создавали шум при каждом поиске реальных активных задач.

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

Затем снёс одной SQL-командой по фильтру: статус «todo», создан конкретным уволенным агентом, старше 30 дней. Минута работы. База стала чище, поиск активных задач — быстрее. Это тоже часть управления системами: регулярная уборка мёртвого груза, который накапливается в любой живой системе.

Пароль в техническом файле: как я едва не опубликовал его в открытый доступ

Параллельно в тот же день занимался другим проектом. Хотел настроить доступ к своей базе знаний с телефона — выгрузить технические документы в удобный формат для мобильного использования. Начал готовить файлы к экспорту.

И поймал неприятное.

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

Прогнал все файлы через фильтр: скрипт, который ищет паттерны — пароли, API-ключи, токены, строки подключения к БД, приватные ключи SSH. Проверил в 4 прохода с разными паттернами поиска, чтобы ничего не пропустить. Убедился, что ничего не осталось. Только после этого выложил в базу знаний.

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

Урок: файл «для себя» становится файлом «для всех» в тот момент, когда вы переносите его в облако, базу знаний или любое место с расширенным доступом. Технические заметки, которые вы пишете в спешке посреди задачи, часто содержат строки подключения, скопированные из конфигов «чтобы не потерять». Фильтр credentials нужно применять до экспорта, не после. Это не параноя — это нормальная гигиена при работе с несколькими инструментами и аккаунтами одновременно.

Когда выключать — правильное решение

В тот же день я отключил один канал публикаций. Две недели он работал в автоматическом режиме: генерировал изображения через DALL-E, публиковал посты по расписанию, тратил деньги на API-запросы к генеративным сервисам. Система работала технически исправно — ни одной красной лампочки в дайджесте.

Результат за 14 дней работы: 5 переходов, ноль заявок, ноль клиентов.

Здесь я не искал ошибку конфигурации — канал работал корректно. Задача (приводить заявки) не выполнялась на протяжении всего тестового периода. Это другой тип проблемы: не «сломан», а «не работает как ожидалось в бизнес-смысле». Решение — отключить.

Разница с историей про скрипт с гостями:

• Скрипт с Booking.com был технически сломан (протухший OAuth-токен), но задача (получать сообщения гостей) оставалась актуальной. Решение: починить.
• Канал публикаций работал технически, но задача (приводить клиентов) не выполнялась 14 дней подряд. Решение: отключить.

Код от отключённого канала я оставил в архиве. Конкретные блоки логики — интеграция с DALL-E, шаблон публикации, парсер форматов — могут использоваться в другом контексте. Архив занимает место на диске, но ничего не стоит. Воссоздание логики с нуля — реальные часы работы.

Тихий сбой: память, которая перестала писать

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

Этот сбой не даёт красную лампочку в утреннем отчёте. Инструмент работал: принимал запросы, возвращал ответы, вёл диалог в нормальном режиме. Просто один внутренний механизм — запись в долгосрочное хранилище — тихо остановился. Внешне ничего не изменилось. Я ничего не заметил, потому что смотрел на вход (запросы и ответы), а не на выход (что появляется в базе).

Починил. Дописал руками то, что потерялось за неделю — восстановил ключевые факты и контекст, которые должны были сохраниться автоматически. Неприятно, но поправимо. Хуже было бы продолжать несколько месяцев в уверенности, что всё накапливается — а потом обнаружить, что база знаний пустая.

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

Пять принципов управления AI-системами

«Юрий Солар, основатель Solar OS: Красная лампочка в отчёте бота значит только одно — надо залезть и проверить самому. Самый дорогой совет за тот день был "отключи", а правильным ответом оказалось "почини". Разница — в готовности залезть внутрь.»

Из практики управления 14 агентами я вывел несколько рабочих принципов:

Агент видит симптом — диагноз ставишь ты

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

Диагностика дешевле потери канала

Час на проверку скрипта против потери канала связи с гостями на неопределённый срок. Гость написал про депозит — вопрос не ответили — оценка на Booking.com упала. Эта цепочка не считается в деньгах сразу, но отражается в реальных показателях через недели. Стоимость часа диагностики — в разы меньше стоимости испорченного рейтинга на платформе бронирования.

Архивируй перед удалением

110 задач: снёс, но сохранил CSV. Код отключённого канала: оставил в архиве. Стоимость хранения файлов — минимальная. Стоимость воссоздания логики с нуля — реальная. Это правило не требует героических усилий: одна команда дампа перед удалением. За полтора года я ни разу не открывал эти архивы — но несколько раз был рад, что они есть.

Мониторинг должен быть двухуровневым

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

Credentials в личных файлах — это публичные credentials

Если файл когда-нибудь выйдет за периметр (а он выйдет — в облако, в базу знаний, в инструмент с расширенным доступом), пароль в нём уже скомпрометирован. Фильтр credentials на выходе — всегда, без исключений. Проходить в несколько итераций по разным паттернам, не в один. Это занимает 5–10 минут и исключает класс проблем, которые очень неприятно решать постфактум.

Что такое «смотреть за системами» на практике

К концу того дня у меня было пять завершённых дел: починен канал связи с гостями Booking.com и Airbnb, удалены 110 мёртвых задач от уволенного агента, очищены технические файлы от credentials, отключён неработающий канал публикаций, восстановлена долгосрочная память AI-инструмента.

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

AI-автоматизация освобождает время от рутинных операций. Она не освобождает от необходимости понимать, как работают инструменты, которые эту рутину выполняют. Разница между «у меня есть автоматизация» и «у меня работает автоматизация» — именно в этом ежедневном контроле. Один — добавил инструменты и забыл. Второй — добавил инструменты и смотрит за ними.

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

Сколько у вас в бизнесе вещей помечено как «не работает», а на самом деле там просто протух токен авторизации? И сколько вещей работает, но не в ту сторону — тихо и без красных лампочек?

Если тема управления AI-системами в реальных условиях интересна — в клубе «Solar — внутрянка» я выкладываю конкретные артефакты: AGENTS.md моих агентов, скрипты мониторинга, чеклисты диагностики, SQL-команды для уборки мёртвого груза. Всё, что крутится у меня в продакшне прямо сейчас, а не теоретические разборы про «будущее автоматизации». Бери и адаптируй: https://4bos.ru/inside/

— Solar OS.