Риски внедрения ИИ: где нужен контроль человека, а где он мешает автоматизации

В ИИ-процессе легко построить одну из двух плохих систем.

В первой модель получает слишком много свободы: сама отправляет сообщения, меняет данные в CRM, запускает операции и только после ошибки привлекает внимание сотрудника. Во второй человек подтверждает каждый шаг — резюме письма, категорию заявки, найденный документ, внутреннюю заметку. Формально контроль есть. По факту сотрудник превращается в кнопку «Одобрить», а автоматизация создаёт новую очередь.

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

Главный вопрос поэтому звучит не так: «Можно ли доверять ИИ?» Нужно спросить: какое действие система собирается выполнить, что произойдёт при ошибке и можно ли безопасно вернуть процесс назад?

Контроль нужен не над моделью вообще, а над конкретным действием

Один и тот же ответ модели может иметь разный риск.

Если ИИ подготовил внутреннее резюме заявки, ошибка приведёт к дополнительной проверке менеджером. Если тот же текст автоматически ушёл клиенту как коммерческое предложение, последствия уже другие. А если на основании распознанной суммы система инициировала платёж, цена ошибки выросла ещё сильнее.

Поэтому сначала нужно разделить две сущности:

1. Предложение модели. Классификация, извлечённые поля, черновик письма, найденные документы, рекомендуемое действие.
2. Изменение внешней системы. Отправка сообщения, запись в CRM, смена статуса, удаление данных, выдача доступа, финансовая операция.

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

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

Четыре режима участия человека

Для проектирования контроля удобно использовать не два состояния — «автоматически» и «вручную», — а четыре.

Режим	Когда подходит	Примеры
Автоматическое выполнение	Ошибка недорогая, действие обратимо, результат проверяется кодом	Нормализация телефона, поиск дубля, техническое повторение запроса
Автоматически с наблюдением	Большой поток однотипных операций, ошибки можно обнаружить и откатить	Классификация обращений, внутренние резюме, заполнение некритичных полей
Подтверждение до действия	Есть внешний эффект, финансовое или репутационное последствие, сложный откат	Отправка письма клиенту, изменение условий, возврат, массовое обновление
Решение человека	Недостаточно данных, есть конфликт правил или ситуация не входит в утверждённый процесс	Исключение из договора, спорный документ, нестандартная претензия

Разница между вторым и третьим режимом особенно важна.

При наблюдении система выполняет операцию сама, а команда проверяет выборку, отслеживает отклонения и может остановить процесс. При подтверждении операция не начинается, пока сотрудник не увидит параметры и не согласится с ними.

Microsoft рекомендует заранее определить, что агент делает автономно, что требует одобрения или переопределения и когда он обязан передать задачу человеку. Там же отдельно указана обратная ошибка: если отправлять на согласование все низкорисковые действия, сотрудники становятся узким местом процесса.[3]

Как определить точку обязательного подтверждения

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

Для каждого действия задайте пять вопросов.

1. Какова стоимость ошибки

Учитывайте не только прямые деньги. Ошибка может привести к:

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

Чем выше потенциальный ущерб, тем ближе контроль должен находиться к моменту исполнения.

2. Можно ли отменить действие

Внутреннюю заметку обычно можно исправить. Отправленное сообщение нельзя «разотправить», даже если технически его удалось удалить из одного канала. Массовое изменение данных иногда восстанавливается из журнала, но сам откат может занять время и заблокировать работу.

Высокая стоимость отката — основание запросить подтверждение заранее.

3. Насколько однозначны входные данные

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

При неоднозначности ИИ не должен выбирать наиболее правдоподобный вариант только потому, что workflow требует продолжения. Правильный результат здесь — уточнение или передача человеку.

4. Можно ли проверить результат обычным кодом

Формат реквизита, наличие обязательного поля, допустимый статус, лимит длины, существование заказа и право пользователя лучше проверять детерминированно. Для этого не нужен второй запрос к модели.

ИИ полезен там, где нужно понять текст или сопоставить неструктурированные данные. Но разрешение на действие должны выдавать правила вне модели.

5. Как быстро команда заметит ошибку

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

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

Microsoft, OWASP и практическое руководство n8n связывают предварительное подтверждение прежде всего с высокорисковыми, необратимыми и неоднозначными операциями.[2][4][7]

Почему подтверждение каждого шага не делает систему безопасной

На пилоте широкое подтверждение полезно: команда видит решения модели, накапливает примеры и понимает, какие проверки нужны. Но оставлять этот режим навсегда — тоже риск.

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

Исследование Anthropic на данных Claude Code показывает похожее изменение поведения: среди новых пользователей полное автоматическое одобрение применялось примерно в 20% сессий, а у более опытных — более чем в 40%. Одновременно частота прерываний выросла примерно с 5% до 9% ходов. Авторы интерпретируют это как переход от проверки каждого шага к наблюдению и вмешательству при необходимости.[1]

Здесь нужна оговорка: исследование относится к инструменту разработки, а не к продажам, платежам или клиентской поддержке. Переносить его показатели на бизнес-процесс нельзя.

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

Каким должно быть окно подтверждения

Вопрос «Разрешить ИИ продолжить?» почти бесполезен. Сотруднику приходится либо доверять системе вслепую, либо самостоятельно восстанавливать весь контекст.

Карточка подтверждения должна показывать:

• какое действие будет выполнено;
• в какой системе и над каким объектом;
• старое и новое значение;
• исходные данные;
• основание или найденный документ;
• предупреждение о возможном последствии;
• можно ли отменить операцию;
• что произойдёт при отклонении;
• кто запросил и кто подтвердил действие.

Для сообщения клиенту нужно показать адресата и полный текст. Для изменения CRM — карточку, поле, прежнее и новое значение. Для документа — версию, основание и расхождение. Для массовой операции — число затрагиваемых объектов и несколько примеров.

Microsoft и OWASP рекомендуют показывать планируемые действия до исполнения, сохранять журнал инструментов и результатов, а также иметь системный механизм паузы или остановки. Для высокорисковых и необратимых операций они предлагают явное подтверждение человека.[2][4]

Условный пример: обработка счёта поставщика

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

Нерациональный вариант — передать весь процесс агенту: прочитать письмо, определить поставщика, найти заказ, изменить реквизиты и инициировать оплату.

Более управляемая схема выглядит так.

1. ИИ извлекает данные из письма и вложения. Поставщик, номер документа, сумма, заказ и назначение платежа возвращаются в структурированном виде.
2. Обычный workflow проверяет поля. Система ищет дубли, сверяет поставщика и заказ, проверяет наличие обязательных данных и допустимые форматы.
3. Если данные совпали, система создаёт внутренний черновик. Это обратимая операция, которую после тестов можно выполнять автоматически.
4. Расхождения уходят сотруднику. Новый банковский реквизит, отсутствие заказа, несовпадение суммы или два подходящих договора не должны разрешаться догадкой модели.
5. Финальное финансовое действие подтверждает уполномоченный человек. ИИ может собрать контекст и объяснить расхождения, но не подменяет установленный порядок согласования.

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

Если весь процесс состоит из однозначных форм, сверок и маршрутов, языковая модель может вообще не понадобиться. Сначала стоит определить, где достаточно обычного workflow, а где действительно нужен ИИ.

Архитектура контроля: модель не должна проверять сама себя

Рабочий контур можно представить так:

Входные данные → ИИ предлагает результат → детерминированная проверка → политика риска → автоматическое действие / подтверждение / эскалация → журнал.

Политика риска — это обычный программный компонент. Он получает тип действия, объект, параметры, роль пользователя и контекст процесса. Затем применяет заранее заданные правила.

Например:

• create_internal_draft — автоматически;
• update_noncritical_field — автоматически после проверки схемы;
• send_external_message — после подтверждения;
• change_bank_details — передать ответственному;
• delete_records — запретить для данного процесса.

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

OpenAI также разделяет модельное решение и человеческое подтверждение: при чувствительном вызове инструмента выполнение приостанавливается до одобрения или отклонения. Для высокорисковых операций документация рекомендует сохранять прикладную границу авторизации вне вызывающего компонента.[5][6]

Для агентов, подключённых к CRM, отдельно нужны узкие инструменты, минимальные права и проверка параметров вне модели. Это разобрано в статье о том, как ограничить права ИИ-агента в CRM.

Как ослаблять контроль после пилота

Автономность лучше расширять по одной операции, а не включать одним переключателем для всего агента.

Шаг 1. Составьте реестр действий

Записывайте не функции продукта, а реальные изменения процесса: прочитать документ, создать черновик, отправить сообщение, сменить статус, удалить запись.

Шаг 2. На старте подтверждайте больше операций записи

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

Официальные рекомендации разных платформ здесь могут выглядеть строже или мягче. OpenAI для некоторых инструментальных сценариев предлагает строгий режим подтверждения. Microsoft и OWASP формулируют границу через риск, воздействие и обратимость.[2][4][5][6]

Для пилота разумно выбрать более строгий режим, а затем ослаблять его только на проверенных операциях.

Шаг 3. Сохраняйте решение сотрудника

Нужен не только факт нажатия кнопки. Полезно фиксировать:

• одобрено без изменений;
• исправлено перед выполнением;
• отклонено;
• передано другому специалисту;
• причина изменения или отказа.

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

Шаг 4. Автоматизируйте обратимые действия по одному

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

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

Шаг 5. Не убирайте контроль с критических границ

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

Что измерять на пилоте

Одной «точности ИИ» недостаточно. Контроль является частью процесса, поэтому нужны показатели процесса и участия человека:

• доля операций в каждом режиме;
• доля одобрений без изменений;
• доля исправленных и отклонённых предложений;
• время ожидания подтверждения;
• размер очереди согласований;
• число эскалаций из-за неполных или противоречивых данных;
• ошибки, обнаруженные после автоматического действия;
• количество откатов и повторных операций;
• доля карточек, где сотруднику не хватило контекста;
• ручное время на одну проверку.

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

Для систем, отвечающих по корпоративным документам, проверку источников, отказов и передачи человеку лучше вынести в отдельный тестовый набор. Подробная методика есть в материале о том, как тестировать RAG-чат-бота перед запуском.

Когда human-in-the-loop не решает проблему

Добавить кнопку согласования недостаточно.

Подход не работает, если:

• никто не назначен владельцем решения;
• сотруднику не показывают контекст;
• подтверждение приходит человеку без нужных полномочий;
• процесс не умеет ждать и корректно продолжать выполнение;
• после отклонения агент пробует выполнить действие другим способом;
• нет журнала и невозможно восстановить ход операции;
• нет аварийной остановки;
• компания не анализирует причины исправлений;
• ручная проверка дороже и медленнее исходного процесса.

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

Вывод

Риски внедрения ИИ нельзя снизить правилом «всё проверяет человек». Такое правило либо останавливает автоматизацию, либо со временем превращается в формальность.

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

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

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

Частые вопросы

Что означает human-in-the-loop

Human-in-the-loop — это организация процесса, при которой система в заранее определённых точках запрашивает решение, проверку или дополнительные данные у человека. Это не обязательно означает ручное подтверждение каждого шага.

Нужно ли проверять каждый ответ ИИ

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

Может ли один ИИ проверять ответы другого

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

Кто должен подтверждать действие ИИ

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

Когда можно убрать подтверждение человека

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

Источники

1. Anthropic. Measuring AI agent autonomy in practice. 18 февраля 2026 года.
2. Microsoft Learn. Reduce autonomous agentic AI risk. 19 марта 2026 года.
3. Microsoft Learn. Use the agent design framework. 24 февраля 2026 года.
4. OWASP Cheat Sheet Series. AI Agent Security Cheat Sheet.
5. OpenAI API. Guardrails and human review.
6. OpenAI API. Programmatic Tool Calling.
7. n8n, Elvis Saravia. Production AI Playbook: Human Oversight. 9 марта 2026 года.