Контроль над ИИ-системой строится из четырёх уровней, и ни один из них не сводится к тому, чтобы читать ответы модели. Часть действий модели не разрешена вообще - на уровне прав доступа. Часть проходит через утверждение человеком. Часть решается правилами до обращения к модели. И для всего остального описано, что происходит при отказе.
Это не про недоверие к технологии. Это про то, что вероятностный инструмент нельзя проверять теми же способами, что обычную программу: у неё нет одинакового ответа на одинаковый вход, и «протестировали, работает» здесь не значит ничего.
Почему «проверять ответы» не работает
Идея выглядит разумно: пусть сотрудник читает то, что предложила система, и исправляет ошибки. На практике она разваливается по трём причинам:
- Экономика. Если проверка ответа занимает столько же времени, сколько сделать работу самому, экономии нет. А именно так и получается, когда ответ приходит без указания источника: чтобы убедиться, человек открывает те же документы и читает их сам.
- Внимание. Человек, который двести раз подряд увидел правильный ответ, на двести первом нажимает «принять» не глядя. Это свойство внимания, а не халатность, и бороться с ним увещеваниями бесполезно.
- Масштаб. Проверка ответов не масштабируется: рост объёма в десять раз означает рост нагрузки на проверяющего в те же десять раз, и вся выгода автоматизации исчезает.
Работающий контроль устроен иначе: он не про чтение каждого ответа, а про то, что система физически не может сделать, и про то, что проверяется автоматически.
Четыре уровня контроля
| Уровень | Что решает | Как проверить, что он есть |
|---|---|---|
| Что модели не разрешено | Ограничивает область возможного вреда независимо от поведения модели | Попросите список выданных прав и ключей: запреты должны быть видны там, а не в инструкции для модели |
| Что проходит через утверждение | Ставит человека между предложением и действием там, где цена ошибки высокая | Спросите, какие действия требуют подтверждения сейчас и по какому признаку подтверждение снимается |
| Что решается правилами до модели | Убирает из работы модели то, где правило записывается словами | Спросите, какая доля обращений закрывается без вызова модели вообще |
| Что происходит при отказе | Не даёт задаче исчезнуть или пройти дальше как выполненной | Спросите, куда уходит задача при сбое и кто по имени разбирает эту очередь |
Что модели вообще не разрешено
Самый надёжный уровень, потому что он не зависит от поведения модели. Запрет живёт в правах доступа и в коде: если система не должна отправлять письма клиентам, у неё нет ключей от почты. Если не должна менять сумму сделки, у её учётной записи нет прав на это поле.
Инструкция в промпте вида «не трогай настройки доступа» - это просьба. Модель её нарушает, и происходит это регулярно, особенно когда в текст, который она обрабатывает, кто-то намеренно вписал другую инструкцию. Проверяется этот уровень не доверием, а списком выданных доступов.
Что проходит через утверждение человеком
Второй уровень для действий, которые разрешены, но дорого стоят при ошибке. Система готовит результат и показывает его человеку, человек нажимает «да» или правит.
Важно, что стоит рядом с кнопкой. Хорошее подтверждение показывает предложенное действие вместе с основанием: документ, из которого взят ответ, или поля карточки, на которых построено решение. Тогда проверка занимает секунды. Плохое подтверждение - это кнопка «применить» без объяснения, и через неделю её нажимают не глядя.
Что решается правилами до модели
Третий уровень часто пропускают, а он самый дешёвый. Значительная часть обращений закрывается без языковой модели вообще: точное совпадение с типовым вопросом, поиск по ключу, проверка формата. Правило, которое можно записать словами без «примерно», отдаётся обычному коду.
Выгода двойная. Такие ответы предсказуемы и бесплатны, а модель получает меньше работы, и на оставшемся её качество выше, потому что задача стала уже.
Что происходит при отказе
Четвёртый уровень описывает поведение системы, когда что-то пошло не так: модель не смогла ответить, интеграция вернула ошибку, документ оказался нечитаемым.
Правильное поведение: задача не исчезает и не проходит дальше как выполненная. Она уходит в очередь к человеку с описанием того, что именно не получилось. У очереди есть хозяин по имени и выделенное время на её разбор. Без хозяина очередь копится, и через месяц системой перестают пользоваться.
Первый месяц: человек утверждает всё
Стандартный режим запуска: месяц каждое действие подтверждает человек. Это не осторожность ради осторожности, а способ собрать данные.
За месяц накапливается статистика: на каких типах обращений система ошибается, на каких не ошибается никогда, где ошибки дорогие и где безобидные. По этой статистике подтверждение снимается точечно - с тех шагов, где промахов не было, и остаётся там, где цена ошибки высокая.
Второй эффект человеческий. Люди перестают бояться, когда месяц видят, что предлагает система, и понимают её сильные и слабые места. Запуск в полностью автоматическом режиме с первого дня даёт обратный результат: одна заметная ошибка на первой неделе закрывает проект независимо от общего качества.
Расписания у снятия подтверждения нет. Есть накопленные цифры, и решение принимается по ним.
Как понять, что действие действительно выполнено
Отдельная тема, потому что здесь ломается больше всего интеграций.
Система отправила запрос в CRM, сервер ответил «принято», статус зелёный. А карточка не изменилась: сработало правило автоматизации, поле оказалось обязательным, у учётной записи не хватило прав, запись была заблокирована другим процессом.
Правильная схема - обратная проверка. После действия система перечитывает состояние и сверяет с ожидаемым: стало ли поле таким, каким должно было стать. Не сошлось - несколько попыток с паузой, потом очередь к человеку с описанием расхождения.
Это скучная и дорогая часть работы, и её обычно не делают. Именно из-за неё зелёный индикатор может неделями скрывать, что половина заявок никуда не записалась. Спросить про это стоит до договора: вопрос входит в список как выбрать подрядчика, а разбор последствий - в материале про то, почему проекты не доходят до результата.
Что измерять
| Что обычно показывают в отчёте | Что стоит спрашивать вместо этого |
|---|---|
| Обработано 3 000 обращений | Сколько из них закрыто без участия человека |
| Средняя точность 92% | На каких типах обращений ошибки и сколько они стоят |
| Система работает без сбоев | Сколько задач ушло в очередь к человеку и за какое время её разобрали |
| Сотрудники используют систему | Сколько времени экономит одно обращение с учётом проверки |
| Модель обновлена до новой версии | Изменилась ли доля ошибок после обновления и на чём это замерили |
Левая колонка - активность, она растёт всегда просто потому, что систему включили. Правая - исход, ради которого затевалось. Метрика выбирается до начала работ и записывается в задание: как формулировать, разобрано в материале про постановку задачи подрядчику.
Когда автономность оправдана
Полностью автоматический режим без подтверждения возможен, и иногда он правильный. Условия три, и нужны все:
- Цена ошибки низкая: промах замечают и исправляют за секунды, необратимых последствий нет.
- Статистика собрана: на этом типе задач за месяц наблюдения ошибок не было или они были в пределах, которые вы готовы принять.
- Есть обратная проверка: система сама убеждается, что действие выполнено, и умеет отправить задачу человеку, когда не убедилась.
Типичные кандидаты - разметка тем обращений, заполнение служебных полей, черновики внутренних документов. Типичные некандидаты - всё, что видит клиент, и всё, что связано с деньгами.
Требования к данным в автономном режиме те же, что и в ручном, и они не смягчаются от того, что человек перестал смотреть: разбор лежит в разделе про требования 152-ФЗ.
Как это выглядит в моих проектах
- Права выдаются по минимуму: система получает доступ ровно к тем полям и действиям, которые нужны задаче, и ни к чему больше. Список доступов - часть передаваемой документации, его можно открыть и проверить.
- Первый месяц подтверждение стоит на всём, что меняет данные или видно клиенту. Каждое подтверждение показывает основание: документ или поля, на которых построено решение.
- После каждого действия в чужой системе идёт обратная проверка состояния. Расхождение - три попытки, потом очередь.
- У очереди назначен человек со стороны клиента ещё до запуска. Не отдел, а конкретный человек, и на разбор у него выделено время в календаре.
Как это устроено внутри услуги, описано на страницах про внедрение под ключ и разработку ассистентов и агентов. Общая карта темы - в материале про внедрение ИИ в бизнес.
Частые вопросы
Не превращается ли утверждение человеком в ту же ручную работу?
Превращается, если подтверждение сделано плохо. Когда человек, чтобы принять решение, вынужден открывать те же документы и читать их сам, экономии действительно нет. Правильное подтверждение показывает основание рядом с предложением: документ-источник или поля, из которых собран ответ. Тогда проверка занимает секунды вместо минут, и разница между «сделать самому» и «проверить» становится десятикратной.
Сколько времени занимает утверждение в первый месяц?
Зависит от объёма, но порядок такой: несколько секунд на обращение при хорошо сделанном подтверждении. При потоке в сотню обращений в день это меньше часа. Планировать первый месяц надо так, будто экономии нет вовсе: она появляется со второго-третьего, когда подтверждение снимается с шагов, где ошибок не было.
Можно ли сделать ИИ-систему полностью автономной?
На отдельных задачах да, при трёх условиях: низкая цена ошибки, собранная за месяц статистика без промахов и наличие обратной проверки выполнения. На задачах, которые видит клиент, и на всём, что связано с деньгами, автономность я не рекомендую независимо от статистики: выигрыш во времени там мал, а цена одного заметного промаха высока.
Как проверить, что подрядчик выстраивает контроль?
Тремя вопросами. Первый: покажите список прав и ключей, которые получит система, - запреты должны быть видны там, а не в инструкции для модели. Второй: как вы проверяете, что действие реально выполнено, а не вернуло «принято». Третий: куда уходит задача при сбое и кто по имени её разбирает. Конкретные ответы на все три означают, что человек работал с живой эксплуатацией, а не собирал демо.
Что делать, если система уже работает без контроля?
Начать с двух самых дешёвых уровней. Первый - посмотреть выданные права и убрать всё, что задаче не нужно: это делается за день и сразу ограничивает область возможного вреда. Второй - завести очередь для сбоев и назначить человека, который её читает. Подтверждение действий и обратную проверку добавляют следом, и это уже работа на несколько дней. Останавливать систему на время этих правок обычно не требуется.
Что дальше
Если нужно понять, где в вашем случае должен стоять человек и что можно отдать системе, это разбирается на бесплатном разборе за тридцать минут: смотрим процесс и цену ошибки на каждом шаге.
Написать можно в Telegram или на почту hi@za-ai.ru.