Контроль АС: что проверять, когда работу за вас делает автоматизированная система

Когда часть работы уходит программе, роботу или ИИ-ассистенту, появляется новый вид задач: проверять, что эта штука до сих пор делает то, что нужно. Это и есть контроль АС.

Что скрывается за аббревиатурой

АС — автоматизированная система. Связка из людей, программ и правил, которая выполняет работу по заданному сценарию. Под определение попадает многое: бухгалтерская программа, CRM, скрипт выгрузки отчётов, чат-бот на сайте, ИИ-ассистент, который разбирает входящую почту.

Контроль АС отвечает на один вопрос: система выдаёт то, что от неё ждут? Всё остальное — способы получить на него честный ответ.

Три точки, где контроль реально работает

Проверять всё подряд бессмысленно. Контроль имеет смысл в трёх местах.

На входе. Какие данные попадают в систему и кто имеет к ней доступ. Мусор на входе даёт мусор на выходе, и никакая проверка результата этого не спасёт. Сюда же — права: кто может менять настройки, промпты, правила обработки.

В процессе. Логи и промежуточные результаты. Система, которая работает молча и показывает только финал, непроверяема по определению. Если журнала действий нет, контроль сводится к гаданию.

На выходе. Сверка результата с эталоном. Эталон придётся сделать руками один раз: десяток примеров, где вы точно знаете правильный ответ.

Почему с ИИ-ассистентом схема ломается

Обычная АС предсказуема. Скрипт, который считает сумму по столбцу, посчитает её одинаково сегодня и через год. Настроили, проверили при внедрении, дальше поглядываете на ошибки.

С ИИ-ассистентом так не выйдет по двум причинам.

Первая: один и тот же запрос даёт разные формулировки ответа. Совпадение с эталоном символ в символ перестаёт быть критерием — приходится оценивать смысл.

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

Вывод простой: контроль ИИ-ассистента живёт в режиме регулярной выборочной проверки. Разовой приёмки при внедрении мало.

Практический минимум

Вот что я делаю, когда запускаю любую автоматизацию в работу.

• Собираю набор тестовых кейсов. Десять–двадцать реальных примеров с заранее известным правильным результатом. Половину беру простых, половину — пограничных, где легко ошибиться.
• Прогоняю их перед запуском и после каждого изменения. Меняли промпт, правило, источник данных — прогон заново.
• Ввожу выборочную проверку. Каждую неделю смотрю несколько случайных результатов целиком, от входных данных до финала.
• Записываю, что считаю ошибкой. Без этого разные люди будут считать ошибкой разное, и статистика не сойдётся.
• Оставляю ручной путь. Если система встала, работа должна продолжиться руками. Иначе одна сломанная интеграция останавливает отдел.

Чек-лист перед запуском

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

Частые ошибки

Контроль ради отчёта. Галочки проставлены, результаты никто не смотрел. Такой контроль хуже отсутствующего: он создаёт ложное спокойствие.

Проверка только финального результата. Итог выглядит правдоподобно, а внутри система взяла данные из устаревшего источника. Наружу это вылезет через месяц.

Один человек и настраивает, и проверяет. Он проверяет свою же логику и видит то, что ожидает увидеть.

Проверка по ощущениям. «Вроде нормально работает» — это отсутствие критерия. Нужна пара конкретных признаков, по которым результат либо принимают, либо возвращают.

Отсутствие пересмотра. Правила проверки писались под старый процесс, процесс изменился, проверка осталась прежней и ловит пустоту.

С чего начать

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

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

Контроль АС стоит воспринимать как часть эксплуатации, наравне с обновлениями и резервными копиями. Система, которую никто не проверяет, рано или поздно начинает врать — тихо, правдоподобно и долго.