Риски и ошибки внедрения ИИ в бизнесе: что может пойти не так

Риск внедрения ИИ шире, чем ошибка модели

Допустим, ИИ неправильно определил тип обращения клиента.

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

Другой сценарий: система сама меняет статус сделки в CRM, назначает ответственного и отправляет клиенту сообщение. Та же ошибка уже запустила цепочку действий.

Поэтому при внедрении нужно разделять четыре уровня:

• ошибка самой модели;
• ошибка AI-системы;
• ошибка бизнес-процесса;
• последствия для компании.

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

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

Неправильно выбрали задачу или пытаются автоматизировать хаос

Первая ошибка часто возникает ещё до разработки.

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

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

Ещё хуже, если сам процесс не определён.

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

Перед разработкой нужно определить:

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

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

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

Плохие данные делают ненадёжной даже хорошую модель

AI-система работает с тем, что ей дали.

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

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

Поэтому для корпоративного ИИ нужно определить:

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

При этом не всю информацию стоит складывать в одну базу знаний.

Инструкцию можно искать через RAG. А актуальную сумму задолженности клиента правильнее получать непосредственно из CRM или учётной системы.

У каждого типа информации должен быть свой источник истины.

И ещё одна распространённая ошибка — передавать модели максимум контекста «на всякий случай». Больше данных не всегда означает лучший результат. Лишний контекст повышает стоимость, добавляет шум и может ухудшать ответ.

Проверять нужно не только модель. Нужно проверять то, что она читает.

Галлюцинации и ошибки: результат ИИ нельзя принимать на веру

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

Хороший промт снижает риск, но не устраняет его.

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

Надёжность создают проверки вокруг неё:

источник → генерация → проверка → результат или передача человеку.

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

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

Так надёжнее, чем бесконечно улучшать «идеальный промт».

Интеграции могут сломать то, что хорошо работало в демо

Чат с моделью и AI-система, подключённая к CRM, ERP, 1С и API, — разные по сложности решения.

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

Теперь в системе две одинаковые операции.

Поэтому production-решению нужны:

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

Инженеры используют для этого retry, idempotency, rollback и другие механизмы. Физический смысл простой: один сбой не должен запускать пять новых.

Доступы тоже должны быть ограничены

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

Права пользователя должны сохраняться во всём AI-контуре.

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

ИИ получает только те данные и инструменты, которые нужны конкретному сценарию.

Внешним данным нельзя автоматически доверять

AI-система может читать сайты, письма и загруженные документы. Внутри них могут находиться инструкции, рассчитанные на изменение поведения модели — один из вариантов prompt injection.

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

Сотрудники могут сломать внедрение без единой технической ошибки

Даже хорошо работающая система бесполезна, если она не встроена в процесс.

Типичный вариант: старую схему работы оставили, а AI-систему добавили рядом.

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

Автоматизация есть. Свободного времени почему-то не прибавилось.

Если часть операции передана AI-системе, старый процесс нужно пересобрать.

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

Исправления сотрудников полезно собирать. Если один и тот же тип ошибки повторяется постоянно, это уже данные для улучшения:

ошибка → исправление → анализ → изменение данных, правил или логики.

Без такого контура система способна месяцами повторять одну и ту же ошибку с завидным постоянством.

Пилот работает. Production может не работать

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

В реальной эксплуатации условия меняются.

На масштабе появляются:

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

Сто тестовых запросов и десять тысяч ежедневных — это уже не одна и та же система.

После пилота появляется полная стоимость владения

Стоимость AI-решения не заканчивается разработкой.

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

Дешёвый прототип вполне может превратиться в дорогую production-систему, если эту часть не посчитать заранее.

Качество нужно контролировать после запуска

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

Поэтому после запуска полезно отслеживать хотя бы:

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

Если эти показатели меняются, нужно разбираться в причине.

AI-систему нельзя один раз собрать и считать законченной.

Как управлять рисками внедрения ИИ

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

В результате получается простой контур:

задача → данные → цена ошибки → ограничения → проверка → права → интеграция → мониторинг.

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