ИИ-агент состоит из пяти блоков: языковая модель, база знаний с поиском по ней, память диалога, инструменты — то есть доступ к вашим системам, — и правила со стоп-темами. Модель в этом списке самая заметная, самая обсуждаемая и при этом самая дешёвая и самая заменяемая часть. В проекте на 300 000 ₽ на неё приходится около 10 % бюджета, а остальные 90 % — на то, чтобы у модели были верные факты, ограниченные права и предсказуемое поведение.
Практическая польза от этого разбора появляется в момент чтения сметы. Когда подрядчик пишет строку «разработка ИИ-агента — 400 000 ₽», обсуждать нечего: вы не знаете, что внутри, и не можете спросить, чего там не хватает. Когда та же сумма разложена по пяти блокам, разговор становится инженерным: почему на коннекторы заложено две недели, кто ведёт базу знаний после сдачи, где список стоп-тем, что происходит при отказе 1С.
Дальше — по одному блоку за раз: что делает, что произойдёт при его отказе, сколько он стоит и что спросить о нём у подрядчика. В конце — разбор сметы на 300 000 ₽ по долям, чек-лист из девяти вопросов и честный список случаев, когда все пять блоков не нужны и хватит правила в три строки.
Пять блоков и что ломается при отказе каждого
Считать будем на одном примере: оптовая компания на 60 человек, продажа комплектующих, около 2 600 обращений в месяц от клиентов — статус заказа, наличие, счёт, замена позиции. Учёт в 1С:УТ, сделки в Битрикс24, телефония Mango Office. Агент принимает обращения в MAX и на почте, отвечает по прайсу и регламентам, сам смотрит статус отгрузки и создаёт заявку менеджеру. Ниже — что именно ломается, если каждый из блоков откажет; обратите внимание, что снаружи все пять отказов выглядят одинаково.
Схема архитектуры. Слева вход «Обращение клиента (MAX, почта, телефон)». В центре крупный блок «Модель» с подписью «формулирует и выбирает шаг». Вокруг него четыре блока со стрелками в обе стороны: сверху «База знаний и поиск» (подпись связи «фрагменты документов»), слева «Память диалога» (подпись «что уже сказано»), справа «Инструменты» с тремя ветками к прямоугольникам «Битрикс24», «1С:УТ», «Mango Office» (подписи «чтение» и «запись»), снизу «Правила и стоп-темы» с жирной стрелкой-заслонкой перед выходом. Справа выход «Ответ клиенту» и отдельная стрелка вниз в блок «Журнал действий».
| Блок | Что делает | Что будет при отказе | Заметно ли снаружи |
|---|---|---|---|
| Модель | Понимает вопрос, формулирует ответ, выбирает следующий шаг | Агент молчит или отвечает шаблоном; при заранее заложенной запасной модели переключение занимает минуты | Да, сразу |
| База знаний и поиск | Находит в ваших документах фрагменты, на которых строится ответ | Агент отвечает общими словами и начинает достраивать факты сам | Нет — самый опасный отказ |
| Память диалога | Держит контекст переписки: что клиент уже сказал и что агент уже пообещал | Клиент повторяет вводные на каждом сообщении, диалог рассыпается на третьем шаге | Да, клиент раздражается |
| Инструменты | Читает и меняет данные в CRM, 1С, расписании, телефонии | Агент рассказывает, но не делает: заявка не создана, а клиент уверен, что создана | Нет — выясняется через сутки |
| Правила и стоп-темы | Выключают генерацию там, где ошибка стоит денег, и зовут человека | Агент обсуждает возврат денег, называет сроки и обещает скидки от вашего имени | Нет — выясняется по претензии |
Порядок диагностики отсюда следует обратный привычному. Когда система ответила не то, первым делом проверяют не модель, а два поля в журнале: какие фрагменты нашёл поиск и какие инструменты сработали. В нашей практике примерно четыре разбора из пяти заканчиваются на первом же поле — нужного фрагмента среди найденного не было, потому что документ не загружен, устарел или нарезан так, что заголовок оторвался от текста. Замена модели в этой ситуации не меняет ничего, но обходится в две недели работы и в новый счёт. Этот сценарий стоит проговорить с подрядчиком заранее и записать в регламент сопровождения: сначала журнал, потом гипотезы.
Правый столбец объясняет, почему смету надо читать по блокам. Три отказа из пяти невидимы в момент, когда происходят: система продолжает бодро отвечать, а неверный ответ обнаруживается через сутки или через претензию. Именно поэтому в проекте появляются строки, которые на первый взгляд кажутся необязательными, — журнал, выборочный контроль, приёмочные тесты. Они не улучшают систему, они делают её отказы видимыми.
Блок 1. Модель — самая заменяемая и самая дешёвая часть
Модель отвечает за две вещи: понять произвольный текст и сформулировать ответ. Это ровно та часть, которую нельзя сделать без неё и которую можно поменять на другую за один-два дня работы, если система спроектирована аккуратно. По состоянию на сентябрь 2026 для российской компании реалистичный выбор такой: GigaChat 3 в вариантах Lite, Pro и Max и GigaChat 3.1 Ultra, корпоративная платформа GigaChat Enterprise с вариантами размещения в облаке, на своём железе и в гибриде; YandexGPT 5 и связанные с ним сервисы Yandex AI Studio; T-Lite и T-Pro от Т-Банка; Cotype Pro от МТС. Отдельная ветка — открытые модели на своём сервере: Qwen 3, Llama 4, DeepSeek-R1 и V3.2, Mistral, разворачиваемые обычно через Ollama.
Про OpenAI и Anthropic придётся сказать прямо, потому что их продолжают закладывать в проекты. Прямая оплата из России невозможна, страна не входит в список поддерживаемых для их API, и доступ идёт через рублёвые прокси и агрегаторов. Для бизнес-процесса, от которого зависят продажи, это не инструмент, а риск: посредник может пропасть, тарифы меняются в одностороннем порядке, а вопрос о том, где физически обрабатываются персональные данные клиентов, остаётся открытым. Мы исходим из того, что зарубежная модель может быть в проекте как запасной вариант для редких сложных запросов на обезличенных данных, но не как опора.
Практический вывод для сметы: строка «модель» должна быть маленькой, а рядом с ней должна стоять фраза про слой абстракции. Стоимость подключения и настройки промптов в проекте на 300 000 ₽ — около 30 000 ₽. Стоимость вызовов в эксплуатации на нашем примере с 2 600 обращений — примерно 15 600 ₽ в месяц при 6 ₽ на диалог. Если подрядчик утверждает, что выбор модели — главное решение проекта, попросите его назвать, сколько будет стоить переезд на другую модель через год. Правильный ответ измеряется днями.
Прослойка в коде, через которую система обращается к модели, не зная, какая именно модель отвечает. Позволяет сменить провайдера, добавить запасную модель на случай сбоя и увести чувствительные запросы на локальную модель, не переписывая логику. Что спросить у подрядчика: «покажите, в скольких местах кода у вас упоминается конкретный провайдер модели».
Блок 2. База знаний и поиск — здесь живёт правда
Модель не знает ваш прайс, ваши сроки поставки и ваш регламент возврата. Чтобы она отвечала не общими фразами, а вашими фактами, перед каждым ответом система ищет в ваших документах подходящие фрагменты и подставляет их в запрос вместе с инструкцией «отвечать строго по этому». Этот механизм называется RAG; мы разобрали его отдельно и по шагам в материале «RAG простыми словами», включая то, почему в 8 случаях из 10 виноват именно поиск, а не модель. Здесь важна одна вещь для сметы: это самый трудоёмкий блок из пяти.
Трудоёмкость берётся не из технологии, а из состояния документов. Регламент, написанный в 2019 году и с тех пор трижды исправленный в переписке, надо привести к одной версии. Прайс в четырёх файлах с разными названиями одних и тех же позиций — свести. Инструкции, которые существуют только в голове старшего менеджера, — записать. В нашем примере это 60 000 ₽ на сбор, чистку и нарезку базы плюс 45 000 ₽ на индексацию, настройку поиска и замер качества на контрольном наборе вопросов. Вместе — треть проекта, и это самая честная треть: она остаётся вашей независимо от того, какой агент работает поверх.
Готовность базы к работе проверяется одним упражнением, и сделать его можно до подписания договора. Возьмите двадцать реальных вопросов, которые ваши сотрудники задавали за последнюю неделю, и для каждого найдите руками документ и пункт с правильным ответом. Если на пять из двадцати ответа в документах нет вообще, а ещё на три нашлось два противоречащих друг другу, вы уже знаете, из чего будет состоять первый этап проекта и почему он стоит денег. Обратный случай тоже бывает: если все двадцать ответов нашлись за полчаса и лежат в одном упорядоченном разделе, база у вас в порядке, и подрядчик обязан снизить эту строку сметы.
Каждый ответ агента обязан сопровождаться указанием, из какого документа и какого его фрагмента он собран. Без этого сотрудник не может проверить ответ, а спор с клиентом не разбирается: вы не докажете ни что система ответила верно, ни что она ошиблась. Это требование к приёмке, а не пожелание: если в демонстрации ссылок нет, спросите, почему.
Блок 3. Память: короткая, длинная и 152-ФЗ
Память бывает двух видов, и путать их дорого. Короткая живёт в пределах одного диалога: она помнит, что клиент уже назвал номер заказа, что агент уже предложил замену и что от неё отказались. Технически это несколько последних сообщений плюс краткая выжимка, хранится обычно в быстром хранилище вроде Redis и стирается через несколько часов. Длинная память живёт между диалогами: она помнит, что этот клиент год назад жаловался на срыв срока, обычно берёт позиции определённой марки и работает по постоплате.
Две колонки: «Короткая память (контекст диалога)» и «Длинная память (профиль клиента)». Пять строк сравнения: «Что хранит» — последние сообщения и выжимка / историю обращений, предпочтения, жалобы; «Сколько живёт» — часы / месяцы и годы; «Где лежит» — быстрое хранилище рядом с приложением / база данных компании; «Персональные данные» — как правило нет / да; «Что нужно по 152-ФЗ» — ничего особенного / хранение в РФ, согласие, срок, поручение обработки подрядчику. Нижняя строка выделена рамкой.
Длинная память — это персональные данные почти всегда: имя, телефон, история покупок, содержание жалоб. Отсюда четыре требования, которые должны быть в договоре, а не подразумеваться: базы физически размещены в России; есть основание обработки и согласие там, где оно нужно; определён срок хранения и механизм удаления; отношения с подрядчиком оформлены поручением обработки. С 1 сентября 2026 года действует регулирование в области ИИ, включающее требования к обработке персональных данных в таких системах и маркировку ИИ-контента, поэтому компании имеет смысл завести внутреннюю политику использования ИИ — короткий документ на две страницы, который отвечает, какие данные можно передавать модели, а какие нет.
Полезно понимать, как долгая память выглядит в работе, потому что её обычно представляют себе слишком широко. Это не «агент знает о клиенте всё», а короткая карточка на 5–10 фактов, которую система дописывает после каждого диалога: обычный способ оплаты, привычная марка, был ли конфликт и по какому поводу, какие позиции возвращались. Именно карточка, а не архив переписки: полный текст прошлых диалогов в запрос всё равно не помещается, а хранить его без нужды — лишний риск. Практический признак хорошо спроектированной длинной памяти — вы можете открыть её и прочитать глазами за минуту, и там нет ничего, чего вы не смогли бы объяснить клиенту, если он спросит, что о нём записано.
Практический совет по бюджету: длинную память часто закладывают «на будущее», а пользуются ей единицы сценариев. Прежде чем платить за блок, назовите три конкретных случая, в которых агент поведёт себя иначе, зная историю клиента. Если случаев не нашлось, начните без длинной памяти — добавить её позже дешевле, чем год хранить чужие персональные данные без нужды.
Блок 4. Инструменты: «рассказал» против «сделал»
Инструмент — это разрешённое действие агента во внешней системе. Именно этот блок отделяет агента от чат-бота и именно он определяет большую часть цены. Разница между тремя уровнями выглядит в диалоге как мелочь, а в смете — как двукратный разрыв.
Описанная и ограниченная операция, которую агент может выполнить сам: «получить статус заказа по номеру», «создать сделку», «перенести запись», «отправить счёт». У каждого инструмента есть права, лимиты и запись в журнал. Что спросить у подрядчика: «дайте полный список инструментов агента с лимитом по каждому и укажите, какие из них меняют данные».
| Уровень | Как выглядит в диалоге | Что нужно технически | Цена сверх базового | Срок |
|---|---|---|---|---|
| Рассказал по регламенту | «Возврат оформляется за 3 рабочих дня, нужен акт и накладная» | Только база знаний и поиск | входит в базовый проект | — |
| Посмотрел ваши данные | «Ваш заказ 12 345 отгружен вчера, машина в пути, ориентир — четверг» | Сервисный доступ на чтение к 1С:УТ и Битрикс24, обработка недоступности систем | 60 000–120 000 ₽ | 1–2 недели |
| Сделал за клиента | «Оформил возврат, номер обращения 8842, акт отправил на почту» | Права на запись, лимиты, откат неудачного действия, журнал, отдельная приёмка | 150 000–250 000 ₽ | 3–5 недель |
Технически прыжок с третьей строки на вторую невелик — те же методы API, только другие. Дорожает не код, а всё вокруг него. Появляется вопрос прав: агент не должен ходить под учётной записью директора, ему нужна отдельная служебная запись с минимально необходимым набором операций. Появляется вопрос отката: если агент создал заказ, а 1С не подтвердила проведение, кто-то должен убрать полузаписанный документ. Появляется вопрос лимитов: не больше одного возврата на диалог, не дороже установленной суммы, не больше определённого числа действий в сутки. И появляется отдельная приёмка на поведение при отказе чужой системы — что агент скажет клиенту, когда 1С недоступна.
Карта связей. В центре узел «Агент». Слева каналы: «MAX», «Почта», «Телефония Mango Office». Справа три системы: «Битрикс24», «1С:УТ», «Хранилище базы знаний». Связи подписаны тем, что передаётся и в какую сторону: к Битрикс24 — «чтение: карточка клиента, история» и «запись: создать сделку, добавить комментарий (лимит 1 сделка на диалог)»; к 1С:УТ — «чтение: статус заказа, остаток, цена» и пунктирная связь «запись: заблокировано»; к базе знаний — «чтение: фрагменты регламентов». Внизу узел «Журнал действий», к нему стрелки от всех связей с подписью «каждое действие».
Обратите внимание на пунктир к 1С на схеме. Разумная стартовая конфигурация для оптовой компании — читать из учётной системы всё, а писать в неё ничего: заявку агент создаёт в CRM, а её проведение в 1С делает человек. Это снимает большую часть рисков и половину срока проекта, а снятая с людей работа почти не уменьшается: клиенту в 95 % случаев нужен ответ, а не проводка. Право на запись в учётную систему имеет смысл открывать вторым этапом, когда журнал за пару месяцев показал, что агент действительно понимает происходящее.
Блок 5. Правила и стоп-темы — отдельный документ, а не строчка в промпте
Правила — единственный блок, который целиком принадлежит вам и который вы должны уметь прочитать без подрядчика. Это перечень тем, где генерация выключается и диалог принудительно уходит человеку, плюс лимиты на действия, плюс список того, что агенту запрещено обещать. Ключевое инженерное требование: проверка живёт в коде до генерации, а не внутри текста промпта. Просьбу, написанную в промпте, модель может проигнорировать под давлением необычной формулировки клиента; отдельный классификатор и словарь триггерных фраз проигнорировать нельзя.
Тема, при распознавании которой агент прекращает отвечать сам и передаёт диалог человеку с пометкой причины. Обязательный минимум: возврат денег, жалоба и претензия, вопросы здоровья, любые персональные данные третьих лиц, угрозы и конфликт, прямая просьба позвать сотрудника. Что спросить у подрядчика: «покажите список стоп-тем и место в коде, где он проверяется до вызова модели».
Линейная схема слева направо. «Сообщение клиента» → ромб «Стоп-тема?» (ветка «да» уходит вниз в блок «Оператор, причина зафиксирована») → ромб «Есть ответ в базе знаний?» (ветка «нет» уходит вниз в тот же блок «Оператор») → ромб «Действие в пределах лимита?» (ветка «нет» — вниз в «Оператор») → блок «Вызов модели» → блок «Ответ со ссылкой на источник» → блок «Запись в журнал». Подпись под схемой: «все три проверки выполняются в коде до вызова модели».
- Список стоп-тем — 6–12 пунктов, каждый с примером фразы клиента, по которой он срабатывает. Хранится в вашем документе, меняется без релиза системы.
- Лимиты на действия: максимальная сумма операции, число изменяющих действий на диалог, суточный предел. По умолчанию — самые узкие значения, расширять по журналу.
- Запреты на обещания: сроки поставки вне тех, что подтверждает 1С; скидки; гарантийные обязательства; любые формулировки о качестве товара третьих лиц.
- Правило неопределённости: если подходящих фрагментов в базе не нашлось, агент говорит, что уточнит, и передаёт вопрос человеку. Ответ «не знаю» — целевое поведение, а не дефект.
- Порог эскалации по эмоции: два подряд негативных сообщения клиента — принудительный перевод на человека независимо от темы.
Разбор сметы: куда уходят 300 000 ₽
Соберём всё вместе на нашем примере. Проект для оптовой компании: агент в MAX и на почте, отвечает по прайсу и регламентам, смотрит статус заказа в 1С:УТ на чтение, создаёт заявку в Битрикс24, стоп-темы и лимиты настроены, журнал ведётся. Срок — 6 недель, бюджет — 300 000 ₽. Вот как эта сумма распадается по блокам.
Горизонтальная столбчатая диаграмма долей бюджета, отсортированная по убыванию. Шесть полос с подписями и суммами: «Инструменты и коннекторы» 75 000 ₽ (25 %), «База знаний» 60 000 ₽ (20 %), «Поиск и хранилище» 45 000 ₽ (15 %), «Разбор процесса и приёмка» 45 000 ₽ (15 %), «Правила, лимиты, журнал» 45 000 ₽ (15 %), «Модель» 30 000 ₽ (10 %). Полоса «Модель» выделена другим цветом. Общий итог подписан: 300 000 ₽, срок 6 недель.
К этому добавляется эксплуатация, которую в смету обычно не кладут, а зря. На нашем потоке 2 600 обращений в месяц она складывается так: вызовы модели около 15 600 ₽, хранилище и переиндексация 7 000 ₽, сервер с журналами 10 000 ₽, выборочный контроль 5 % диалогов — примерно 6 100 ₽, ведение базы знаний 8 часов работы — 7 200 ₽, сопровождение подрядчиком 25 000 ₽. Итого около 70 900 ₽ в месяц, или 850 000 ₽ за год — почти втрое больше внедрения. Считать проект по цене внедрения, не глядя на эту цифру, — самая частая ошибка в переговорах.
Те же пять блоков определяют и календарь проекта, и это второй способ проверить смету на вменяемость. Если подрядчик обещает собрать всё за две недели, значит, какой-то блок он собирается пропустить — почти всегда это подготовка базы знаний или приёмочные тесты. Правильный график устроен так, что заказчик получает проверяемый результат в конце каждой недели, а не одну демонстрацию в конце проекта. Проверяемый — значит такой, который можно принять или не принять по заранее названному признаку: список документов в действующей редакции, работающий поиск, ответы со ссылкой на источник, журнал с записями.
Лента времени на 6 недель, шесть отрезков. Сверху — какой блок собирается, снизу — что принимает заказчик. Неделя 1 «Разбор процесса и сценарии» → «карта обращений и набор приёмочных сценариев». Неделя 2 «База знаний: сбор и чистка» → «прайс и регламенты в одной действующей редакции». Неделя 3 «Поиск и хранилище» → «поиск находит нужный документ на контрольных вопросах». Неделя 4 «Инструменты: коннекторы к Битрикс24 и 1С:УТ» → «агент видит статус заказа и создаёт заявку». Неделя 5 «Правила, стоп-темы, лимиты, журнал» → «список стоп-тем работает, действия пишутся в журнал». Неделя 6 «Модель, промпты, приёмка» → «протокол приёмки по сценариям». Справа итог: 300 000 ₽, 6 недель.
Журнал: то, чего нет в презентациях
Шестого блока в списке нет, потому что он не участвует в работе агента, — но без него систему невозможно эксплуатировать. Журнал фиксирует каждое обращение и каждое действие: что спросил клиент, какие фрагменты нашёл поиск, что ответила модель, какой инструмент был вызван и с каким результатом, сработало ли правило, сколько стоил вызов. Через месяц эксплуатации журнал становится главным источником решений: по нему видно, какие вопросы система не закрывает, где база знаний пуста и какие лимиты пора расширить.
Нарисованный абстрактный экран журнала, не скриншот реального продукта. Верхняя полоса — фильтры: «дата», «канал», «сработало правило», «переведено на человека». Таблица из шести колонок с подписями: «Время», «Вопрос клиента», «Найденные источники (документ и фрагмент)», «Ответ», «Вызванные инструменты и результат», «Стоимость вызова». Одна строка выделена и раскрыта карточкой сбоку с подписями «причина перевода на человека: стоп-тема «возврат денег»» и «версия правил: 12». Справа сводка: «за неделю: 640 диалогов, 71 % закрыто без человека, 4 % без источника».
Три метрики из журнала стоит смотреть каждую неделю первые три месяца. Доля ответов без ссылки на источник — она должна стремиться к нулю, рост означает, что агент начал сочинять. Доля переводов на человека — нормальные 10–20 % в начале снижаются за счёт пополнения базы знаний, а не за счёт ослабления правил. Доля повторных обращений по тому же вопросу в течение суток — прямой показатель того, что ответ формально дан, а задача клиента не решена.
Девять вопросов подрядчику до подписания
Эти вопросы стоит задать письменно и получить письменные ответы — они же становятся основой технического задания. Ни один из них не требует технической подготовки, но каждый закрывает конкретный риск из разобранных выше. Смежные формулировки для самого договора мы собрали в отдельном материале о том, что должно быть в договоре на разработку.
- 1Какая модель используется, где она физически работает и сколько стоит переезд на другую? Ответ «за пару дней, у нас слой абстракции» — здоровый. Ответ «мы работаем только с одной» — риск.
- 2Откуда агент берёт факты и будет ли в каждом ответе ссылка на документ и фрагмент? Если ссылок нет, проверить ответ нельзя ни вам, ни вашему сотруднику.
- 3Кто приводит базу знаний в порядок, сколько это стоит и в какой строке сметы лежит? Это 20 % бюджета, и она не должна тихо перекочевать на ваших людей.
- 4Что агент помнит между диалогами, где это хранится и как оформлено по 152-ФЗ? Нужны ответы про размещение баз в России, срок хранения и поручение обработки.
- 5Полный список инструментов: что читает и что имеет право менять, с лимитом по каждому. Список должен быть в приложении к договору, а не в переписке.
- 6Что происходит при отказе 1С, CRM или телефонии — что агент скажет клиенту и что запишет в журнал? Отсутствие ответа означает, что этот случай не проектировали.
- 7Где список стоп-тем и в каком месте он проверяется — до вызова модели или внутри промпта? Правильный ответ только один.
- 8Как выглядит приёмка: какой набор сценариев, сколько вопросов с эталонными ответами, какой порог считается сдачей? «Покажем демонстрацию» приёмкой не является.
- 9Сколько стоит эксплуатация в месяц по шести строкам — модель, хранилище, сервер, контроль, ведение базы, сопровождение? Сумма за год обычно больше внедрения, и это надо увидеть до подписания.
Когда пять блоков не нужны
Схема из пяти блоков выглядит внушительно, и это её недостаток: она провоцирует строить всё сразу. В большинстве обращений, которые к нам приходят, задача закрывается одним-двумя блоками или вовсе без них. Ниже — случаи, где мы сами отговариваем от полной сборки.
- Нужен только ответ по документам, без действий в системах. Тогда блока «инструменты» нет вовсе, проект превращается в поиск по базе знаний за 150 000–200 000 ₽ вместо 300 000 ₽ и собирается за 3–8 недель.
- Вопросов много, но они одинаковые. Двадцать типовых вопросов закрываются кнопочным меню за 30 000–120 000 ₽, и это не хуже, а лучше: ответ воспроизводим, проверять нечего, счёта за токены нет.
- Решение принимается по правилу, которое можно записать в три строки. «Заявка дороже 300 000 ₽ — руководителю, из региона — региональному менеджеру, остальные — по кругу» пишется в CRM за час и работает без всякой модели.
- База знаний — двадцать страниц, и они не меняются. Поиск здесь избыточен: проще подставить весь текст в запрос целиком, это дешевле и точнее.
- Документы противоречат друг другу, и никто не знает, какая версия действует. Пока это так, любой агент будет уверенно цитировать неправильный регламент. Сначала наведение порядка в данных, потом внедрение.
- Процесс не описан и держится на двух опытных сотрудниках. Агент зафиксирует их случайную практику и разгонит её. Сначала регламент — иначе получится дорогая автоматизация неизвестно чего.
Разумный порядок сборки для тех, кому агент всё-таки нужен, обратный привычному: сначала база знаний с поиском и ответами со ссылкой на источник, потом чтение данных из учётной системы, и только третьим шагом — право что-то менять. Каждый шаг даёт измеримый результат сам по себе и не требует следующего. Если первый шаг не дал ожидаемой доли закрытых обращений, второй и третий не спасут — они добавят возможностей, но не изменят того, что у системы нет верных фактов.
Итог одной строкой: когда в следующий раз увидите в смете строку «разработка ИИ-агента», попросите разложить её на пять частей и назвать долю каждой. Если доля модели больше четверти, вам продают не систему, а подключение к чужому сервису. Если в смете нет строк про базу знаний, коннекторы и правила, эти работы никуда не делись — их просто выполнят ваши сотрудники, бесплатно и в свободное время, которого у них нет.
