Риски внедрения ИИ: что идёт не так

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

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

Ниже шесть рисков, которые срабатывают на практике. Не «этические» и не «регуляторные», а те, из-за которых проекты останавливаются, а деньги оказываются потрачены зря.

Риск первый: проект не дойдёт до работы

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

Деньги при этом потрачены полностью. Не наполовину, не «на опыт» — полностью, потому что незапущенная система не приносит ничего.

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

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

Что снижает риск до старта:

• одна задача вместо пяти. Доведённая до цифр задача полезнее пяти начатых;
• названный ответственный внутри компании, у которого это в приоритетах, а не «в дополнение к основной работе»;
• договорённость о первых неделях: кто читает диалоги, кто дописывает правила, как часто.

Риск второй: система уверенно ошибается перед клиентом

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

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

Управляется это тремя ограничениями, и все три задаются на этапе проектирования:

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

Один честный ответ на всё за пределами базы. «Уточню у коллеги и вернусь» — и передача диалога человеку. Это лучше любой попытки угадать.

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

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

Риск третий: счёт растёт вместе с использованием

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

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

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

Три способа, которыми этот риск закрывается:

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

Главный вопрос подрядчику здесь звучит так: посчитайте стоимость месяца на моём реальном объёме обращений, а не на демонстрации. Если ответа нет, это само по себе сигнал.

Риск четвёртый: данные уезжают наружу

Всё, что попадает в запрос к модели, покидает ваш контур. Это не страшилка, а описание механики: запрос уходит в инфраструктуру того, чью модель вы используете.

Вопросы, которые нужно закрыть до начала работ, а не после первого инцидента:

Какие данные вообще попадают в запрос. Часто выясняется, что половину можно не отправлять. Чтобы ответить на вопрос «где мой заказ», модели не нужны ни фамилия клиента, ни его телефон — достаточно статуса и срока.

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

Где физически работает модель. Российские модели размещены в России, зарубежные — нет. Для части компаний это определяющий фактор, для части — нет, но знать об этом надо до, а не после.

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

Хорошая новость: значительная часть задач решается так, что персональные данные в модель не уходят вообще. Их обрабатывает ваш код, а модели достаётся обезличенная формулировка.

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

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

Он состоит из двух разных зависимостей, и их полезно различать.

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

Зависимость от платформы. Собранный в конструкторе сценарий редактируется только в этом конструкторе. Переезд означает сборку заново вручную. Где именно проходит эта граница и когда конструктор перестаёт окупаться, разбирал в статье конструктор чат-ботов или разработка.

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

Риск шестой: автоматизировали не то

Самый обидный, потому что технически всё сделано правильно.

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

Признаки того, что процесс к автоматизации не готов:

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

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

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

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

Все шесть рисков в одной таблице

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

Отдельно про агентов: риск действия, а не ответа

Запрос «риски внедрения ии агентов» стоит рядом с общим не случайно. У агентов появляется класс риска, которого нет у обычного бота или у чата с моделью, и он требует отдельных мер.

Разница простая. Чат-бот отвечает. Агент действует: создаёт запись в CRM, отправляет письмо, меняет статус заказа, ставит задачу сотруднику. Чем агент отличается от бота по устройству, разбирал в статье чем ИИ-агент отличается от чат-бота; здесь важно одно следствие.

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

Отсюда три конкретных риска и три меры против них.

Риск: действие по неверно понятому запросу. Клиент написал «отмените последний», имея в виду один товар из заказа, агент отменил заказ целиком.

Мера — белый список действий. Агент умеет ровно то, что ему разрешено, и не умеет всё остальное. Не «может пользоваться CRM», а «может создать заявку и изменить срок; удалять и отменять не может». Список пишется до разработки и является частью задания.

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

Мера — подтверждение человеком для необратимого. Агент готовит действие и показывает его, а нажимает человек. Это не отменяет автоматизацию: девяносто процентов работы агент всё равно делает сам, а на подтверждение уходит секунда.

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

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

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

Как снизить риски до начала работ

Пять шагов до подписания

1. 1
   Выбрать одну задачуТу, что повторяется чаще всего и измеряется числами. Не «внедрим ИИ», а конкретный процесс
2. 2
   Посчитать текущие цифрыСколько обращений, сколько времени уходит, сколько теряется. Без этого эффект нечем измерить
3. 3
   Решить вопрос данныхЧто уходит в модель, что обезличивается, что не уходит никогда
4. 4
   Договориться о потолке расходовЖёсткий лимит на месяц и поведение системы при его достижении
5. 5
   Зафиксировать, что остаётся у васКод, доступы, документация, данные — письменно, до начала работ

Как отличить проект, который дойдёт, от проекта, который умрёт

Умрётденьги на ветер

• «Внедряем ИИ во все процессы»
• Ответственный — «все понемногу»
• Исходных цифр никто не собирал
• Успех описан словами «станет удобнее»
• Про данные и потолок расходов не говорили

Дойдётуправляемый проект

• Одна задача с понятной границей
• Есть человек, у которого это в приоритетах
• Известно, сколько обращений и сколько теряется
• Успех описан числом, которое можно проверить
• Данные, расходы и права оговорены письменно

Что зафиксировать письменно до начала работ

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

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

На чьих аккаунтах живёт система. Сервер, домен, платёжный шлюз, аккаунт у поставщика модели. Каждый пункт, оформленный на подрядчика, — это точка, в которой вы от него зависите.

Потолок расходов и что происходит при его достижении. Не «будем следить», а конкретно: лимит в рублях на месяц и поведение системы при исчерпании — остановиться, переключить на человека, уведомить кого-то.

Какие данные уходят в модель. Список полей, а не общее «данные обращения». И отдельно — что делается для обезличивания.

Что считаем результатом. Число, а не ощущение. «Доля обращений, закрытых без человека, не ниже сорока процентов на третий месяц» — это результат. «Станет удобнее» — нет.

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

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

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

Как понять через полгода, что проект окупился

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

Лечится это одним действием до старта: снять исходные цифры. Потом их взять будет неоткуда.

Что минимально нужно померить заранее:

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

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

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

Чего в этом списке нет

Стоит сказать и об обратном — о рисках, которые обсуждают часто, а срабатывают редко.

«ИИ заменит сотрудников и они уволятся». На практике происходит другое: система забирает механическую часть, и люди довольно быстро перестают по ней скучать. Сопротивление возникает не от страха увольнения, а когда инструмент неудобный или его внедрили без объяснений.

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

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

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

Три ответа, по которым видно опытного подрядчика

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

Вопрос: «Сколько будет стоить месяц работы при нашем объёме обращений?»

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

Вопрос: «Что система ответит, если не знает ответа?»

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

Вопрос: «Что останется у меня, если мы прекратим работать?»

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

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

Что делаю я

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

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

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