Создание ИИ-ассистента укладывается в пять шагов: выбрать одну задачу, собрать данные, написать инструкцию, подключить к рабочим системам и проверить, что он сделал то, о чём отчитался. Первые три делаются за вечер на готовом конструкторе, без единой строчки кода, - поэтому интернет полон инструкций из четырёх пунктов. Четвёртый и пятый занимают всё остальное время и стоят всех остальных денег.
Дальше разбор по шагам. Чем собирают на практике, во что обходится каждый шаг помимо времени и как понять, что вашу задачу за вечер уже не собрать.
Что собирается за вечер, а что занимает месяц
Описываете задачу словами - за минуты получаете 80-90% решения. Остаток это тесты, крайние случаи и уверенность, что оно не сломается тихо, когда изменится соседняя система. Граница держится независимо от того, каким инструментом вы пользуетесь.
Порог входа снизился, а потребность понимать, что делаешь, осталась прежней. Базовые навыки отладки экономят часы позже: без них любая поломка выглядит как «оно перестало работать», и дальше этого диагноз не идёт.
Это не повод не браться. Собрать ассистента самому - нормальный путь, и для части задач он единственный разумный. Просто инструкция из четырёх пунктов заканчивается ровно там, где начинается разница между демонстрацией и рабочим процессом. Что такое ИИ-ассистент для бизнеса и какие они бывают - отдельный разговор, здесь речь только о сборке.
Пять шагов сборки
Шаг 1. Одна задача, а не «ассистент для всего»
Виртуальный ассистент, собранный под одну задачу, работает. Собранный под всё сразу не работает ни подо что: у него нет ни понятной базы знаний, ни критерия, что ответ правильный.
Задачу стоит брать ту, которая уже болит и уже сколхожена вручную. Если в компании кто-то ведёт для этого табличку, пишет шаблоны ответов или каждый день отвечает на один и тот же вопрос - это подходящий кандидат. Если процесс существует только в планах, автоматизировать пока нечего.
Прежде чем что-то менять, неделю посмотрите, как процесс идёт сейчас: кто что делает, где ждёт, где переспрашивает. Половина будущих требований к ассистенту рождается именно там, а не при выборе инструмента.
Шаг 2. Данные: что ассистент читает и кто следит за актуальностью
Ассистент отвечает по тому, что вы ему дали. Значит, придётся решить три вещи: какие документы он читает, в каком они виде и кто следит за их актуальностью.
Ценность резко вырастает, когда работа компании превращена в текст, который модель может прочитать. Сложность хранилища тут решает мало: в открытом сравнении систем памяти для ассистентов выиграла обычная markdown-вики, а специализированная инфраструктура осталась позади. Приём, на котором всё держится, называется генерация с дополненной выборкой (RAG): перед ответом система ищет нужные куски в ваших файлах и говорит по ним, а не по общим знаниям модели.
Дальше начинается неприятное. База знаний зарастает мусором, если её не чистить: устаревшие инструкции, три версии одного регламента, документы уволившихся. Ассистент, отвечающий по прошлогоднему приказу, вреднее отсутствия ассистента, потому что ему верят. Это не разовая работа, а роль - кто-то должен собрать корпоративную базу знаний и потом за неё отвечать.
Шаг 3. Инструкция: что писать и чего от неё не ждать
Системная инструкция задаёт роль, границы, тон и право сказать «не знаю». Порядок тут важен. Сначала вы решаете, должна ли большая языковая модель вообще отвечать на такой запрос, и только потом - что именно она скажет. Разбор запроса перед ответом снимает половину будущих неприятностей.
У инструкции есть предел, который почти все недооценивают. Она ограничивает мягко. Фраза «не трогай раздел с ценами» конкурирует с обучением модели быть полезной и старательной, и иногда проигрывает. Жёсткие границы живут в коде: если действие опасное, оно должно быть технически недоступно. Словами в промпте это не закрывается.
Шаг 4. Подключение к рабочим системам
Самый недооценённый шаг. Здесь ассистент превращается в интеллектуального агента - программу, которой разрешено выполнять действия в чужих системах. До этого шага он умел разговаривать, теперь начинает менять данные.
Подключить доступ не значит подключить процесс. «Готовая интеграция» на практике часто означает «вот вам адрес для запросов, дальше сами»: поля не совпадают, права выданы шире нужного, а порядок действий приходится описывать заново под конкретную компанию.
Здесь же прячется самая тихая поломка. Платформа отправляет запрос, получает в ответ код успеха и отмечает задачу выполненной, хотя целевая система действие отклонила. Формально всё зелёное, фактически ничего не произошло. Интеграции требуют узкой квалификации, и самостоятельная сборка чаще всего заканчивается именно на этом шаге, а не на выборе модели.
Шаг 5. Проверка: как понять, что ассистент сделал то, что сказал
Правильный вопрос звучит не «есть ли интеграция», а «можете ли вы доказать, что после действия система находится в том состоянии, о котором ассистент отчитался». Проверка состояния - отдельная работа, и её надо закладывать сразу.
Первый месяц каждое действие подтверждает человек в контуре, и только потом подтверждение снимается с тех шагов, где ошибок не осталось. Неудачная операция после трёх попыток уходит в человеческую очередь и не роняет весь процесс. Итоговые суммы и подсчёты остаются за кодом: модель их выдумывает.
Чем собирают: три способа и предел каждого
Способов ровно три. Разница между ними не в качестве, а в том, до каких задач каждый доходит.
| Способ | Что реально собирается | Что придётся доделать руками | Где предел |
|---|---|---|---|
| Конструктор внутри готового сервиса | Чат-бот на сайте или в Telegram, отвечающий по загруженным документам; кастомный GPT для внутренних вопросов | Наполнить базу, написать тексты отказов, настроить передачу диалога человеку | Действия за пределами самого сервиса: чужая CRM, учётная система, почта |
| No-code-связка (n8n и похожие) | Цепочка «событие - обращение к модели - действие в другой системе»: amoCRM, Битрикс24, 1С, почта | Обработку ошибок, повторные попытки, проверку результата, права доступа | Длинные ветвящиеся сценарии и всё, где нужно доказать, что действие выполнено |
| Своя разработка | Что угодно, включая жёсткие ограничения в коде и собственную проверку состояния систем | Всё, включая эксплуатацию и обновления | Квалификация и время того, кто это сопровождает |
Ни один способ не лучше остальных сам по себе. Конструктор закрывает повторяющиеся вопросы клиентов и внутренний справочник. No-code вытягивает связки между системами, пока сценарий помещается на один экран. Своя разработка нужна там, где искусственный интеллект трогает деньги, обязательства перед клиентами или данные, за которые вы отвечаете по закону.
Где самостоятельная сборка останавливается
Шесть мест, в которых это происходит чаще всего. Все они известны заранее, и почти все дешевеют, если посмотреть на них до старта, а не после.
| Место | Как это выглядит | Что делать заранее |
|---|---|---|
| Проверка дороже работы | Каждый ответ приходится сверять с источником, и это дольше, чем сделать вручную | Брать задачи, где правильность ответа видна за секунды, а не требует чтения всего документа |
| Теряет контекст и выдумывает цифры | Между сессиями забывает договорённости, в итогах появляются суммы, которых нет в документах | Считать итоги кодом, а модели оставить текст; хранить состояние вне диалога |
| Длинная цепочка | На третьем-четвёртом шаге перестаёт держать правила и уходит в сторону | Резать сценарий на короткие шаги с проверкой между ними |
| Счёт за обращения к модели | Месячный бюджет выгорает за неделю на трафике, который никто не считал | Считать по числу обращений, а не по числу сотрудников; ставить лимит и оповещение |
| Чинить нечем | Собрано по подсказкам модели, при поломке непонятно, что означает код | Не собирать самому то, что придётся сопровождать другому человеку |
| Чужая платформа | Аккаунт заблокировали - полгода работы исчезли вместе с ним | Держать данные, документы и инструкции у себя, а платформу считать сменной деталью |
Что стоит эксплуатация, о которой не пишут в инструкциях
Стоимость постройки упала, стоимость плохой эксплуатации осталась прежней. Собрать первую версию сегодня можно за вечер; счёт приходит потом и по другим статьям.
Чаще всего никто заранее не думает, как система будет жить после запуска. Не сказано, что считается готовым результатом, кто владеет им внутри компании и что делать, когда оно упадёт в два часа ночи. Пока ассистент отвечает на вопросы сотрудников, это терпимо. Когда он трогает заявки клиентов, молчание по этим вопросам обходится дороже разработки.
Считать это лучше до старта. Разбор статей расхода и того, сколько стоит ИИ-ассистент в разработке и в содержании, лежит на отдельной странице - здесь важно только то, что второй счёт существует.
Когда собрать самому - правильное решение, а когда нет
Самому стоит браться, когда задача одна, данные ваши, цена ошибки низкая, а пользоваться результатом будете вы же. Внутренний справочник по документам, помощник для черновиков, разбор личной почты - здесь подрядчик избыточен, а собственный опыт сборки окупается пониманием, что вообще происходит внутри.
Не стоит браться, когда ассистент трогает деньги, клиентов или чужие системы; когда сопровождать его будет не тот, кто собирал; когда цена одной незамеченной ошибки выше стоимости работы. Есть и четвёртый случай, чисто человеческий. Часть владельцев осознанно отдаёт профессионалам всё, чего не хочет учить, чтобы заниматься тем, что у них получается лучше. Нормальная позиция.
Если вы в одной из этих ситуаций, то разработка ассистентов на заказ решает не задачу «написать промпт», а задачу «сделать так, чтобы через полгода оно всё ещё работало и было кому чинить».
Частые вопросы
Сколько времени займёт собрать ассистента самому?
До первой демонстрации - вечер. На конструкторе внутри готового сервиса это пара часов: загрузить документы, написать инструкцию, проверить на десяти вопросах. До состояния, в котором ассистента можно показать клиенту или пустить в рабочий процесс, - недели. Разница уходит на крайние случаи, подключение к системам и проверку того, что действия выполняются. Сроки зависят в основном от числа систем, которые он трогает, а не от сложности самих ответов.
Нужно ли уметь программировать?
До четвёртого шага - нет. Конструкторы и no-code-платформы закрывают выбор задачи, загрузку данных и инструкцию без единой строчки кода. На подключении к рабочим системам всё меняется: там нужны права доступа, сопоставление полей, обработка ошибок и повторные попытки. И ещё одно. Чтобы поставить задачу модели правильно, нужен опыт работы с системами; умения писать промпты тут не хватает. Без такого опыта ассистент получается вежливым и бесполезным.
Что будет, если ассистент ошибётся?
Зависит от того, что ему разрешено. При правильном устройстве опасные действия недоступны ему технически: списать деньги, удалить запись или отправить письмо клиенту он не может, потому что такой возможности у него нет в коде. Тогда худший случай - отклонённый черновик, а не разбор последствий. Если же ассистенту выданы полные права и никто не проверяет результат, ошибка станет заметна тогда, когда её увидит клиент.
Можно ли обойтись готовым конструктором и не платить за разработку?
Да, и для многих задач это правильный выбор: внутренний справочник, ответы на повторяющиеся вопросы, черновики писем. Конструктор дешевле и быстрее. Помнить стоит об одном - вы зависите от чужой платформы. Аккаунты блокируют, тарифы меняются, сервисы закрываются, и работа месяцев исчезает вместе с ними. Поэтому документы, инструкции и логику держите у себя в виде, который переносится куда угодно.
Что делать с документами компании: их можно загружать в ассистента?
Зависит от того, что в документах и куда они уезжают. Внутренние регламенты и инструкции обычно загружают без опасений. Персональные данные клиентов, договоры и медицинские сведения требуют отдельного решения по контуру: где размещается модель, кто имеет доступ к переписке, что хранится в логах. Разбирать это надо до загрузки первого файла, а не после - подробности собраны на странице про безопасность LLM в компании.
Собрал сам, работает через раз - что чинить в первую очередь?
Порядок диагностики почти всегда один. Сначала данные: проверьте, есть ли вообще правильный ответ в документах, которые видит ассистент, и не лежат ли рядом три версии одного регламента. Потом инструкция: попросите модель объяснить, на основании чего она ответила. Потом интеграция: откройте целевую систему и посмотрите своими глазами, изменилась ли там запись после действия ассистента. В большинстве случаев причина находится на первом пункте, хотя выглядит как проблема модели.
Что дальше
Если вы собрали ассистента сами и остановились - приходите с тем, что уже собрано. За полчаса видно, где именно предел: в данных, в инструкции или в интеграции, и стоит ли вообще переделывать. Бесплатный разбор, 30 минут, без обязательств.
Написать можно в Telegram или на почту hi@za-ai.ru.