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

Так начинают почти всегда. А неудачные внедрения ИИ в площадку на базе 1С-Битрикс или в CRM на базе Битрикс24 проваливаются раньше кода: непонятно, что считать успехом; не решено, что делать, когда модель врёт; в ответ уходят устаревшие тексты или поля, которые нельзя отдавать во внешний API. А бот пишет живому человеку - и это уже не эксперимент.

Десять вопросов ниже можно пройти за один созвон - до начала разработки и до счёта за API. Программистом быть не нужно: на большинство ответит тот, кто знает процесс. Где нужна цифра, её можно попросить у того, кто сопровождает систему.

1. Одна цифра, а не "хотим ИИ"

На созвоне звучит "хотим ИИ в поддержку". У каждого своя картинка: меньше обращений, бот на главной, "как у других". Пока цель такая, после запуска нечего сравнить. Появился виджет - или сдвинулась цифра?

Нужна одна метрика, которую видно до и после. Обычно держат время до первого ответа в поддержке: не "станет умнее", а насколько быстрее. Если цель - сократить это время на 30%, это уже можно проверить за понятный срок. Какая одна цифра должна сдвинуться, и когда мы это смотрим?

2. Модель ошибётся. Что тогда

Бот уверенно называет цену, которой нет в каталоге, или обещает срок, который склад не подтвердит. Если такое уходит человеку без проверки, пилот закончился - это уже инцидент.

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

3. Сначала замер без модели

Цифру из первого вопроса не с чем сравнить, если нет замера без ИИ. Две-четыре недели текущей работы: сколько сейчас длится первый ответ, сколько обращений, где люди уже ждут. Замер скучный, поэтому его часто пропускают.

Тогда после запуска сравнивают с ощущением "вроде стало лучше". Ощущение не защищает бюджет и не ловит регресс. Цифру с потолка в день релиза взять легко. Проверить процесс за 2-4 недели до запуска - нет.

4. Источники живые, и у них есть владелец

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

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

5. Какие поля нельзя отдавать наружу

В сделке и в заказе живут телефоны, адреса, составы корзин, комментарии менеджеров. Часть этого нельзя отправлять во внешний API - ни "для контекста", ни "на всякий случай".

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

6. Где обрабатывается запрос

Где крутится модель, часто важнее того, как её называют в маркетинге. Облако в РФ, своя серверная инфраструктура, гибрид - варианты разные по цене, задержке и по тому, что можно отдать наружу. Для персональных данных это ещё и 152-ФЗ: расположение согласуют с юристом и службой безопасности, а не ставят, потому что ключ уже был.

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

7. Бэкенд, не ключ в шаблоне

Бэкенд принимает запросы к модели сам: очереди, лимиты, журнал запросов. Ключи не в git и не на фронте. Ключ в шаблоне сайта - это не "быстрее запустить", это ключ в открытом доступе.

Запросы к модели идут через прокси на вашем бэкенде. Если площадка сама не держит нагрузку, бот только добавит расход. Про запас по скорости и обмену с 1С есть отдельная статья - "7 признаков, что ваш сайт не выдержит рост".

8. Сначала бьём по боту сами

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

Нужна отдельная площадка, где до показа людям по боту специально бьют плохими вопросами и читают, что он выдумывает. Не формальная проверка "сайт открывается". Где это делают сейчас и кто читает ответы?

9. Потолок затрат в пик

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

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

10. Кто правит ответы первые месяцы

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

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

Как это складывается

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

Виджет не вызывает модель из браузера: запросы идут через бэкэнд, ключ API остаётся там. Промпт ведут в версиях, в логах персональные данные не хранят открытым текстом. Если модель молчит или врёт, отвечает человек - кнопка "позвать человека" видна с первого экрана.

В Бэкэнд бутике <redPerformance /> этот список мы проходим на диагностике, до интеграции. Сопровождение как раз про первые месяцы, когда ответы ещё правят руками. Как устроена работа от письма до приёмки - на странице "Как мы работаем".

В Telegram-канале @redPerformance - разборы, заметки, советы и кейсы.