Риск 1. Плохое качество исходных данных
Система обучается и работает на тех данных, которые ей предоставили. Если записи звонков ведутся с перебоями, документы приходят в разных форматах, а в CRM половина карточек не заполнена - результат анализа будет отражать этот же беспорядок, только автоматически и в масштабе.
Как снизить: проверка качества и полноты данных - обязательная часть аудита до начала внедрения, а не то, что выясняется по ходу проекта.
Риск 2. Расплывчатые критерии оценки
Для контроля звонков нужен хотя бы черновой скрипт. Для проверки договоров - чек-лист обязательных условий. Без формализованных критериев система оценивает так же нечётко, как оценивал бы человек «на глаз» - просто быстрее и в большем масштабе.
Как снизить: формализация критериев - часть подготовки к пилоту, а не то, что можно пропустить ради скорости запуска.
Риск 3. Внедрение сразу нескольких направлений
Попытка закрыть несколько процессов одновременно - контроль звонков, документооборот, аналитику - распыляет ресурсы компании и подрядчика, увеличивает срок и стоимость, и откладывает момент, когда появится первый подтверждённый результат.
Как снизить: пилот на одном процессе, проверка эффекта, только потом расширение - а не параллельный запуск нескольких контуров сразу.
Риск 4. Никто не назначен отвечать за результат
Систему можно внедрить технически безупречно, но если результаты анализа некому смотреть и никто не отвечает за реакцию на найденные проблемы - эффекта не будет независимо от качества технологии. Это управленческий риск, а не технический.
Как снизить: определить ответственного за работу с результатами системы ещё до запуска - кто смотрит отчёты, кто принимает решения по найденным проблемам.
Риск 5. Подрядчик без формата пилота
Если подрядчик сразу предлагает полный проект без возможности проверить эффект на ограниченном участке - риск ошибки полностью ложится на компанию: если гипотеза окажется неверной, это выяснится поздно и дорого.
Как снизить: требовать формат пилота на старте - подробнее в статье про выбор подрядчика для внедрения ИИ.
Риск 6. Излишние ожидания от технологии
Ожидание, что система «сама разберётся» с любой ситуацией, приводит к разочарованию там, где задача на самом деле требует суждения человека - например, окончательного решения по спорному клиентскому случаю. ИИ хорошо работает с повторяемыми, измеримыми процессами и хуже - с уникальными ситуациями, которые не описать заранее заданными критериями.
Как снизить: заранее разграничить, что система решает автоматически, а что передаётся человеку - эти границы стоит определить на этапе проектирования, а не выяснять по факту ошибок.
Риск 7. Вопросы доступа и безопасности данных
Подключение системы к CRM, базе данных или документообороту компании - это доступ к чувствительной информации. Если заранее не определить, какие данные доступны, есть ли среди них персональные данные и как разграничены права доступа, - риск не в самой технологии, а в том, что доступ окажется шире необходимого.
Как снизить: разграничение доступа и определение того, какие данные действительно нужны системе, - обязательная часть проектирования, а не то, что решается постфактум.
Как эти риски связаны с форматом внедрения
Большинство рисков выше снимаются одной и той же последовательностью действий: аудит данных и критериев → пилот на одном процессе → проверка результата → только потом масштабирование. Это не формальность, а способ увидеть проблему на маленьком масштабе, прежде чем она повторится в масштабе всей компании.
Частые вопросы
Можно ли полностью исключить риски при внедрении ИИ?
Нет, но большинство перечисленных рисков управляемые - они снижаются структурой процесса внедрения (аудит, пилот, чёткие критерии), а не устраняются полностью технологией.
Какой из рисков встречается чаще всего?
По практике - попытка внедрить несколько направлений сразу и расплывчатые критерии оценки: оба риска связаны не с технологией, а с тем, как организован сам процесс внедрения.
Кто должен нести ответственность за эти риски - компания или подрядчик?
Часть рисков (качество данных, назначение ответственного за результат) - зона ответственности компании. Часть (формат пилота, прозрачность метрик) - зона ответственности подрядчика. Разделение стоит проговорить до начала проекта.
Хотите пройтись по этим рискам применительно к конкретному процессу в вашей компании? Можно обсудить это на этапе аудита, до принятия решения о внедрении.