10 ошибок внедрения ИИ: что проверить до затрат на разработку

Агент делает неверную карточку в CRM. Команда меняет модель, переписывает промпт и добавляет ещё документов. Карточка становится другой, но никто не может объяснить, какая правка помогла. Знакомая проблема: лечат весь проект сразу.

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

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

Десять ошибок внедрения ИИ: что попросить показать

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

1. Автоматизировать задачу, у которой нет полезного выхода

«Сделать ИИ для отдела продаж» не объясняет, что принимать. Лучше: «Из входящего письма подготовить карточку лида, показать менеджеру и сохранить после его подтверждения». Видны объект, выход, пользователь и граница.

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

Что исправить: записать цель в четырёх полях: вход, готовый результат, получатель, дальнейшее действие. Если задача решается формой и правилом, сравните этот вариант с агентом.

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

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

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

Что исправить: сохранить фактическую карту с состояниями «новое», «нужно уточнение», «готов черновик», «принято», «передано человеку». Для каждого перехода назвать условие и ответственного.

3. Одновременно автоматизировать весь отдел

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

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

Расширяйте по одному измерению после приёмки. Для организации проверки есть паспорт и план пилота ИИ-агента.

4. Загрузить документы без владельца и действующей версии

В базе два прайса. Агент нашёл старый и аккуратно процитировал его. Замена модели не сделает старую цену новой.

Что исправить: составить реестр: источник, владелец, версия, область применения, дата пересмотра и правило конфликта. Устаревшие документы исключать из поиска, а не просто добавлять свежие рядом.

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

5. Исправлять любую ошибку одним промптом

Инструкция «не создавай дубликаты» не заменяет проверку записи в CRM. «Используй свежие данные» не определяет, какой из файлов действующий. Промпт полезен там, где нужно описать поведение модели; у него нет доступа к фактам, которые система не передала.

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

Что исправить: вести карточку сбоя: ожидаемое → фактическое → причина → один изменённый компонент → повторный тест. Принцип начинать с простой проверяемой архитектуры описан в руководстве Anthropic по агентам.

6. Проверять только то, что хорошо получилось на демо

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

Что исправить: сохранить таблицу «вход → ожидаемое поведение → факт → причина расхождения». Дубликат заявки не должен создавать вторую запись. Отсутствие документа не должно превращаться в уверенный ответ.

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

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

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

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

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

8. Дать агенту права шире задачи

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

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

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

9. Не проверить тайм-аут, повтор и остановку

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

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

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

10. Оставить поддержку «кому-нибудь из разработки»

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

Что исправить: назначить владельца процесса и владельца эксплуатации. Зафиксировать, кто видит оповещение, кто останавливает систему, где хранится версия, как проверяют обновление и из какого бюджета оплачивают работу. Один человек может совмещать роли, обязанности от этого не исчезают.

Попросите показать порядок действий при сегодняшнем сбое. Состав такой работы разобран в статье о поддержке ИИ-агента. Подход к ответственности, измерению и управлению риском можно сверить с NIST AI RMF Core.

Как восстановить проблемный пилот: короткий пример

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

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

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

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

Помогу определить, что проверять в вашем проекте первым

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

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

Обсудить проект на бесплатной диагностике