Компания покупает ИИ решение, вешает его на сайт или на телефон и через квартал не может сказать, стало лучше или хуже. Это не редкий случай, это типовой сценарий. И причина почти никогда не в модели.
Причина в том, что до установки не сняли базовую линию. Нет цифры до, значит нет цифры после, значит спор о пользе превращается в спор о вкусах. Модель тут ни при чём, сломана рамка внедрения.
Что говорит государственный стандарт
Полезно посмотреть, как это устроено у тех, кто пишет правила. Ядро NIST AI Risk Management Framework состоит из четырёх функций: govern, map, measure, manage. Управлять, описывать, измерять, регулировать. Измерение стоит внутри рамки, а не сбоку от неё.
Функция governance описана как сквозная: она пронизывает три остальные, а не идёт отдельным этапом в конце. На практике это значит, что правила игры задаются до запуска, а не пишутся задним числом, когда что-то пошло не так.
В разделе о постановке риска NIST описывает управление рисками ИИ как путь к снижению возможного негативного воздействия таких систем. Речь именно про управление риском, а не про определение самого риска. Смысл простой: риск не повод отказываться от внедрения, это то, чем надо управлять по ходу.
Зрелое внедрение пишет критерий go или no-go заранее
В разделе об эффективности фреймворка перечислено, что пользователи фреймворка, как ожидается, получают. В этом списке стоят явные процессы принятия решения go или no-go о вводе системы в эксплуатацию. Это не предписание сверху, а описание того, чем отличается зрелое внедрение от незрелого. Явные, то есть записанные заранее, с критерием.
У большинства пилотов такого критерия нет вообще. Никто не договорился, при каком результате пилот считается удачным, а при каком его выключают. Поэтому неудачные пилоты не останавливают, а тихо расширяют, надеясь, что на большем объёме заработает.
Там же NIST рекомендует периодически оценивать, улучшил ли фреймворк способность управлять рисками. Оценивать периодически, а не один раз при запуске.
Последовательность, которая работает
Сначала две недели замеров, до того как что-то трогать. Считаем то, что и так происходит: сколько обращений пришло, за сколько ответили, сколько потеряли на каждом переходе.
Потом один процесс, не пять. Пять автоматизаций одновременно дают неразличимый результат: непонятно, что помогло, а что навредило.
Потом теневой режим. Агент предлагает действие, но не выполняет его, а человек сравнивает предложение со своим решением. Неделя такого режима показывает качество лучше любой презентации.
Потом гейт подтверждения на всё, что уходит наружу к клиенту. И только после этого узкая автономия на самом безопасном шаге.
Пилот, который нельзя провалить
Отдельная ловушка это пилот, устроенный так, что провалиться он не может в принципе. Успехом объявляется всё: сотрудникам понравилось, интерфейс удобный, вопросов стало меньше. Такой пилот ничего не проверяет, он только тратит квартал.
Признак простой. Если до запуска нельзя назвать результат, при котором вы скажете «не сработало», то это не эксперимент, а покупка с отложенным разочарованием.
Кто именно скажет слово «выключаем»
Управление у NIST описано как сквозная функция, а не как этап. На языке небольшой компании это значит, что у цифры есть конкретный человек, и его имя записано там же, где критерий.
Запускает пилот обычно один, данные смотрит другой, а решение не принимает никто. Поэтому неудачные внедрения не выключают, а тихо расширяют, надеясь, что на большем объёме заработает.
Критерий остановки задаётся заранее
Через тридцать дней смотрим четыре цифры: скорость первого ответа, доля пойманных обращений, возвращённые часы ручной работы и одна цифра по выручке. Если не сдвинулась ни одна, пилот провалился и его надо выключать.
Это и есть то самое решение no go, записанное заранее. В PATech мы ставим его в самом начале, потому что внедрение без критерия остановки это не проект, а надежда.