Кто отвечает за результат ИИ-проекта

Что произошло

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

Расхождение объясняется управлением. По отраслевым исследованиям, две зависимости повторяются от отрасли к отрасли. Проекты с назначенным ответственным за результат — конкретным человеком со стороны бизнеса — дают отдачу втрое выше проектов, где ответственность распределена между комитетом, подрядчиком и ИТ-департаментом. А проекты с прозрачным учётом затрат — стоимость инференса, разметки, сопровождения, времени сотрудников — окупаются впятеро чаще тех, где затраты растворены в общем ИТ-бюджете.

Эти два наблюдения объясняют, почему разговор об ИИ сместился от архитектуры к организации. Вопрос «какую модель выбрать» стал техническим. Вопрос «кто отвечает за то, что система работает и приносит деньги» — главным.

Одновременно изменилась природа самих систем. Пока ИИ отвечал на вопросы, ответственность была понятна: ответ читает человек, он и решает. Когда ИИ начал выполнять действия — создавать документы, менять данные в учётных системах, отправлять сообщения контрагентам, — вопрос ответственности стал вопросом комплаенса, и регуляторы обратили на него внимание.

Формула ответственности: четыре роли

Мы описываем распределение ответственности в ИИ-проекте формулой из четырёх частей: человек отвечает, ИИ исполняет, процедура подтверждает, правило останавливает. Каждая часть — отдельная роль с отдельным механизмом, и отсутствие любой из них делает контур неуправляемым.

Человек отвечает: владелец процесса

Ответственный за результат ИИ-проекта — это не руководитель проекта внедрения и не руководитель ИТ. Это владелец бизнес-процесса, в который ИИ встраивается: руководитель службы поддержки, если автоматизируется обработка обращений; главный бухгалтер, если — сверка документов; директор по закупкам, если — подготовка спецификаций. Именно он знает, как процесс измеряется сегодня, и именно ему предстоит объяснять, почему показатель изменился или не изменился.

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

Владелец процесса получает три полномочия: утверждать метрики, на которых измеряется результат; останавливать систему, если метрики ухудшились; менять границы автоматизации — какие случаи система решает сама, какие передаёт людям.

ИИ исполняет: границы автоматизации

Роль ИИ — выполнить работу внутри заданных границ. Границы описываются явно: перечень типов задач, которые система обрабатывает; перечень действий, которые она может совершать в учётных системах; перечень случаев, в которых она обязана передать задачу человеку. Всё, что не входит в перечень, — запрещено.

Механика здесь важнее формулировок. Границы должны быть реализованы технически, а не только в регламенте: система имеет доступ только к тем функциям учётных систем, которые перечислены; действия за пределами перечня невозможны на уровне прав, а не на уровне инструкции в промпте. Инструкция «не удаляй записи» в промпте — не граница. Отсутствие права на удаление у учётной записи, от имени которой работает система, — граница.

Процедура подтверждает: метрики до и после

Результат ИИ-проекта существует только в сравнении. До запуска фиксируются показатели процесса: время обработки, доля ошибок, стоимость операции, нагрузка на сотрудников. После запуска те же показатели измеряются тем же способом. Разница — результат, и он либо есть, либо нет.

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

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

Правило останавливает: критерий остановки и журнал

Четвёртая роль — правило, при выполнении которого система прекращает работу или передаёт задачу человеку без обсуждения. Правило формулируется до запуска и включает три вида условий.

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

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

Ответственность без правила остановки — это обещание. Правило остановки без ответственного — это выключатель, который никто не нажмёт.

Как это выглядит на практике

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

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

Сеть клиник, заполнение медицинской документации. Здесь границы задал регулятор: система готовит черновик, врач подтверждает каждый документ. Метрика процесса — время врача на документацию — измерялась до и после. Журнал хранит все версии черновика и правки врача. Именно наличие журнала позволило пройти проверку без замечаний.

Что это значит для российской компании

Регуляторный взгляд. Российские регуляторы подходят к автоматизированным решениям с одной общей позиции: у каждого решения, влияющего на клиента или на безопасность, должен быть ответственный, и решение должно быть объяснимо. Для Банка России ответственность кредитной организации перед клиентом не зависит от того, принял решение сотрудник или алгоритм, а требования к операционной надёжности распространяются на любые автоматизированные системы. 152-ФЗ требует, чтобы решения, порождающие юридические последствия для субъекта персональных данных, не принимались исключительно автоматически без его согласия и без возможности оспорить. Для субъектов КИИ требования к управлению изменениями и журналированию действий распространяются на любые системы внутри значимых объектов, включая ИИ.

Из этого следует практический вывод: агентный контур, в котором система совершает действия без правила остановки и без журнала, не пройдёт внутренний комплаенс в банке, страховой компании, операторе связи или промышленной компании с объектами КИИ. Не потому, что регулятор прямо запретил ИИ, а потому, что ответить на вопросы «кто принял решение», «почему» и «как его остановить» будет некому.

Закрытый контур. Журнал действий ИИ-системы содержит входные данные — а значит, персональные данные, коммерческую тайну, данные КИИ. Он хранится внутри периметра, и модель, которая эти данные обрабатывает, — тоже. Это определяет архитектуру: инференс на своих серверах, журнал в своей базе, доступ по ролям.

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

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

Что делать: пошагово

1. Назначьте владельца процесса до выбора технологии. Одного человека, руководителя подразделения, в чьи показатели встроится результат. Зафиксируйте его полномочия: метрики, остановка, границы.
2. Измерьте процесс до запуска. Время, стоимость, доля ошибок, нагрузка на людей — тем способом, которым будете измерять после. Без базовой линии результата не будет.
3. Посчитайте полную стоимость. Инференс на плановую нагрузку, сопровождение, разметка, время сотрудников на проверку. Сравните с ожидаемым эффектом. Если экономика не сходится — не запускайте.
4. Опишите границы автоматизации явно. Перечень задач, перечень действий в системах, перечень случаев эскалации. Реализуйте границы правами доступа, а не инструкциями.
5. Сформулируйте правило остановки. Условия на уровне операции, потока и изменений. Кто и как принимает решение о возобновлении.
6. Постройте журнал. Для каждого действия — входные данные, источники, решение, уверенность, подтверждение. Проверьте, что по журналу можно восстановить любой случай.
7. Запустите в режиме подтверждения. Первые недели каждое действие подтверждает человек; система накапливает статистику. Автоматизацию расширяйте по типам задач, где расхождения с человеком минимальны.
8. Пересматривайте метрики ежемесячно. Владелец процесса получает отчёт по метрикам до и после, затратам, эскалациям и остановкам — и принимает решение о расширении, сужении или закрытии.

Типичные ошибки

• Назначать ответственным руководителя ИТ или подрядчика. Почему: ни тот ни другой не отвечает за бизнес-показатель процесса и не может изменить процесс. Что вместо: владелец процесса из бизнес-подразделения с полномочиями.
• Измерять систему вместо процесса. Почему: точность модели не говорит о том, стал ли процесс быстрее и дешевле. Что вместо: метрики процесса до и после, измеренные одним способом.
• Задавать границы в промпте. Почему: инструкция в промпте — не ограничение, а пожелание, которое модель может проигнорировать. Что вместо: права доступа и перечень доступных функций на уровне интеграции.
• Откладывать правило остановки «до первого инцидента». Почему: первый инцидент случается на живых данных и стоит дороже проекта. Что вместо: правило до запуска, проверенное на тестовом стенде.
• Вести журнал для разработчиков, а не для аудита. Почему: технические логи не отвечают на вопрос «почему принято это решение» и не хранятся достаточно долго. Что вместо: журнал решений с входными данными и источниками, срок хранения по требованиям регулятора.
• Растворять затраты в ИТ-бюджете. Почему: без выделенного учёта невозможно закрыть неокупаемый проект — он не виден. Что вместо: отдельная статья с инференсом, сопровождением и временем сотрудников.

Как понять, что вы на верном пути

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

Вопросы, которые нам задают

Что делать, если владелец процесса не хочет брать ответственность? Это сигнал, а не препятствие. Чаще всего отказ означает, что владелец не верит в эффект или не понимает, как система устроена. В первом случае стоит пересчитать экономику вместе с ним — возможно, он прав. Во втором — провести управленческое обучение и запустить систему в режиме подтверждения, чтобы он увидел её работу до того, как отвечать за неё.

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

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

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

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