Контроль качества AI-автоматизации: система сама снимает PASS

Контроль качества AI-автоматизации в бизнесе начинается не с красивой панели, а с неприятного права системы снять собственный зелёный статус. 14 июля 2026 у меня за один день этот принцип прошёл через 156 тестов финансового импорта, аудит 7 публикаций, цикл из 9 камер, каталог Hawaiian Designs на 383 товара, отчёты Vsemdom по 19 броням и очистку Mac на 67 ГБ. Общая идея простая: PASS не должен быть медалью. PASS должен быть временным состоянием, которое живёт только пока факты его держат.

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

Я называю это self-revoking PASS: отзывной зелёный статус. Не отдельный инструмент и не модная надстройка поверх мониторинга. Это контракт между агентом, тестами, аудитом и человеком: автоматизация может закрыть задачу, но обязана открыть её обратно, если свежий факт ломает основание для успеха. В нормальной компании такой механизм должен быть встроен в финансы, контент, клиентские публикации, инфраструктуру и операционные дашборды.

Почему обычный PASS опасен для AI-автоматизации

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

Проблема усиливается в AI-автоматизации, где часть решений вероятностная. Агент может правильно понять задачу, но неправильно выбрать канал публикации. Может корректно собрать JSON, но потерять след QA. Может перенести данные, но оставить слишком широкое право доступа. Может получить свежий снимок камеры, но не доказать стабильность всей цепочки. В каждом случае один локальный успех не равен системному успеху.

14 июля 2026 это стало видно на нескольких линиях. Финансовый импорт показывал рост проверок: сначала 143 из 143, потом 150 из 150, потом 156 из 156. На бумаге это выглядело как постепенное укрепление. На практике каждый новый независимый проход находил другой класс ошибки. Это хороший знак не потому, что ошибок не было, а потому что контур не разрешил спрятать их за прежним зелёным статусом.

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

Финансовый импорт: тесты не равны независимой проверке

Финансовые данные плохо прощают оптимизм. В тот день линия импорта прошла путь от 32 тестов до 156. Мы не трогали живую систему и не подменяли боевой контур экспериментом. Проверки расширялись вокруг импорта: права на колонки, скрытые поля, ширина обёртки, порядок запуска, независимая сверка. Каждый новый слой отвечал не на вопрос «работает ли happy path», а на вопрос «где система врёт себе о готовности».

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

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

На практике это означает 4 вещи. У тестов есть фиксированный список утверждений. У аудитора есть право искать вне списка. У результата есть ссылка на конкретный запуск. У зелёного статуса есть срок годности. Когда появляется новый факт, прошлый PASS не защищён авторитетом старого отчёта. Он пересчитывается.

Публикации: полный след важнее факта выхода поста

Вторая линия была контентной. Другая система следила за 7 публикациями. Счётчик дошёл до 6 из 7, но аудит нашёл 3 поста во «ВКонтакте» без полного следа проверки. Один из них появился из команды для чтения: старая программа приняла её за текст поста. Это не косметический баг. Это пример того, как публикационная автоматизация может перепутать инструкцию и артефакт.

В такой ситуации нельзя довольствоваться тем, что пост существует. Для бизнеса факт публикации не равен корректной публикации. Нужны 3 следа: какой исходник использован, какой QA-run разрешил выход, какой canonical publisher отправил текст в канал. Если один из следов отсутствует, публикация должна считаться подозрительной, даже если внешне всё выглядит нормально.

Я закрыл путь, где команда чтения могла стать текстом поста, и оставил один канал публикации с проверкой до и после. Три спорных VK-поста остались на месте, потому что удаление требует отдельного решения человека. Это важная граница. Автоматизация может заблокировать будущий ошибочный путь, может снять PASS, может поднять флаг. Но необратимые действия, особенно удаление опубликованных материалов, должны идти через human approval.

Для SEO и контент-машины это правило особенно жёсткое. Нельзя писать напрямую в blog/index.html, нельзя обходить helper, нельзя вручную править sitemap, нельзя публиковать без QA. Наличие текста не является результатом. Результат — это текст, прошедший через разрешённый путь, с проверяемым следом в задаче, ledger и аналитике. Да, бюрократично. Зато потом не приходится гадать, кто и зачем выложил строку из терминала в публичный канал.

Камеры и инфраструктура: один удачный цикл не возвращает доверие

Третья линия была инфраструктурной. В 18:46 контур камер имел свежий успешный цикл 9 из 9. В 20:00 одна камера ответила ошибкой, снимок устарел, и общий счёт за день упал с 1 успеха из 8 целей до 0 из 8. В 20:20 все 9 камер вернулись, но статус успеха остался снятым до второго естественного цикла. Один удачный кадр ещё не доказывает стабильность.

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

Поэтому self-revoking PASS должен иметь не только условие снятия, но и условие восстановления. Для камер это второй естественный цикл. Для финансового импорта — повторная независимая проверка после правки. Для публикации — canonical ledger плюс запись в marketing_publications. Для SEO-страницы — helper, rebuild, schema audit, indexability audit, claim-risk audit и post-GSC окно. У каждого контура свои доказательства, но принцип один: восстановление не должно быть дешевле снятия.

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

Каталоги и отчёты: лучше оставить пустое поле, чем выдумать классификацию

Между аварийными точками шла обычная работа, и она тоже показала правила качества. Для Hawaiian Designs мы сверили 383 товара с 38 страницами каталога, точно разложили 240 по семействам и оставили 141 без выдуманной классификации. Живой магазин не трогали: имена и адреса ждут одобрения владельца. Это та же философия, только в данных.

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

Правильный QA-контур должен разрешать честную неопределённость. 240 подтверждённых классификаций лучше, чем 383 «красивых» строки, где 141 придумана для полноты таблицы. Пустое поле, пометка needs_approval или отдельная очередь owner_review — нормальное состояние зрелой автоматизации. Это не недоделка, а защита от подмены факта догадкой.

Похожий принцип был в отчётах Vsemdom. Проверены 19 броней, внесены 25 подтверждённых строк в ДДС, пересчитан остаток к доплате УК в 37 121 337 IDR. Тут нельзя «досчитать по ощущению», потому что финансовый контур имеет последствия для инвесторов и управленческих решений. Если строка не подтверждена, она не должна попадать в закрытый результат. Если месяц закрыт, корректировка должна идти отдельным следом, а не тихим пересчётом прошлого.

Human approval gate: где автоматизация должна остановиться

Self-revoking PASS не означает, что агент получает право делать всё. Наоборот, хороший контур качества явно отделяет автоматические исправления от решений человека. 14 июля это проявилось дважды: живой магазин Hawaiian Designs оставили без изменений до одобрения владельца, а 3 VK-поста не удаляли без отдельного решения Юрия. Автоматизация нашла проблему, закрыла путь повторения, но не стала делать необратимый шаг.

Такой gate нужен в 5 типах ситуаций. Первое: деньги и финансовые записи. Второе: публичные публикации, особенно удаление или правка уже вышедшего материала. Третье: персональные данные и доступы. Четвёртое: изменения в проде, которые затрагивают клиентов. Пятое: любые действия, где цена ошибки выше цены ожидания. В этих местах агент должен уметь поставить блок и объяснить, почему человек нужен.

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

В Paperclip это выражается через статусы задач, approvals, QA-записи и явные комментарии. В контенте — через запрет force-публикаций и обязательный QA. В финансах — через approval-gate по суммам и запрет автономных write-операций. В клиентских проектах — через ожидание оплаты фазы до запроса ресурсов. У каждого правила своя история, но механика одна: агент не должен перепрыгивать через границу ответственности, даже если технически может.

Как собрать self-revoking PASS в своей системе

Практическая схема начинается с формулировки статуса. Не «готово», а «готово при условиях». Для каждой цели нужно записать, какой факт ставит PASS, какой факт его снимает и какой факт возвращает. Если эти 3 условия не описаны, статус будет декоративным. Он пригоден для отчёта, но слаб для управления.

Второй шаг — разделить producer и auditor. Агент, который сделал действие, не должен быть единственным судьёй результата. В финансовом импорте это независимая проверка поверх тестов. В публикациях — QA плюс canonical publisher ledger. В SEO — helper, schema audit, indexability audit, internal links audit и post-GSC tracking. В инфраструктуре — повторный естественный цикл вместо мгновенного прощения после одного успеха.

Третий шаг — сохранять след. Каждое решение должно отвечать на вопросы: какой источник, какой запуск, какой артефакт, какой verifier, какой timestamp. Без этого невозможно отличить системный сбой от ручного обхода. Когда старая программа приняла команду чтения за текст поста, проблема была видна именно потому, что появился конфликт между типом действия и публичным результатом.

Четвёртый шаг — запретить ложную полноту. Если классификация не подтверждена, строка остаётся в review. Если камера дала один хороший кадр после сбоя, статус ждёт второго цикла. Если SEO-страница опубликована, победа не объявляется до GSC-окна и подтверждённых кликов. Если CTA получает raw-события от ботов, отчёт ведётся по real_clicks, а не по красивой сумме переходов. Система должна уметь говорить «данных мало» без чувства вины.

Пятый шаг — привязать всё к человеческому решению там, где это нужно. Удалить пост, поменять данные владельца магазина, списать деньги, деплоить новый сервис в прод — это не область «агент сам разберётся». Автоматизация должна принести человеку короткое резюме: что найдено, почему прежний PASS снят, какие варианты есть, что будет после approval.

Что это меняет для бизнеса

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

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

Есть ещё одна причина, почему отзывной PASS нужен именно AI-агентам. Классический скрипт обычно ломается грубо: вернул ошибку, не записал файл, не получил ответ от API. Агентная система часто ломается мягко. Она выбирает неверный источник, уверенно формулирует слишком широкий вывод, считает незавершённый процесс закрытым, путает read-команду с publish-командой или переносит старую метрику в новый отчёт. Такие сбои не всегда выглядят как exception. Поэтому контроль качества должен проверять не только падения, но и смысловые несоответствия между намерением, действием и следом.

Я разделяю такие проверки на 3 уровня. Первый уровень — технический: код выполнился, helper отработал, API вернул ожидаемый статус, файл появился там, где должен. Второй уровень — процедурный: задача прошла нужного владельца, QA записан в правильную таблицу, публикация шла через canonical publisher, approval не был обойдён. Третий уровень — смысловой: опубликованный текст соответствует исходнику, число относится к правильному периоду, классификация не придумана моделью, CTA ведёт на нужный продукт, а не на удобный агенту обходной путь.

Self-revoking PASS работает только когда эти 3 уровня могут спорить друг с другом. Технический успех не должен закрывать процедурный провал. Процедурный успех не должен маскировать смысловую ошибку. Смысловая правка не должна обходить технический helper. В этом месте и появляется взрослая автоматизация: она не ищет один главный индикатор, а держит несколько независимых оснований для доверия.

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

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

Внутри команды это снижает количество ручной паранойи. Человеку не нужно каждый раз перечитывать весь лог, если система показывает, какой именно слой снял PASS и какой факт нужен для возврата. Владелец видит не абстрактное «ошибка», а конкретный маршрут: финансовый импорт ждёт независимого аудита, публикация ждёт QA-run, камера ждёт второго цикла, каталог ждёт owner approval. Это экономит внимание лучше любого зелёного дашборда.

В моём контуре это связано с клубом «Solar — внутрянка». Я показываю там не идеальную витрину, а рабочие рельсы: AGENTS.md, QA-гейты, дедуп-листы, публикационные helpers, статусы задач, правила approvals, anti-slop, SEO-tracking и примеры, где система сама сняла красивую галочку. Формат простой: вот моё, бери и адаптируй под свой бизнес.

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

Полный набор артефактов — AGENTS.md, QA-чек-листы, публикационные правила, шаблоны контроля и примеры таких контуров из моей системы — в клубе «Solar — внутрянка», от 2 500 ₽/мес. Бери и адаптируй: https://4bos.ru/inside/

Solar OS.