Менеджер по закупкам получает от ИИ-ассистента рекомендацию одобрить счет поставщика. Он нажимает «подтвердить», не открывая вложение. Через неделю выясняется: реквизиты в счете подменили, а модель не сверила их с базой контрагентов. Вопрос «кто виноват» здесь не философский. Это вопрос ИИ и человек в бизнесе: как разделить ответственность между системой и сотрудником так, чтобы такие истории не повторялись.
О том, заменит ли ИИ человека и чем это может обернуться для общества в целом, мы писали в статье о будущем искусственного интеллекта. Здесь разговор другой: не про будущее человечества, а про понедельник в отделе продаж, бухгалтерии или HR. Про то, какие правила нужны внутри компании уже сейчас, чтобы решения с участием ИИ не превращались в источник юридических и репутационных рисков.
Дальше: кто должен проверять вывод модели перед тем, как он станет действием, как фиксировать цепочку «запрос, ответ модели, решение человека», и в каких процессах человек обязан оставаться в контуре, а не просто формально нажимать «ок».
ИИ и человек в бизнесе: почему отвечает компания, а не модель
У модели нет юридического лица. Она не может быть стороной договора, истцом или ответчиком. Значит за любое действие, совершенное на основе рекомендации ИИ, отвечает тот, кто его утвердил, или компания, которая встроила модель в процесс без контроля. Суд, налоговая или контрагент не станут разбираться, какой алгоритм ошибся: они увидят подпись сотрудника, платеж с расчетного счета или письмо, отправленное от имени организации.
В России нет отдельного закона, который прямо регулирует распределение ответственности за решения ИИ внутри бизнеса. Есть Кодекс этики в сфере искусственного интеллекта, принятый 26 октября 2021 года Альянсом в сфере ИИ вместе с Аналитическим центром при правительстве и Минэкономразвития. Но сам кодекс прямо называет себя рекомендательным: присоединение к нему добровольное, а его нормы не заменяют ни договор, ни внутренний регламент компании. К кодексу присоединились сотни организаций, включая крупнейшие банки и ИТ-компании, но подпись под документом не освобождает от операционной работы. Правила ответственности компания выстраивает сама, и именно от их качества зависит, что произойдет, если модель ошибется.
На практике это означает: прежде чем включать ИИ в процесс, нужно решить, кто подписывает итоговое действие, а не только кто настраивает модель. Специалист, который просто разрешил использовать ассистента, редко совпадает с тем, кто должен объяснять контрагенту или проверяющему органу, почему решение оказалось ошибочным. Распределение этих ролей стоит закрепить письменно, а не держать в голове у руководителя отдела.
Три уровня риска: когда ИИ решает сам, а когда нужен человек
Удобный способ не растягивать контроль на все процессы одинаково: разделить решения по уровню риска. Чем выше цена ошибки, тем жестче требование к присутствию человека.
| Уровень риска | Примеры решений | Роль ИИ | Роль человека |
|---|---|---|---|
| Низкий | Черновик письма, категоризация заявок, подсказки для оператора | Действует автономно после настройки | Периодический выборочный аудит, без проверки каждого случая |
| Средний | Скоринг лидов, рекомендации по цене, план рекламной кампании | Готовит вариант и обоснование | Проверяет перед запуском, может отклонить без объяснения модели |
| Высокий | Платежи, кадровые решения, юридически значимые документы, медицина и безопасность | Только советует, не действует сама | Обязательное подтверждение человеком перед каждым действием, с подписью и фиксацией причины |
Граница между уровнями не абстрактная: она зависит от того, можно ли отменить последствия решения без потерь. Платеж, увольнение, отказ клиенту в выплате: все это решения, которые дорого разворачивать назад. Если ошибка необратима или задевает третьих лиц, человек должен стоять между выводом модели и действием, а не после него.
Полезно пересматривать эту границу не реже раза в год: то, что сегодня относится к низкому риску, может перейти в средний, если процесс начинает затрагивать больше клиентов или крупнее суммы. Статичный список уровней риска устаревает так же быстро, как и сам продукт на основе ИИ.
Где граница проходит чаще всего
- Финансовые операции выше установленного компанией порога суммы
- Решения, которые меняют статус сотрудника: наем, увольнение, премия, дисциплинарное взыскание
- Коммуникация, которая публикуется от имени компании вовне: пресс-релизы, ответы в публичных каналах, юридические письма
- Решения, где ошибка задевает здоровье, безопасность или персональные данные клиента
- Договоры и коммерческие предложения с индивидуальными условиями, которые нельзя откатить после отправки клиенту
- Решения, влияющие на кредитный лимит, скоринг или доступ клиента к услуге
Кто проверяет вывод модели: четыре роли
Без распределения ролей проверка превращается в формальность: один и тот же человек пишет запрос модели и сам же его утверждает, а значит никто фактически не проверяет вывод. Рабочая схема держится на четырех ролях, даже если в небольшой компании их выполняют два человека.
- Владелец процесса: решает, где в принципе допустим ИИ, и устанавливает уровень риска для каждого сценария.
- Проверяющий: читает вывод модели до того, как он повлияет на клиента, деньги или документ, и ищет фактические ошибки и несоответствия.
- Утверждающий: обладает полномочием запустить действие и несет ответственность за решение независимо от того, кто его предложил.
- Аудитор: раз в период просматривает выборку решений и логов, чтобы поймать системную ошибку, а не единичный случай.
Эти роли не обязаны существовать в виде отдельных штатных единиц. В компании из десяти человек владельцем процесса и утверждающим вполне может быть один руководитель, а проверяющим кто-то из команды, кто физически не участвовал в формулировке запроса. Главное условие: проверяющий и утверждающий не совпадают с тем, кто составил запрос к модели, иначе проверка превращается в самопроверку.
Проверяющему особенно важно помнить: модель может уверенно сформулировать неверный факт, цифру или ссылку на документ, которого не существует. Почему это происходит и как с этим бороться, мы разбирали в статье про ИИ-галлюцинации. Правило простое: чем увереннее звучит ответ модели, тем внимательнее его стоит сверять с первоисточником, а не с собственным ощущением правдоподобности.
Как документировать цепочку решений
Если решение с участием ИИ оспорят, клиент пожалуется или внутренний аудит задаст вопрос, у компании должна быть возможность восстановить всю цепочку: что спросили у модели, что она ответила, кто это проверил и на основании чего приняли итоговое решение. Без этого разговор о причинах ошибки превращается в гадание.
Минимальный набор данных, который стоит сохранять для каждого решения среднего и высокого риска:
- Исходный запрос или данные, на основе которых модель готовила ответ
- Версия модели или промпта на момент решения
- Полный ответ модели, без сокращений
- Имя и роль проверяющего, дата и время проверки
- Итоговое решение человека и его обоснование, если оно отличается от предложения модели
- Фактическое действие и его результат
Хранить эти данные удобнее в той же системе, где фиксируются остальные операционные логи компании, а не в отдельной таблице, которую ведут вручную. Ручной лог быстро расходится с реальностью: сотрудник забывает вписать строку в момент загрузки, а через месяц восстановить точный порядок действий уже невозможно.
Срок хранения этих логов логично привязывать к сроку хранения документов самого процесса: если бухгалтерская проводка хранится несколько лет по внутренней политике компании, лог решения, которое к ней привело, хранится столько же. Отдельного универсального срока для «логов ИИ» не существует, он всегда наследуется от процесса, в который встроена модель.
Где компании чаще всего ошибаются
- Логируют только факт использования ИИ, без самого ответа модели и без версии промпта, из-за чего ошибку потом невозможно воспроизвести
- Поручают проверку тому же человеку, который формулировал запрос, и теряют независимый взгляд на результат
- Считают, что ИИ-ассистент обучен «понимать контекст компании», и пропускают его вывод без сверки с регламентом или базой данных
- Меняют модель или промпт без уведомления проверяющих, из-за чего правила проверки устаревают быстрее, чем их пересматривают
- Вводят правила контроля только после инцидента, а не до масштабирования процесса на ИИ
- Не разделяют лог для низкорискового и высокорискового сценария, из-за чего важные записи тонут среди рутинных черновиков
Кодекс этики ИИ и ISO 42001: на что опереться
Два ориентира помогают не изобретать правила с нуля. Российский Кодекс этики в сфере искусственного интеллекта описывает общие принципы: приоритет человека, прозрачность, недопустимость вреда. Это система добровольных рекомендаций, а не технический регламент, поэтому она не подскажет, как оформить лог проверки или кто утверждает платеж. Международный стандарт ISO/IEC 42001, опубликованный ISO и IEC в декабре 2023 года, устроен конкретнее: это стандарт системы менеджмента ИИ, по которому можно пройти сертификацию, и он прямо требует определять роли, оценивать риски применения ИИ и фиксировать человеческий надзор за решениями.
Для небольшой компании смысл не в том, чтобы выбрать один документ и слепо следовать его тексту, а в том, чтобы взять принципы кодекса как публичную позицию для клиентов и партнеров, а структуру ISO 42001 как внутренний рабочий чек-лист. Это разные по природе документы: один декларирует ценности, другой описывает процесс.
| Документ | Статус | Что дает бизнесу |
|---|---|---|
| Кодекс этики в сфере ИИ (2021) | Рекомендательный, добровольное присоединение | Публичную позицию и общие принципы для политики компании |
| ISO/IEC 42001:2023 | Международный стандарт, сертифицируемый | Структуру процессов, ролей и контроля рисков, даже без прохождения сертификации |
Компании не обязаны сертифицироваться по ISO 42001, чтобы использовать его логику. Структуру стандарта удобно взять как чек-лист при написании внутреннего регламента: какие роли нужны, что документировать, как часто пересматривать правила.
Частые вопросы
Кто юридически отвечает, если ИИ принял неверное решение в компании?
Отвечает компания и конкретный сотрудник, утвердивший действие, а не модель: у ИИ нет юридического лица и он не может быть стороной спора. Если решение привело к ущербу, разбирают, кто должен был проверить вывод модели и почему проверка не сработала, а не то, «почему ошибся алгоритм».
Нужно ли всегда проверять вывод ИИ человеком перед действием?
Нет, это зависит от уровня риска. Для низкорисковых задач, например черновиков текста, достаточно периодического выборочного аудита. Для финансовых операций, кадровых решений и публичных коммуникаций нужна обязательная проверка и подпись человека перед каждым конкретным действием.
Обязателен ли Кодекс этики ИИ для российских компаний?
Нет, кодекс носит рекомендательный характер, присоединение добровольное. Он принят 26 октября 2021 года Альянсом в сфере ИИ и к нему присоединились сотни организаций, но подпись под документом не заменяет внутренний регламент компании по проверке и документированию решений с ИИ.
Что даст компании стандарт ISO/IEC 42001, если она не планирует сертификацию?
Даже без сертификации структуру стандарта, опубликованного в декабре 2023 года, можно использовать как шаблон внутреннего регламента: он описывает, как оценивать риски применения ИИ, какие роли нужны для контроля и как фиксировать человеческий надзор за решениями.
Сколько нужно хранить логи решений, принятых с помощью ИИ?
Единого универсального срока нет. Логично привязать срок хранения лога к сроку хранения документа или решения, которое ИИ помогал подготовить: если это бухгалтерский или кадровый документ, лог хранится по той же внутренней политике, что и сам документ.
С чего начать
- Составьте список процессов, где уже используется или планируется ИИ, и присвойте каждому уровень риска: низкий, средний, высокий.
- Назначьте для процессов среднего и высокого риска отдельных проверяющего и утверждающего: это не должен быть один человек.
- Введите единый формат лога решения: запрос, версия модели, ответ, проверка, итоговое действие.
- Зафиксируйте периодичность аудита логов, например раз в квартал, и ответственного за него.
Если выстраивать эти правила и саму автоматизацию процессов с ИИ самостоятельно некогда, этим занимается команда автоматизации Neurounit: там изначально закладывают роли проверки и логирование в сценарии работы с ИИ, а не добавляют их постфактум после инцидента.
