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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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