Как AI-агенты проверяют себя перед рискованным действием

AI-агент для бизнеса нельзя оценивать по скорости ответа. В 2026 году полезный агент отличается не тем, что за 3 секунды пишет убедительный текст, а тем, что перед рискованным действием умеет сказать: данных не хватает, submit запрещён, `goal_complete=false`. В Solar OS это не абстрактная этика, а рабочая механика: 8 июля 2026 в одном дне сошлись голосовой бот Алиса, LKPM до 15 июля, Coretax, банки Permata и Danamon, SEO-контуры и личный Telegram-ассистент.

Общий вывод из этого дня простой: автоматизация бизнес-процессов становится взрослой, когда перестаёт торопиться к красивому финалу. Голосовой бот не должен делать вид, что звонок прошёл, если после фразы клиента стоит тишина. Бухгалтерский агент не должен ставить нулевой квартал, если в Danamon найдены Q2 credits на 4,264,920.89 IDR. SEO-агент не должен выпускать страницу только потому, что текст длинный: нужны schema, sitemap, indexability, check date и отсутствие дубля. Машина, которая не умеет остановиться, просто быстро размазывает ошибку по системе.

Что считается рискованным действием для AI-агента

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

У рискованного действия есть 5 признаков. Первое: его увидит внешний человек или государственная система. Второе: откат стоит времени, денег или репутации. Третье: агент работает на неполных данных. Четвёртое: ошибка выглядит правдоподобно, поэтому её трудно поймать глазами. Пятое: у действия есть дедлайн, который давит на оператора. LKPM до 15 июля подходит под все 5 признаков. Голосовой звонок клиента подходит минимум под 3. Публикация SEO-страницы на 4bos.ru тоже подходит: страница попадает в индекс, sitemap и AI-поиск, потом её приходится разгребать не как черновик, а как публичный сигнал.

В Solar OS рискованное действие переводится из режима «модель решила» в режим «контур разрешил». Разница грубая, зато полезная. Модель может уверенно написать: отчётность закрыта. Контур спрашивает: где скрин OSS, где preview, какие KBLI проверены, есть ли банковские credits, закрыты ли Coretax proofs, кто имеет право нажать submit. Если ответа нет, задача остаётся открытой. Да, это скучно. Зато скука дешевле объяснений налоговой, почему оптимизм внезапно стал методом бухгалтерского учёта.

Архитектура самопроверки: evidence, stop rule, owner

Минимальная архитектура самопроверки состоит из 3 слоёв: evidence queue, stop rules и owner approval. Evidence queue хранит доказательства, а не настроение агента. Stop rules запрещают действие при нехватке доказательств. Owner approval даёт человеку право нажать последнюю кнопку там, где цена ошибки выше порога. Этот набор звучит как корпоративная бюрократия, пока не видишь систему, которая без него радостно закрывает отчёт по пустому экрану.

Evidence queue — это очередь фактов. В бухгалтерском контуре PT Solar Property Bali 8 июля появился не один «готовый отчёт», а 105 задач в master evidence queue. Внутри были 19 пробелов по Coretax proof, отдельные маршруты по Badung, 3484, Permata March и April, Coretax obligations и LKPM preview. Такая очередь не красивая для презентации, но она даёт владельцу главное: где именно риск, кто следующий исполнитель, какое доказательство уже найдено, почему нельзя закрывать квартал одной фразой.

Stop rule — это жёсткий запрет, а не рекомендация. Если нет evidence по банковскому месяцу, агент не пишет «скорее всего ноль». Если в OSS висит Perlu Perbaikan, агент не нажимает submit. Если голосовой бот записал аудио, но не проверил паузу после реплики клиента, тест не считается принятым. Если SEO-страница не прошла TL;DR, FAQ, entity density и anti-slop, она не публикуется. Stop rule должен быть простым до неприятного: нет доказательства — нет действия.

Owner approval нужен не везде. Если агент меняет локальный черновик, человек не нужен. Если агент публикует на сайт, отправляет отчётность, принимает финансовое решение или действует от имени владельца, человек должен видеть пакет решения. Не длинный роман, а карточку: что найдено, что не найдено, какая кнопка предлагается, какой риск, где скрины, какие суммы, какой deadline. Хороший агент экономит время владельца не тем, что прячет риск, а тем, что приносит риск в виде 1 понятного решения.

Голосовой бот: самопроверка качества, а не демо голоса

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

У звонка есть много мест, где система может притвориться живой. Запись существует, но пользователь слышит тишину. Отчёт пришёл, но бот после слова «услышала» молчит до конца разговора. Голос приятный, но на пике хрипит. Перебивание работает в одном тесте и исчезает в другом. Владелец видит красивый transcript и думает, что продукт готов. Клиент в этот момент уже успел повесить трубку. Если агент не проверяет такие места, бизнес получает демо вместо процесса.

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

Такой подход меняет постановку задачи для разработчика. Вместо «сделай голосового бота» появляется набор acceptance checks. Бот должен ответить в Telegram. Бот должен дождаться законченной реплики. Бот должен принять перебивание. Бот должен не зависнуть после подтверждения. Бот должен положить трубку при завершении. Бот должен отправить владельцу отчёт. Бот должен показать стоимость. Каждая проверка либо PASS, либо FAIL. Серой зоны меньше, театр презентаций скукоживается. Где-то в этот момент продукт начинает работать.

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

Бухгалтерский контур: почему агент не имеет права верить пустому экрану

Бухгалтерская автоматизация особенно любит опасные выводы. Система показывает пустой экран, человек устал, дедлайн близко, агент хочет закрыть задачу. Возникает соблазн написать: квартал нулевой. 8 июля этот соблазн был главным тестом. По LKPM до 15 июля нашли живой OSS, подтвердили строки KBLI 55193, 55900 и 55199, увидели старый статус Perlu Perbaikan, зафиксировали скрины, но submit не нажали. Это правильный результат: не героический, зато пригодный для жизни.

Банковская часть дала ещё более простой урок. По Permata и Danamon Q2 evidence выросло до 5 из 7 месяцев. Потом всплыла неприятная деталь: квартал нельзя считать нулевым, потому что в Danamon есть Q2 credits на 4,264,920.89 IDR. Если бы агент работал в режиме «найди удобный вывод», он бы спрятался за отсутствующими экранами. В режиме evidence queue он обязан показать конфликт: часть proof собрана, часть отсутствует, сумма есть, нулевой отчёт запрещён.

Здесь самопроверка защищает не только от ошибки модели. Она защищает от человеческой психологии. Человек хочет завершить. Агент хочет поставить done. Менеджер хочет увидеть зелёный статус. Но отчётность не интересуется желаниями. Поэтому в контуре появляется поле `goal_complete=false`, пока нет доказательств. Это маленькая строка, которая стоит дороже половины презентаций про AI transformation. Она не даёт системе объявить победу, когда внутри ещё лежит 19 пробелов по Coretax proof.

Похожую логику описывает NIST AI Risk Management Framework: AI-системы надо проектировать с управлением рисками, измерением, ответственностью и прозрачностью. В прикладной операционке это переводится без академического тумана: покажи evidence, покажи rule, покажи owner, покажи журнал решения. Ссылка на рамку: NIST AI Risk Management Framework. Документ большой, но для малого бизнеса вывод один: AI не должен быть чёрным ящиком, который говорит «готово» красивым голосом.

SEO и GEO: публикация тоже рискованное действие

SEO-страница кажется безопасной: текст можно потом поправить. Это ловушка. Страница уходит в sitemap, попадает в индекс, получает canonical, Open Graph, Twitter Card, FAQPage, Article schema и внутренние ссылки. Для AI-поиска она становится не черновиком, а источником. Поэтому публикация на 4bos.ru проходит тот же принцип: сначала доказательства качества, потом выпуск. Никаких ручных правок шаблонов, никаких обходов helper, никаких «потом допишем FAQ». Ручной энтузиазм уже достаточно раз делал из сайта музей неожиданных решений.

В SEO/GEO-контуре 8 июля шла дисциплина не «писать больше текста», а усиливать правильные страницы по живому поисковому сигналу. На 4bos убрали старое позиционирование про 16 вилл и 19 агентов. По другим сайтам шли отдельные controlled GEO sprint и check date на 22 июля, но для 4bos важен собственный вывод: страница должна отвечать на B2B-запрос, вести в клуб, иметь машинно читаемую структуру и не повторять свежий угол из ленты. Если статья выходит только потому, что агент устал, это не контент-маркетинг. Это цифровой шум с CMS-доступом.

Для статьи самопроверка выглядит как набор технических и редакционных ворот. TL;DR должен быть прямым ответом, а не вступительным реверансом. FAQ должен отвечать на реальные вопросы. В первых 1500 символах должны быть сущности и числа. Текст должен иметь 5-7 H2, нормальную иерархию, внутреннюю ссылку и CTA на клуб. Anti-slop убирает фразы, от которых текст пахнет автогенерацией. Dedup проверяет, что за последние 14 дней не выходил тот же угол. Только после этого helper собирает HTML, листинг, sitemap и schema.

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

Как собрать self-check контур в малом бизнесе

Начинать лучше не с платформы и не с выбора модели. Начинать надо с карты действий. Выпишите 20 действий, которые AI-агент может выполнить в вашем процессе: ответить клиенту, создать счёт, поменять статус сделки, опубликовать пост, отправить отчёт, назначить встречу, поставить задачу бухгалтеру, закрыть тикет, удалить файл, открыть доступ. После этого разделите их на 3 группы: безопасные, условно безопасные и рискованные. Безопасные можно автоматизировать быстрее. Рискованные получают evidence, stop rules и approval.

Для каждого рискованного действия нужна карточка проверки. В ней 7 полей: действие, источник данных, обязательные evidence, запреты, owner, rollback, журнал. Для LKPM действие — submit. Источник — OSS. Evidence — скрины, KBLI, preview, статус. Запрет — Perlu Perbaikan без ручной проверки. Owner — человек, который отвечает за отчётность. Rollback — что делать, если отправили неверно. Журнал — дата, время, кто видел пакет. Для голосового бота действие — принять звонок как passed. Evidence — запись, transcript, паузы, перебивание, отчёт, цена.

Следующий слой — статусы. Не используйте только todo/done. Добавьте состояния вроде needs_evidence, blocked_by_owner, ready_for_review, approved, submitted, failed_acceptance. Такие статусы раздражают тех, кто любит зелёные доски. Зато они показывают правду. Если Danamon April не найден, задача не должна выглядеть как почти закрытая. Если Coretax proof отсутствует, агент не должен писать «готово, кроме мелочей». В операционке «мелочь» часто имеет форму штрафа, потерянного доступа или публичной страницы с мусором.

Третий слой — журнал решений. В Solar OS это может быть issue, comment, systemd log, database row или отчёт в Telegram. Формат не так важен, как неизбежность записи. Агент должен оставлять след: почему он остановился, чего не хватает, какие числа нашёл, какую кнопку предлагает. 8 июля в другом контуре всплыло 337845 чатов в базе ChatRadar, и cron оказался хрупким, поэтому ежедневный долив переехал в systemd timers. Это та же идея: не верить тихой автоматизации без проверяемого следа. Если процесс молчит, он не здоровый. Он просто ещё не пойман.

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

Чек-лист перед submit

Перед рискованным действием агент должен пройти короткий чек-лист. Первое: есть ли полный список входных данных. Второе: есть ли минимум 2 независимых доказательства для критичного вывода. Третье: есть ли конфликт, например пустой экран и банковский credit. Четвёртое: прописан ли stop rule. Пятое: известно ли, кто владелец решения. Шестое: есть ли журнал. Седьмое: есть ли rollback. Восьмое: не нарушает ли действие публичные правила компании, например CTA только на клуб или запрет выдуманных цифр.

Этот чек-лист не надо превращать в 40-страничный регламент. Он должен жить рядом с агентом: в prompt, AGENTS.md, workflow, tool wrapper, validator, CI или issue template. Для 4bos публикация статьи идёт через helper, который проверяет payload: slug, title, meta description, date, TL;DR, FAQ, body, H2, word count, entity density. Для финансового контура validator проверяет evidence. Для голосового бота acceptance проверяет звонок. Разные домены, одна логика: агент не принимает свою уверенность за доказательство.

Хорошая самопроверка имеет неприятное свойство: она часто портит красивый статус. Вместо «закрыли бухгалтерию» получается «собрали 5 из 7 месяцев, нашли Q2 credits, 19 Coretax gaps, submit запрещён». Вместо «голосовой бот готов» получается «29 секунд прошли, стоимость $0.0446, перебивание есть, пауза проверена, следующий тест нужен по громкости». Вместо «SEO опубликовано» получается «draft прошёл QA, anti-slop, dedup, helper, sitemap». Это менее эффектно. Зато бизнес получает систему, которая не врёт владельцу ради приятного отчёта.

Что забрать в свою операционку

Если у вас уже есть AI-агенты или автоматизации, проверьте не количество сценариев, а наличие стоп-контуров. Найдите 5 действий, где агент может навредить: деньги, отчётность, доступы, публичные ответы, публикации. Для каждого действия запишите evidence, stop rule, owner, rollback и журнал. Потом заставьте агента перед действием отвечать не «я уверен», а «вот доказательства, вот риск, вот почему можно или нельзя продолжать». Это и есть переход от игрушечного AI к операционной системе.

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

Дальше можно расширять карту. Для каждой новой автоматизации добавляйте acceptance checks до запуска, а не после первого неприятного скрина от клиента. Если агент пишет текст, проверяйте факты, дубль и CTA. Если агент трогает деньги, проверяйте сумму, источник и право подписи. Если агент закрывает задачу, требуйте evidence. Если агент зовёт человека, он должен объяснить, чего именно не хватает. Так появляется управляемый слой AI-операционки: меньше героизма, больше журнала. Скучно? Да. Работает? Именно поэтому.

Ещё один практичный тест: попросите агента объяснить отказ. Не результат, а причину остановки. Плохой агент пишет: «не удалось выполнить». Нормальный агент пишет: «нет Danamon April, найден Q2 credit, Coretax proof отсутствует, owner должен проверить LKPM preview». Эта разница экономит часы. Владелец сразу понимает, кого пинговать, какой файл искать и какую кнопку не нажимать. Поэтому self-check — не украшение архитектуры, а интерфейс управления риском. Без этого агент остаётся быстрым стажёром с доступом к кнопкам.

В Solar OS эта логика крутится 24/7: голосовые звонки, бухгалтерские очереди, Telegram Business, SEO/GEO, мониторинг timers, публикации и внутренние задачи. Полный набор артефактов — AGENTS.md, промпты, чек-листы, validators, примеры issue-пакетов и рабочие контуры — лежит в клубе «Solar — внутрянка», от 2 500 ₽/мес. Бери и адаптируй: https://4bos.ru/inside/

Solar OS.